Red Hat OpenShift 主要元件

請檢視叢 Red Hat OpenShift on IBM Cloud 集中的 -managed IBM 主節點中的下列元件。

您無法修改這些元件。 IBM 會管理元件，並在主要修補程式更新期間自動更新它們。

在 OpenShift Container Platform 4 中，有許多元件是由對應的操作器所配置，以方便管理。 下表一起討論這些運算子及元件，以聚焦於元件提供給叢集的主要功能。

單一承租戶

主要元件及所有主要元件僅供您專用，不會與其他 IBM 客戶共用。

抄本

主元件（包括 Red Hat OpenShift API 伺服器及 etcd 資料儲存庫）各有三個副本；若位於多區域都會區內，則會分散配置於各區域，以實現更高的可用性。

cloud-controller-manager

雲端控制器管理程式管理雲端提供者特定的元件，例如 IBM Cloud 負載平衡器。

cluster-health

叢集性能元件會監視叢集的性能，並與服務的 IBM Cloud 監視及度量整合。

cluster-policy-controller

cluster-policy-controller 會維護在叢集內建立 Pod 所需的原則資源。

cluster-version-operator

叢集版本操作器 (CVO) 會安裝並更新在叢集中執行的其他操作器。 如需相關資訊，請參閱 GitHub 專案。

control-plane-operator

控制平面操作員管理主要中控制平面元件的安裝及更新。

etcd, etcd-molecule, etcd-operator

etcd 是高度可用的鍵值儲存庫，其中儲存叢集的所有 Kubernetes 資源（例如服務、部署及 Pod）的狀況。 etcd 中的資料每 8 小時會備份一次至由 IBM 管理的加密儲存實例中。

kube-controller-manager, openshift-controller-manager

Kubernetes 控制器 會監看叢集內物件的狀態，例如工作量的抄本集。 當物件的狀態發生變化時（例如，複製集中的某個 Pod 發生故障），控制器管理員會啟動矯正措施，以恢復至所需的狀態。 Red Hat OpenShift 控制器會對 Red Hat OpenShift API 特有的物件 (例如專案) 執行相同的功能。

kube-scheduler

Kubernetes 排程器會監控新建立的 Pod，並根據容量、效能需求、政策限制、反親和性規範以及工作負載需求，決定將其部署至何處。 如果找不到符合需求的工作者節點，則不會在叢集裡部署 Pod。

manifests-bootstrapper

manifests-boot-strapper 工作會設定具有必要憑證的主要節點，以加入作為叢集的主要節點。

oauth-openshift

內建的 OAuth 伺服器會自動設定與 IBM Cloud Identity and Access Management (IAM) 整合。 您無法將其他支援的身分提供者新增至叢集。 如需有關如何透過 IAM 與群集進行驗證的詳細資訊，請參閱 存取 Red Hat OpenShift 群集。

openshift-apiserver, openshift-apiserver-operator, kube-apiserver

API 伺服器是所有從工作節點發送至主節點的叢集管理請求的主要入口點。 API 伺服器會驗證並處理變更 Kubernetes 物件 (例如 Pod 或服務) 及 Red Hat OpenShift 物件 (例如專案或使用者) 的狀態的要求。 然後，API 伺服器會將此狀態儲存在 etcd 資料儲存庫中。

konnectivity-server, konnectivity-operator

Konnectivity 伺服器會與 Konnectivity 代理程式協同運作，以安全的方式將主節點與工作節點連接起來。 此連線支援對您的 Pod 和服務發起的 apiserver proxy 呼叫；對 kubelet 發起的 oc exec、attach 及 logs 呼叫；以及具有變更與驗證功能的 Webhook。

許可控制器

在 Red Hat OpenShift on IBM Cloud 叢集中，針對特定功能實作了存取控制程式。 使用許可控制器，您可以在叢集裡設定原則，以判定是否允許叢集裡的特定動作。 在該政策中，您可以指定在哪些情況下使用者無法執行某項操作，即使該操作屬於您透過 RBAC 指派給該使用者的一般權限範圍內。 因此，在 API 請求由 Red Hat OpenShift API 伺服器處理之前，存取控制器可為您的叢集提供額外的安全防護層。 當您建立 Red Hat OpenShift 叢集時，下列 Kubernetes 許可控制器 會以給定順序自動安裝在 Red Hat OpenShift 主節點中，使用者無法變更這些主節點:

• NamespaceLifecycle
• LimitRanger
• ServiceAccount
• DefaultStorageClass
• ResourceQuota
• StorageObjectInUseProtection
• PersistentVolumeClaimResize
• Priority
• BuildByStrategy
• OriginPodNodeEnvironment
• PodNodeSelector
• ExternalIPRanger
• NodeRestriction
• SecurityContextConstraint
• SCCExecRestrictions
• PersistentVolumeLabel
• OwnerReferencesPermissionEnforcement
• PodTolerationRestriction
• openshift.io/JenkinsBootstrapper
• openshift.io/BuildConfigSecretInjector
• openshift.io/ImageLimitRange
• openshift.io/RestrictedEndpointsAdmission
• openshift.io/ImagePolicy
• openshift.io/IngressAdmission
• openshift.io/ClusterResourceQuota
• MutatingAdmissionWebhook
• ValidatingAdmissionWebhook

您可以在 叢集中安裝自訂的准入控制器，或從 Red Hat OpenShift on IBM Cloud 提供的可選准入控制器中進行選擇。 強制執行容器映像檔安全: 安裝 Portieris 以封鎖來自未簽署映像檔的容器部署。

如果您是手動安裝了存取控制器，且不再需要使用它們，請務必將其完全移除。 若未完全移除存取控制器，它們可能會阻擋您想在叢集上執行的所有操作。

Red Hat OpenShift 工作節點元件

請檢查 Red Hat OpenShift on IBM Cloud 叢集內客戶端管理的工件節點中的下列元件。

這些元件在工作者節點上執行，因為您可以將它們與部署至叢集的工作負載搭配使用。 例如，您的應用程式可能使用 OperatorHub 中的操作器，該操作器會從內部登錄中的映像檔執行容器。 您負責使用這些元件，但 IBM 會在您選擇套用的工作者節點修補程式更新中為它們提供更新項目。

在 OpenShift Container Platform中，對應的操作器會配置許多元件，以方便管理。 下表一起討論這些運算子及元件，以聚焦於元件提供給叢集的主要功能。

單一承租戶

工作節點和所有工作節點元件僅供您專用，不與其他人共用IBM顧客。 但是，如果您使用工作節點虛擬機，則底層硬體可能會與其他節點共用IBM客戶，取決於您選擇的硬體隔離等級。

作業系統

如需依叢集版本列出的受支援作業系統清單，請參閱 版本資訊。

CRI-O 儲存器執行時期

您的工作者節點會以 CRI-O 作為容器執行時期介面來安裝。 如需相關資訊，請參閱 儲存器執行時期。

專案

Red Hat OpenShift 將您的資源整理成專案，這些專案是帶有註解的 Kubernetes 命名空間，並包含比社群版 Kubernetes 叢集更多的元件，用以執行 Red Hat OpenShift 中的各項功能，例如目錄。 選取的專案元件將在下列各行中說明。 如需詳細資訊，請參閱執行 專案。

calico-system, tigera-operator

Calico 負責管理您的叢集的網路政策，並包含若干元件，用於管理容器網路連線、IP 位址指派以及網路流量控制。 Tigera 操作器會安裝及管理 Calico 元件的生命週期。

default

若您未指定專案，或未為您的 Kubernetes 資源建立專案，則會使用此專案。

ibm-system

此專案包含 ibm-cloud-provider-ip 的部署，該部署與 keepalived 協同運作，為發送至應用程式 Pod 的請求提供狀態檢查及第 4 層負載平衡功能。

kube-system

此專案包含許多元件，用於在工作節點上執行 Kubernetes。

• ibm-master-proxy: ibm-master-proxy 是一個守護程序集，負責將來自工作節點的請求轉發至高可用性主副本的 IP 位址。 在單一區域叢集裡，主節點有三個抄本，每個抄本位於個別的主機上。 對於具有多區域功能之區域中的叢集，主節點具有三個分散在各區域之中的抄本。 高可用性負載平衡器會將向主節點網域名稱發出的要求轉遞到主節點抄本。
• kubelet: kubelet 是一種工作節點代理程式，運行於每個工作節點上，負責監控運行於該工作節點上的 Pod 的健康狀態，並監聽 API 伺服器發送的事件。 根據這些事件，kubelet 會建立或移除 Pod，確保存活探測與就緒探測正常運作，並將 Pod 的狀態回報給 API 伺服器。
• vpn: Konnectivity 代理程式會與 Konnectivity 伺服器協同運作，以安全的方式將主節點與工作節點連接起來。 此連線支援對 Pod 及服務的 apiserver proxy 呼叫，以及對 kubelet 的 oc exec、attach 及 logs 呼叫。
• 其他元件：kube-system 專案還包含用於管理 IBM 所提供的資源的元件，例如用於檔案儲存和區塊儲存的儲存外掛程式、入站應用程式負載平衡器 (ALB) 以及 keepalived。

openshift-cloud-credential-operator

雲端認證操作員管理要求雲端提供者認證之 Red Hat OpenShift 元件的控制器。 控制器可確保只使用作業所需的認證，而不使用任何提升的許可權，例如 admin。 如需相關資訊，請參閱 GitHub 專案。

openshift-cluster-node-tuning-operator

IBM 會管理 節點調整操作器，該操作器會在叢集裡的每一個工作者節點上執行常駐程式集，以調整工作者節點。

openshift-cluster-samples-operator

依預設，samples 操作器 會管理 Red Hat OpenShift 叢集隨附的選取映像檔串流和範本。 您可以從 Red Hat OpenShift Web 主控台中的 開發人員 視景 部署這些範本。

openshift-cluster-storage-operator

叢集儲存體操作器可確保已設定預設儲存類別。

openshift-console, openshift-console-operator

Red Hat OpenShift Web 主控台是基於 Web 的介面，您可以使用它來管理在群集中執行的 Red Hat OpenShift 和 Kubernetes 資源。 您也可以使用主控台來顯示 oc login 記號，以從 CLI 向叢集進行鑑別。 如需相關資訊，請參閱導覽 Red Hat OpenShift 主控台。

openshift-dns, openshift-dns-operator

DNS 專案包含用於依據工作節點上設定的 iptables 規則，對傳入的網路流量進行驗證的元件，並作為代理伺服器處理獲准進入或離開叢集的請求。

openshift-image-registry

Red Hat OpenShift 提供內部 容器映像檔登錄，可用來透過主控台在本端管理及檢視映像檔。 或者，您可以 設定專用 IBM Cloud Container Registry 或 將映像檔從 IBM Cloud Container Registry 匯入至內部登錄。 內部登錄隨附 IBM Cloud 基礎架構帳戶中的 File Storage for Classic 磁區，以 儲存登錄映像檔。 檔案儲存空間磁區是透過 image-registry-storage 持續性磁區要求 (PVC) 來佈建。

openshift-ingress, openshift-ingress-operator

Red Hat OpenShift 使用 路由將應用程式的服務直接暴露在主機名稱上，以便外部用戶端可以存取服務。 若要建立路徑，叢集會使用 Ingress 操作器。 您也可以使用 Ingress，在外部公開應用程式並自訂遞送。 Ingress 由三個元件組成 :Ingress 運算子、Ingress 控制器及 Route 資源。 Ingress 控制器會將服務與主機名稱進行對應。 預設情況下，Ingress 控制器包含兩個複本。 請確保您的叢集至少有兩個工作節點，以便 Ingress 控制器能在不同的運算主機上運行，從而提高可用性。

openshift-marketplace

依預設，市場包括 Red Hat OpenShift 叢集隨附的 OperatorHub。 OperatorHub 包括來自 Red Hat 和第三方供應商的操作員。 請記住，這些操作員是由社群提供的，可能無法與您的群集整合，也不受 IBM 的支援。 您可以從 Red Hat OpenShift 網頁主控台的 OperatorHub 啟用操作員。

openshift-monitoring

OpenShift Container Platform 包括叢集的 內建監視堆疊，其中包括度量值和警示管理功能。 如需內建監視堆疊與其他選項 (例如 IBM Cloud Monitoring) 的比較，請參閱 瞭解用於記載及監視的選項。

openshift-multus

OpenShift Container Platform 使用 Multus 容器網路介面 (CNI) 外掛程式來容許 多個 Pod 網路。 不過，您無法將叢集配置為使用多個 Pod 網路。Red Hat OpenShift on IBM Cloud 叢集僅支援依預設為叢集設定的 Calico。 如果已啟用，服務網格 會使用 Multus 外掛程式。

openshift-network-operator

叢集網路操作員(CNO) 會管理依預設設定的叢集網路元件，例如 CNI Pod 網路提供者外掛程式及 DNS 操作員。

openshift-operator-lifecycle-manager

操作器生命週期管理程式(OLM) 可管理叢集中執行之所有操作器及型錄的生命週期，包括預設元件及您新增之任何自訂操作器的操作器。

openshift-service-ca, openshift-service-ca-operator

憑證管理中心 (CA) 操作員執行憑證簽署，並將憑證注入叢集中的 API 伺服器資源及 configmap。 如需相關資訊，請參閱 GitHub 專案。

具有公用和專用雲端服務端點的叢集

下圖顯示叢集的元件，以及在同時啟用 公用和專用雲端服務端點 時如何互動。 因為兩個服務端點都已啟用，所以 VPC 會為每個服務建立一個公用負載平衡器，以用於入埠資料流量。

僅具有專用雲端服務端點的叢集

下圖顯示叢集的元件，以及在僅啟用 專用雲端服務端點 時它們如何互動。 因為僅啟用專用雲端服務端點，所以您的 VPC 會針對入埠資料流量的每一個服務建立專用負載平衡器。

VPC 主節點和工作者節點元件

主要 及 工作者節點 包含叢集的標準叢集架構中所述的相同元件。 有關此架構 OpenShift Container Platform 的更多資訊，請參閱 文件 Red Hat OpenShift。

Master

主節點元件（包括 API 伺服器和 etcd）有三個抄本，可跨區域分佈，以實現更高可用性。 主節點包含叢集的標準叢集架構中說明的相同元件。 主節點及所有主節點元件僅供您專用，不會與其他 IBM 客戶共用。

工作者節點

使用 Red Hat OpenShift on IBM Cloud 時，叢集管理的虛擬機器是稱為工作者節點的實例。 這些工作節點虛擬機器和所有工作節點元件僅供您專用，不與其他人共用IBM顧客。 然而，底層硬體是與其他共享的IBM顧客。 您可以透過以下提供的自動化工具來管理工作節點Red Hat OpenShift on IBM Cloud，例如 API、CLI 或控制台。 與傳統叢集不同，您不會在基礎架構入口網站或獨立的基礎架構帳單中看到 VPC 運算工作節點，而是透過 Red Hat OpenShift on IBM Cloud 來管理所有與工作節點相關的維護及計費作業。

工作節點包含與「經典叢集架構」中所述相同的 組件。

當您執行 oc get nodes 時，可能會注意到工作者節點的 ROLES 同時標示為 master,worker。 這些節點是 IBM Cloud 中的工作節點，並不包含由 IBM 所管理的主節點元件。 相反地，這些節點被標記為「master」，因為它們執行 OpenShift Container Platform 元件，這些元件是設定和管理叢集內預設資源（例如 OperatorHub 和內部註冊表）所必需的。

叢集網路

工作者節點在指定區域中的 VPC 子網路中進行建立。 主節點與工作者節點之間的通訊在專用網路上執行。 如果您建立已啟用公用及專用雲端服務端點的叢集，則已鑑別外部使用者可以透過公用網路與主節點通訊，例如執行 oc 指令。 如果您建立只啟用專用雲端服務端點的叢集，則已鑑別的外部使用者只能透過專用網路與主節點進行通訊。 您可以透過在專用網路上設定 VPC VPN、IBM Cloud Direct Link或 IBM Cloud Transit Gateway，來設定叢集以與內部部署網路、其他 VPC 或標準基礎架構中的資源進行通訊。

應用程式網路

針對您在叢集裡建立的任何網路服務，會在叢集外部的 VPC 中自動建立 Virtual Private Cloud 負載平衡器。 例如，依預設，VPC 負載平衡器會在叢集裡公開路由器服務。 或者，您可以為應用程式建立 Kubernetes LoadBalancer 服務，並自動產生 VPC 負載平衡器。 VPC 負載平衡器是應用程式的多區域，並透過在工作者節點上自動開啟的專用節點埠來遞送應用程式的要求。 如果已啟用公用及專用雲端服務端點，則依預設會將路由器及 VPC 負載平衡器建立為公用。 如果僅啟用專用雲端服務端點，則依預設會將路由器和 VPC 負載平衡器建立為專用。 如需相關資訊，請參閱 VPC 叢集的公用 或 專用應用程式網路。 Calico 用作叢集網路原則光纖。

儲存空間

您只能設定 IBM Cloud Object Storage 和 Cloud Databases。