IBM Cloud Docs
服務的架構及相依關係

服務的架構及相依關係

檢閱 Red Hat® OpenShift® on IBM Cloud® 叢集的範例架構、元件及相依關係。

在 Red Hat OpenShift on IBM Cloud中,您的叢集包含 IBM管理的主節點,可保護元件 (例如 API 伺服器和 etcd),以及您配置以執行應用程式工作量的客戶管理工作者節點,以及 Red Hat OpenShift提供的預設元件。 集群內的預設組件,例如Red Hat OpenShift網路控制台或OperatorHub,隨Red Hat OpenShift您的集群的版本。

典型 Red Hat OpenShift 架構

檢閱架構圖,然後捲動下列表格,以取得在標準基礎架構上執行之 Red Hat OpenShift on IBM Cloud 叢集中主要節點及工作者節點元件的說明。 有關 OpenShift Container Platform 架構的詳細資訊,請參閱 Red Hat OpenShift docs

當您執行 oc get nodes 時,可能會注意到工作者節點的 ROLES 同時標示為 master,worker。 這些節點是 IBM Cloud中的工作者節點,不包括 IBM所管理的主要元件。 相反地,這些節點會標示為 master,因為它們會執行在叢集內設定及管理預設資源 (例如 OperatorHub 及內部登錄) 所需的 OpenShift Container Platform 元件。

Red Hat OpenShift on IBM Cloud叢集架構
Red Hat OpenShift主元件

Red Hat OpenShift 主要元件

在 Red Hat OpenShift on IBM Cloud 叢集的 IBM管理的主節點中檢閱下列元件。

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

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

單一承租戶

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

抄本

主元件 (包括 Red Hat OpenShift API 伺服器和 etcd 資料儲存庫) 具有三個複本,如果位於多區都會區,則會分散在不同區域,以獲得更高的可用性。 主節點元件每 8 小時備份一次。

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 部署到何處。 如果找不到符合需求的工作者節點,則不會在叢集裡部署 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 代理合作,以安全地連結主機與工作節點。 此連線支援 apiserver proxy 呼叫您的 Pod 和服務; oc execattachlogs 呼叫 kubelet;以及變更和驗證 webhook。

許可控制器

Red Hat OpenShift on IBM Cloud 集群中的特定功能實作了准入控制器。 使用許可控制器,您可以在叢集裡設定原則,以判定是否允許叢集裡的特定動作。 在政策中,您可以指定使用者不能執行某個動作的條件,即使這個動作是您使用 RBAC 指派給使用者的一般權限的一部分。 因此,在 Red Hat OpenShift API 伺服器處理 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 是一個 daemon 集,可將工作者節點的要求轉發到高可用性主複本的 IP 位址。 在單一區域叢集裡,主節點有三個抄本,每個抄本位於個別的主機上。 對於具有多區域功能之區域中的叢集,主節點具有三個分散在各區域之中的抄本。 高可用性負載平衡器會將向主節點網域名稱發出的要求轉遞到主節點抄本。
  • kubelet:kubelet 是在每個 Worker 節點上執行的 Worker 節點代理,負責監控在 Worker 節點上執行的 Pod 的健康狀況,並觀察 API 伺服器傳送的事件。 根據這些事件,kubelet 會建立或移除 Pod、確保有效性和就緒性探測,並將 Pod 的狀態回報至 API 伺服器。
  • vpn:Konnectivity 代理程式與 Konnectivity 伺服器合作,以安全地連結主機與工作節點。 此連線支援對 Pod 及服務的 apiserver proxy 呼叫,以及對 kubelet 的 oc execattachlogs 呼叫。
  • 其他元件: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 控制器可以在不同的運算主機上執行,以提高可用性。
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) 運算基礎架構上執行之 Red Hat OpenShift on IBM Cloud 叢集中的主節點及工作者節點元件說明。

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

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

Red Hat OpenShift on IBM Cloud位於具有公有雲和私有雲服務端點的 VPC 叢集架構上
具有公有雲和私有雲服務端點的 VPC 叢集架構上的Red Hat OpenShift

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

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

僅在具有私有雲服務端點的 VPC 叢集架構上的Red Hat OpenShift on IBM Cloud
僅在具有私有雲服務端點的 VPC 叢集架構上的Red Hat OpenShift

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

主要工作者節點 包含叢集的標準叢集架構中所述的相同元件。 有關 OpenShift Container Platform 架構的詳細資訊,請參閱 Red Hat OpenShift docs

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 管理工作節點的所有維護和計費活動。
工作站節點包含 Classic 群集架構中所述的相同 元件
當您執行 oc get nodes 時,可能會注意到工作者節點的 ROLES 同時標示為 master,worker。 這些節點是 IBM Cloud中的工作者節點,不包括 IBM所管理的主要元件。 相反地,這些節點會標示為 master,因為它們會執行在叢集內設定及管理預設資源 (例如 OperatorHub 及內部登錄) 所需的 OpenShift Container Platform 元件。
叢集網路
工作者節點在指定區域中的 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。