第 4 章 OpenShift Container Platform control plane

control plane 主机和节点主机之间的 OpenShift Container Platform 版本必须匹配。例如，在一个 4.9 集群中，所有 control plane 主机都必须是 4.9，所有节点也必需是 4.9。

可以接受集群升级过程中的临时不匹配。例如，当从 OpenShift Container Platform 4.8 升级到 4.9 时，一些节点将在其他节点之前升级到 4.9。control plane 主机和节点主机的长期偏移可能会暴露旧计算机器给错误和缺失的功能。用户应该尽快解决偏移的 control plane 主机和节点主机。

kubelet 服务不能更新于 kube-apiserver，且可能会有最多两个旧的次版本，具体取决于 OpenShift Container Platform 版本是否奇数甚至更低。下表显示了适当的版本兼容性：

在 Kubernetes 集群中，worker 节点是运行和管理 Kubernetes 用户请求的实际工作负载的地方。worker 节点公告其容量，而作为 master 服务一部分的调度程序决定在哪些节点上启动容器和 pod。重要服务在每个 worker 节点上运行，包括 CRI-O（即容器引擎）、Kubelet（接受并履行运行和停止容器工作负载请求的服务），以及服务代理（管理 worker 之间 Pod 的通信）。

在 OpenShift Container Platform 中，机器集用来控制 worker 机器。具有 worker 角色的机器驱动计算工作负载，这些负载由自动扩展它们的特定机器池管控。因为 OpenShift Container Platform 具有支持多种机器类型的能力，因此 worker 机器被归类为计算 (compute)机器。在本发行版本中，worker 机器和 计算机器是可以被互换使用的术语，因为计算机器的唯一默认类型是 worker 机器。在未来的 OpenShift Container Platform 版本中，默认情况下可能会使用不同类型的计算机器，如基础架构机器。

在 Kubernetes 集群中，control plane 节点（也称为 master 节点）运行控制 Kubernetes 集群所需的服务。在 OpenShift Container Platform 中，control plane 机器是 control plane。它们不仅仅包含用于管理 OpenShift Container Platform 集群的 Kubernetes 服务。因为所有具有 control plane 角色的机器都是 control plane 机器，所以 master 和 control plane 是可以互换使用的术语。control plane 机器不会被分成机器集，而是由一系列独立的机器 API 资源定义。 额外的控件应用到 control plane 机器，以防止您删除所有 control plane 机器并破坏集群。

master 上属于 Kubernetes 类别的服务包括 Kubernetes API 服务器、etcd、Kubernetes 控制器管理器和 Kubernetes 调度程序。

另外，在 control plane 上运行的 OpenShift 服务包括 OpenShift API 服务器、OpenShift 控制器管理器、OpenShift OAuth API 服务器和 OpenShift OAuth 服务器。

control plane 机器上的某些服务作为 systemd 服务运行，另一些则作为静态 pod 运行。

systemd 服务适合需要始终在特定系统启动后不久出现的服务。对于 control plane 机器，这包括允许远程登录的 sshd。它还包括以下服务：

CRI-O 和 Kubelet 必须作为 systemd 服务直接在主机上运行，因为它们必须先运行，然后您才能运行其他容器。

installer-* 和 revision-pruner-* control plane pod 必须使用 root 权限运行，因为它们需要写入属于 root 用户的 /etc/kubernetes 目录。这些 pod 位于以下命名空间中：

在 OpenShift Container Platform 4.6 中，所有集群功能都划分到一系列平台 Operator 中。平台 Operator 管理集群功能的特定方面，如集群范围的应用程序日志记录、Kubernetes control plane 管理或机器置备系统。

每个 Operator 都为您提供确定集群功能的简单 API。Operator 将管理组件生命周期的细节隐藏起来。Operator 可以管理一个组件或数十个组件，但最终目标始终是通过自动化常见操作来减轻运维负担。Operator 还提供了更为精细的配置体验。若要配置各个组件，您可以修改 Operator 公开的 API，而不必修改全局配置文件。

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 构造来管理应用程序。

OpenShift 更新服务（OpenShift Update Service，简称 OSUS）为 OpenShift Container Platform（包括 Red Hat Enterprise Linux CoreOS（RHCOS））提供了无线更新（over-the air update）功能。它提供了一个图表，其中包含组件 Operator 的顶点（vertices）和连接它们的 边（edges）。图中的边代表了您可以安全更新到的版本。顶点是更新的有效负载，用于指定受管集群组件的预期状态。

集群中的 Cluster Version Operator (CVO) 会检查 OpenShift Container Platform 更新服务，并根据当前组件版本和图中的信息决定有效的更新和更新路径。当您请求更新时，CVO 使用该更新的发行镜像来更新您的集群。发行工件 (artifact) 作为容器镜像托管在 Quay 中。

为了让 OpenShift Update Service 仅提供兼容的更新，可以使用一个版本验证管道来驱动自动化过程。每个发行工件都会被验证是否与支持的云平台和系统架构以及其他组件包兼容。在管道确认有适用的版本后，OpenShift Update Service 会通知您它可用。

两个控制器在持续更新模式下运行。第一个控制器持续更新有效负载清单，将清单应用到集群，并输出 Operator 的受控推出的状态，以指示它们是否处于可用、升级或失败状态。第二个控制器轮询 OpenShift Update Service，以确定更新是否可用。

在更新过程中，Machine Config Operator(MCO)将新配置应用到集群机器。MCO 会处理由 maxUnavailable 字段指定的、协调机器配置池中的节点数量，并将它们标记为不可用。在默认情况下，这个值被设置为 1。然后，MCO 会应用新配置并重启机器。

如果您将 Red Hat Enterprise Linux (RHEL) 机器用作 worker，MCO 不会在这些机器上更新 kubelet，因为您必须首先在这些机器上更新 OpenShift API。

当新版本规格应用到旧的 kubelet 时，RHEL 机器无法返回 Ready 状态。在机器可用前，您无法完成更新。但是，因为已设置了最大不可用节点数，所以可以在一定机器无法使用的情况下，确保正常的集群操作。

OpenShift Update Service 由 Operator 和一个或多个应用程序实例组成。

OpenShift Container Platform 4.6 集成了操作系统和集群管理。由于集群管理自己的更新，包括集群节点上 Red Hat Enterprise Linux CoreOS (RHCOS) 的更新，因此 OpenShift Container Platform 提供了可靠的生命周期管理体验，能够简化节点升级的编配。

OpenShift Container Platform 使用三个守护进程集和控制器来简化节点管理。这些守护进程集通过使用标准的 Kubernetes 式构造来编配操作系统更新和主机配置更改。它们包括：

机器配置是 Ignition 配置的子集。machine-config-daemon 读取机器配置，以查看是否需要进行 OSTree 更新，或者是否必须应用一系列 systemd kubelet 文件更改、配置更改，或者对操作系统或 OpenShift Container Platform 配置的其他更改。

执行节点管理操作时，您可以创建或修改 KubeletConfig 自定义资源(CR)。