OpenShift 文档正在迁移，不久后将仅在 docs.redhat.com（所有 Red Hat 产品文档的中心）提供。立即体验 新的文档体验。
  1. 文档
    2. history bug_report picture_as_pdf
×

控制平面架构

控制平面由控制平面机器组成，管理 OpenShift Container Platform 集群。控制平面机器管理计算机器上的工作负载，计算机器也称为工作节点。集群本身通过集群版本操作符 (CVO)、机器配置操作符和一组单独的操作符的动作来管理所有机器的升级。

使用机器配置池进行节点配置管理

运行控制平面组件或用户工作负载的机器根据其处理的资源类型分为多个组。这些机器组称为机器配置池 (MCP)。每个 MCP 管理一组节点及其对应的机器配置。节点的角色决定了它所属的 MCP；MCP 根据其分配的节点角色标签来管理节点。MCP 中的节点具有相同的配置；这意味着可以根据工作负载的增加或减少来扩展和缩减节点。

默认情况下，集群安装时会创建两个 MCP：master 和 worker。每个默认 MCP 都具有由机器配置操作符 (MCO) 应用的已定义配置，MCO 负责管理 MCP 并促进 MCP 更新。

对于工作节点，您可以创建其他 MCP（或自定义池）来管理具有超出默认节点类型的自定义用例的节点。不支持控制平面节点的自定义 MCP。

自定义池是从工作池继承其配置的池。它们使用针对工作池的任何机器配置，但增加了仅针对自定义池部署更改的能力。由于自定义池从工作池继承其配置，因此对工作池的任何更改也应用于自定义池。MCO 不支持不从工作池继承其配置的自定义池。

一个节点只能包含在一个 MCP 中。如果一个节点具有多个与多个 MCP 对应的标签，例如worker,infra，则它由 infra 自定义池管理，而不是工作池。自定义池在选择要管理的节点方面优先考虑节点标签；不属于自定义池的节点由工作池管理。

建议为要在集群中管理的每个节点角色创建一个自定义池。例如，如果您创建 infra 节点来处理基础设施工作负载，建议创建一个自定义 infra MCP 来将这些节点组合在一起。如果您将infra角色标签应用于工作节点使其具有worker,infra双标签，但没有自定义 infra MCP，则 MCO 将其视为工作节点。如果您从节点中删除worker标签并应用infra标签而不将其分组到自定义池中，则 MCO 无法识别该节点，并且该节点不受集群管理。

任何仅运行基础设施工作负载且标有infra角色的节点都不会计入订阅总数。管理 infra 节点的 MCP 与集群确定订阅费用的方式互斥；使用合适的infra角色标记节点并使用污点来阻止用户工作负载在该节点上调度是避免基础设施工作负载订阅费用的唯一要求。

MCO 独立地应用池的更新；例如，如果存在影响所有池的更新，则每个池的节点将彼此并行更新。如果您添加自定义池，则该池中的节点也会尝试与主节点和工作节点同时更新。

可能存在节点上的配置与当前应用的机器配置不完全匹配的情况。这种情况称为“配置漂移”。机器配置守护程序 (MCD) 定期检查节点的配置漂移。如果 MCD 检测到配置漂移，则 MCO 将节点标记为degraded，直到管理员纠正节点配置。降级节点在线且可运行，但无法更新。

其他资源

OpenShift Container Platform 中的机器角色

OpenShift Container Platform 为主机分配不同的角色。这些角色定义了机器在集群中的功能。集群包含标准master和worker角色类型的定义。

集群还包含bootstrap角色的定义。由于引导机器仅在集群安装期间使用，因此其功能在集群安装文档中进行了说明。

控制平面和节点主机兼容性

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

集群升级期间的临时不匹配是可以接受的。例如，从之前的 OpenShift Container Platform 版本升级到 4.17 时，一些节点将在其他节点之前升级到 4.17。控制平面主机和节点主机的长期偏差可能会使较旧的计算机器暴露于错误和缺少的功能。用户应尽快解决控制平面主机和节点主机的偏差。

kubelet服务不得比kube-apiserver新，并且可以最多比kube-apiserver旧两个次要版本，具体取决于 OpenShift Container Platform 版本是奇数还是偶数。下表显示了适当的版本兼容性

OpenShift Container Platform 版本 支持的kubelet偏差

奇数 OpenShift Container Platform 次要版本[1]

最多比 kube-apiserver 旧一个版本

偶数 OpenShift Container Platform 次要版本[2]

最多比 kube-apiserver 旧两个版本

  1. 例如，OpenShift Container Platform 4.11、4.13。

  2. 例如，OpenShift Container Platform 4.10、4.12。

集群工作节点

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

  • CRI-O，这是容器引擎。

  • kubelet，这是接受和满足运行和停止容器工作负载请求的服务。

  • 服务代理，它管理跨工作节点的 Pod 通信。

  • runC 或 crun 低级容器运行时，它创建和运行容器。

有关如何启用 crun 而不是默认 runC 的信息，请参阅创建ContainerRuntimeConfig CR 的文档。

在 OpenShift Container Platform 中，计算机器集控制计算机器，这些计算机器被分配了worker机器角色。具有worker角色的机器驱动受特定机器池控制的计算工作负载，该机器池会自动扩展它们。由于 OpenShift Container Platform 具有支持多种机器类型的功能，因此具有worker角色的机器被归类为计算机器。在此版本中，术语“工作机器”和“计算机器”可以互换使用，因为唯一默认类型的计算机器是工作机器。在将来的 OpenShift Container Platform 版本中，默认情况下可能会使用不同类型的计算机器，例如基础设施机器。

计算机器集是在machine-api命名空间下的计算机器资源的组合。计算机器集是旨在在特定云提供商上启动新计算机器的配置。相反，机器配置池 (MCP) 是机器配置操作符 (MCO) 命名空间的一部分。MCP 用于将机器组合在一起，以便 MCO 可以管理它们的配置并促进它们的升级。

集群控制平面

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

对于大多数 OpenShift Container Platform 集群，控制平面机器由一系列独立的机器 API 资源定义。对于受支持的云提供商和 OpenShift Container Platform 版本组合，可以使用控制平面机器集管理控制平面。额外的控件应用于控制平面机器，以防止您删除所有控制平面机器并破坏您的集群。

所有生产部署都必须使用三个控制平面节点。但是，在裸机平台上，集群可以扩展到五个控制平面节点。

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

表 1. 在控制平面上运行的 Kubernetes 服务
组件 描述

Kubernetes API 服务器

Kubernetes API 服务器验证和配置 Pod、服务和副本控制器的數據。它还为集群的共享状态提供了一个中心点。

etcd

etcd 存储持久化的控制平面状态，而其他组件监视 etcd 的变化，从而使其自身进入指定状态。

Kubernetes 控制器管理器

Kubernetes 控制器管理器监视 etcd 中对象（例如副本、命名空间和服务帐户控制器对象）的变化，然后使用 API 来强制执行指定的状态。多个这样的进程创建一个集群，一次只有一个活动领导者。

Kubernetes 调度器

Kubernetes 调度器监视新创建的且未分配节点的 Pod，并选择最佳节点来托管 Pod。

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

表 2. 在控制平面上运行的 OpenShift 服务
组件 描述

OpenShift API 服务器

OpenShift API 服务器验证和配置 OpenShift 资源（例如项目、路由和模板）的数据。

OpenShift API 服务器由 OpenShift API 服务器操作符管理。

OpenShift 控制器管理器

OpenShift 控制器管理器监视 etcd 中 OpenShift 对象（例如项目、路由和模板控制器对象）的变化，然后使用 API 来强制执行指定的状态。

OpenShift 控制器管理器由 OpenShift 控制器管理器操作符管理。

OpenShift OAuth API 服务器

OpenShift OAuth API 服务器验证和配置用于向 OpenShift Container Platform 进行身份验证的数据，例如用户、组和 OAuth 令牌。

OpenShift OAuth API 服务器由集群身份验证操作符管理。

OpenShift OAuth 服务器

用户向 OpenShift OAuth 服务器请求令牌以向 API 进行身份验证。

OpenShift OAuth 服务器由集群身份验证操作符管理。

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

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

  • CRI-O 容器引擎 (crio)，它运行和管理容器。OpenShift Container Platform 4.17 使用 CRI-O 而不是 Docker 容器引擎。

  • Kubelet (kubelet)，它接受来自控制平面服务的管理机器上容器的请求。

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

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

  • openshift-etcd

  • openshift-kube-apiserver

  • openshift-kube-controller-manager

  • openshift-kube-scheduler

其他资源

OpenShift Container Platform 中的操作符

操作符是 OpenShift Container Platform 中最重要的组件之一。它们是打包、部署和管理控制平面服务的首选方法。它们还可以为用户运行的应用程序提供优势。

操作符与 Kubernetes API 和 CLI 工具（例如 kubectl 和 OpenShift CLI (oc)）集成。它们提供监控应用程序、执行健康检查、管理空中 (OTA) 更新以及确保应用程序保持在您指定状态的方法。

操作符还提供了更细粒度的配置体验。您可以通过修改操作符公开的 API 来配置每个组件，而不是修改全局配置文件。

由于 CRI-O 和 Kubelet 运行在每个节点上，因此几乎所有其他集群功能都可以通过使用操作符在控制平面上进行管理。通过使用操作符添加到控制平面的组件包括关键的网络和凭据服务。

虽然两者都遵循类似的操作符概念和目标，但 OpenShift Container Platform 中的操作符由两个不同的系统管理，具体取决于其用途

集群操作符

由集群版本操作符 (CVO) 管理，并默认安装以执行集群功能。

可选附加组件操作符

由操作符生命周期管理器 (OLM) 管理，并且可以供用户在其应用程序中运行。也称为 *基于 OLM 的操作符*。

集群操作符

在 OpenShift Container Platform 中，所有集群功能都划分为一系列默认的 *集群操作符*。集群操作符管理集群功能的特定区域，例如集群范围的应用程序日志记录、Kubernetes 控制平面的管理或机器配置系统。

集群操作符由 ClusterOperator 对象表示，集群管理员可以在 OpenShift Container Platform Web 控制台中从 **管理** → **集群设置** 页面查看该对象。每个集群操作符都提供了一个简单的 API 用于确定集群功能。操作符隐藏了管理该组件生命周期的细节。操作符可以管理单个组件或数十个组件，但最终目标始终是通过自动化常见操作来减少操作负担。

其他资源

附加组件操作符

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

使用 OpenShift Container Platform Web 控制台中的 OperatorHub，集群管理员和授权用户可以选择要从操作符目录中安装的操作符。从 OperatorHub 安装操作符后，可以将其全局或在特定命名空间中提供，以便在用户应用程序中运行。

可用的默认目录源包括 Red Hat 操作符、经过认证的操作符和社区操作符。集群管理员还可以添加他们自己的自定义目录源，其中可以包含一组自定义的操作符。

开发人员也可以使用 Operator SDK 来帮助创作利用 OLM 功能的自定义操作符。然后，他们的操作符可以被捆绑并添加到自定义目录源中，该源可以添加到集群并提供给用户。

OLM 不管理构成 OpenShift Container Platform 架构的集群操作符。
其他资源

etcd 概述

etcd 是一个一致的分布式键值存储，它保存少量可以完全放入内存中的数据。虽然 etcd 是许多项目的一个核心组件，但它是 Kubernetes 的主要数据存储，Kubernetes 是容器编排的标准系统。

使用 etcd 的好处

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

  • 保持云原生应用程序的一致运行时间，即使单个服务器出现故障也能保持其运行。

  • 存储和复制 Kubernetes 的所有集群状态。

  • 分发配置数据，为节点配置提供冗余性和弹性。

etcd 的工作原理

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

etcd Operator 会观察、分析并采取行动

  1. 它通过使用 Kubernetes API 来观察集群状态。

  2. 它分析当前状态与所需状态之间的差异。

  3. 它通过 etcd 集群管理 API、Kubernetes API 或两者共同来修复这些差异。

etcd 保持集群状态，该状态会不断更新。此状态会持续持久化，导致大量的小型更改频繁发生。因此，使用快速、低延迟 I/O 来支持 etcd 集群成员至关重要。有关 etcd 最佳实践的更多信息，请参见“推荐的 etcd 实践”。

其他资源