机器配置

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

流程

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 \ ...

流程

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 阶段，则状态会添加新配置。

流程

1. 创建一个 Butane 配置，包括 chrony.conf 文件的内容。例如，要在 worker 节点上配置 chrony，请创建一个 99-worker-chrony.bu 文件。

   注意

   如需有关 Butane 的信息，请参阅"使用 Butane 创建机器配置"。

   variant: openshift
   version: 4.16.0
   metadata:
     name: 99-worker-chrony 1
     labels:
       machineconfiguration.openshift.io/role: worker 2
   storage:
     files:
     - path: /etc/chrony.conf
       mode: 0644 3
       overwrite: true
       contents:
         inline: |
           pool 0.rhel.pool.ntp.org iburst 4
           driftfile /var/lib/chrony/drift
           makestep 1.0 3
           rtcsync
           logdir /var/log/chrony

   1 2

   在 control plane 节点上，在这两个位置中将 master 替换为 worker。

   3

   为机器配置文件的 mode 字段指定数值模式。在创建文件并应用更改后，模式 将转换为十进制值。您可以使用 oc get mc <mc-name> -o yaml 命令来检查 YAML 文件。

   4

   指定任何有效的、可访问的时间源，如 DHCP 服务器提供的源。或者，您可以指定以下 NTP 服务器：1.rhel.pool.ntp.org, 2.rhel.pool.ntp.org, 或 3.rhel.pool.ntp.org。

2. 使用 Butane 生成 MachineConfig 对象文件 99-worker-chrony.yaml，其中包含要交付至节点的配置：

   $ butane 99-worker-chrony.bu -o 99-worker-chrony.yaml

3. 使用以下两种方式之一应用配置：

   • 如果集群还没有运行，在生成清单文件后，将 MachineConfig 对象文件添加到 <installation_directory>/openshift 目录中，然后继续创建集群。

   • 如果集群已在运行，请应用该文件：

     $ oc apply -f ./99-worker-chrony.yaml

流程

1. 创建 MachineConfig CR，为指定节点角色禁用 chronyd。

   1. 在 disable-chronyd.yaml 文件中保存以下 YAML：

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfig
      metadata:
        labels:
          machineconfiguration.openshift.io/role: <node_role> 1
        name: disable-chronyd
      spec:
        config:
          ignition:
            version: 3.2.0
          systemd:
            units:
              - contents: |
                  [Unit]
                  Description=NTP client/server
                  Documentation=man:chronyd(8) man:chrony.conf(5)
                  After=ntpdate.service sntp.service ntpd.service
                  Conflicts=ntpd.service systemd-timesyncd.service
                  ConditionCapability=CAP_SYS_TIME
                  [Service]
                  Type=forking
                  PIDFile=/run/chrony/chronyd.pid
                  EnvironmentFile=-/etc/sysconfig/chronyd
                  ExecStart=/usr/sbin/chronyd $OPTIONS
                  ExecStartPost=/usr/libexec/chrony-helper update-daemon
                  PrivateTmp=yes
                  ProtectHome=yes
                  ProtectSystem=full
                  [Install]
                  WantedBy=multi-user.target
                enabled: false
                name: "chronyd.service"

      1

      要禁用 chronyd 的节点角色，如 master。

   2. 运行以下命令来创建 MachineConfig CR：

      $ oc create -f disable-chronyd.yaml

流程

1. 列出 OpenShift Container Platform 集群的现有 MachineConfig 对象，以确定如何标记您的机器配置：

   $ oc get MachineConfig

   输出示例

   NAME                                               GENERATEDBYCONTROLLER                      IGNITIONVERSION   AGE
   00-master                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   00-worker                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   01-master-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   01-master-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   01-worker-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   01-worker-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   99-master-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   99-master-ssh                                                                                 3.2.0             40m
   99-worker-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   99-worker-ssh                                                                                 3.2.0             40m
   rendered-master-23e785de7587df95a4b517e0647e5ab7   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   rendered-worker-5d596d9293ca3ea80c896a1191735bb1   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m

2. 创建一个用于标识内核参数的 MachineConfig 对象文件（例如 05-worker-kernelarg-selinuxpermissive.yaml）

   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: worker1
     name: 05-worker-kernelarg-selinuxpermissive2
   spec:
     kernelArguments:
       - enforcing=03

   1

   仅将新内核参数应用到 worker 节点。

   2

   用于标识它插入到机器配置中的什么位置（05）以及发挥什么作用（添加一个内核参数来配置 SELinux permissive 模式）。

   3

   将确切的内核参数标识为 enforcing=0。

3. 创建新机器配置：

   $ oc create -f 05-worker-kernelarg-selinuxpermissive.yaml

4. 检查机器配置以查看是否添加了新配置：

   $ oc get MachineConfig

   输出示例

   NAME                                               GENERATEDBYCONTROLLER                      IGNITIONVERSION   AGE
   00-master                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   00-worker                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   01-master-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   01-master-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   01-worker-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   01-worker-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   05-worker-kernelarg-selinuxpermissive                                                         3.2.0             105s
   99-master-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   99-master-ssh                                                                                 3.2.0             40m
   99-worker-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   99-worker-ssh                                                                                 3.2.0             40m
   rendered-master-23e785de7587df95a4b517e0647e5ab7   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   rendered-worker-5d596d9293ca3ea80c896a1191735bb1   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m

5. 检查节点：

   $ oc get nodes

   输出示例

   NAME                           STATUS                     ROLES    AGE   VERSION
   ip-10-0-136-161.ec2.internal   Ready                      worker   28m   v1.29.4
   ip-10-0-136-243.ec2.internal   Ready                      master   34m   v1.29.4
   ip-10-0-141-105.ec2.internal   Ready,SchedulingDisabled   worker   28m   v1.29.4
   ip-10-0-142-249.ec2.internal   Ready                      master   34m   v1.29.4
   ip-10-0-153-11.ec2.internal    Ready                      worker   28m   v1.29.4
   ip-10-0-153-150.ec2.internal   Ready                      master   34m   v1.29.4

   您可以发现，在应用更改时每个 worker 节点上的调度都会被禁用。

6. 前往其中一个 worker 节点并列出内核命令行参数（主机上的 /proc/cmdline 中），以检查内核参数确实已发挥作用：

   $ oc debug node/ip-10-0-141-105.ec2.internal

   输出示例

   Starting pod/ip-10-0-141-105ec2internal-debug ...
   To use host binaries, run `chroot /host`
   
   sh-4.2# cat /host/proc/cmdline
   BOOT_IMAGE=/ostree/rhcos-... console=tty0 console=ttyS0,115200n8
   rootflags=defaults,prjquota rw root=UUID=fd0... ostree=/ostree/boot.0/rhcos/16...
   coreos.oem.id=qemu coreos.oem.id=ec2 ignition.platform.id=ec2 enforcing=0
   
   sh-4.2# exit

   您应看到 enforcing=0 参数已添加至其他内核参数。

流程

1. 要在 control plane 节点上启用多路径安装后：

   • 创建机器配置文件，如 99-master-kargs-mpath.yaml，该文件指示集群添加 master 标签并标识多路径内核参数，例如：

     apiVersion: machineconfiguration.openshift.io/v1
     kind: MachineConfig
     metadata:
       labels:
         machineconfiguration.openshift.io/role: "master"
       name: 99-master-kargs-mpath
     spec:
       kernelArguments:
         - 'rd.multipath=default'
         - 'root=/dev/disk/by-label/dm-mpath-root'

2. 在 worker 节点上启用多路径安装后：

   • 创建机器配置文件，如 99-worker-kargs-mpath.yaml，该文件指示集群添加 worker 标签并标识多路径内核参数，例如：

     apiVersion: machineconfiguration.openshift.io/v1
     kind: MachineConfig
     metadata:
       labels:
         machineconfiguration.openshift.io/role: "worker"
       name: 99-worker-kargs-mpath
     spec:
       kernelArguments:
         - 'rd.multipath=default'
         - 'root=/dev/disk/by-label/dm-mpath-root'

3. 使用之前创建的 master 或 worker YAML 文件创建新机器配置：

   $ oc create -f ./99-worker-kargs-mpath.yaml

4. 检查机器配置以查看是否添加了新配置：

   $ oc get MachineConfig

   输出示例

   NAME                                               GENERATEDBYCONTROLLER                      IGNITIONVERSION   AGE
   00-master                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   00-worker                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   01-master-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   01-master-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   01-worker-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   01-worker-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   99-master-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   99-master-ssh                                                                                 3.2.0             40m
   99-worker-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   99-worker-kargs-mpath                              52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             105s
   99-worker-ssh                                                                                 3.2.0             40m
   rendered-master-23e785de7587df95a4b517e0647e5ab7   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   rendered-worker-5d596d9293ca3ea80c896a1191735bb1   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m

5. 检查节点：

   $ oc get nodes

   输出示例

   NAME                           STATUS                     ROLES    AGE   VERSION
   ip-10-0-136-161.ec2.internal   Ready                      worker   28m   v1.29.4
   ip-10-0-136-243.ec2.internal   Ready                      master   34m   v1.29.4
   ip-10-0-141-105.ec2.internal   Ready,SchedulingDisabled   worker   28m   v1.29.4
   ip-10-0-142-249.ec2.internal   Ready                      master   34m   v1.29.4
   ip-10-0-153-11.ec2.internal    Ready                      worker   28m   v1.29.4
   ip-10-0-153-150.ec2.internal   Ready                      master   34m   v1.29.4

   您可以发现，在应用更改时每个 worker 节点上的调度都会被禁用。

6. 前往其中一个 worker 节点并列出内核命令行参数（主机上的 /proc/cmdline 中），以检查内核参数确实已发挥作用：

   $ oc debug node/ip-10-0-141-105.ec2.internal

   输出示例

   Starting pod/ip-10-0-141-105ec2internal-debug ...
   To use host binaries, run `chroot /host`
   
   sh-4.2# cat /host/proc/cmdline
   ...
   rd.multipath=default root=/dev/disk/by-label/dm-mpath-root
   ...
   
   sh-4.2# exit

   您应看到添加的内核参数。

流程

1. 为实时内核创建一个机器配置：创建一个 YAML 文件（例如，99-worker-realtime.yaml），其中包含一个 realtime 内核类型的 MachineConfig 对象。本例告诉集群在所有 worker 节点中使用实时内核：

   $ cat << EOF > 99-worker-realtime.yaml
   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: "worker"
     name: 99-worker-realtime
   spec:
     kernelType: realtime
   EOF

2. 将机器配置添加到集群。键入以下内容将机器配置添加到集群中：

   $ oc create -f 99-worker-realtime.yaml

3. 检查实时内核： 每当受影响节点重新引导后，登录到集群，并运行以下命令来确保您配置的节点组中使用实时内核替换了常规内核：

   $ oc get nodes

   输出示例

   NAME                                        STATUS  ROLES    AGE   VERSION
   ip-10-0-143-147.us-east-2.compute.internal  Ready   worker   103m  v1.29.4
   ip-10-0-146-92.us-east-2.compute.internal   Ready   worker   101m  v1.29.4
   ip-10-0-169-2.us-east-2.compute.internal    Ready   worker   102m  v1.29.4

   $ oc debug node/ip-10-0-143-147.us-east-2.compute.internal

   输出示例

   Starting pod/ip-10-0-143-147us-east-2computeinternal-debug ...
   To use host binaries, run `chroot /host`
   
   sh-4.4# uname -a
   Linux <worker_node> 4.18.0-147.3.1.rt24.96.el8_1.x86_64 #1 SMP PREEMPT RT
           Wed Nov 27 18:29:55 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

   内核名称包含 rt 和 "PREMPT RT" 来表示这是一个实时内核。

4. 要返回常规内核，请删除 MachineConfig 对象：

   $ oc delete -f 99-worker-realtime.yaml

流程

1. 创建一个 Butane 配置文件 40-worker-custom-journald.bu，其中包含带有所需设置的 /etc/systemd/journald.conf 文件。

   注意

   有关 Butane 的信息，请参阅"使用 Butane 创建机器配置"。

   variant: openshift
   version: 4.16.0
   metadata:
     name: 40-worker-custom-journald
     labels:
       machineconfiguration.openshift.io/role: worker
   storage:
     files:
     - path: /etc/systemd/journald.conf
       mode: 0644
       overwrite: true
       contents:
         inline: |
           # Disable rate limiting
           RateLimitInterval=1s
           RateLimitBurst=10000
           Storage=volatile
           Compress=no
           MaxRetentionSec=30s

2. 使用 Butane 生成 MachineConfig 对象文件 40-worker-custom-journald.yaml，包含要发送到 worker 节点的配置：

   $ butane 40-worker-custom-journald.bu -o 40-worker-custom-journald.yaml

3. 将机器配置应用到池：

   $ oc apply -f 40-worker-custom-journald.yaml

4. 检查是否应用新机器配置，并且节点是否处于降级状态。它可能需要几分钟时间。worker 池将显示更新进行中，每个节点都成功应用了新的机器配置：

   $ oc get machineconfigpool
   NAME   CONFIG             UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE
   master rendered-master-35 True    False    False    3            3                 3                   0                    34m
   worker rendered-worker-d8 False   True     False    3            1                 1                   0                    34m

5. 要检查是否应用了更改，您可以登录到 worker 节点：

   $ oc get node | grep worker
   ip-10-0-0-1.us-east-2.compute.internal   Ready    worker   39m   v0.0.0-master+$Format:%h$
   $ oc debug node/ip-10-0-0-1.us-east-2.compute.internal
   Starting pod/ip-10-0-141-142us-east-2computeinternal-debug ...
   ...
   sh-4.2# chroot /host
   sh-4.4# cat /etc/systemd/journald.conf
   # Disable rate limiting
   RateLimitInterval=1s
   RateLimitBurst=10000
   Storage=volatile
   Compress=no
   MaxRetentionSec=30s
   sh-4.4# exit

流程

1. 为扩展创建机器配置：创建一个 YAML 文件（如 80-extensions.yaml），其中包含 MachineConfig extensions 对象。本例告诉集群添加 usbguard 扩展。

   $ cat << EOF > 80-extensions.yaml
   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: worker
     name: 80-worker-extensions
   spec:
     config:
       ignition:
         version: 3.2.0
     extensions:
       - usbguard
   EOF

2. 将机器配置添加到集群。键入以下内容将机器配置添加到集群中：

   $ oc create -f 80-extensions.yaml

   这会将所有 worker 节点设置为安装 usbguard 的 rpm 软件包。

3. 检查是否应用了扩展：

   $ oc get machineconfig 80-worker-extensions

   输出示例

   NAME                 GENERATEDBYCONTROLLER IGNITIONVERSION AGE
   80-worker-extensions                       3.2.0           57s

4. 检查是否应用新机器配置，并且节点是否处于降级状态。它可能需要几分钟时间。worker 池将显示更新进行中，每台机器都成功应用了新机器配置：

   $ oc get machineconfigpool

   输出示例

   NAME   CONFIG             UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE
   master rendered-master-35 True    False    False    3            3                 3                   0                    34m
   worker rendered-worker-d8 False   True     False    3            1                 1                   0                    34m

5. 检查扩展。要检查是否应用了扩展，请运行：

   $ oc get node | grep worker

   输出示例

   NAME                                        STATUS  ROLES    AGE   VERSION
   ip-10-0-169-2.us-east-2.compute.internal    Ready   worker   102m  v1.29.4

   $ oc debug node/ip-10-0-169-2.us-east-2.compute.internal

   输出示例

   ...
   To use host binaries, run `chroot /host`
   sh-4.4# chroot /host
   sh-4.4# rpm -q usbguard
   usbguard-0.7.4-4.el8.x86_64.rpm

流程

1. 创建 Butane 配置文件 98-worker-firmware-blob.bu，它会更新搜索路径，以便其为 root 所有且对本地存储可写。以下示例将本地工作站的自定义 blob 文件放在 /var/lib/firmware 下的节点上。

   注意

   有关 Butane 的信息，请参阅"使用 Butane 创建机器配置"。

   自定义固件 blob 的 Butane 配置文件

   variant: openshift
   version: 4.16.0
   metadata:
     labels:
       machineconfiguration.openshift.io/role: worker
     name: 98-worker-firmware-blob
   storage:
     files:
     - path: /var/lib/firmware/<package_name> 1
       contents:
         local: <package_name> 2
       mode: 0644 3
   openshift:
     kernel_arguments:
       - 'firmware_class.path=/var/lib/firmware' 4

   1

   设置将固件软件包复制到的节点上的路径。

   2

   指定包含从运行 Butane 的系统上本地文件目录中读取的内容的文件。本地文件的路径相对于 files-dir 目录，必须在下一步中使用 --files-dir 选项指定它。

   3

   为 RHCOS 节点上的文件设置权限。建议把选项设置为 0644 。

   4

   firmware_class.path 参数自定义内核搜索路径，在其中查找从本地工作站复制到节点的根文件系统的自定义固件 Blob。这个示例使用 /var/lib/firmware 作为自定义路径。

2. 运行 Butane 生成 MachineConfig 对象文件，该文件使用名为 98-worker-firmware-blob.yaml 的本地工作站中的固件 blob 副本。固件 blob 包含要传送到节点的配置。以下示例使用 --files-dir 选项指定工作站上本地文件或目录所在的目录：

   $ butane 98-worker-firmware-blob.bu -o 98-worker-firmware-blob.yaml --files-dir <directory_including_package_name>

3. 通过两种方式之一将配置应用到节点：

   • 如果集群还没有运行，在生成清单文件后，将 MachineConfig 对象文件添加到 <installation_directory>/openshift 目录中，然后继续创建集群。

   • 如果集群已在运行，请应用该文件：

     $ oc apply -f 98-worker-firmware-blob.yaml

     已为您创建一个 MachineConfig 对象 YAML 文件，以完成机器的配置。

4. 如果将来需要更新 MachineConfig 对象，请保存 Butane 配置。

流程

1. 使用您的操作系统支持的工具，创建一个哈希密码。例如，通过运行以下命令，使用 mkpasswd 创建哈希密码：

   $ mkpasswd -m SHA-512 testpass

   输出示例

   $ $6$CBZwA6s6AVFOtiZe$aUKDWpthhJEyR3nnhM02NM1sKCpHn9XN.NPrJNQ3HYewioaorpwL3mKGLxvW0AOb4pJxqoqP4nFX77y0p00.8.

2. 创建包含 core 用户名和散列密码的机器配置文件：

   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: worker
     name: set-core-user-password
   spec:
     config:
       ignition:
         version: 3.2.0
       passwd:
         users:
         - name: core 1
           passwordHash: <password> 2

   1

   这必须是 core。

   2

   与 core 帐户一起使用的散列密码。

3. 运行以下命令来创建机器配置：

   $ oc create -f <file-name>.yaml

   节点不会重启，并在几分钟内可用。您可以使用 oc get mcp 来监控要更新的机器配置池，如下例所示：

   NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
   master   rendered-master-d686a3ffc8fdec47280afec446fce8dd   True      False      False      3              3                   3                     0                      64m
   worker   rendered-worker-4605605a5b1f9de1d061e9d350f251e5   False     True       False      3              0                   0                     0                      64m

验证

1. 节点返回 UPDATED=True 状态后，运行以下命令为节点启动 debug 会话：

   $ oc debug node/<node_name>

2. 运行以下命令，将 /host 设置为 debug shell 中的根目录：

   sh-4.4# chroot /host

3. 检查 /etc/shadow 文件的内容：

   输出示例

   ...
   core:$6$2sE/010goDuRSxxv$o18K52wor.wIwZp:19418:0:99999:7:::
   ...

   哈希密码分配给 core 用户。

流程

1. 编辑 machineconfigurations.operator.openshift.io 对象以定义节点中断策略：

   $ oc edit MachineConfiguration cluster -n openshift-machine-config-operator

2. 添加类似如下的节点中断策略：

   apiVersion: operator.openshift.io/v1
   kind: MachineConfiguration
   metadata:
     name: cluster
   # ...
   spec:
     nodeDisruptionPolicy: 1
       files: 2
       - actions: 3
         - reload: 4
             serviceName: chronyd.service 5
           type: Reload
         path: /etc/chrony.conf 6
       sshkey: 7
         actions:
         - type: Drain
         - reload:
             serviceName: crio.service
           type: Reload
         - type: DaemonReload
         - restart:
             serviceName: crio.service
           type: Restart
       units: 8
       - actions:
         - type: Drain
         - reload:
             serviceName: crio.service
           type: Reload
         - type: DaemonReload
         - restart:
             serviceName: crio.service
           type: Restart
         name: test.service

   1

   指定节点中断策略。

   2

   指定对这些路径进行修改的机器配置文件定义和操作列表。此列表支持最多 50 个条目。

   3

   指定在更改指定文件时要执行的一系列操作。操作按此列表中设置的顺序应用。此列表支持最多 10 个条目。

   4

   指定在对指定文件更改时，重新加载这里列出的服务。

   5

   指定要执行操作的服务的完整名称。

   6

   指定由机器配置管理的文件位置。当对 path 中的文件进行了更改时，策略中的操作将应用。

   7

   指定在对集群中的 SSH 密钥更改时要执行的操作列表。

   8

   指定在更改这些单元时要执行的 systemd 单元名称和操作的列表。

先决条件

1. 为您要配置的节点类型获取与静态 MachineConfigPool CR 关联的标签。执行以下步骤之一：

   1. 查看机器配置池：

      $ oc describe machineconfigpool <name>

      例如：

      $ oc describe machineconfigpool worker

      输出示例

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfigPool
      metadata:
        creationTimestamp: 2019-02-08T14:52:39Z
        generation: 1
        labels:
          custom-kubelet: set-max-pods 1

      1

      如果添加了标签，它会出现在 labels 下。

   2. 如果标签不存在，则添加一个键/值对：

      $ oc label machineconfigpool worker custom-kubelet=set-max-pods

流程

1. 查看您可以选择的可用机器配置对象：

   $ oc get machineconfig

   默认情况下，与 kubelet 相关的配置为 01-master-kubelet 和 01-worker-kubelet。

2. 检查每个节点的最大 pod 的当前值：

   $ oc describe node <node_name>

   例如：

   $ oc describe node ci-ln-5grqprb-f76d1-ncnqq-worker-a-mdv94

   在 Allocatable 小节中找到 value: pods: <value>：

   输出示例

   Allocatable:
    attachable-volumes-aws-ebs:  25
    cpu:                         3500m
    hugepages-1Gi:               0
    hugepages-2Mi:               0
    memory:                      15341844Ki
    pods:                        250

3. 通过创建一个包含 kubelet 配置的自定义资源文件，设置 worker 节点上的每个节点的最大 pod：

   重要

   以特定机器配置池为目标的 kubelet 配置也会影响任何依赖的池。例如，为包含 worker 节点的池创建 kubelet 配置也适用于任何子集池，包括包含基础架构节点的池。要避免这种情况，您必须使用仅包含 worker 节点的选择表达式创建新的机器配置池，并让 kubelet 配置以这个新池为目标。

   apiVersion: machineconfiguration.openshift.io/v1
   kind: KubeletConfig
   metadata:
     name: set-max-pods
   spec:
     machineConfigPoolSelector:
       matchLabels:
         custom-kubelet: set-max-pods 1
     kubeletConfig:
       maxPods: 500 2

   1

   输入机器配置池中的标签。

   2

   添加 kubelet 配置。在本例中，使用 maxPods 设置每个节点的最大 pod。

   注意

   kubelet 与 API 服务器进行交互的频率取决于每秒的查询数量 (QPS) 和 burst 值。如果每个节点上运行的 pod 数量有限，使用默认值（kubeAPIQPS 为 50，kubeAPIBurst 为 100）就可以。如果节点上有足够 CPU 和内存资源，则建议更新 kubelet QPS 和 burst 速率。

   apiVersion: machineconfiguration.openshift.io/v1
   kind: KubeletConfig
   metadata:
     name: set-max-pods
   spec:
     machineConfigPoolSelector:
       matchLabels:
         custom-kubelet: set-max-pods
     kubeletConfig:
       maxPods: <pod_count>
       kubeAPIBurst: <burst_rate>
       kubeAPIQPS: <QPS>

   1. 为带有标签的 worker 更新机器配置池：

      $ oc label machineconfigpool worker custom-kubelet=set-max-pods

   2. 创建 KubeletConfig 对象：

      $ oc create -f change-maxPods-cr.yaml

   3. 验证 KubeletConfig 对象是否已创建：

      $ oc get kubeletconfig

      输出示例

      NAME                AGE
      set-max-pods        15m

      根据集群中的 worker 节点数量，等待每个 worker 节点被逐个重启。对于有 3 个 worker 节点的集群，这个过程可能需要大约 10 到 15 分钟。

4. 验证更改是否已应用到节点：

   1. 在 worker 节点上检查 maxPods 值已更改：

      $ oc describe node <node_name>

   2. 找到 Allocatable 小节：

       ...
      Allocatable:
        attachable-volumes-gce-pd:  127
        cpu:                        3500m
        ephemeral-storage:          123201474766
        hugepages-1Gi:              0
        hugepages-2Mi:              0
        memory:                     14225400Ki
        pods:                       500 1
       ...

      1

      在本例中，pods 参数应报告您在 KubeletConfig 对象中设置的值。

5. 验证 KubeletConfig 对象中的更改：

   $ oc get kubeletconfigs set-max-pods -o yaml

   这应该显示 True 状态和 type:Success，如下例所示：

   spec:
     kubeletConfig:
       maxPods: 500
     machineConfigPoolSelector:
       matchLabels:
         custom-kubelet: set-max-pods
   status:
     conditions:
     - lastTransitionTime: "2021-06-30T17:04:07Z"
       message: Success
       status: "True"
       type: Success

1. 为 ContainerRuntimeConfig CR 创建 YAML 文件：

   apiVersion: machineconfiguration.openshift.io/v1
   kind: ContainerRuntimeConfig
   metadata:
    name: overlay-size
   spec:
    machineConfigPoolSelector:
      matchLabels:
        pools.operator.machineconfiguration.openshift.io/worker: '' 1
    containerRuntimeConfig: 2
      logLevel: debug
      overlaySize: 8G

   1

   为您要修改的机器配置池指定一个标签。

   2

   根据需要设置参数。

2. 创建 ContainerRuntimeConfig CR：

   $ oc create -f <file_name>.yaml

3. 验证是否已创建 CR：

   $ oc get ContainerRuntimeConfig

   输出示例

   NAME           AGE
   overlay-size   3m19s

4. 检查是否创建了新的 containerruntime 机器配置：

   $ oc get machineconfigs | grep containerrun

   输出示例

   99-worker-generated-containerruntime   2c9371fbb673b97a6fe8b1c52691999ed3a1bfc2  3.2.0  31s

5. 监控机器配置池，直到所有系统都显示为 ready 状态：

   $ oc get mcp worker

   输出示例

   NAME    CONFIG               UPDATED  UPDATING  DEGRADED  MACHINECOUNT  READYMACHINECOUNT  UPDATEDMACHINECOUNT  DEGRADEDMACHINECOUNT  AGE
   worker  rendered-worker-169  False    True      False     3             1                  1                    0                     9h

6. 验证设置是否在 CRI-O 中应用：

   1. 打开到机器配置池中节点的 oc debug 会话，并运行 chroot /host。

      $ oc debug node/<node_name>

      sh-4.4# chroot /host

   2. 验证 crio.conf 文件中的更改：

      sh-4.4# crio config | grep 'log_level'

      输出示例

      log_level = "debug"

   3. 验证 'storage.conf' 文件中的更改：

      sh-4.4# head -n 7 /etc/containers/storage.conf

      输出示例

      [storage]
        driver = "overlay"
        runroot = "/var/run/containers/storage"
        graphroot = "/var/lib/containers/storage"
        [storage.options]
          additionalimagestores = []
          size = "8G"

流程

1. 创建配置对象：

   $ oc apply -f overlaysize.yml

2. 要将新的 CRI-O 配置应用到 worker 节点，请编辑 worker 机器配置池：

   $ oc edit machineconfigpool worker

3. 根据在 ContainerRuntimeConfig CRD 中设置的 matchLabels 名称添加 custom-crio 标签：

   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfigPool
   metadata:
     creationTimestamp: "2020-07-09T15:46:34Z"
     generation: 3
     labels:
       custom-crio: overlay-size
       machineconfiguration.openshift.io/mco-built-in: ""

4. 保存更改，然后查看机器配置：

   $ oc get machineconfigs

   新的 99-worker-generated-containerruntime 和 rendered-worker-xyz 对象被创建：

   输出示例

   99-worker-generated-containerruntime  4173030d89fbf4a7a0976d1665491a4d9a6e54f1   3.2.0             7m42s
   rendered-worker-xyz                   4173030d89fbf4a7a0976d1665491a4d9a6e54f1   3.2.0             7m36s

5. 创建这些对象后，监控机器配置池以了解要应用的更改：

   $ oc get mcp worker

   worker 节点将 UPDATING 显示为 True，以及机器数量、更新的数字和其他详情：

   输出示例

   NAME   CONFIG              UPDATED   UPDATING   DEGRADED  MACHINECOUNT  READYMACHINECOUNT  UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
   worker rendered-worker-xyz False True False     3             2                   2                    0                      20h

   完成后，worker 节点会从 UPDATING 转换回 False，UPDATEDMACHINECOUNT 数与 MACHINECOUNT 数匹配：

   输出示例

   NAME   CONFIG              UPDATED   UPDATING   DEGRADED  MACHINECOUNT  READYMACHINECOUNT  UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
   worker   rendered-worker-xyz   True      False      False      3         3            3             0           20h

   查看 worker 机器，您会看到新的 8 GB 最大大小配置适用于所有 worker：

   输出示例

   head -n 7 /etc/containers/storage.conf
   [storage]
     driver = "overlay"
     runroot = "/var/run/containers/storage"
     graphroot = "/var/lib/containers/storage"
     [storage.options]
       additionalimagestores = []
       size = "8G"

   在容器内，您会看到 root 分区现在为 8 GB：

   输出示例

   ~ $ df -h
   Filesystem                Size      Used Available Use% Mounted on
   overlay                   8.0G      8.0K      8.0G   0% /

流程

1. 运行以下命令，编辑名为 cluster 的 MachineConfiguration 对象，以启用引导镜像的更新：

   $ oc edit MachineConfiguration cluster

   • 可选：为所有机器集配置引导镜像更新功能：

     apiVersion: operator.openshift.io/v1
     kind: MachineConfiguration
     metadata:
       name: cluster
       namespace: openshift-machine-config-operator
     spec:
     # ...
       managedBootImages: 1
         machineManagers:
         - resource: machinesets
           apiGroup: machine.openshift.io
           selection:
             mode: All 2

     1

     激活引导镜像更新功能。

     2

     指定集群中的所有机器集都会被更新。

   • 可选：为特定机器集配置引导镜像更新功能：

     apiVersion: operator.openshift.io/v1
     kind: MachineConfiguration
     metadata:
       name: cluster
       namespace: openshift-machine-config-operator
     spec:
     # ...
       managedBootImages: 1
         machineManagers:
         - resource: machinesets
           apiGroup: machine.openshift.io
           selection:
             mode: Partial
             partial:
               machineResourceSelector:
                 matchLabels:
                   update-boot-image: "true" 2

     1

     激活引导镜像更新功能。

     2

     指定具有此标签的任何机器集都会被更新。

     提示

     如果机器集中没有适当的标签，请运行以下命令来添加键/值对：

     $ oc label machineset.machine ci-ln-hmy310k-72292-5f87z-worker-a update-boot-image=true -n openshift-machine-api

验证

1. 通过查看机器配置对象来查看引导镜像更新的当前状态：

   $ oc get machineconfiguration cluster -n openshift-machine-api -o yaml

   使用引导镜像引用的机器集示例

   kind: MachineConfiguration
   metadata:
     name: cluster
   # ...
   status:
     conditions:
     - lastTransitionTime: "2024-09-09T13:51:37Z" 1
       message: Reconciled 1 of 2 MAPI MachineSets | Reconciled 0 of 0 CAPI MachineSets
         | Reconciled 0 of 0 CAPI MachineDeployments
       reason: BootImageUpdateConfigurationAdded
       status: "True"
       type: BootImageUpdateProgressing
     - lastTransitionTime: "2024-09-09T13:51:37Z" 2
       message: 0 Degraded MAPI MachineSets | 0 Degraded CAPI MachineSets | 0 CAPI MachineDeployments
       reason: BootImageUpdateConfigurationAdded
       status: "False"
       type: BootImageUpdateDegraded

   1

   引导镜像更新的状态。目前，引导镜像更新不支持 Cluster CAPI Operator 机器集和机器部署。

   2

   指明任何引导镜像是否更新失败。如果有任何更新失败，Machine Config Operator 会降级。在这种情况下，可能需要手动干预。

2. 运行以下命令来获取引导镜像版本：

   $ oc get machinesets <machineset_name> -n openshift-machine-api -o yaml

   使用引导镜像引用的机器集示例

   apiVersion: machine.openshift.io/v1beta1
   kind: MachineSet
   metadata:
     labels:
       machine.openshift.io/cluster-api-cluster: ci-ln-77hmkpt-72292-d4pxp
       update-boot-image: "true"
     name: ci-ln-77hmkpt-72292-d4pxp-worker-a
     namespace: openshift-machine-api
   spec:
   # ...
     template:
   # ...
       spec:
   # ...
         providerSpec:
   # ...
           value:
             disks:
             - autoDelete: true
               boot: true
               image: projects/rhcos-cloud/global/images/rhcos-416-92-202402201450-0-gcp-x86-64 1
   # ...

   1

   此引导镜像与当前的 OpenShift Container Platform 版本相同。

流程

1. 通过编辑 MachineConfiguration 对象禁用更新的引导镜像：

   $ oc edit MachineConfiguration cluster

2. 删除 managedBootImages 小节：

   apiVersion: operator.openshift.io/v1
   kind: MachineConfiguration
   metadata:
     name: cluster
     namespace: openshift-machine-config-operator
   spec:
   # ...
     managedBootImages: 1
       machineManagers:
       - resource: machinesets
         apiGroup: machine.openshift.io
         selection:
           mode: All

   1

   删除整个小节以禁用更新的引导镜像。

流程

1. 可选：运行以下命令，列出您可以自动删除的渲染机器配置。任何在命令输出中被标记为 as it’s currently in use 的渲染的机器配置都不会被删除。

   $ oc adm prune renderedmachineconfigs --pool-name=worker

   输出示例

   Dry run enabled - no modifications will be made. Add --confirm to remove rendered machine configs.
   DRY RUN: Deleted rendered MachineConfig rendered-worker-23d7322831a57f02998e7e1600a0865f
   DRY RUN: Deleted rendered MachineConfig rendered-worker-fc94397dc7c43808c7014683c208956e
   DRY RUN: Skipping deletion of rendered MachineConfig rendered-worker-ad5a3cad36303c363cf458ab0524e7c0 as it's currently in use

   其中：

   pool-name

   可选：指定您要从中删除机器配置的机器配置池。

2. 运行以下命令来删除未使用的渲染机器配置。以下流程中的命令将删除 worker 机器配置池中两个最早未使用的机器配置。

   $ oc adm prune renderedmachineconfigs --pool-name=worker --count=2 --confirm

   其中：

   --count

   可选：指定您要删除的未使用呈现的机器配置的最大数量，从最旧的开始。

   --confirm

   可选：指定您要删除的未使用呈现的机器配置的最大数量，从最旧的开始。

   --pool-name

   可选：指定您要从中删除机器的机器配置池。如果没有指定，则会评估所有池。

1. 为指定池呈现新机器配置。
2. 对池中的节点执行 cordon 和 drain 操作。
3. 将其余机器配置参数写入节点。
4. 将自定义分层镜像应用到节点。
5. 使用新镜像重启节点。

流程

1. 创建 machineOSconfig 对象：

   1. 创建一个类似以下示例的 YAML 文件：

      apiVersion: machineconfiguration.openshift.io/v1alpha1
      kind: MachineOSConfig
      metadata:
        name: layered
      spec:
        machineConfigPool:
          name: <mcp_name> 1
        buildInputs:
          containerFile: 2
          - containerfileArch: noarch
            content: |-
              FROM configs AS final
              RUN rpm-ostree install cowsay && \
                ostree container commit
          imageBuilder: 3
            imageBuilderType: PodImageBuilder
          baseImagePullSecret: 4
            name: global-pull-secret-copy
          renderedImagePushspec: image-registry.openshift-image-registry.svc:5000/openshift/os-image:latest  5
          renderedImagePushSecret: 6
            name: builder-dockercfg-7lzwl
        buildOutputs: 7
          currentImagePullSecret:
            name: builder-dockercfg-7lzwl

      1

      指定与要部署自定义分层镜像的节点关联的机器配置池的名称。

      2

      指定用于配置自定义分层镜像的 Containerfile。

      3

      指定要使用的镜像构建器的名称。这必须是 PodImageBuilder。

      4

      指定 MCO 从 registry 中拉取基础操作系统镜像的 pull secret 名称。

      5

      指定要将新构建的自定义分层镜像推送到的镜像 registry。这可以是集群可访问的任何 registry。本例使用内部 OpenShift Container Platform registry。

      6

      指定 MCO 将新构建的自定义分层镜像推送到该 registry 的推送 secret 名称。

      7

      指定镜像 registry 所需的 secret，节点需要拉取新构建的自定义分层镜像。这应该与用于将镜像推送到存储库的 secret 不同。

   2. 创建 MachineOSConfig 对象：

      $ oc create -f <file_name>.yaml

2. 如果需要，当 MachineOSBuild 对象被创建且处于 READY 状态时，修改您要使用新自定义分层镜像的节点 spec：

   1. 检查 MachineOSBuild 对象是否为 READY。当 SUCCEEDED 值为 True 时，构建已完成。

      $ oc get machineosbuild

      显示 MachineOSBuild 对象已就绪的输出示例

      NAME                                                                PREPARED   BUILDING   SUCCEEDED   INTERRUPTED   FAILED
      layered-rendered-layered-ad5a3cad36303c363cf458ab0524e7c0-builder   False      False      True        False         False

   2. 通过为 MachineOSConfig 对象中指定的机器配置池添加标签来编辑您要部署自定义分层镜像的节点：

      $ oc label node <node_name> 'node-role.kubernetes.io/<mcp_name>='

      其中：

      node-role.kubernetes.io/<mcp_name>=

      指定用于标识用于部署自定义分层镜像的节点选择器。

      当您保存更改时，MCO 会排空、封锁并重启节点。重新引导后，该节点将使用新的自定义分层镜像。

验证

1. 使用以下命令验证新 pod 是否正在运行：

   $ oc get pods -n <machineosbuilds_namespace>

   NAME                                                              READY   STATUS    RESTARTS   AGE
   build-rendered-layered-ad5a3cad36303c363cf458ab0524e7c0           2/2     Running   0          2m40s 1
   # ...
   machine-os-builder-6fb66cfb99-zcpvq                               1/1     Running   0          2m42s 2

   1

   这是自定义分层镜像构建的构建 pod。

   2

   此 pod 可用于故障排除。

2. 验证 MachineOSConfig 对象是否包含对新自定义分层镜像的引用：

   $ oc describe MachineOSConfig <object_name>

   apiVersion: machineconfiguration.openshift.io/v1alpha1
   kind: MachineOSConfig
   metadata:
     name: layered
   spec:
     buildInputs:
       baseImagePullSecret:
         name: global-pull-secret-copy
       containerFile:
       - containerfileArch: noarch
         content: ""
       imageBuilder:
         imageBuilderType: PodImageBuilder
       renderedImagePushSecret:
         name: builder-dockercfg-ng82t-canonical
       renderedImagePushspec: image-registry.openshift-image-registry.svc:5000/openshift-machine-config-operator/os-image:latest
     buildOutputs:
       currentImagePullSecret:
         name: global-pull-secret-copy
     machineConfigPool:
       name: layered
   status:
     currentImagePullspec: image-registry.openshift-image-registry.svc:5000/openshift-machine-config-operator/os-image@sha256:f636fa5b504e92e6faa22ecd71a60b089dab72200f3d130c68dfec07148d11cd 1

   1

   新自定义分层镜像的摘要镜像拉取 spec。

3. 验证 MachineOSBuild 对象是否包含对新自定义分层镜像的引用。

   $ oc describe machineosbuild <object_name>

   apiVersion: machineconfiguration.openshift.io/v1alpha1
   kind: MachineOSBuild
   metadata:
     name: layered-rendered-layered-ad5a3cad36303c363cf458ab0524e7c0-builder
   spec:
     desiredConfig:
       name: rendered-layered-ad5a3cad36303c363cf458ab0524e7c0
     machineOSConfig:
       name: layered
     renderedImagePushspec: image-registry.openshift-image-registry.svc:5000/openshift-machine-config-operator/os-image:latest
   # ...
   status:
     conditions:
       - lastTransitionTime: "2024-05-21T20:25:06Z"
         message: Build Ready
         reason: Ready
         status: "True"
         type: Succeeded
     finalImagePullspec: image-registry.openshift-image-registry.svc:5000/openshift-machine-config-operator/os-image@sha256:f636fa5b504e92e6faa22ecd71a60b089dab72200f3d130c68dfec07148d11cd 1

   1

   新自定义分层镜像的摘要镜像拉取 spec。

4. 验证适当的节点是否使用新的自定义分层镜像：

   1. 以 root 用户身份为 control plane 节点启动一个 debug 会话：

      $ oc debug node/<node_name>

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

      sh-4.4# chroot /host

   3. 运行 rpm-ostree status 命令，以查看自定义分层镜像正在使用：

      sh-5.1# rpm-ostree status

      输出示例

      # ...
      Deployments:
      * ostree-unverified-registry:quay.io/openshift-release-dev/os-image@sha256:f636fa5b504e92e6faa22ecd71a60b089dab72200f3d130c68dfec07148d11cd 1
                         Digest: sha256:bcea2546295b2a55e0a9bf6dd4789433a9867e378661093b6fdee0031ed1e8a4
                        Version: 416.94.202405141654-0 (2024-05-14T16:58:43Z)

      1

      新自定义分层镜像的摘要镜像拉取 spec。

流程

1. 创建机器配置文件。

   1. 创建一个类似以下示例的 YAML 文件：

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfig
      metadata:
        labels:
          machineconfiguration.openshift.io/role: worker 1
        name: os-layer-custom
      spec:
        osImageURL: quay.io/my-registry/custom-image@sha256... 2

      1

      指定要应用自定义分层镜像的机器配置池。

      2

      指定存储库中自定义分层镜像的路径。

   2. 创建 MachineConfig 对象：

      $ oc create -f <file_name>.yaml

      重要

      强烈建议您在推出集群前测试生产环境中的镜像。

1. 检查 worker 机器配置池已使用新机器配置推出：

   1. 检查是否创建了新机器配置：

      $ oc get mc

      输出示例

      NAME                                               GENERATEDBYCONTROLLER                      IGNITIONVERSION   AGE
      00-master                                          5bdb57489b720096ef912f738b46330a8f577803   3.2.0             95m
      00-worker                                          5bdb57489b720096ef912f738b46330a8f577803   3.2.0             95m
      01-master-container-runtime                        5bdb57489b720096ef912f738b46330a8f577803   3.2.0             95m
      01-master-kubelet                                  5bdb57489b720096ef912f738b46330a8f577803   3.2.0             95m
      01-worker-container-runtime                        5bdb57489b720096ef912f738b46330a8f577803   3.2.0             95m
      01-worker-kubelet                                  5bdb57489b720096ef912f738b46330a8f577803   3.2.0             95m
      99-master-generated-registries                     5bdb57489b720096ef912f738b46330a8f577803   3.2.0             95m
      99-master-ssh                                                                                 3.2.0             98m
      99-worker-generated-registries                     5bdb57489b720096ef912f738b46330a8f577803   3.2.0             95m
      99-worker-ssh                                                                                 3.2.0             98m
      os-layer-custom                                                                                                 10s 1
      rendered-master-15961f1da260f7be141006404d17d39b   5bdb57489b720096ef912f738b46330a8f577803   3.2.0             95m
      rendered-worker-5aff604cb1381a4fe07feaf1595a797e   5bdb57489b720096ef912f738b46330a8f577803   3.2.0             95m
      rendered-worker-5de4837625b1cbc237de6b22bc0bc873   5bdb57489b720096ef912f738b46330a8f577803   3.2.0             4s  2

      1

      新机器配置

      2

      新的渲染机器配置

   2. 检查新机器配置中的 osImageURL 值是否指向预期的镜像：

      $ oc describe mc rendered-worker-5de4837625b1cbc237de6b22bc0bc873

      输出示例

      Name:         rendered-worker-5de4837625b1cbc237de6b22bc0bc873
      Namespace:
      Labels:       <none>
      Annotations:  machineconfiguration.openshift.io/generated-by-controller-version: 5bdb57489b720096ef912f738b46330a8f577803
                    machineconfiguration.openshift.io/release-image-version: 4.16.0-ec.3
      API Version:  machineconfiguration.openshift.io/v1
      Kind:         MachineConfig
      ...
        Os Image URL: quay.io/my-registry/custom-image@sha256...

   3. 检查关联的机器配置池是否使用新机器配置更新：

      $ oc get mcp

      输出示例

      NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
      master   rendered-master-15961f1da260f7be141006404d17d39b   True      False      False      3              3                   3                     0                      39m
      worker   rendered-worker-5de4837625b1cbc237de6b22bc0bc873   True      False      False      3              0                   0                     0                      39m 1

      1

      当 UPDATING 字段为 True 时，机器配置池会使用新机器配置进行更新。在这种情况下，您将无法在输出看到新机器配置列表。当字段变为 False 时，代表 worker 机器配置池已应用到新机器配置。

   4. 检查节点以查看是否禁用了在节点上调度。这表示要应用更改：

      $ oc get nodes

      输出示例

      NAME                                         STATUS                     ROLES                  AGE   VERSION
      ip-10-0-148-79.us-west-1.compute.internal    Ready                      worker                 32m   v1.29.4
      ip-10-0-155-125.us-west-1.compute.internal   Ready,SchedulingDisabled   worker                 35m   v1.29.4
      ip-10-0-170-47.us-west-1.compute.internal    Ready                      control-plane,master   42m   v1.29.4
      ip-10-0-174-77.us-west-1.compute.internal    Ready                      control-plane,master   42m   v1.29.4
      ip-10-0-211-49.us-west-1.compute.internal    Ready                      control-plane,master   42m   v1.29.4
      ip-10-0-218-151.us-west-1.compute.internal   Ready                      worker                 31m   v1.29.4

2. 当节点重新处于 Ready 状态时，检查该节点是否使用自定义分层镜像：

   1. 打开节点的 oc debug 会话。例如：

      $ oc debug node/ip-10-0-155-125.us-west-1.compute.internal

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

      sh-4.4# chroot /host

   3. 运行 rpm-ostree status 命令，以查看自定义分层镜像正在使用：

      sh-4.4# sudo rpm-ostree status

      输出示例

      State: idle
      Deployments:
      * ostree-unverified-registry:quay.io/my-registry/...
                         Digest: sha256:...

流程

1. 删除应用自定义分层镜像的机器配置。

   $ oc delete mc os-layer-custom

   删除机器配置后，节点将重新引导。

1. 检查 worker 机器配置池是否使用以前的机器配置更新：

   $ oc get mcp

   输出示例

   NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
   master   rendered-master-6faecdfa1b25c114a58cf178fbaa45e2   True      False      False      3              3                   3                     0                      39m
   worker   rendered-worker-6b000dbc31aaee63c6a2d56d04cd4c1b   False     True       False      3              0                   0                     0                      39m 1

   1

   当 UPDATING 字段为 True 时，机器配置池会使用以前的机器配置进行更新。当字段变为 False 时，worker 机器配置池已应用到以前的机器配置。

2. 检查节点以查看是否禁用了在节点上调度。这表示要应用更改：

   $ oc get nodes

   输出示例

   NAME                                         STATUS                     ROLES                  AGE   VERSION
   ip-10-0-148-79.us-west-1.compute.internal    Ready                      worker                 32m   v1.29.4
   ip-10-0-155-125.us-west-1.compute.internal   Ready,SchedulingDisabled   worker                 35m   v1.29.4
   ip-10-0-170-47.us-west-1.compute.internal    Ready                      control-plane,master   42m   v1.29.4
   ip-10-0-174-77.us-west-1.compute.internal    Ready                      control-plane,master   42m   v1.29.4
   ip-10-0-211-49.us-west-1.compute.internal    Ready                      control-plane,master   42m   v1.29.4
   ip-10-0-218-151.us-west-1.compute.internal   Ready                      worker                 31m   v1.29.4

3. 当节点重新处于 Ready 状态时，检查该节点是否使用基础镜像：

   1. 打开节点的 oc debug 会话。例如：

      $ oc debug node/ip-10-0-155-125.us-west-1.compute.internal

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

      sh-4.4# chroot /host

   3. 运行 rpm-ostree status 命令，以查看自定义分层镜像正在使用：

      sh-4.4# sudo rpm-ostree status

      输出示例

      State: idle
      Deployments:
      * ostree-unverified-registry:podman pull quay.io/openshift-release-dev/ocp-release@sha256:e2044c3cfebe0ff3a99fc207ac5efe6e07878ad59fd4ad5e41f88cb016dacd73
                         Digest: sha256:e2044c3cfebe0ff3a99fc207ac5efe6e07878ad59fd4ad5e41f88cb016dacd73

1. 集群会自动升级到 x.y.z+1 版本，但使用自定义分层镜像的节点除外。
2. 然后，您可以创建一个引用更新的 OpenShift Container Platform 镜像和之前应用的 RPM 的新 Containerfile。
3. 创建指向更新的自定义分层镜像的新机器配置。