|
要为您的集群启用 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 核心组件仅在 x86_64、ppc64le 和 s390x 架构上使用已提交给 NIST 以进行 FIPS 140-2/140-3 验证的 RHEL 加密库。 |
×
机器配置概述
有时您需要更改在 OpenShift Container Platform 节点上运行的操作系统。这可能包括更改网络时间服务的设置、添加内核参数或以特定方式配置日志记录。
除了少数特殊功能外，对 OpenShift Container Platform 节点上操作系统的绝大多数更改都可以通过创建所谓的MachineConfig对象来完成，这些对象由机器配置操作符管理。例如，您可以使用机器配置操作符 (MCO) 和机器配置来管理对 systemd、CRI-O 和 kubelet、内核、Network Manager 和其他系统功能的更新。
本节中的任务描述如何使用机器配置操作符的功能来配置 OpenShift Container Platform 节点上的操作系统功能。
|
NetworkManager 将新的网络配置存储到 以前，NetworkManager 将新的网络配置存储到 |
关于机器配置操作符
OpenShift Container Platform 4.17 集成了操作系统和集群管理。由于集群管理其自身的更新，包括对集群节点上 Red Hat Enterprise Linux CoreOS (RHCOS) 的更新，因此 OpenShift Container Platform 提供了一种有见地的生命周期管理体验，简化了节点升级的编排。
OpenShift Container Platform 使用三个守护程序集和控制器来简化节点管理。这些守护程序集使用标准的 Kubernetes 风格结构来编排对主机的操作系统更新和配置更改。它们包括
-
machine-config-controller，它协调来自控制平面的机器升级。它监控所有集群节点并编排其配置更新。 -
machine-config-daemon守护进程部署在集群中的每个节点上，根据机器配置和MachineConfigController的指令更新机器配置。当节点检测到更改时，它会驱逐其上的Pod，应用更新并重新启动。这些更改以Ignition配置文件的形式出现，这些文件应用指定的机器配置并控制kubelet配置。更新本身通过容器交付。此过程对于成功管理OpenShift Container Platform和RHCOS更新至关重要。 -
machine-config-server守护进程集，为加入集群的控制平面节点提供Ignition配置文件。
机器配置是Ignition配置的一个子集。machine-config-daemon读取机器配置以查看是否需要执行OSTree更新，或者是否必须应用一系列systemd kubelet文件更改、配置更改或对操作系统或OpenShift Container Platform配置的其他更改。
执行节点管理操作时，您将创建或修改KubeletConfig自定义资源 (CR)。
|
当机器配置发生更改时，机器配置操作符 (MCO) 会自动重新启动所有相应的节点，以便更改生效。 您可以使用节点中断策略来减轻某些机器配置更改造成的干扰。请参阅*了解机器配置更改后节点重启行为*。 或者，您可以在进行更改之前阻止节点在机器配置更改后自动重新启动。通过在相应的机器配置池中将 以下修改不会触发节点重新启动
|
节点上的配置可能与当前应用的机器配置完全不匹配。这种情况称为*配置漂移*。机器配置守护进程 (MCD) 定期检查节点是否存在配置漂移。如果MCD检测到配置漂移，则MCO会将节点标记为degraded，直到管理员更正节点配置。降级的节点处于联机并可运行状态，但无法更新。
其他资源
机器配置概述
机器配置操作符 (MCO) 管理对systemd、CRI-O和Kubelet、内核、网络管理器和其他系统功能的更新。它还提供一个MachineConfig CRD，可以将配置文件写入主机（请参阅machine-config-operator）。了解MCO的功能以及它与其他组件的交互方式对于对OpenShift Container Platform集群进行高级的系统级更改至关重要。以下是一些关于MCO、机器配置及其使用方法的注意事项
-
机器配置按其名称的字典序递增顺序（字母顺序）进行处理。渲染控制器使用列表中的第一个机器配置作为基础，并将其余配置附加到基础机器配置。
-
机器配置可以对代表OpenShift Container Platform节点池的每个系统的操作系统上的文件或服务进行特定更改。
-
MCO对机器池中的操作系统应用更改。所有OpenShift Container Platform集群都从worker和控制平面节点池开始。通过添加更多角色标签，您可以配置自定义节点池。例如，您可以设置一个包含应用程序所需特定硬件功能的自定义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配置设置之前将其包装到机器配置中。
-
当MCO管理的文件在MCO外部发生更改时，机器配置守护进程 (MCD) 将节点设置为
degraded。但是，它不会覆盖有问题的文件，并且应继续处于degraded状态。 -
使用机器配置的一个关键原因是，当您为OpenShift Container Platform集群中的池启动新节点时，它将被应用。
machine-api-operator预配新机器，MCO对其进行配置。
MCO 使用 Ignition 作为配置格式。OpenShift Container Platform 4.6 已从 Ignition 配置规范版本 2 迁移到版本 3。
机器配置可以更改什么？
MCO 可以更改的组件类型包括
-
配置：创建 Ignition 配置对象（请参阅 Ignition 配置规范）来执行诸如修改文件、systemd 服务和其他 OpenShift Container Platform 机器上的功能等操作，包括：
-
配置文件：创建或覆盖
/var或/etc目录中的文件。 -
systemd 单元：创建并设置 systemd 服务的状态，或通过添加其他设置来扩展现有 systemd 服务。
-
用户和组：在安装后更改 passwd 部分中的 SSH 密钥。
-
仅支持使用机器配置更改
core用户的 SSH 密钥。 -
不支持使用机器配置添加新用户。
-
-
-
内核参数：在 OpenShift Container Platform 节点启动时向内核命令行添加参数。
-
内核类型：可以选择指定使用非标准内核来代替标准内核。使用
realtime来使用 RT 内核（用于 RAN）。这仅在某些平台上受支持。使用64k-pages参数启用 64k 页面大小的内核。此设置仅限于具有 64 位 ARM 架构的机器。 -
fips：启用 FIPS 模式。FIPS 应在安装时设置，而不是安装后过程。
-
扩展：通过添加选定的预打包软件来扩展 RHCOS 功能。对于此功能，可用的扩展包括 usbguard 和内核模块。
-
自定义资源（用于
ContainerRuntime和Kubelet）：在机器配置之外，MCO 管理两个特殊的自定义资源，用于修改 CRI-O 容器运行时设置 (ContainerRuntimeCR) 和 Kubelet 服务 (KubeletCR)。
MCO 不是唯一可以在 OpenShift Container Platform 节点上更改操作系统组件的 Operator。其他 Operator 也可以修改操作系统级功能。一个示例是节点调整 Operator，它允许您通过 Tuned 守护程序配置文件进行节点级调整。
安装后可以执行的 MCO 配置任务包含在以下过程中。有关必须在 OpenShift Container Platform 安装期间或之前执行的系统配置任务，请参阅 RHCOS 裸机安装的说明。默认情况下，使用 MCO 进行的许多更改都需要重新引导。
以下修改不会触发节点重新启动
-
当MCO检测到以下任何更改时，它会在不驱逐或重新启动节点的情况下应用更新
-
机器配置的
spec.config.passwd.users.sshAuthorizedKeys参数中SSH密钥的更改。 -
openshift-config命名空间中全局Pull Secret或Pull Secret的更改。 -
Kubernetes API服务器操作符自动轮换
/etc/kubernetes/kubelet-ca.crt证书颁发机构 (CA)。
-
-
当MCO检测到
/etc/containers/registries.conf文件的更改（例如添加或编辑ImageDigestMirrorSet、ImageTagMirrorSet或ImageContentSourcePolicy对象）时，它会驱逐相应的节点，应用更改，然后取消隔离节点。节点驱逐不会针对以下更改发生-
添加具有为每个镜像设置的
pull-from-mirror = "digest-only"参数的注册表。 -
在注册表中添加具有
pull-from-mirror = "digest-only"参数设置的镜像。 -
向
unqualified-search-registries列表添加项目。
-
在其他情况下，您可以通过使用节点中断策略来减轻 MCO 进行更改时对工作负载的中断。有关信息，请参阅了解机器配置更改后的节点重启行为。
在某些情况下，节点上的配置可能与当前应用的机器配置完全不匹配。此状态称为配置漂移。机器配置守护程序 (MCD) 定期检查节点的配置漂移。如果 MCD 检测到配置漂移，则 MCO 会将节点标记为已降级，直到管理员更正节点配置。已降级的节点处于联机并可运行状态，但无法更新。有关配置漂移的更多信息，请参阅了解配置漂移检测。
使用机器配置池进行节点配置管理
运行控制平面组件或用户工作负载的机器根据它们处理的资源类型分为几组。这些机器组称为机器配置池 (MCP)。每个 MCP 管理一组节点及其相应的机器配置。节点的角色决定了它属于哪个 MCP；MCP 根据其分配的节点角色标签来管理节点。MCP 中的节点具有相同的配置；这意味着可以根据工作负载的增加或减少来扩展和缩减节点。
默认情况下，集群安装时会创建两个 MCP：master 和 worker。每个默认 MCP 都有由机器配置操作员 (MCO) 应用的定义配置，MCO 负责管理 MCP 并促进 MCP 更新。
对于工作节点，您可以创建其他 MCP 或自定义池来管理具有超出默认节点类型的自定义用例的节点。不支持控制平面节点的自定义 MCP。
自定义池是从工作池继承其配置的池。它们使用针对工作池的任何机器配置，但增加了仅将更改部署到自定义池的功能。由于自定义池从工作池继承其配置，因此对工作池的任何更改也都会应用于自定义池。MCO 不支持不从工作池继承其配置的自定义池。
|
一个节点只能包含在一个 MCP 中。如果一个节点具有多个对应于多个 MCP 的标签，例如 |
建议为要在集群中管理的每个节点角色创建一个自定义池。例如，如果您创建 infra 节点来处理 infra 工作负载，建议创建一个自定义 infra MCP 来将这些节点组合在一起。如果您将infra 角色标签应用于工作节点，使其具有worker,infra 双标签，但没有自定义 infra MCP，则 MCO 会将其视为工作节点。如果您从节点中删除worker 标签并应用infra 标签而不将其分组到自定义池中，则 MCO 不会识别该节点，并且该节点不受集群管理。
|
任何仅运行 infra 工作负载且标记有 |
MCO 独立地为池应用更新；例如，如果有一个影响所有池的更新，则每个池的节点将彼此并行更新。如果您添加自定义池，则该池中的节点也将尝试与主节点和工作节点同时更新。
节点上的配置可能与当前应用的机器配置完全不匹配。这种情况称为*配置漂移*。机器配置守护进程 (MCD) 定期检查节点是否存在配置漂移。如果MCD检测到配置漂移，则MCO会将节点标记为degraded，直到管理员更正节点配置。降级的节点处于联机并可运行状态，但无法更新。
了解机器配置操作员节点耗尽行为
当您使用机器配置更改系统功能（例如添加新的配置文件、修改 systemd 单元或内核参数或更新 SSH 密钥）时，机器配置操作员 (MCO) 会应用这些更改并确保每个节点都处于所需的配置状态。
进行更改后，MCO 将生成新的渲染机器配置。在大多数情况下，应用新的渲染机器配置时，操作员会在每个受影响的节点上执行以下步骤，直到所有受影响的节点都具有更新的配置
-
隔离。MCO 将节点标记为不可调度其他工作负载。
-
驱逐。MCO 终止节点上所有正在运行的工作负载，导致这些工作负载被重新调度到其他节点上。
-
应用。MCO 根据需要将新配置写入节点。
-
重启。MCO 重启节点。
-
取消隔离。MCO 将节点标记为可调度工作负载。
在此过程中，MCO 基于机器配置池中设置的MaxUnavailable值维护所需的 Pod 数量。
|
某些情况可能会阻止 MCO 驱逐节点。如果 MCO 无法驱逐节点，则操作员将无法重启节点，从而阻止通过机器配置对节点进行的任何更改。有关更多信息和缓解步骤，请参阅MCCDrainError运行手册。 |
如果 MCO 驱逐主节点上的 Pod，请注意以下情况：
-
在单节点 OpenShift 集群中，MCO 跳过驱逐操作。
-
为了防止干扰服务（例如 etcd），MCO 不会驱逐静态 Pod。
|
在某些情况下，节点不会被驱逐。有关更多信息，请参阅“关于机器配置操作员”。 |
可以通过使用节点中断策略或禁用控制平面重启来减轻驱逐和重启周期造成的干扰。有关更多信息，请参阅“了解机器配置更改后节点重启行为”和“禁用机器配置操作员自动重启”。
了解配置漂移检测
在某些情况下，节点的磁盘状态可能与其在机器配置中配置的状态不同。这称为配置漂移。例如，集群管理员可能会手动修改通过机器配置配置的文件、systemd 单元文件或文件权限。这会导致配置漂移。配置漂移可能会导致机器配置池中节点之间出现问题，或者在更新机器配置时出现问题。
机器配置操作员 (MCO) 使用机器配置守护程序 (MCD) 定期检查节点的配置漂移。如果检测到配置漂移，MCO 会将节点和机器配置池 (MCP) 设置为Degraded并报告错误。降级的节点在线且可运行，但无法更新。
MCD 在以下任何情况下都会执行配置漂移检测：
-
节点启动时。
-
在机器配置中指定的任何文件（Ignition 文件和 systemd drop-in 单元）在机器配置外部被修改后。
-
应用新的机器配置之前。
如果将新的机器配置应用于节点，则 MCD 会暂时关闭配置漂移检测。需要此关闭操作，因为新的机器配置必然与节点上的机器配置不同。应用新的机器配置后，MCD 会使用新的机器配置重新启动配置漂移检测。
执行配置漂移检测时，MCD 会验证文件内容和权限是否完全与当前应用的机器配置指定的权限匹配。通常情况下，MCD 在检测触发后不到一秒钟内就能检测到配置漂移。
如果 MCD 检测到配置漂移，则 MCD 将执行以下任务：
-
向控制台日志发出错误。
-
发出 Kubernetes 事件。
-
停止节点上的进一步检测。
-
将节点和 MCP 设置为
degraded。
可以通过列出 MCP 来检查是否存在降级节点。
$ oc get mcp worker如果 MCP 降级，则DEGRADEDMACHINECOUNT字段的值非零，类似于以下输出：
示例输出
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE
worker rendered-worker-404caf3180818d8ac1f50c32f14b57c3 False True True 2 1 1 1 5h51m可以通过检查机器配置池来确定问题是否由配置漂移引起。
$ oc describe mcp worker示例输出
...
Last Transition Time: 2021-12-20T18:54:00Z
Message: Node ci-ln-j4h8nkb-72292-pxqxz-worker-a-fjks4 is reporting: "content mismatch for file \"/etc/mco-test-file\"" (1)
Reason: 1 nodes are reporting degraded status on sync
Status: True
Type: NodeDegraded (2)
...| 1 | 此消息表明节点的/etc/mco-test-file文件（由机器配置添加）在机器配置外部发生了更改。 |
| 2 | 节点状态为NodeDegraded。 |
或者，如果知道哪个节点降级，则检查该节点：
$ oc describe node/ci-ln-j4h8nkb-72292-pxqxz-worker-a-fjks4示例输出
...
Annotations: cloud.network.openshift.io/egress-ipconfig: [{"interface":"nic0","ifaddr":{"ipv4":"10.0.128.0/17"},"capacity":{"ip":10}}]
csi.volume.kubernetes.io/nodeid:
{"pd.csi.storage.gke.io":"projects/openshift-gce-devel-ci/zones/us-central1-a/instances/ci-ln-j4h8nkb-72292-pxqxz-worker-a-fjks4"}
machine.openshift.io/machine: openshift-machine-api/ci-ln-j4h8nkb-72292-pxqxz-worker-a-fjks4
machineconfiguration.openshift.io/controlPlaneTopology: HighlyAvailable
machineconfiguration.openshift.io/currentConfig: rendered-worker-67bd55d0b02b0f659aef33680693a9f9
machineconfiguration.openshift.io/desiredConfig: rendered-worker-67bd55d0b02b0f659aef33680693a9f9
machineconfiguration.openshift.io/reason: content mismatch for file "/etc/mco-test-file" (1)
machineconfiguration.openshift.io/state: Degraded (2)
...| 1 | 指示在节点和列出的机器配置之间检测到配置漂移的错误消息。此处的错误消息指示由机器配置添加的/etc/mco-test-file的内容在机器配置外部发生了更改。 |
| 2 | 节点状态为Degraded。 |
可以通过执行以下补救措施之一来纠正配置漂移并将节点返回到Ready状态：
-
确保节点上文件的內容和文件权限与机器配置中配置的内容匹配。可以手动重写文件内容或更改文件权限。
-
在降级节点上生成强制文件。强制文件会导致 MCD 绕过通常的配置漂移检测并重新应用当前的机器配置。
在节点上生成强制文件会导致该节点重启。
检查机器配置池状态
要查看机器配置操作员 (MCO)、其子组件及其管理的资源的状态，请使用以下oc命令：
步骤
-
要查看集群中每个机器配置池 (MCP) 上可用的 MCO 管理节点的数量，请运行以下命令：
$ oc get machineconfigpool示例输出NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-06c9c4… True False False 3 3 3 0 4h42m worker rendered-worker-f4b64… False True False 3 2 2 0 4h42m其中
- UPDATED
-
True状态表示 MCO 已将当前机器配置应用于该 MCP 中的节点。当前机器配置在oc get mcp输出的STATUS字段中指定。False状态表示 MCP 中的节点正在更新。 - UPDATING
-
True状态表示 MCO 正在将MachineConfigPool自定义资源中指定的所需机器配置应用于该 MCP 中的至少一个节点。所需机器配置是新的、已编辑的机器配置。正在更新的节点可能无法用于调度。False状态表示 MCP 中的所有节点都已更新。 - DEGRADED
-
True状态表示 MCO 被阻止将当前或所需的机器配置应用于该 MCP 中的至少一个节点，或者配置失败。降级的节点可能无法用于调度。False状态表示 MCP 中的所有节点都已准备好。 - MACHINECOUNT
-
指示该 MCP 中机器的总数。
- READYMACHINECOUNT
-
指示该 MCP 中已准备好进行调度的机器总数。
- UPDATEDMACHINECOUNT
-
指示该 MCP 中具有当前机器配置的机器总数。
- DEGRADEDMACHINECOUNT
-
指示该 MCP 中标记为已降级或无法协调的机器总数。
在之前的输出中，有三个控制平面（主）节点和三个工作节点。控制平面 MCP 及其关联的节点已更新到当前机器配置。工作 MCP 中的节点正在更新到所需的机器配置。工作 MCP 中的两个节点已更新，一个仍在更新中，如
UPDATEDMACHINECOUNT为2所示。由于DEGRADEDMACHINECOUNT为0且DEGRADED为False，因此没有问题。在 MCP 中的节点更新期间，
CONFIG下列出的机器配置是当前机器配置，MCP 正从该配置进行更新。更新完成后，列出的机器配置是所需的机器配置，MCP 已更新到该配置。如果正在隔离节点，则该节点不包含在
READYMACHINECOUNT中，但包含在MACHINECOUNT中。此外，MCP 状态设置为UPDATING。由于该节点具有当前机器配置，因此它包含在UPDATEDMACHINECOUNT总数中。示例输出NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-06c9c4… True False False 3 3 3 0 4h42m worker rendered-worker-c1b41a… False True False 3 2 3 0 4h42m -
要通过检查
MachineConfigPool自定义资源来检查 MCP 中节点的状态，请运行以下命令：$ oc describe mcp worker示例输出... Degraded Machine Count: 0 Machine Count: 3 Observed Generation: 2 Ready Machine Count: 3 Unavailable Machine Count: 0 Updated Machine Count: 3 Events: <none>如果正在隔离节点，则该节点不包含在
就绪机器数中。它包含在不可用机器数中。示例输出... Degraded Machine Count: 0 Machine Count: 3 Observed Generation: 2 Ready Machine Count: 2 Unavailable Machine Count: 1 Updated Machine Count: 3 -
要查看每个现有的
MachineConfig对象，请运行以下命令：$ oc get machineconfigs示例输出NAME GENERATEDBYCONTROLLER IGNITIONVERSION AGE 00-master 2c9371fbb673b97a6fe8b1c52... 3.2.0 5h18m 00-worker 2c9371fbb673b97a6fe8b1c52... 3.2.0 5h18m 01-master-container-runtime 2c9371fbb673b97a6fe8b1c52... 3.2.0 5h18m 01-master-kubelet 2c9371fbb673b97a6fe8b1c52… 3.2.0 5h18m ... rendered-master-dde... 2c9371fbb673b97a6fe8b1c52... 3.2.0 5h18m rendered-worker-fde... 2c9371fbb673b97a6fe8b1c52... 3.2.0 5h18m请注意，列为
rendered的MachineConfig对象不应更改或删除。 -
要查看特定机器配置（在本例中为
01-master-kubelet）的内容，请运行以下命令：$ oc describe machineconfigs 01-master-kubelet该命令的输出显示此
MachineConfig对象包含配置文件（cloud.conf和kubelet.conf）和 systemd 服务（Kubernetes Kubelet）。示例输出Name: 01-master-kubelet ... Spec: Config: Ignition: Version: 3.2.0 Storage: Files: Contents: Source: data:, Mode: 420 Overwrite: true Path: /etc/kubernetes/cloud.conf Contents: Source: data:,kind%3A%20KubeletConfiguration%0AapiVersion%3A%20kubelet.config.k8s.io%2Fv1beta1%0Aauthentication%3A%0A%20%20x509%3A%0A%20%20%20%20clientCAFile%3A%20%2Fetc%2Fkubernetes%2Fkubelet-ca.crt%0A%20%20anonymous... Mode: 420 Overwrite: true Path: /etc/kubernetes/kubelet.conf Systemd: Units: Contents: [Unit] Description=Kubernetes Kubelet Wants=rpc-statd.service network-online.target crio.service After=network-online.target crio.service ExecStart=/usr/bin/hyperkube \ kubelet \ --config=/etc/kubernetes/kubelet.conf \ ...
如果应用的机器配置出现问题，您可以随时撤消更改。例如，如果您已运行oc create -f ./myconfig.yaml来应用机器配置，则可以通过运行以下命令来删除该机器配置：
$ oc delete -f ./myconfig.yaml如果这是唯一的问题，则受影响池中的节点应返回到非降级状态。这实际上会导致渲染的配置回滚到其先前渲染的状态。
如果您向集群添加自己的机器配置，则可以使用前面示例中所示的命令来检查其状态以及应用它们的池的相关状态。
检查机器配置节点状态
在更新期间，您可能需要监控各个节点的进度，以防出现问题并需要对节点进行故障排除。
要查看机器配置操作器 (MCO) 对集群更新的状态，请使用以下oc命令：
|
改进的 MCO 状态报告仅为技术预览功能。技术预览功能不受 Red Hat 生产服务级别协议 (SLA) 的支持，并且可能功能不完整。Red Hat 不建议在生产环境中使用它们。这些功能可让您提前访问即将推出的产品功能，从而使客户能够在开发过程中测试功能并提供反馈。 有关 Red Hat 技术预览功能的支持范围的更多信息，请参阅技术预览功能支持范围。 |
先决条件
-
您在
FeatureGate自定义资源 (CR) 中设置featureSet: TechPreviewNoUpgrade以启用集群的功能集功能。
步骤
-
通过运行以下命令，获取所有机器配置池中所有节点的更新状态摘要：
$ oc get machineconfignodes示例输出NAME UPDATED UPDATEPREPARED UPDATEEXECUTED UPDATEPOSTACTIONCOMPLETED UPDATECOMPLETED RESUMED ip-10-0-12-194.ec2.internal True False False False False False ip-10-0-17-102.ec2.internal False True False False False False ip-10-0-2-232.ec2.internal False False True False False False ip-10-0-59-251.ec2.internal False False False True False False ip-10-0-59-56.ec2.internal False False False False True True ip-10-0-6-214.ec2.internal False False Unknown False False False其中
- UPDATED
-
True状态表示 MCO 已将当前机器配置应用于该特定节点。False状态表示节点当前正在更新。Unknown状态表示操作正在处理中。 - UPDATEPREPARED
-
False状态表示 MCO 尚未开始协调要分发的新的机器配置。True状态表示 MCO 已完成此更新阶段。Unknown状态表示操作正在处理中。 - UPDATEEXECUTED
-
False状态表示 MCO 尚未开始隔离和排空节点。它还表示磁盘状态和操作系统尚未开始更新。True状态表示 MCO 已完成此更新阶段。Unknown状态表示操作正在处理中。 - UPDATEPOSTACTIONCOMPLETED
-
False状态表示 MCO 尚未开始重新引导节点或关闭守护程序。True状态表示 MCO 已完成重新引导和更新节点状态。Unknown状态表示此阶段的更新过程中发生了错误，或者 MCO 当前正在应用更新。 - UPDATECOMPLETED
-
False状态表示 MCO 尚未开始取消隔离节点并更新节点状态和指标。True状态表示 MCO 已完成更新节点状态和可用指标。 - RESUMED
-
False状态表示 MCO 尚未启动配置漂移监视器。True状态表示节点已恢复运行。Unknown状态表示操作正在处理中。在前面描述的主要阶段内，您可以拥有次要阶段，您可以使用这些阶段更详细地查看更新进度。您可以使用前面命令的
-o wide选项获取包含更新次要阶段的更多信息。这将提供附加的UPDATECOMPATIBLE、UPDATEFILESANDOS、DRAINEDNODE、CORDONEDNODE、REBOOTNODE、RELOADEDCRIO和UNCORDONED列。这些次要阶段并不总是发生，并且取决于您要应用的更新类型。
-
通过运行以下命令，检查特定机器配置池中节点的更新状态：
$ oc get machineconfignodes $(oc get machineconfignodes -o json | jq -r '.items[]|select(.spec.pool.name=="<pool_name>")|.metadata.name') (1)1 池的名称是 MachineConfigPool对象名称。示例输出NAME UPDATED UPDATEPREPARED UPDATEEXECUTED UPDATEPOSTACTIONCOMPLETE UPDATECOMPLETE RESUMED ip-10-0-48-226.ec2.internal True False False False False False ip-10-0-5-241.ec2.internal True False False False False False ip-10-0-74-108.ec2.internal True False False False False False -
通过运行以下命令，检查单个节点的更新状态：
$ oc describe machineconfignode/<node_name> (1)1 节点的名称是 MachineConfigNode对象名称。示例输出Name: <node_name> Namespace: Labels: <none> Annotations: <none> API Version: machineconfiguration.openshift.io/v1alpha1 Kind: MachineConfigNode Metadata: Creation Timestamp: 2023-10-17T13:08:58Z Generation: 1 Resource Version: 49443 UID: 4bd758ab-2187-413c-ac42-882e61761b1d Spec: Node Ref: Name: <node_name> Pool: Name: master ConfigVersion: Desired: rendered-worker-823ff8dc2b33bf444709ed7cd2b9855b (1) Status: Conditions: Last Transition Time: 2023-10-17T13:09:02Z Message: Node has completed update to config rendered-master-cf99e619747ab19165f11e3546c71f1e Reason: NodeUpgradeComplete Status: True Type: Updated Last Transition Time: 2023-10-17T13:09:02Z Message: This node has not yet entered the UpdatePreparing phase Reason: NotYetOccured Status: False Config Version: Current: rendered-worker-823ff8dc2b33bf444709ed7cd2b9855b Desired: rendered-worker-823ff8dc2b33bf444709ed7cd2b9855b (2) Health: Healthy Most Recent Error: Observed Generation: 31 当在节点上检测到新配置时， spec.configversion.desired字段中指定的所需配置会立即更新。2 status.configversion.desired字段中指定的所需配置仅在机器配置守护程序 (MCD) 验证新配置后才更新。MCD 通过检查更新的当前阶段来执行验证。如果更新成功通过UPDATEPREPARED阶段，则状态将添加新配置。
其他资源
-
有关功能门的更多信息，请参阅使用 Web 控制台启用功能集。
了解机器配置操作器证书
机器配置操作器证书用于保护 Red Hat Enterprise Linux CoreOS (RHCOS) 节点和机器配置服务器之间的连接。有关更多信息，请参阅机器配置操作器证书。
查看和交互式使用证书
集群中的机器配置控制器 (MCC) 处理以下证书，这些证书可以在ControllerConfig 资源中找到。
-
/etc/kubernetes/kubelet-ca.crt -
/etc/kubernetes/static-pod-resources/configmaps/cloud-config/ca-bundle.pem -
/etc/pki/ca-trust/source/anchors/openshift-config-user-ca-bundle.crt
MCC 还处理镜像注册表证书及其关联的用户捆绑证书。
您可以获取有关列出证书的信息，包括证书所属的底层捆绑包以及签名和主题数据。
先决条件
-
此过程包含一些可选步骤，这些步骤需要安装
python-yqRPM 包。
步骤
-
运行以下命令获取详细的证书信息：
$ oc get controllerconfig/machine-config-controller -o yaml | yq -y '.status.controllerCertificates'示例输出- bundleFile: KubeAPIServerServingCAData notAfter: '2034-10-23T13:13:02Z' notBefore: '2024-10-25T13:13:02Z' signer: CN=admin-kubeconfig-signer,OU=openshift subject: CN=admin-kubeconfig-signer,OU=openshift - bundleFile: KubeAPIServerServingCAData notAfter: '2024-10-26T13:13:05Z' notBefore: '2024-10-25T13:27:14Z' signer: CN=kubelet-signer,OU=openshift subject: CN=kube-csr-signer_@1729862835 - bundleFile: KubeAPIServerServingCAData notAfter: '2024-10-26T13:13:05Z' notBefore: '2024-10-25T13:13:05Z' signer: CN=kubelet-signer,OU=openshift subject: CN=kubelet-signer,OU=openshift # ... -
使用以下命令检查机器配置池状态，获取在
ControllerConfig资源中找到的信息的简化版本：$ oc get mcp master -o yaml | yq -y '.status.certExpirys'示例输出- bundle: KubeAPIServerServingCAData expiry: '2034-10-23T13:13:02Z' subject: CN=admin-kubeconfig-signer,OU=openshift - bundle: KubeAPIServerServingCAData expiry: '2024-10-26T13:13:05Z' subject: CN=kube-csr-signer_@1729862835 - bundle: KubeAPIServerServingCAData expiry: '2024-10-26T13:13:05Z' subject: CN=kubelet-signer,OU=openshift - bundle: KubeAPIServerServingCAData expiry: '2025-10-25T13:13:05Z' subject: CN=kube-apiserver-to-kubelet-signer,OU=openshift # ...此方法适用于已经使用机器配置池信息的 OpenShift Container Platform 应用程序。
-
检查节点上有哪些镜像注册表证书：
-
登录到节点：
$ oc debug node/<node_name> -
在调试 shell 中将
/host设置为根目录：sh-5.1# chroot /host -
查看
/etc/docker/cert.d目录的内容：sh-5.1# ls /etc/docker/certs.d示例输出image-registry.openshift-image-registry.svc.cluster.local:5000 image-registry.openshift-image-registry.svc:5000
-