控制平面架构

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

在AWS上的Red Hat OpenShift Service中，计算机器集控制分配了worker机器角色的计算机器。具有worker角色的机器驱动由特定机器池管理的计算工作负载，该机器池会自动扩展它们。由于AWS上的Red Hat OpenShift Service具有支持多种机器类型的功能，因此具有worker角色的机器被分类为计算机器。在此版本中，术语工作节点和计算机器可互换使用，因为唯一默认类型的计算机器是工作节点。在AWS上的Red Hat OpenShift Service的未来版本中，可能默认使用不同类型的计算机器，例如基础设施机器。

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

对于大多数AWS上的Red Hat OpenShift Service集群，控制平面机器由一系列独立的机器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 是 AWS 上 Red Hat OpenShift Service 中的默认组件，有助于将 Kubernetes 原生应用程序作为 Operators 进行管理。它们共同提供了一个系统，用于发现、安装和管理集群上可用的可选附加组件 Operators。

使用 AWS 上 Red Hat OpenShift Service 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简化了在像AWS上的Red Hat OpenShift Service这样的Kubernetes容器平台上使用etcd。使用etcd Operator，您可以创建或删除etcd成员，调整集群大小，执行备份以及升级etcd。

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

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