4.2. OpenShift Container Platform 中的机器角色

OpenShift Container Platform 版本必须与 control plane 主机和节点主机间的匹配。例如，在 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 位于以下命名空间中：