1.2. 机器配置概述
Machine Config Operator（MCO）管理对 systemd、CRI-O 和 Kubelet、内核、Network Manager 和其他系统功能的更新。它还提供了一个 MachineConfig CRD，它可以在主机上写入配置文件（请参阅 machine-config-operator）。了解 MCO 的作用以及如何与其他组件交互对于对 OpenShift Container Platform 集群进行高级系统级更改至关重要。以下是您应该了解的 MCO、机器配置以及它们的使用方式：
- 机器配置按字母顺序处理，按字母顺序增加名称。呈现控制器使用列表中的第一个机器配置作为基础，并将剩余的附加到基本机器配置中。
- 机器配置可以对每个系统的操作系统上的文件或服务进行特定的更改，代表一个 OpenShift Container Platform 节点池。
MCO 应用对机器池中的操作系统的更改。所有 OpenShift Container Platform 集群都以 worker 和 control plane 节点池开头。通过添加更多角色标签，您可以配置自定义节点池。例如，您可以设置一个自定义的 worker 节点池，其中包含应用程序所需的特定硬件功能。但是，本节中的示例着重介绍了对默认池类型的更改。
重要一个节点可以应用多个标签来指示其类型，如
master或worker，但只能是一个单一机器配置池的成员。-
机器配置更改后，MCO 根据
topology.kubernetes.io/zone标签，按区字母更新受影响的节点。如果一个区域有多个节点，则首先更新最旧的节点。对于不使用区的节点，如裸机部署中的节点，节点会按使用的时间升级，首先更新最旧的节点。MCO 一次更新机器配置池中由maxUnavailable字段指定的节点数量。 - 在将 OpenShift Container Platform 安装到磁盘前，必须先进行一些机器配置。在大多数情况下，这可以通过创建直接注入 OpenShift Container Platform 安装程序进程中的机器配置来实现，而不必作为安装后机器配置运行。在其他情况下，您可能需要在 OpenShift Container Platform 安装程序启动时传递内核参数时进行裸机安装，以完成诸如设置每个节点的 IP 地址或高级磁盘分区等操作。
- MCO 管理机器配置中设置的项目。MCO 不会覆盖您对系统进行的手动更改，除非明确告知 MCO 管理冲突文件。换句话说，MCO 只提供您请求的特定更新，它不会声明对整个节点的控制。
- 强烈建议手动更改节点。如果您需要退出某个节点并启动一个新节点，则那些直接更改将会丢失。
-
MCO 只支持写入
/etc和/var目录里的文件，虽然有些目录的符号链接可以通过符号链接到那些区域之一来写入。例如/opt和/usr/local目录。 - Ignition 是 MachineConfig 中使用的配置格式。详情请参阅 Ignition 配置规格 v3.2.0。
- 虽然 Ignition 配置设置可以在 OpenShift Container Platform 安装时直接交付，且以 MCO 提供 Ignition 配置的方式格式化，但 MCO 无法查看这些原始 Ignition 配置是什么。因此，您应该在部署 Ignition 配置前将 Ignition 配置设置嵌套到机器配置中。
-
当由 MCO 管理的文件在 MCO 之外更改时，Machine Config Daemon（MCD）会将该节点设置为
degraded。然而，它不会覆盖这个错误的文件，它应该继续处于degraded（降级）状态。 -
使用机器配置的一个关键原因是，当您为 OpenShift Container Platform 集群中的池添加新节点时，会应用它。
machine-api-operator置备一个新机器， MCO 配置它。
MCO 使用 Ignition 作为配置格式。OpenShift Container Platform 4.6 从 Ignition 配置规格版本 2 移到版本 3。
1.2.1. 机器配置可以更改什么？
MCO 可更改的组件类型包括：
config：创建 Ignition 配置对象（请参阅 Ignition 配置规格），以完成修改 OpenShift Container Platform 机器上的文件、systemd 服务和其他功能，包括：
-
Configuration files：创建或覆盖
/var或/etc目录中的文件。 - systemd units：在附加设置中丢弃并设置 systemd 服务的状态，或者添加到现有 systemd 服务中。
用户和组：在安装后更改 passwd 部分中的 SSH 密钥。
重要-
只有
core用户才支持使用机器配置更改 SSH 密钥。 - 不支持使用机器配置添加新用户。
-
只有
-
Configuration files：创建或覆盖
- kernelArguments：在 OpenShift Container Platform 节点引导时在内核命令行中添加参数。
-
kernelType：（可选）使用非标准内核而不是标准内核。使用
realtime来使用 RT 内核（用于 RAN）。这只在选择的平台上被支持。使用64k-pages参数启用 64k 页大小内核。此设置专用于具有 64 位 ARM 架构的机器。 fips：启用 FIPS 模式。不应在安装时设置 FIPS，而不是安装后的步骤。
重要要为集群启用 FIPS 模式，您必须从配置为以 FIPS 模式操作的 Red Hat Enterprise Linux (RHEL) 计算机运行安装程序。有关在 RHEL 中配置 FIPS 模式的更多信息，请参阅将 RHEL 切换到 FIPS 模式。
当以 FIPS 模式运行 Red Hat Enterprise Linux (RHEL) 或 Red Hat Enterprise Linux CoreOS (RHCOS)时，OpenShift Container Platform 核心组件使用 RHEL 加密库，在 x86_64、ppc64le 和 s390x 架构上提交到 NIST FIPS 140-2/140-3 Validation。
- extensions：通过添加所选预打包软件来扩展 RHCOS 功能。对于这个功能，可用的扩展程序包括 usbguard 和内核模块。
-
Custom resources（用于
ContainerRuntime和Kubelet）：在机器配置外，MCO 管理两个特殊自定义资源，用于修改 CRI-O 容器运行时设置（ContainerRuntimeCR）和 Kubelet 服务（KubeletCR）。
MCO 不是更改 OpenShift Container Platform 节点上的操作系统组件的唯一 Operator。其他 Operator 也可以修改操作系统级别的功能。一个例子是 Node Tuning Operator，它允许您通过 Tuned 守护进程配置集进行节点级别的性能优化。
可以在安装后进行的 MCO 配置任务包括在以下步骤中。如需在 OpenShift Container Platform 安装过程中或之前完成的系统配置任务，请参阅 RHCOS 裸机安装的描述。默认情况下，在 MCO 中进行的许多更改都需要重启。
以下修改不会触发节点重新引导：
当 MCO 检测到以下任何更改时，它会在不排空或重启节点的情况下应用更新：
-
在机器配置的
spec.config.passwd.users.sshAuthorizedKeys参数中更改 SSH 密钥。 -
在
openshift-config命名空间中更改全局 pull secret 或 pull secret。 -
Kubernetes API Server Operator 自动轮转
/etc/kubernetes/kubelet-ca.crt证书颁发机构（CA）。
-
在机器配置的
当 MCO 检测到对
/etc/containers/registries.conf文件的更改时，如添加或编辑ImageDigestMirrorSet、ImageTagMirrorSet或ImageContentSourcePolicy对象，它会排空对应的节点，应用更改并取消记录节点。对于以下更改，节点排空不会发生：-
增加了一个 registry，带有为每个镜像（mirror）设置了
pull-from-mirror = "digest-only"参数。 -
增加了一个镜像（mirror），带有在一个 registry 中设置的
pull-from-mirror = "digest-only"参数。 -
在
unqualified-search-registries列表中添加项目。
-
增加了一个 registry，带有为每个镜像（mirror）设置了
在其他情况下，您可以使用 节点中断策略来减少 MCO 更改时造成工作负载中断的情况。如需更多信息，请参阅了解在机器配置更改后节点重启的行为。
在某些情况下，节点上的配置与当前应用的机器配置指定不完全匹配。这个状态被称为 配置偏移。Machine Config Daemon(MCD)定期检查节点是否有配置偏移。如果 MCD 检测到配置偏移，MCO 会将节点标记为 降级(degraded)，直到管理员更正节点配置。降级的节点在线且可操作，但无法更新。有关配置偏移的更多信息，请参阅了解配置偏移检测。
1.2.2. 使用机器配置池进行节点配置管理
运行 control plane 组件或用户工作负载的机器会根据其处理的资源类型划分为组。这些机器组称为机器配置池（MCP）。每个 MCP 管理一组节点及其对应的机器配置。节点的角色决定了它所属的 MCP ; MCP 会根据其分配的节点角色标签管理节点。MCP 中的节点具有相同的配置 ; 这意味着节点可以扩展并缩减，以适应增加或降低的工作负载。
默认情况下，在安装时集群创建两个 MCP：master 和 worker。每个默认 MCP 都有一个定义的配置，由 Machine Config Operator（MCO）应用，它负责管理 MCP 并协调 MCP 更新。
对于 worker 节点，您可以创建额外的 MCP 或自定义池，以管理带有扩展了默认节点类型的自定义用例的节点。不支持用于 control plane 节点的自定义 MCP。
自定义池是从 worker 池中继承其配置的池。它们将任何机器配置用于 worker 池，但添加了仅针对自定义池部署更改的能力。由于自定义池从 worker 池继承其配置，对 worker 池的任何更改都会应用到自定义池。MCO 不支持从 worker 池中继承其配置的自定义池。
节点只能包含在一个 MCP 中。如果节点有多个与多个 MCP 对应的标签，如 worker,infra，它由 infra 自定义池而不是 worker 池管理。自定义池根据节点标签在选择节点时具有优先权。不属于自定义池的节点由 worker 池管理。
建议您为集群中要管理的每个节点角色创建一个自定义池。例如，如果您创建 infra 节点来处理 infra 工作负载，建议创建一个自定义 infra MCP 将那些节点分组在一起。如果您将 infra 角色标签应用到 worker 节点，使其具有 workerinfra dual 标签，但没有自定义 infra MCP，则 MCO 认为它是一个 worker 节点。如果您从节点中删除 worker 标签，并应用 infra 标签而不将其分组到自定义池中，则该节点不可被 MCO 识别，且不受集群管理。
任何使用 infra 角色标记的节点如果只运行 infra 工作负载，则不计算到订阅总数中。管理 infra 节点的 MCP 与集群决定订阅的方式相互排斥 ; 为节点添加适当 infra 角色的标签，并使用污点以防止用户工作负载调度到该节点上，这是避免为 infra 工作负载添加订阅的唯一要求。
MCO 独立应用池更新。例如，如果有会影响所有池的更新，则每个池更新中的节点会相互并行。如果您添加自定义池，则该池中的节点还会尝试与 master 和 worker 节点同时更新。
在某些情况下，节点上的配置与当前应用的机器配置指定不完全匹配。这个状态被称为 配置偏移。Machine Config Daemon(MCD)定期检查节点是否有配置偏移。如果 MCD 检测到配置偏移，MCO 会将节点标记为 降级(degraded)，直到管理员更正节点配置。降级的节点在线且可操作，但无法更新。
