支持控制台（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

OpenShift Container Platform 4.14 集成了操作系统和集群管理。由于集群管理自己的更新，包括集群节点上 Red Hat Enterprise Linux CoreOS (RHCOS) 的更新，因此 OpenShift Container Platform 提供了可靠的生命周期管理体验，能够简化节点升级的编配。

OpenShift Container Platform 使用三个守护进程集和控制器来简化节点管理。这些守护进程集通过使用标准的 Kubernetes 式构造来编配操作系统更新和主机配置更改。它们包括：

  • machine-config-controller，协调从 control plane 进行的机器升级。它监控所有集群节点并编配其配置更新。
  • machine-config-daemon 守护进程集在集群中的每个节点上运行，并根据 MachineConfigController 的指示将机器更新为机器配置定义的配置。 当节点检测到更改时，它会排空其 pod，应用更新并重启。这些更改以 Ignition 配置文件的形式出现，这些文件应用指定的机器配置并控制 kubelet 配置。更新本身在容器中交付。此过程是成功管理 OpenShift Container Platform 和 RHCOS 更新的关键。
  • machine-config-server 守护进程集，在加入集群时为 control plane 节点提供 Ignition 配置文件。

机器配置是 Ignition 配置的子集。machine-config-daemon 读取机器配置，以查看是否需要进行 OSTree 更新，或者是否必须应用一系列 systemd kubelet 文件更改、配置更改，或者对操作系统或 OpenShift Container Platform 配置的其他更改。

执行节点管理操作时，您可以创建或修改 KubeletConfig 自定义资源(CR)。

重要

当对机器配置进行修改时，Machine Config Operator（MCO） 会自动重启所有对应的节点，以使更改生效。

要防止节点在机器配置更改后自动重启，在更改之前，必须通过在相应的机器配置池中将 spec.paused 字段设置为 true 来暂停自动引导过程。暂停后，机器配置更改不会生效，除非将 spec.paused 字段设置为 false，且节点已重启至新配置。

以下修改不会触发节点重新引导：

  • 当 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 列表中添加项目。

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

5.1.1. 机器配置概述

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.1.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）。这只在选择的平台上被支持。
  • 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.1.2. 项目

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

5.1.2. 了解 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 排空节点。如果 MCO 无法排空节点，Operator 将无法重启该节点，从而导致通过机器配置对节点进行任何更改。如需更多信息和缓解步骤，请参阅 MCCDrainError runbook。

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

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

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

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

5.1.3. 了解配置偏移检测

当节点的磁盘上状态与机器配置中配置的内容不同时，可能会出现情况。这称为 配置偏移(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.4. 检查机器配置池状态

要查看 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.5. 查看证书并与其交互

以下证书由 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 证书及其关联的用户捆绑包证书。

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

先决条件

  • 此流程包含需要安装 python-yq RPM 软件包的可选步骤。

流程

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

    $ 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
# ...

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

    $ 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 应用程序。

  • 检查节点上有哪些镜像 registry 证书：

    1. 登录到节点： 

      $ oc debug node/<node_name>

    2. 将 /host 设置为 debug shell 中的根目录： 

      sh-5.1# chroot /host

    3. 查看 /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

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.