6.2. OpenShift Container Platform 中的机器角色
OpenShift Container Platform 为主机分配不同的角色。这些角色定义机器在集群内的功能。集群包含标准 master 和 worker 角色类型的定义。
集群还包含 bootstrap 角色的定义。由于 bootstrap 机器仅在集群安装期间使用，因此其功能在集群安装文档中阐述。
6.2.1. control plane 和节点主机兼容性
OpenShift Container Platform 版本必须与 control plane 主机和节点主机间的匹配。例如，在一个 4.12 集群中，所有 control plane 主机都必须是 4.12，所有节点也必需是 4.12。
在集群升级过程中出现临时的不匹配可以被接受。例如，当从 OpenShift Container Platform 4.11 升级到 4.12 时，一些节点会升级到 4.12。因为较长的 control plane 主机和节点主机偏移可能会使旧的计算机器存在错误并缺失一些功能。用户应该尽快解决偏移的 control plane 主机和节点主机。
kubelet 服务不能比 kube-apiserver 更新，并根据您的 OpenShift Container Platform 版本号是否是奇数还是偶数，最多可以早于两个次版本。下表显示了适当的版本兼容性：
| OpenShift Container Platform 版本 | 支持的 kubelet 偏移 |
|---|---|
| 奇数的 OpenShift Container Platform 次版本 [1] | 最多早于一个版本 |
| 偶数 OpenShift Container Platform 次版本 [2] | 最多早于两个版本 |
- 例如，OpenShift Container Platform 4.9、4.11。
- 例如，OpenShift Container Platform 4.8、4.10、4.12。
6.2.2. 集群 worker
在 Kubernetes 集群中，worker 节点是运行和管理 Kubernetes 用户请求的实际工作负载的地方。worker 节点公告其容量，以及 control plane 服务调度程序，决定在哪些节点上启动 pod 和容器。重要服务在每个 worker 节点上运行，包括 CRI-O （即容器引擎）、Kubelet （接受并履行运行和停止容器工作负载的请求）；服务代理，用于管理跨 worker 的 pod 的通信；以及 runC 或 crun （技术预览）低级别容器运行时，该服务创建并运行容器。
有关如何启用 crun 而不是默认的 runC 的详情，请参考创建 ContainerRuntimeConfig CR 的文档。
在 OpenShift Container Platform 中，计算机器控制分配了 worker 机器的计算机器。具有 worker 角色的机器驱动计算工作负载，这些工作负载由自动扩展它们的特定机器池管理。由于 OpenShift Container Platform 具有支持多个机器类型的能力，所以具有 worker 角色的机器被归类为 compute 机器。在本发行版本中，worker 机器和 计算机器是可以被互换使用的术语，因为计算机器的唯一默认类型是 worker 机器。在未来的 OpenShift Container Platform 版本中，默认情况下可能会使用不同类型的计算机器，如基础架构机器。
计算机器集是 machine-api 命名空间下的计算机器资源分组。计算机器集是设计在特定云供应商上启动新计算机器的配置。相反，机器配置池（MCP）是 Machine Config Operator（MCO）命名空间的一部分。MCP 用于将机器分组在一起，以便 MCO 能够管理其配置并便于升级。
6.2.3. 集群 control plane
在 Kubernetes 集群中，master 节点运行控制 Kubernetes 集群所需的服务。在 OpenShift Container Platform 中，control plane 由具有 master 机器角色的 control plane 机器组成。它们不仅仅包含用于管理 OpenShift Container Platform 集群的 Kubernetes 服务。
对于大多数 OpenShift Container Platform 集群，control plane 机器由一系列独立的机器 API 资源定义。对于支持的云供应商和 OpenShift Container Platform 版本组合，control plane 可使用 control plane 机器集管理。额外的控件应用到 control plane 机器，以防止您删除所有 control plane 机器并破坏集群。
所有生产部署都必须使用三个 control plane 节点。
control plane 上属于 Kubernetes 类别的服务包括 Kubernetes API 服务器、etcd、Kubernetes 控制器管理器和 Kubernetes 调度程序。
| 组件 | 描述 |
|---|---|
| Kubernetes API 服务器 | Kubernetes API 服务器验证并配置 pod、服务和复制控制器的数据。它还为集群的共享状态提供了一个焦点。 |
| etcd | etcd 存储持久 control plane 状态，其他组件则监视 etcd 的更改，以使其自身进入指定状态。 |
| Kubernetes 控制器管理器 | Kubernetes 控制器管理器监视 etcd 是否有对象的更改，如复制、命名空间，务帐户控制器对象，然后使用 API 来强制实施指定的状态。多个这样的过程会创建在某个时间点上有一个活跃群首的集群。 |
| Kubernetes 调度程序 | Kubernetes 调度程序监视没有分配节点的新创建的 pod，并选择托管该 pod 的最佳节点。 |
另外，在 control plane 上运行的 OpenShift 服务包括 OpenShift API 服务器、OpenShift 控制器管理器、OpenShift OAuth API 服务器和 OpenShift OAuth 服务器。
| 组件 | 描述 |
|---|---|
| OpenShift API 服务器 | OpenShift API 服务器验证并配置 OpenShift 资源（如项目、路由和模板）的数据。 OpenShift API 服务器由 OpenShift API Server Operator 管理。 |
| OpenShift 控制器管理器 | OpenShift 控制器管理器监视 etcd 是否有 OpenShift 对象的更改，如项目、路由和模板控制器对象，然后使用 API 来强制实施指定的状态。 OpenShift 控制器管理器由 OpenShift Controller Manager Operator 管理。 |
| OpenShift OAuth API 服务器 | OpenShift OAuth API 服务器验证并配置数据以向 OpenShift Container Platform 进行身份验证，如用户、组和 OAuth 令牌。 OpenShift OAuth API 服务器由 Cluster Authentication Operator 管理。 |
| OpenShift OAuth 服务器 | 用户从 OpenShift OAuth 服务器请求令牌，以向 API 进行身份验证。 OpenShift OAuth 服务器由 Cluster Authentication Operator 管理。 |
control plane 机器上的某些服务作为 systemd 服务运行，另一些则作为静态 pod 运行。
systemd 服务适合需要始终在特定系统启动后不久出现的服务。对于 control plane 机器，这包括允许远程登录的 sshd。它还包括以下服务：
- CRI-O 容器引擎 (crio)，用于运行和管理容器。OpenShift Container Platform 4.12 使用 CRI-O，而不是 Docker Container Engine。
- kubelet (kubelet)，从 control plane 服务接受管理机器上容器的请求。
CRI-O 和 Kubelet 必须作为 systemd 服务直接在主机上运行，因为它们必须先运行，然后您才能运行其他容器。
installer-* 和 revision-pruner-* control plane pod 必须使用 root 权限运行，因为它们需要写入属于 root 用户的 /etc/kubernetes 目录。这些 pod 位于以下命名空间中：
-
openshift-etcd -
openshift-kube-apiserver -
openshift-kube-controller-manager -
openshift-kube-scheduler
