3.1. 瞭解 OpenShift Container Platform control plane
control plane 由 master 機器組成，負責管理 OpenShift Container Platform 集群。control plane 機器管理計算機器（也被稱為 worker）上的工作負載。集群本身通過Cluster Version Operator、Machine Config Operator 和一組單獨 Operator 的操作來管理對機器的所有升級。
3.1.1. OpenShift Container Platform 中的機器角色
OpenShift Container Platform 為主機分配不同的角色。這些角色定義機器在集群內的功能。集群包含標準 master 和 worker 角色類型的定義。
注意
集群還包含 bootstrap 角色的定義。由於 bootstrap 機器僅在集群安裝期間使用，因此其功能在集群安裝文檔中闡述。
3.1.1.1. 集群 worker
在 Kubernetes 集群中，worker 節點是運行和管理 Kubernetes 用戶請求的實際工作負載的地方。worker 節點公告其容量，而作為 master 服務一部分的調度程序決定在哪些節點上啟動容器和 Pod。重要服務在每個 worker 節點上運行，包括 CRI-O（即容器引擎）、Kubelet（接受並履行運行和停止容器工作負載請求的服務），以及服務代理（管理 worker 之間 Pod 的通信）。
在 OpenShift Container Platform 中，MachineSets 控制 worker 機器。具有 worker 角色的機器驅動計算工作負載，這些負載由自動擴展它們的特定機器池管控。因為 OpenShift Container Platform 具有支持多種機器類型的能力，因此 worker 機器被歸類為計算 (compute)機器。在此版本中，術語“worker 機器”和“計算機器”可互換使用，因為計算機器的唯一默認類型就是 worker 機器。在未來的 OpenShift Container Platform 版本中，默認情況下可能會使用不同類型的計算機器，如基礎架構機器。
3.1.1.2. 集群 master
在 Kubernetes 集群中，master 節點運行控制 Kubernetes 集群所需的服務。在 OpenShift Container Platform 中，master 機器是 control plane。它們不僅僅包含用於管理 OpenShift Container Platform 集群的 Kubernetes 服務。因為所有具有 control plane 角色的機器都是 master 機器，所以 master 和 control plane 是可以互換的術語。master 機器不會被分成一個 MachineSet，而是由一系列獨立的機器 API 資源定義。 附加控件應用到 master 機器，以防止您刪除所有 master 機器並破壞集群。
注意
使用三個 master 節點雖然理論上可以使用任意數量的 master 節點，但由於 master 靜態 Pod 和 etcd 靜態 Pod 在相同的主機上工作，所以這個數量會受 etcd 仲裁的限制。
master 上屬於 Kubernetes 類別的服務包括 API 服務器、etcd、Controller Manager Server 和 HAProxy 服務。
表 3.1. 在 control plane 上運行的 Kubernetes 服務
組件 描述
API Server Kubernetes API 服務器驗證並配置 Pod、服務和複製控制器的數據。它還為集群的共享狀態提供一個焦點。
etcd etcd 存儲持久 master 狀態，其他組件則監視 etcd 的更改，以使其自身進入指定狀態。
Controller Manager Server Controller Manager Server 監視 etcd 中對象的更改，如複製、命名空間和服務帳戶控制器對象，然後使用 API 強制執行指定的狀態。多個這樣的過程會創建在某個時間點上有一個活躍群首的集群。
master 機器上的某些服務作為 systemd 服務運行，其他服務則作為靜態 Pod 運行。
systemd 服務適合需要始終在特定系統啟動後不久出現的服務。對於 master 機器，這包括允許遠程登錄的 sshd。它還包括以下服務：
• CRI-O 容器引擎 (crio)，用於運行和管理容器。OpenShift Container Platform 4.4 使用 CRI-O，而不是 Docker Container Engine。
• Kubelet (kubelet)，從 master 服務接受管理機器上容器的請求。
CRI-O 和 Kubelet 必須作為 systemd 服務直接在主機上運行，因為它們必須先運行，然後您才能運行其他容器。
3.1.2. OpenShift Container Platform 中的 Operator
在 OpenShift Container Platform 中，Operator 是在 control plane 上打包、部署和管理服務的首選方法。它們還為用戶運行的應用程序提供了便利。Operator 與 Kubernetes API 和 CLI 工具（如 kubectl 和 oc 命令）集成。它們提供了各種方式，以監視應用程序、執行健康檢查、管理無線更新，以及確保應用程序保持在指定的狀態。
因為 CRI-O 和 Kubelet 在每個節點上運行，所以幾乎所有其他集群功能都可以通過使用 Operator 在 control plane 上進行管理。Operator 是 OpenShift Container Platform 4.4 中最重要的組件。使用 Operator 添加到 control plane 的組件包括重要的網絡服務和憑證服務。
在 OpenShift Container Platform 集群中管理其他 Operator 的 Operator 是 Cluster Version Operator。
OpenShift Container Platform 4.4 使用不同類型的 Operator 來執行集群操作，並在集群上運行各種服務供您的應用程序使用。
3.1.2.1. OpenShift Container Platform 中的平臺 Operator
在 OpenShift Container Platform 4.4 中，所有集群功能都劃分到一系列平臺 Operator 中。平臺 Operator 管理集群功能的特定方面，如集群範圍的應用程序日誌記錄、Kubernetes control plane 管理或機器置備系統。
每個 Operator 都為您提供確定集群功能的簡單 API。Operator 將管理組件生命週期的細節隱藏起來。Operator 可以管理一個組件或數十個組件，但最終目標始終是通過自動化常見操作來減輕運維負擔。Operator 還提供了更為精細的配置體驗。若要配置各個組件，您可以修改 Operator 公開的 API，而不必修改全局配置文件。
3.1.2.2. 由 OLM 管理的 Operator
Cluster Operator Lifecycle Management (OLM) 組件管理可在應用程序中使用的 Operator。它不管理組成 OpenShift Container Platform 的 Operator。OLM 是一個將 Kubernetes 原生應用程序作為 Operator 進行管理的框架。它不管理 Kubernetes 清單，而是管理 Kubernetes Operator。OLM 管理兩種 Operator，即 Red Hat Operator 和經認證的 Operator。
一些 Red Hat Operator 用來提供集群功能，如調度程序和問題檢測器。其他 Operator 則可供您自助管理並在應用程序中使用，例如 etcd。OpenShift Container Platform 還提供由社區構建和維護並經過認證的 Operator 。這些經過認證的 Operator 為傳統應用程序提供 API 層，因此您可以通過 Kubernetes 構造來管理應用程序。
3.1.2.3. 關於 OpenShift Container Platform 更新服務
OpenShift Container Platform 更新服務是一種託管服務，為 OpenShift Container Platform 和 Red Hat Enterprise Linux CoreOS (RHCOS) 提供無線更新 (over-the air update)。它提供了一個組件 Operator 圖，其中包含各個頂點及連接它們的邊。圖中的邊顯示可以安全更新的版本，頂點是更新有效負載，用於指定託管集群組件的預期狀態。
集群中的 Cluster Version Operator (CVO) 會檢查 OpenShift Container Platform 更新服務，並根據當前組件版本和圖中的信息決定有效的更新和更新路徑。當您請求更新時，OpenShift Container Platform CVO 使用該更新的發行鏡像來升級您的集群。發行工件 (artifact) 作為容器鏡像託管在 Quay 中。
為了使 OpenShift Container Platform 更新服務僅提供兼容的更新，提供了一個版本驗證管道來驅動自動化。每個發行工件都會被驗證是否與支持的雲平臺和系統架構以及其他組件包兼容。在管道確認有適用的版本後，OpenShift Container Platform 更新服務會通知您可以進行更新。
重要
因為更新服務會顯示所有有效的更新，所以不能強制更新到一個更新服務沒有顯示的版本。
對於連續更新模式，會運行兩個控制器。一個控制器不斷更新有效負載清單，將它們應用於集群，並輸出受控 Operator 部署的狀態（可用、正在進行升級或失敗）。第二個控制器輪詢 OpenShift Container Platform 更新服務以確定更新是否可用。
重要
不支持將集群還原到以前的版本或執行回滾。僅支持升級到較新版本。
在升級過程中，Machine Config Operator (MCO) 會將新配置應用到集群機器。它將機器配置池中由 maxUnavailable 字段指定數量的節點保護起來，並將其標記為不可用。在默認情況下，這個值被設置為 1。然後，它會應用新配置並重啟機器。如果您將 Red Hat Enterprise Linux (RHEL) 機器用作 worker，MCO 不會在這些機器上更新 kubelet，因為您必須首先在這些機器上更新 OpenShift API。因為新版本的規格被應用到舊的 kubelet，所以 RHEL 機器無法返回 Ready 狀態。在機器可用前，您無法完成更新。但是，通過設置不可用節點的最大數量可以確保當不可用機器的數量沒有超過這個值時，正常的集群操作仍然可以繼續進行。
3.1.2.4. 瞭解 Machine Config Operator
OpenShift Container Platform 4.4 集成了操作系統和集群管理。由於集群管理自己的更新，包括集群節點上 Red Hat Enterprise Linux CoreOS (RHCOS) 的更新，因此 OpenShift Container Platform 提供了可靠的生命週期管理體驗，能夠簡化節點升級的編配。
OpenShift Container Platform 使用三個 DaemonSet 和控制器來簡化節點管理。這些 DaemonSet 通過使用標準的 Kubernetes 式構造來編配操作系統更新和主機配置更改。它們包括：
• machine-config-controller，協調從 control plane 進行的機器升級。它監控所有集群節點並編配其配置更新。
• machine-config-daemon DaemonSet，在集群中的每個節點上運行，並按照 MachineConfigController 的指示將機器更新為 MachineConfig 定義的配置。 當節點看到更改時，它將排空其 Pod，應用更新並重啟。這些更改以 Ignition 配置文件的形式出現，這些文件應用指定的機器配置並控制 kubelet 配置。更新本身在容器中交付。此過程是成功管理 OpenShift Container Platform 和 RHCOS 更新的關鍵。
• machine-config-server DaemonSet，在 master 節點加入集群時為其提供 Ignition 配置文件。
機器配置是 Ignition 配置的子集。machine-config-daemon 讀取機器配置，以查看是否需要進行 OSTree 更新，或者是否必須應用一系列 systemd kubelet 文件更改、配置更改，或者對操作系統或 OpenShift Container Platform 配置的其他更改。
執行節點管理操作時，您可以創建或修改 KubeletConfig Custom Resource (CR)。
