第 4 章 control plane 架构
control plane 由 control plane 机器组成，负责管理 Red Hat OpenShift Service on AWS 集群。control plane 机器管理计算机器（也被称为 worker）上的工作负载。集群本身通过 Cluster Version Operator (CVO)和一组单独 Operator 的操作来管理对机器的所有升级。
在带有托管的 control plane (HCP)的 Red Hat OpenShift Service on AWS (ROSA)上不支持这个 control plane 架构。
4.1. Red Hat OpenShift Service on AWS 中的机器角色
Red Hat OpenShift Service on AWS 分配不同的角色。这些角色定义机器在集群内的功能。集群包含标准 master 和 worker 角色类型的定义。
4.1.1. 集群 worker
在 Kubernetes 集群中，worker 节点运行和管理 Kubernetes 用户请求的实际工作负载。worker 节点公告其容量，以及 control plane 服务调度程序，决定在哪些节点上启动 pod 和容器。以下重要服务在每个 worker 节点上运行：
- CRI-O，即容器引擎。
- kubelet，这是接受并履行运行和停止容器工作负载的请求的服务。
- 服务代理，用于管理跨 worker 的 pod 的通信。
- runC 或 crun 低级别容器运行时，用于创建和运行容器。
有关如何启用 crun 而不是默认的 runC 的详情，请参考创建 ContainerRuntimeConfig CR 的文档。
在 Red Hat OpenShift Service on AWS 中，计算机器控制分配了 worker 机器的计算机器。具有 worker 角色的机器驱动计算工作负载，这些工作负载由自动扩展它们的特定机器池管理。因为 Red Hat OpenShift Service on AWS 具有支持多个机器类型的能力，所以具有 worker 角色的机器被归类为 compute 机器。在本发行版本中，worker 机器和 计算机器是可以被互换使用的术语，因为计算机器的唯一默认类型是 worker 机器。在 Red Hat OpenShift Service on AWS 的未来版本中，默认可能会使用不同类型的计算机器，如基础架构机器。
计算机器集是 machine-api 命名空间下的计算机器资源分组。计算机器集是设计在特定云供应商上启动新计算机器的配置。相反，机器配置池（MCP）是 Machine Config Operator（MCO）命名空间的一部分。MCP 用于将机器分组在一起，以便 MCO 能够管理其配置并便于升级。
4.1.2. 集群 control plane
在 Kubernetes 集群中，master 节点运行控制 Kubernetes 集群所需的服务。在 Red Hat OpenShift Service on AWS 中，control plane 由具有 master 机器角色的 control plane 机器组成。它们不仅仅包含用于管理 Red Hat OpenShift Service on AWS 集群的 Kubernetes 服务。
对于大多数 Red Hat OpenShift Service on AWS 集群，control plane 机器由一系列独立的机器 API 资源定义。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 服务器验证并配置数据以向 Red Hat OpenShift Service on AWS 进行身份验证，如用户、组和 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)，用于运行和管理容器。Red Hat OpenShift Service on AWS 4 使用 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
