OpenShift容器平台控制平面

OpenShift Container Platform版本必须在控制平面主机和节点主机之间匹配。例如，在4.9集群中，所有控制平面主机必须为4.9，所有节点必须为4.9。

集群升级期间的临时不匹配是可以接受的。例如，当从OpenShift Container Platform 4.8升级到4.9时，某些节点将比其他节点先升级至4.9。控制平面主机和节点主机的长期倾斜可能会使较旧的计算机器暴露出错误和缺少的功能。用户应尽快解决倾斜的控制平面主机和节点主机。

这个库贝莱服务不得晚于kube-apiserver公司，根据OpenShift容器平台的版本是奇数还是偶数，最多可以有两个较旧的次要版本。下表显示了相应的版本兼容性：

在Kubernetes集群中，工作节点是运行和管理Kubernete用户请求的实际工作负载的地方。工作节点公布其容量，而作为主服务一部分的调度程序决定在哪个节点上启动容器和pod。重要的服务运行在每个工作节点上，包括CRI-O，它是容器引擎，Kubelet，它是接受并满足运行和停止容器工作负载请求的服务，以及服务代理，它管理工作人员之间pods的通信。

在OpenShift容器平台中，机器集控制工人机器。具有工作者角色的计算机驱动由自动缩放它们的特定计算机池管理的计算工作负载。因为OpenShift Container Platform具有支持多种机器类型的能力，所以工作机器被分类为计算机器。在本版本中，术语工人机器和计算机可以互换使用，因为计算机器的唯一默认类型是工作机器。在OpenShift Container Platform的未来版本中，默认情况下可能会使用不同类型的计算机器，例如基础结构机器。

在Kubernetes集群中，控制平面节点（也称为主节点）运行控制Kubernetes集群所需的服务。在OpenShift容器平台中，控制平面机器是控制平面。它们不仅包含用于管理OpenShift容器平台集群的Kubernetes服务。因为所有具有控制平面角色的机器都是控制平面机器，所以术语主人和控制平面可以互换使用来描述它们。控制平面机器不是被分组到一个机器集中，而是由一系列独立的机器API资源定义的。额外的控件应用于控制平面计算机，以防止删除所有控制平面计算机并中断群集。

主服务器上属于Kubernetes类别的服务包括KubernetesAPI服务器、etcd、Kubernete控制器管理器和Kuberneties调度程序。

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

控制平面计算机上的一些服务作为系统服务运行，而其他服务作为静态吊舱运行。

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

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

这个安装程序-*和修订-主席-*控制平面pods必须以root权限运行，因为它们写入/etc/kubernetes等目录，该目录由根用户所有。这些pods位于以下命名空间中：

在OpenShift Container Platform 4.6中，所有集群功能都被划分为一系列平台操作员。平台操作员管理集群功能，如集群范围的应用程序日志记录、Kubernetes控制平面或机器供应系统。

每个操作员都为您提供了一个简单的API来确定集群功能。运营商隐藏了管理其生命周期的详细信息组件。操作员可以管理单个组件或数十个组件，但最终目标始终是通过自动化常见操作来减少操作负担。运营商还提供更精细的配置体验。您配置每个组件，方法是修改操作员公开的API，而不是修改全局配置文件。

群集操作员生命周期管理（OLM）组件管理操作员可在应用程序中使用的。它不管理包括OpenShift容器平台。OLM是一个将Kubernetes-native应用程序作为Operators进行管理的框架。它不是管理Kubernetes清单，而是管理Kubernet Operators。OLM管理两类操作员，即Red Hat操作员和认证操作员。

一些Red Hat操作员驱动集群功能，如调度程序和问题检测器。还提供了其他工具供您管理自己并在中使用您的应用程序，如etcd。OpenShift集装箱平台还提供认证操作员，社区建造和维护的。这些认证操作员提供传统应用程序的API层，以便您可以通过以下方式管理应用程序Kubernetes构造。

OpenShift更新服务（OSUS）提供OpenShift容器平台的空中更新，包括Red Hat Enterprise Linux CoreOS（RHCOS）。它提供了一个包含顶点组件运算符和边缘连接它们的。图中的边显示可以安全更新到的版本。顶点是更新有效载荷，用于指定受管集群组件的预期状态。

集群中的Cluster Version Operator（CVO）使用OpenShift Update Service进行检查，以根据图中的当前组件版本和信息查看有效更新和更新路径。当您请求更新时，CVO会使用该更新的发布映像来更新集群。发布工件作为容器图像托管在Quay中。

为了允许OpenShift更新服务只提供兼容的更新，发布验证管道推动了自动化。每个发布工件都经过验证，以与受支持的云平台和系统架构以及其他组件包兼容。在管道确认版本的适用性后，OpenShift更新服务会通知您该版本可用。

两个控制器在连续更新模式下运行。第一个控制器持续更新有效负载清单，将清单应用于集群，并输出操作员的受控卷展状态，以指示它们是否可用、升级或失败。第二个控制器轮询OpenShift更新服务以确定更新是否可用。

在更新过程中，机器配置操作员（MCO）将新配置应用于集群机器。MCO根据最大不可用字段，并将其标记为不可用。默认情况下，此值设置为1然后，MCO应用新配置并重新启动机器。

如果您使用Red Hat Enterprise Linux（RHEL）机器作为工作机，MCO不会更新kubelet，因为您必须首先更新机器上的OpenShift API。

随着新版本的规范应用于旧kubelet，RHEL机器无法返回到准备就绪状态。在计算机可用之前，您无法完成更新。但是，设置了不可用节点的最大数量，以确保在该数量的机器停止服务的情况下，正常的集群操作可以继续。

OpenShift更新服务由一个操作员和一个或多个应用程序实例组成。

OpenShift Container Platform 4.6集成了这两者操作系统和群集管理。因为集群管理自己的更新，包括对群集节点上Red Hat Enterprise Linux CoreOS（RHCOS）的更新，OpenShift容器平台提供了固执己见的生命周期管理简化节点升级协调的经验。

OpenShift容器平台使用三个守护程序集和控制器简化节点管理。这些守护程序集协调操作系统更新以及使用标准Kubernetes样式对主机进行配置更改构造。它们包括：

机器配置是点火配置的子集。这个机器配置守护程序读取机器配置以查看是否需要OSTree更新或必须应用一系列systemd kubelet文件更改，配置更改，或操作系统或OpenShift容器平台的其他更改配置。

执行节点管理操作时，可以创建或修改Kubelet配置自定义资源（CR）。