控制平面架构

在 Kubernetes 集群中，工作节点运行和管理 Kubernetes 用户请求的实际工作负载。工作节点宣传其容量，调度程序（一种控制平面服务）确定在哪些节点上启动 Pod 和容器。以下重要服务在每个工作节点上运行

在 OpenShift Dedicated 中，计算机器集控制分配了worker机器角色的计算机器。具有worker角色的机器驱动由自动缩放它们的特定机器池管理的计算工作负载。由于 OpenShift Dedicated 具有支持多种机器类型的容量，因此具有worker角色的机器被称为计算机器。在此版本中，术语工作节点和计算机器可以互换使用，因为唯一默认类型的计算机器是工作节点。在未来版本的 OpenShift Dedicated 中，默认情况下可能会使用不同类型的计算机器，例如基础架构机器。

在 Kubernetes 集群中，主节点运行控制 Kubernetes 集群所需的服务。在 OpenShift Dedicated 中，控制平面由具有master机器角色的控制平面机器组成。它们包含的不仅仅是管理 OpenShift Dedicated 集群的 Kubernetes 服务。

对于大多数 OpenShift Dedicated 集群，控制平面机器由一系列独立的机器 API 资源定义。控制平面使用控制平面机器集进行管理。额外的控件适用于控制平面机器，以防止您删除所有控制平面机器并破坏您的集群。

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

还有一些在控制平面上运行的 OpenShift 服务，包括 OpenShift API 服务器、OpenShift 控制器管理器、OpenShift OAuth API 服务器和 OpenShift OAuth 服务器。

控制平面机器上的一些服务作为 systemd 服务运行，而另一些则作为静态 Pod 运行。

Systemd 服务适用于您需要在特定系统启动后不久始终启动的服务。对于控制平面机器，这些服务包括 sshd，它允许远程登录。它还包括以下服务：

CRI-O 和 Kubelet 必须作为 systemd 服务直接在主机上运行，因为它们需要在运行其他容器之前运行。

installer-* 和 revision-pruner-* 控制平面 Pod 必须以 root 权限运行，因为它们写入 /etc/kubernetes 目录，该目录由 root 用户拥有。这些 Pod 位于以下命名空间：

Operator Lifecycle Manager (OLM) 和 OperatorHub 是 OpenShift Dedicated 中的默认组件，它们有助于将 Kubernetes 原生应用程序作为 Operators 进行管理。它们共同提供了在集群上发现、安装和管理可选附加组件 Operators 的系统。

使用 OpenShift Dedicated Web 控制台中的 OperatorHub，具有 dedicated-admin 角色的管理员和授权用户可以选择要从 Operators 目录中安装的 Operators。从 OperatorHub 安装 Operator 后，可以将其全局可用或在特定命名空间中可用以在用户应用程序中运行。

提供了默认的目录源，其中包括 Red Hat Operators、经过认证的 Operators 和社区 Operators。具有 dedicated-admin 角色的管理员还可以添加他们自己的自定义目录源，其中可以包含一组自定义的 Operators。

开发人员也可以使用 Operator SDK 来帮助编写利用 OLM 功能的自定义 Operators。然后，可以将他们的 Operator 打包并添加到自定义目录源中，该目录源可以添加到集群并提供给用户。

通过使用 etcd，您可以获得多种好处：

为了确保集群配置和管理的可靠方法，etcd 使用 etcd Operator。Operator 简化了在 Kubernetes 容器平台（如 OpenShift Dedicated）上使用 etcd 的过程。使用 etcd Operator，您可以创建或删除 etcd 成员、调整集群大小、执行备份以及升级 etcd。

etcd Operator 观察、分析和采取行动：

etcd 保持集群状态，该状态不断更新。此状态持续持久化，导致大量的小型变更频繁发生。因此，Red Hat 站点可靠性工程 (SRE) 使用快速、低延迟的 I/O 来支持 etcd 集群成员。