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