支持控制台（Console）开发人员开始试用联系人

第 5 章 安装后机器配置任务

有时您需要更改 OpenShift Container Platform 节点上运行的操作系统。这包括更改网络时间服务的设置、添加内核参数或者以特定的方式配置日志。

除了一些特殊功能外，通过创建称为 Machine Config Operator 管理的 MachineConfig 对象，可以对 OpenShift Container Platform 节点上的操作系统进行大多数更改。

本节中的任务介绍了如何使用 Machine Config Operator 的功能在 OpenShift Container Platform 节点上配置操作系统功能。

重要

NetworkManager 以 key file 的格式将新网络配置保存到 /etc/NetworkManager/system-connections/

在以前的版本中，NetworkManager 将新的网络配置以 ifcfg 格式保存到 /etc/sysconfig/network-scripts/。从 RHEL 9.0 开始，RHEL 将新网络配置存储在 /etc/NetworkManager/system-connections/ 中，采用 key 文件格式。以旧格式存储在 /etc/sysconfig/network-scripts/ 中的连接配置仍可以正常工作。对现有配置集的修改会继续更新旧的文件。

5.1. 了解 Machine Config Operator

5.1.1. Machine Config Operator

用途

Machine Congig Operator 管理并应用基本操作系统和容器运行时的配置和更新，包括内核和 kubelet 之间的所有配置和更新。

有四个组件：

  • machine-config-server：为加入集群的新机器提供 Ignition 配置。
  • machine-config-controller：协调机器升级到 MachineConfig 对象定义的配置。提供用来控制单独一组机器升级的选项。
  • machine-config-daemon：在更新过程中应用新机器配置。验证并验证机器的状态到请求的机器配置。
  • machine-config：提供安装、首次启动和更新一个机器的完整机器配置源。
重要

目前，不支持阻止或限制机器配置服务器端点。机器配置服务器必须公开给网络，以便新置备的机器没有现有配置或状态，才能获取其配置。在这个模型中，信任的根是证书签名请求 (CSR) 端点，即 kubelet 发送其证书签名请求以批准加入集群。因此，机器配置不应用于分发敏感信息，如 secret 和证书。

为确保机器配置服务器端点，端口 22623 和 22624 在裸机场景中是安全的，客户必须配置正确的网络策略。

其他资源

项目

openshift-machine-config-operator

5.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。

5.1.2.1. 机器配置可以更改什么？

MCO 可更改的组件类型包括：

  • config：创建 Ignition 配置对象（请参阅 Ignition 配置规格），以完成修改 OpenShift Container Platform 机器上的文件、systemd 服务和其他功能，包括：

    • Configuration files：创建或覆盖 /var 或 /etc 目录中的文件。
    • systemd units：在附加设置中丢弃并设置 systemd 服务的状态，或者添加到现有 systemd 服务中。

    • 用户和组：在安装后更改 passwd 部分中的 SSH 密钥。

      重要
      • 只有 core 用户才支持使用机器配置更改 SSH 密钥。
      • 不支持使用机器配置添加新用户。
  • 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 模式的更多信息，请参阅在 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 容器运行时设置（ContainerRuntime CR）和 Kubelet 服务（Kubelet CR）。

MCO 不是更改 OpenShift Container Platform 节点上的操作系统组件的唯一 Operator。其他 Operator 也可以修改操作系统级别的功能。一个例子是 Node Tuning Operator，它允许您通过 Tuned 守护进程配置集进行节点级别的性能优化。

安装后可以进行的 MCO 配置任务包括在以下步骤中。如需在 OpenShift Container Platform 安装过程中或之前完成的系统配置任务，请参阅 RHCOS 裸机安装的描述。

在某些情况下，节点上的配置与当前应用的机器配置指定不完全匹配。这个状态被称为 配置偏移。Machine Config Daemon(MCD)定期检查节点是否有配置偏移。如果 MCD 检测到配置偏移，MCO 会将节点标记为 降级(degraded)，直到管理员更正节点配置。降级的节点在线且可操作，但无法更新。有关配置偏移的更多信息，请参阅了解配置偏移检测。

5.1.2.2. 项目

详情请参阅 openshift-machine-config-operator GitHub 站点。

5.1.3. 了解 Machine Config Operator 节点排空行为

当您使用机器配置更改系统功能时（如添加新配置文件、修改 systemd 单元或内核参数或更新 SSH 密钥），Machine Config Operator (MCO) 会应用这些更改，并确保每个节点处于所需的配置状态。

在进行更改后，MCO 会确保生成新的机器配置。在大多数情况下，当应用新的机器配置时，Operator 会在每个受影响的节点上执行以下步骤，直到所有受影响的节点都有更新的配置：

  1. Cordon.对于额外的工作负载，MCO 会将节点标记为不可调度。
  2. Drain.MCO 终止节点上运行的所有工作负载，导致工作负载重新调度到其他节点上。
  3. Apply.MCO 根据需要将新配置写入节点。
  4. 重新启动.MCO 重启节点。
  5. Uncordon.对于工作负载，MCO 将节点标记为可调度。

在此过程中，MCO 根据机器配置池中设置的 MaxUnavailable 值维护所需的 pod 数量。

如果 MCO 在 master 节点上排空 pod，请注意以下条件：

  • 在单节点 OpenShift 集群中，MCO 会跳过排空操作。
  • MCO 不会排空静态 pod，以防止干扰服务（如 etcd）。
注意

在某些情况下，节点不会被排空。如需更多信息，请参阅 "About the Machine Config Operator"。

您可以通过禁用 control plane 重启来缓解排空和重启周期造成的中断。如需更多信息，请参阅"禁用 Machine Config Operator 自动重新引导"。

其他资源

5.1.4. 了解配置偏移检测

当节点的磁盘上状态与机器配置中配置的内容不同时，可能会出现情况。这称为 配置偏移(drift)。例如，集群管理员可能会手动修改一个文件、systemd 单元文件，或者通过机器配置配置的文件权限。这会导致配置偏移。配置偏移可能会导致 Machine Config Pool 中的节点或机器配置更新时出现问题。

Machine Config Operator(MCO)使用 Machine Config Daemon(MCD)定期检查节点是否有配置偏移。如果检测到，MCO 会将节点和机器配置池(MCP)设置为 Degraded，并报告错误。降级的节点在线且可操作，但无法更新。

MCD 在出现任何以下条件时执行配置偏移检测：

  • 当节点引导时。
  • 在机器配置中指定的任何文件（Ignition 文件和 systemd 置入单元）后，会在机器配置外修改。

  • 应用新机器配置前。

    注意

    如果您将新机器配置应用到节点，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 绕过常见的配置偏移检测并消除了当前的机器配置。

    注意

    在节点上生成强制文件会导致该节点重新引导。

5.1.5. 检查机器配置池状态

要查看 Machine Config Operator（MCO）、其子组件及其管理的资源的状态，请使用以下 oc 命令：

流程

  1. 要查看集群中为每个机器配置池 (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 中标记为 degraded 或 unreconcilable 的机器总数。

    在前面的输出中，有三个 control plane (master) 节点和三个 worker 节点。control plane MCP 和关联的节点更新至当前机器配置。worker MCP 中的节点会更新为所需的机器配置。worker MCP 中的两个节点被更新，一个仍在更新，如 UPDATEDMACHINECOUNT 为 2。没有问题，如 DEGRADEDMACHINECOUNT 为 0，DEGRADED 为 False。

    虽然 MCP 中的节点正在更新，但 CONFIG 下列出的机器配置是当前的机器配置，该配置会从这个配置进行更新。更新完成后，列出的机器配置是所需的机器配置，它被更新为 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

  2. 要通过检查 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>

    注意

    如果节点被封锁，则节点不包含在 Ready Machine Count 中。它包含在 Unavailable Machine Count 中：

    输出示例

    ...
  Degraded Machine Count:     0
  Machine Count:              3
  Observed Generation:        2
  Ready Machine Count:        2
  Unavailable Machine Count:  1
  Updated Machine Count:      3

  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 对象并不意味着要更改或删除。

  4. 要查看特定机器配置的内容（本例中为 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

如果这是唯一的问题，则受影响池中的节点应返回非降级状态。这会导致呈现的配置回滚到其之前更改的状态。

如果在集群中添加自己的机器配置，您可以使用上例中显示的命令检查其状态以及应用到它们的池的相关状态。

5.1.6. 检查机器配置节点状态

在更新过程中，您可能希望监控单个节点的进度，以防出现问题，您需要对节点进行故障排除。

要查看集群的 Machine Config Operator (MCO) 更新的状态，请使用以下 oc 命令：

重要

改进了 MCO 状态报告只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议（SLA）支持，且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能，并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的更多信息，请参阅技术预览功能支持范围。

流程

  1. 运行以下命令，获取所有机器配置池中所有节点的更新状态概述： 

    $ 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 列。这些辅助阶段并不总是发生，并依赖于您要应用的更新类型。

  2. 运行以下命令，检查特定机器配置池中节点的更新状态： 

    $ 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

  3. 运行以下命令，检查单个节点的更新状态： 

    $ 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:  3

    1
    在节点上检测到新配置时，spec.configversion.desired 字段指定所需的配置会立即更新。
    2
    只有在 Machine Config Daemon (MCD)验证新配置时，status.configversion.desired 字段中指定的配置才会更新。MCD 通过检查更新的当前阶段来执行验证。如果更新成功通过 UPDATEPREPARED 阶段，则状态会添加新配置。

5.1.7. 查看证书并与其交互

以下证书由 Machine Config Controller (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 还处理镜像 registry 证书及其关联的用户捆绑包证书。

您可以获取有关列出的证书的信息，包括减少证书的捆绑包，以及签名和主题数据。

流程

  • 运行以下命令来获取详细的证书信息： 

    $ oc get controllerconfig/machine-config-controller -o yaml | yq -y '.status.controllerCertificates'

    输出示例

    "controllerCertificates": [
                   {
                       "bundleFile": "KubeAPIServerServingCAData",
                       "signer": "<signer_data1>",
                       "subject": "CN=openshift-kube-apiserver-operator_node-system-admin-signer@168909215"
                   },
                   {
                       "bundleFile": "RootCAData",
                       "signer": "<signer_data2>",
                       "subject": "CN=root-ca,OU=openshift"
                   }
                ]

  • 使用以下命令检查机器配置池状态，获取 ControllerConfig 中找到信息的更简单版本： 

    $ oc get mcp master -o yaml | yq -y '.status.certExpirys'

    输出示例

    status:
  certExpirys:
  - bundle: KubeAPIServerServingCAData
    subject: CN=admin-kubeconfig-signer,OU=openshift
  - bundle: KubeAPIServerServingCAData
    subject: CN=kube-csr-signer_@1689585558
  - bundle: KubeAPIServerServingCAData
    subject: CN=kubelet-signer,OU=openshift
  - bundle: KubeAPIServerServingCAData
    subject: CN=kube-apiserver-to-kubelet-signer,OU=openshift
  - bundle: KubeAPIServerServingCAData
    subject: CN=kube-control-plane-signer,OU=openshift

    此方法适用于已经消耗机器配置池信息的 OpenShift Container Platform 应用程序。

  • 通过查看 /etc/docker/cert.d 目录的内容来检查节点上哪些镜像 registry 证书： 

    # ls /etc/docker/certs.d

    输出示例

    image-registry.openshift-image-registry.svc.cluster.local:5000 image-registry.openshift-image-registry.svc:5000

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

© 2024 Red Hat, Inc.