OPENSHIFT CONTAINER PLATFORM CONTROL PLANE

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)。