安装后配置

流程

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. 创建一个 Butane 配置，包括 chrony.conf 文件的内容。例如，要在 worker 节点上配置 chrony，请创建一个 99-worker-chrony.bu 文件。

   注意

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

   variant: openshift
   version: 4.8.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. 列出 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:
     config:
       ignition:
         version: 3.2.0
     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.21.0
   ip-10-0-136-243.ec2.internal   Ready                      master   34m   v1.21.0
   ip-10-0-141-105.ec2.internal   Ready,SchedulingDisabled   worker   28m   v1.21.0
   ip-10-0-142-249.ec2.internal   Ready                      master   34m   v1.21.0
   ip-10-0-153-11.ec2.internal    Ready                      worker   28m   v1.21.0
   ip-10-0-153-150.ec2.internal   Ready                      master   34m   v1.21.0

   您可以发现，在应用更改时每个 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.20.0
   ip-10-0-136-243.ec2.internal   Ready                      master   34m   v1.20.0
   ip-10-0-141-105.ec2.internal   Ready,SchedulingDisabled   worker   28m   v1.20.0
   ip-10-0-142-249.ec2.internal   Ready                      master   34m   v1.20.0
   ip-10-0-153-11.ec2.internal    Ready                      worker   28m   v1.20.0
   ip-10-0-153-150.ec2.internal   Ready                      master   34m   v1.20.0

   您可以发现，在应用更改时每个 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.21.0
   ip-10-0-146-92.us-east-2.compute.internal   Ready   worker   101m  v1.21.0
   ip-10-0-169-2.us-east-2.compute.internal    Ready   worker   102m  v1.21.0

   $ 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.8.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.18.3

   $ 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.9.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. 为您要配置的节点类型获取与静态 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：

   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=large-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

   这应该会显示 status: "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
      pidsLimit: 2048
      logLevel: debug
      overlaySize: 8G
      logSizeMax: "-1"

   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 | egrep 'log_level|pids_limit|log_size_max'

      输出示例

      pids_limit = 2048
      log_size_max = -1
      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. 查看集群中的机器集：

   $ oc get machinesets -n openshift-machine-api

   机器集以 <clusterid>-worker-<aws-region-az> 的形式列出。

2. 查看集群中的机器：

   $ oc get machine -n openshift-machine-api

3. 在您要删除的机器上设置注解：

   $ oc annotate machine/<machine_name> -n openshift-machine-api machine.openshift.io/cluster-api-delete-machine="true"

4. 进行 cordon 操作，排空您要删除的节点：

   $ oc adm cordon <node_name>
   $ oc adm drain <node_name>

5. 扩展机器集：

   $ oc scale --replicas=2 machineset <machineset> -n openshift-machine-api

   或者：

   $ oc edit machineset <machineset> -n openshift-machine-api

   提示

   您还可以应用以下 YAML 来扩展机器集：

   apiVersion: machine.openshift.io/v1beta1
   kind: MachineSet
   metadata:
     name: <machineset>
     namespace: openshift-machine-api
   spec:
     replicas: 2

   您可以扩展或缩减机器集。需要过几分钟以后新机器才可用。

1. 编辑调度程序 Operator CR 以添加默认的集群范围节点选择器：

   $ oc edit scheduler cluster

   使用节点选择器的调度程序 Operator CR 示例

   apiVersion: config.openshift.io/v1
   kind: Scheduler
   metadata:
     name: cluster
   ...
   
   spec:
     defaultNodeSelector: type=user-node,region=east 1
     mastersSchedulable: false
     policy:
       name: ""

   1

   使用适当的 <key>:<value> 对添加节点选择器。

   完成此更改后，请等待重新部署 openshift-kube-apiserver 项目中的 pod。这可能需要几分钟。只有重新部署 pod 后，默认的集群范围节点选择器才会生效。

2. 通过使用机器集或直接编辑节点，为节点添加标签：

   • 在创建节点时，使用机器集向由机器集管理的节点添加标签：

     1. 运行以下命令，将标签添加到 MachineSet 对象中：

        $ oc patch MachineSet <name> --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"<key>"="<value>","<key>"="<value>"}}]'  -n openshift-machine-api 1

        1

        为每个标识添加 <key>/<value> 对。

        例如：

        $ oc patch MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"type":"user-node","region":"east"}}]'  -n openshift-machine-api

        提示

        您还可以应用以下 YAML 来向机器集中添加标签：

        apiVersion: machine.openshift.io/v1beta1
        kind: MachineSet
        metadata:
          name: <machineset>
          namespace: openshift-machine-api
        spec:
          template:
            spec:
              metadata:
                labels:
                  region: "east"
                  type: "user-node"

     2. 使用 oc edit 命令验证标签是否已添加到 MachineSet 对象中：

        例如：

        $ oc edit MachineSet abc612-msrtw-worker-us-east-1c -n openshift-machine-api

        MachineSet 对象示例

        apiVersion: machine.openshift.io/v1beta1
        kind: MachineSet
          ...
        spec:
          ...
          template:
            metadata:
          ...
            spec:
              metadata:
                labels:
                  region: east
                  type: user-node
          ...

     3. 通过缩减至 0 并扩展节点来重新部署与该机器集关联的节点：

        例如：

        $ oc scale --replicas=0 MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-api

        $ oc scale --replicas=1 MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-api

     4. 当节点就绪并可用时，使用 oc get 命令验证该标签是否已添加到节点：

        $ oc get nodes -l <key>=<value>

        例如：

        $ oc get nodes -l type=user-node

        输出示例

        NAME                                       STATUS   ROLES    AGE   VERSION
        ci-ln-l8nry52-f76d1-hl7m7-worker-c-vmqzp   Ready    worker   61s   v1.18.3+002a51f

   • 直接向节点添加标签：

     1. 为节点编辑 Node 对象：

        $ oc label nodes <name> <key>=<value>

        例如，若要为以下节点添加标签：

        $ oc label nodes ci-ln-l8nry52-f76d1-hl7m7-worker-b-tgq49 type=user-node region=east

        提示

        您还可以应用以下 YAML 来向节点添加标签：

        kind: Node
        apiVersion: v1
        metadata:
          name: <node_name>
          labels:
            type: "user-node"
            region: "east"

     2. 使用 oc get 命令验证标签是否已添加到节点：

        $ oc get nodes -l <key>=<value>,<key>=<value>

        例如：

        $ oc get nodes -l type=user-node,region=east

        输出示例

        NAME                                       STATUS   ROLES    AGE   VERSION
        ci-ln-l8nry52-f76d1-hl7m7-worker-b-tgq49   Ready    worker   17m   v1.18.3+002a51f

流程

1. 创建一个包含机器集自定义资源（CR）示例的新 YAML 文件，并将其命名为 <file_name>.yaml。

   确保设置 <clusterID> 和 <role> 参数值。

   1. 如果您不确定要为特定字段设置哪个值，您可以从集群中检查现有机器集：

      $ oc get machinesets -n openshift-machine-api

      输出示例

      NAME                                DESIRED   CURRENT   READY   AVAILABLE   AGE
      agl030519-vplxk-worker-us-east-1a   1         1         1       1           55m
      agl030519-vplxk-worker-us-east-1b   1         1         1       1           55m
      agl030519-vplxk-worker-us-east-1c   1         1         1       1           55m
      agl030519-vplxk-worker-us-east-1d   0         0                             55m
      agl030519-vplxk-worker-us-east-1e   0         0                             55m
      agl030519-vplxk-worker-us-east-1f   0         0                             55m

   2. 检查特定机器集的值：

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

      输出示例

      ...
      template:
          metadata:
            labels:
              machine.openshift.io/cluster-api-cluster: agl030519-vplxk 1
              machine.openshift.io/cluster-api-machine-role: worker 2
              machine.openshift.io/cluster-api-machine-type: worker
              machine.openshift.io/cluster-api-machineset: agl030519-vplxk-worker-us-east-1a

      1

      集群 ID。

      2

      默认节点标签。

2. 创建新的 MachineSet CR:

   $ oc create -f <file_name>.yaml

3. 查看机器集列表：

   $ oc get machineset -n openshift-machine-api

   输出示例

   NAME                                DESIRED   CURRENT   READY   AVAILABLE   AGE
   agl030519-vplxk-infra-us-east-1a    1         1         1       1           11m
   agl030519-vplxk-worker-us-east-1a   1         1         1       1           55m
   agl030519-vplxk-worker-us-east-1b   1         1         1       1           55m
   agl030519-vplxk-worker-us-east-1c   1         1         1       1           55m
   agl030519-vplxk-worker-us-east-1d   0         0                             55m
   agl030519-vplxk-worker-us-east-1e   0         0                             55m
   agl030519-vplxk-worker-us-east-1f   0         0                             55m

   当新机器集可用时，DESIRED 和 CURRENT 的值会匹配。如果机器集不可用，请等待几分钟，然后再次运行命令。

流程

1. 向您要充当应用程序节点的 worker 节点添加标签：

   $ oc label node <node-name> node-role.kubernetes.io/app=""

2. 向您要充当基础架构节点的 worker 节点添加标签：

   $ oc label node <node-name> node-role.kubernetes.io/infra=""

3. 检查相关节点现在是否具有 infra 角色或 app 角色：

   $ oc get nodes

4. 创建默认的集群范围节点选择器。默认节点选择器应用到在所有命名空间中创建的 pod。这会创建一个与 pod 上任何现有节点选择器交集的交集，这会额外限制 pod 的选择器。

   重要

   如果默认节点选择器键与 pod 标签的键冲突，则不会应用默认节点选择器。

   但是，不要设置可能会导致 pod 变得不可调度的默认节点选择器。例如，当 pod 的标签被设置为不同的节点角色（如 node-role.kubernetes.io/infra=""）时，将默认节点选择器设置为特定的节点角色（如 node-role.kubernetes.io/master=""）可能会导致 pod 无法调度。因此，将默认节点选择器设置为特定节点角色时要小心。

   您还可以使用项目节点选择器来避免集群范围节点选择器键冲突。

   1. 编辑 Scheduler 对象：

      $ oc edit scheduler cluster

   2. 使用适当的节点选择器添加 defaultNodeSelector 字段：

      apiVersion: config.openshift.io/v1
      kind: Scheduler
      metadata:
        name: cluster
      ...
      spec:
        defaultNodeSelector: topology.kubernetes.io/region=us-east-1 1
      ...

      1

      默认情况下，此节点选择器示例将容器集部署到 us-east-1 区域的节点。

   3. 保存文件以使改变生效。

流程

1. 向您要分配为带有特定标签的 infra 节点的节点添加标签：

   $ oc label node <node_name> <label>

   $ oc label node ci-ln-n8mqwr2-f76d1-xscn2-worker-c-6fmtx node-role.kubernetes.io/infra=

2. 创建包含 worker 角色和自定义角色作为机器配置选择器的机器配置池：

   $ cat infra.mcp.yaml

   输出示例

   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfigPool
   metadata:
     name: infra
   spec:
     machineConfigSelector:
       matchExpressions:
         - {key: machineconfiguration.openshift.io/role, operator: In, values: [worker,infra]} 1
     nodeSelector:
       matchLabels:
         node-role.kubernetes.io/infra: "" 2

   1

   添加 worker 角色和自定义角色。

   2

   将您添加的标签作为 nodeSelector 添加到节点。

   注意

   自定义机器配置池从 worker 池中继承机器配置。自定义池使用任何针对 worker 池的机器配置，但增加了部署仅针对自定义池的更改的功能。由于自定义池从 worker 池中继承资源，对 worker 池的任何更改也会影响自定义池。

3. 具有 YAML 文件后，您可以创建机器配置池：

   $ oc create -f infra.mcp.yaml

4. 检查机器配置，以确保基础架构配置成功：

   $ oc get machineconfig

   输出示例

   NAME                                                        GENERATEDBYCONTROLLER                      IGNITIONVERSION   CREATED
   00-master                                                   365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
   00-worker                                                   365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
   01-master-container-runtime                                 365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
   01-master-kubelet                                           365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
   01-worker-container-runtime                                 365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
   01-worker-kubelet                                           365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
   99-master-1ae2a1e0-a115-11e9-8f14-005056899d54-registries   365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
   99-master-ssh                                                                                          3.2.0             31d
   99-worker-1ae64748-a115-11e9-8f14-005056899d54-registries   365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
   99-worker-ssh                                                                                          3.2.0             31d
   rendered-infra-4e48906dca84ee702959c71a53ee80e7             365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             23m
   rendered-master-072d4b2da7f88162636902b074e9e28e            5b6fb8349a29735e48446d435962dec4547d3090   3.2.0             31d
   rendered-master-3e88ec72aed3886dec061df60d16d1af            02c07496ba0417b3e12b78fb32baf6293d314f79   3.2.0             31d
   rendered-master-419bee7de96134963a15fdf9dd473b25            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             17d
   rendered-master-53f5c91c7661708adce18739cc0f40fb            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             13d
   rendered-master-a6a357ec18e5bce7f5ac426fc7c5ffcd            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             7d3h
   rendered-master-dc7f874ec77fc4b969674204332da037            5b6fb8349a29735e48446d435962dec4547d3090   3.2.0             31d
   rendered-worker-1a75960c52ad18ff5dfa6674eb7e533d            5b6fb8349a29735e48446d435962dec4547d3090   3.2.0             31d
   rendered-worker-2640531be11ba43c61d72e82dc634ce6            5b6fb8349a29735e48446d435962dec4547d3090   3.2.0             31d
   rendered-worker-4e48906dca84ee702959c71a53ee80e7            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             7d3h
   rendered-worker-4f110718fe88e5f349987854a1147755            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             17d
   rendered-worker-afc758e194d6188677eb837842d3b379            02c07496ba0417b3e12b78fb32baf6293d314f79   3.2.0             31d
   rendered-worker-daa08cc1e8f5fcdeba24de60cd955cc3            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             13d

   您应该会看到一个新的机器配置，带有 rendered-infra-* 前缀。

5. 可选：要部署对自定义池的更改，请创建一个机器配置，该配置使用自定义池名称作为标签，如本例中的 infra。请注意，这不是必须的，在此包括仅用于指示目的。这样，您可以只应用特定于 infra 节点的任何自定义配置。

   注意

   创建新机器配置池后，MCO 会为该池生成一个新的呈现配置，以及该池重启的关联节点以应用新配置。

   1. 创建机器配置：

      $ cat infra.mc.yaml

      输出示例

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfig
      metadata:
        name: 51-infra
        labels:
          machineconfiguration.openshift.io/role: infra 1
      spec:
        config:
          ignition:
            version: 3.2.0
          storage:
            files:
            - path: /etc/infratest
              mode: 0644
              contents:
                source: data:,infra

      1

      将您添加的标签作为 nodeSelector 添加到节点。

   2. 将机器配置应用到 infra-labeled 节点：

      $ oc create -f infra.mc.yaml

6. 确认您的新机器配置池可用：

   $ oc get mcp

   输出示例

   NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
   infra    rendered-infra-60e35c2e99f42d976e084fa94da4d0fc    True      False      False      1              1                   1                     0                      4m20s
   master   rendered-master-9360fdb895d4c131c7c4bebbae099c90   True      False      False      3              3                   3                     0                      91m
   worker   rendered-worker-60e35c2e99f42d976e084fa94da4d0fc   True      False      False      2              2                   2                     0                      91m

   在本例中，worker 节点被改为一个 infra 节点。

流程

1. 向 infra 节点添加污点以防止在其上调度用户工作负载：

   1. 确定节点是否具有污点：

      $ oc describe nodes <node_name>

      输出示例

      oc describe node ci-ln-iyhx092-f76d1-nvdfm-worker-b-wln2l
      Name:               ci-ln-iyhx092-f76d1-nvdfm-worker-b-wln2l
      Roles:              worker
       ...
      Taints:             node-role.kubernetes.io/infra:NoSchedule
       ...

      本例显示节点具有污点。您可以在下一步中继续向 pod 添加容限。

   2. 如果您还没有配置污点以防止在其上调度用户工作负载：

      $ oc adm taint nodes <node_name> <key>:<effect>

      例如：

      $ oc adm taint nodes node1 node-role.kubernetes.io/infra:NoSchedule

      提示

      您还可以应用以下 YAML 来添加污点：

      kind: Node
      apiVersion: v1
      metadata:
        name: <node_name>
        labels:
          ...
      spec:
        taints:
          - key: node-role.kubernetes.io/infra
            effect: NoSchedule
        ...

      本例在 node1 上放置一个键为 node-role.kubernetes.io/infra 的污点，污点是 NoSchedule。具有 NoSchedule effect 的节点仅调度容许该污点的 pod，但允许现有 pod 继续调度到该节点上。

      注意

      如果使用 descheduler，则违反了节点污点的 pod 可能会从集群驱除。

2. 为要在 infra 节点上调度的 pod 配置添加容限，如路由器、registry 和监控工作负载。在 Pod 对象规格中添加以下代码：

   tolerations:
     - effect: NoSchedule 1
       key: node-role.kubernetes.io/infra 2
       operator: Exists 3

   1

   指定添加到节点的效果。

   2

   指定添加到节点的键。

   3

   指定 Exists Operator，以要求节点上存在一个带有键为 node-role.kubernetes.io/infra 的污点。

   此容忍度与 oc adm taint 命令创建的污点匹配。具有此容忍度的 pod 可以调度到 infra 节点上。

   注意

   并不总是能够将通过 OLM 安装的 Operator 的 Pod 移到 infra 节点。移动 Operator Pod 的能力取决于每个 Operator 的配置。

3. 使用调度程序将 pod 调度到 infra 节点。详情请参阅控制节点上的 pod 放置的文档。

流程

1. 查看路由器 Operator 的 IngressController 自定义资源：

   $ oc get ingresscontroller default -n openshift-ingress-operator -o yaml

   命令输出类似于以下文本：

   apiVersion: operator.openshift.io/v1
   kind: IngressController
   metadata:
     creationTimestamp: 2019-04-18T12:35:39Z
     finalizers:
     - ingresscontroller.operator.openshift.io/finalizer-ingresscontroller
     generation: 1
     name: default
     namespace: openshift-ingress-operator
     resourceVersion: "11341"
     selfLink: /apis/operator.openshift.io/v1/namespaces/openshift-ingress-operator/ingresscontrollers/default
     uid: 79509e05-61d6-11e9-bc55-02ce4781844a
   spec: {}
   status:
     availableReplicas: 2
     conditions:
     - lastTransitionTime: 2019-04-18T12:36:15Z
       status: "True"
       type: Available
     domain: apps.<cluster>.example.com
     endpointPublishingStrategy:
       type: LoadBalancerService
     selector: ingresscontroller.operator.openshift.io/deployment-ingresscontroller=default

2. 编辑 ingresscontroller 资源，并更改 nodeSelector 以使用infra 标签：

   $ oc edit ingresscontroller default -n openshift-ingress-operator

     spec:
       nodePlacement:
         nodeSelector: 1
           matchLabels:
             node-role.kubernetes.io/infra: ""
         tolerations:
         - effect: NoSchedule
           key: node-role.kubernetes.io/infra
           value: reserved
         - effect: NoExecute
           key: node-role.kubernetes.io/infra
           value: reserved

   1

   添加 nodeSelector 参数，并设为适用于您想要移动的组件的值。您可以根据为节点指定的值，按所示格式使用 nodeSelector 或使用 <key>: <value> 对。如果您在 infrasructure 节点中添加了污点，还要添加匹配的容限。

3. 确认路由器 Pod 在 infra 节点上运行。

   1. 查看路由器 Pod 列表，并记下正在运行的 Pod 的节点名称：

      $ oc get pod -n openshift-ingress -o wide

      输出示例

      NAME                              READY     STATUS        RESTARTS   AGE       IP           NODE                           NOMINATED NODE   READINESS GATES
      router-default-86798b4b5d-bdlvd   1/1      Running       0          28s       10.130.2.4   ip-10-0-217-226.ec2.internal   <none>           <none>
      router-default-955d875f4-255g8    0/1      Terminating   0          19h       10.129.2.4   ip-10-0-148-172.ec2.internal   <none>           <none>

      在本例中，正在运行的 Pod 位于 ip-10-0-217-226.ec2.internal 节点上。

   2. 查看正在运行的 Pod 的节点状态：

      $ oc get node <node_name> 1

      1

      指定从 Pod 列表获得的 <node_name>。

      输出示例

      NAME                          STATUS  ROLES         AGE   VERSION
      ip-10-0-217-226.ec2.internal  Ready   infra,worker  17h   v1.21.0

      由于角色列表包含 infra，因此 Pod 在正确的节点上运行。

流程

1. 查看 config/instance 对象：

   $ oc get configs.imageregistry.operator.openshift.io/cluster -o yaml

   输出示例

   apiVersion: imageregistry.operator.openshift.io/v1
   kind: Config
   metadata:
     creationTimestamp: 2019-02-05T13:52:05Z
     finalizers:
     - imageregistry.operator.openshift.io/finalizer
     generation: 1
     name: cluster
     resourceVersion: "56174"
     selfLink: /apis/imageregistry.operator.openshift.io/v1/configs/cluster
     uid: 36fd3724-294d-11e9-a524-12ffeee2931b
   spec:
     httpSecret: d9a012ccd117b1e6616ceccb2c3bb66a5fed1b5e481623
     logging: 2
     managementState: Managed
     proxy: {}
     replicas: 1
     requests:
       read: {}
       write: {}
     storage:
       s3:
         bucket: image-registry-us-east-1-c92e88cad85b48ec8b312344dff03c82-392c
         region: us-east-1
   status:
   ...

2. 编辑 config/instance 对象：

   $ oc edit configs.imageregistry.operator.openshift.io/cluster

   spec:
     affinity:
       podAntiAffinity:
         preferredDuringSchedulingIgnoredDuringExecution:
         - podAffinityTerm:
             namespaces:
             - openshift-image-registry
             topologyKey: kubernetes.io/hostname
           weight: 100
     logLevel: Normal
     managementState: Managed
     nodeSelector: 1
       node-role.kubernetes.io/infra: ""
     tolerations:
     - effect: NoSchedule
       key: node-role.kubernetes.io/infra
       value: reserved
     - effect: NoExecute
       key: node-role.kubernetes.io/infra
       value: reserved

   1

   添加 nodeSelector 参数，并设为适用于您想要移动的组件的值。您可以根据为节点指定的值，按所示格式使用 nodeSelector 或使用 <key>: <value> 对。如果您在 infrasructure 节点中添加了污点，还要添加匹配的容限。

3. 验证 registry pod 已移至基础架构节点。

   1. 运行以下命令，以识别 registry pod 所在的节点：

      $ oc get pods -o wide -n openshift-image-registry

   2. 确认节点具有您指定的标签：

      $ oc describe node <node_name>

      查看命令输出，并确认 node-role.kubernetes.io/infra 列在 LABELS 列表中。

流程

1. 编辑 cluster-monitoring-config 配置映射，并更改 nodeSelector 以使用 infra 标签：

   $ oc edit configmap cluster-monitoring-config -n openshift-monitoring

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: cluster-monitoring-config
     namespace: openshift-monitoring
   data:
     config.yaml: |+
       alertmanagerMain:
         nodeSelector: 1
           node-role.kubernetes.io/infra: ""
         tolerations:
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoSchedule
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoExecute
       prometheusK8s:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
         tolerations:
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoSchedule
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoExecute
       prometheusOperator:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
         tolerations:
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoSchedule
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoExecute
       grafana:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
         tolerations:
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoSchedule
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoExecute
       k8sPrometheusAdapter:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
         tolerations:
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoSchedule
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoExecute
       kubeStateMetrics:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
         tolerations:
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoSchedule
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoExecute
       telemeterClient:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
         tolerations:
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoSchedule
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoExecute
       openshiftStateMetrics:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
         tolerations:
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoSchedule
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoExecute
       thanosQuerier:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
         tolerations:
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoSchedule
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoExecute

   1

   添加 nodeSelector 参数，并设为适用于您想要移动的组件的值。您可以根据为节点指定的值，按所示格式使用 nodeSelector 或使用 <key>: <value> 对。如果您在 infrasructure 节点中添加了污点，还要添加匹配的容限。

2. 观察监控 pod 移至新机器：

   $ watch 'oc get pod -n openshift-monitoring -o wide'

3. 如果组件没有移到 infra 节点，请删除带有这个组件的 pod:

   $ oc delete pod -n openshift-monitoring <pod>

   已删除 pod 的组件在 infra 节点上重新创建。

流程

1. 编辑 openshift-logging 项目中的 ClusterLogging 自定义资源（CR）：

   $ oc edit ClusterLogging instance

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogging
   
   ...
   
   spec:
     collection:
       logs:
         fluentd:
           resources: null
         type: fluentd
     logStore:
       elasticsearch:
         nodeCount: 3
         nodeSelector: 1
           node-role.kubernetes.io/infra: ''
         tolerations:
         - effect: NoSchedule
           key: node-role.kubernetes.io/infra
           value: reserved
         - effect: NoExecute
           key: node-role.kubernetes.io/infra
           value: reserved
         redundancyPolicy: SingleRedundancy
         resources:
           limits:
             cpu: 500m
             memory: 16Gi
           requests:
             cpu: 500m
             memory: 16Gi
         storage: {}
       type: elasticsearch
     managementState: Managed
     visualization:
       kibana:
         nodeSelector: 2
           node-role.kubernetes.io/infra: ''
         tolerations:
         - effect: NoSchedule
           key: node-role.kubernetes.io/infra
           value: reserved
         - effect: NoExecute
           key: node-role.kubernetes.io/infra
           value: reserved
         proxy:
           resources: null
         replicas: 1
         resources: null
       type: kibana
   
   ...

   1 2

   添加 nodeSelector 参数，并设为适用于您想要移动的组件的值。您可以根据为节点指定的值，按所示格式使用 nodeSelector 或使用 <key>: <value> 对。如果您在 infrasructure 节点中添加了污点，还要添加匹配的容限。

流程

1. 为 ClusterAutoscaler 资源创建一个 YAML 文件，其中包含自定义的资源定义。

2. 在集群中创建资源：

   $ oc create -f <filename>.yaml 1

   1

   <filename> 是您自定义的资源文件的名称。

流程

1. 为 MachineAutoscaler 资源创建一个 YAML 文件，其中包含自定义的资源定义。

2. 在集群中创建资源：

   $ oc create -f <filename>.yaml 1

   1

   <filename> 是您自定义的资源文件的名称。

1. 在 OpenShift Container Platform web 控制台中，切换到 Administration → Custom Resource Definitions 页面。
2. 在 Custom Resource Definitions 页面中，点击 FeatureGate。
3. 在 Custom Resource Definition Details 页面中，点 Instances 选项卡。
4. 点 集群 功能门，然后点 YAML 选项卡。

5. 编辑集群实例以添加特定的功能集：

   警告

   在集群中启用 TechPreviewNoUpgrade 功能集无法撤消，并会阻止次版本更新。您不应该在生产环境集群中启用此功能。

   功能门自定义资源示例

   apiVersion: config.openshift.io/v1
   kind: FeatureGate
   metadata:
     name: cluster 1
   ....
   
   spec:
     featureSet: TechPreviewNoUpgrade 2

   1

   FeatureGate CR 的名称必须是 cluster。

   2

   添加要启用的功能集：

   • TechPreviewNoUpgrade 启用了特定的技术预览功能。

   保存更改后，会创建新的机器配置，然后更新机器配置池，并在应用更改时在每个节点上调度。

1. 从 Web 控制台中的 Administrator 视角，进入到 Compute → Nodes。
2. 选择一个节点。
3. 在 Node 详情页面中，点 Terminal。

4. 在终端窗口中，将根目录改为 /host ：

   sh-4.2# chroot /host

5. 查看 kubelet.conf 文件：

   sh-4.2# cat /etc/kubernetes/kubelet.conf

   输出示例

    ...
   featureGates:
     InsightsOperatorPullingSCA: true,
     LegacyNodeRoleBehavior: false
    ...

   在集群中启用列为 true 的功能。

   注意

   列出的功能因 OpenShift Container Platform 版本的不同而有所不同。

1. 编辑名为 cluster 的 FeatureGate CR：

   $ oc edit featuregate cluster

   警告

   在集群中启用 TechPreviewNoUpgrade 功能集无法撤消，并会阻止次版本更新。您不应该在生产环境集群中启用此功能。

   FeatureGate 自定义资源示例

   apiVersion: config.openshift.io/v1
   kind: FeatureGate
   metadata:
     name: cluster 1
   spec:
     featureSet: TechPreviewNoUpgrade 2

   1

   FeatureGate CR 的名称必须是 cluster。

   2

   添加要启用的功能集：

   • TechPreviewNoUpgrade 启用了特定的技术预览功能。

   保存更改后，会创建新的机器配置，然后更新机器配置池，并在应用更改时在每个节点上调度。

1. 从 Web 控制台中的 Administrator 视角，进入到 Compute → Nodes。
2. 选择一个节点。
3. 在 Node 详情页面中，点 Terminal。

4. 在终端窗口中，将根目录改为 /host ：

   sh-4.2# chroot /host

5. 查看 kubelet.conf 文件：

   sh-4.2# cat /etc/kubernetes/kubelet.conf

   输出示例

    ...
   featureGates:
     InsightsOperatorPullingSCA: true,
     LegacyNodeRoleBehavior: false
    ...

   在集群中启用列为 true 的功能。

   注意

   列出的功能因 OpenShift Container Platform 版本的不同而有所不同。

流程

1. 修改 APIServer 对象：

   $ oc edit apiserver

2. 把 encryption 项类型设置为 aescbc：

   spec:
     encryption:
       type: aescbc 1

   1

   aescbc 类型表示 AES-CBC 使用 PKCS#7 padding 和 32 字节密钥来执行加密。

3. 保存文件以使改变生效。

   加密过程开始。根据集群的大小，这个过程可能需要 20 分钟或更长的时间才能完成。

4. 验证 etcd 加密是否成功。

   1. 查看 OpenShift API 服务器的 Encrypted 状态条件，以验证其资源是否已成功加密：

      $ oc get openshiftapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'

      在成功加密后输出显示 EncryptionCompleted：

      EncryptionCompleted
      All resources encrypted: routes.route.openshift.io

      如果输出显示 EncryptionInProgress，加密仍在进行中。等待几分钟后重试。

   2. 查看 Kubernetes API 服务器的 Encrypted 状态条件，以验证其资源是否已成功加密：

      $ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'

      在成功加密后输出显示 EncryptionCompleted：

      EncryptionCompleted
      All resources encrypted: secrets, configmaps

      如果输出显示 EncryptionInProgress，加密仍在进行中。等待几分钟后重试。

   3. 查看 OpenShift OAuth API 服务器的 Encrypted 状态条件，以验证其资源是否已成功加密：

      $ oc get authentication.operator.openshift.io -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'

      在成功加密后输出显示 EncryptionCompleted：

      EncryptionCompleted
      All resources encrypted: oauthaccesstokens.oauth.openshift.io, oauthauthorizetokens.oauth.openshift.io

      如果输出显示 EncryptionInProgress，加密仍在进行中。等待几分钟后重试。

流程

1. 修改 APIServer 对象：

   $ oc edit apiserver

2. 将 encryption 字段类型设置为 identity：

   spec:
     encryption:
       type: identity 1

   1

   identity 类型是默认值，意味着没有执行任何加密。

3. 保存文件以使改变生效。

   解密过程开始。根据集群的大小，这个过程可能需要 20 分钟或更长的时间才能完成。

4. 验证 etcd 解密是否成功。

   1. 查看 OpenShift API 服务器的 Encrypted 状态条件，以验证其资源是否已成功解密：

      $ oc get openshiftapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'

      在成功解密后输出显示 DecryptionCompleted：

      DecryptionCompleted
      Encryption mode set to identity and everything is decrypted

      如果输出显示 DecryptionInProgress，解密仍在进行中。等待几分钟后重试。

   2. 查看 Kubernetes API 服务器的 Encrypted 状态条件，以验证其资源是否已成功解密：

      $ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'

      在成功解密后输出显示 DecryptionCompleted：

      DecryptionCompleted
      Encryption mode set to identity and everything is decrypted

      如果输出显示 DecryptionInProgress，解密仍在进行中。等待几分钟后重试。

   3. 查看 OpenShift OAuth API 服务器的 Encrypted 状态条件，以验证其资源是否已成功解密：

      $ oc get authentication.operator.openshift.io -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'

      在成功解密后输出显示 DecryptionCompleted：

      DecryptionCompleted
      Encryption mode set to identity and everything is decrypted

      如果输出显示 DecryptionInProgress，解密仍在进行中。等待几分钟后重试。

流程

1. 为 control plane 节点启动一个 debug 会话：

   $ oc debug node/<node_name>

2. 将您的根目录改为 /host ：

   sh-4.2# chroot /host

3. 如果启用了集群范围的代理，请确定已导出了 NO_PROXY、HTTP_PROXY和 HTTPS_PROXY 环境变量。

4. 运行 cluster-backup.sh 脚本，输入保存备份的位置。

   提示

   cluster-backup.sh 脚本作为 etcd Cluster Operator 的一个组件被维护，它是 etcdctl snapshot save 命令的包装程序（wrapper）。

   sh-4.4# /usr/local/bin/cluster-backup.sh /home/core/assets/backup

   脚本输出示例

   found latest kube-apiserver: /etc/kubernetes/static-pod-resources/kube-apiserver-pod-6
   found latest kube-controller-manager: /etc/kubernetes/static-pod-resources/kube-controller-manager-pod-7
   found latest kube-scheduler: /etc/kubernetes/static-pod-resources/kube-scheduler-pod-6
   found latest etcd: /etc/kubernetes/static-pod-resources/etcd-pod-3
   ede95fe6b88b87ba86a03c15e669fb4aa5bf0991c180d3c6895ce72eaade54a1
   etcdctl version: 3.4.14
   API version: 3.4
   {"level":"info","ts":1624647639.0188997,"caller":"snapshot/v3_snapshot.go:119","msg":"created temporary db file","path":"/home/core/assets/backup/snapshot_2021-06-25_190035.db.part"}
   {"level":"info","ts":"2021-06-25T19:00:39.030Z","caller":"clientv3/maintenance.go:200","msg":"opened snapshot stream; downloading"}
   {"level":"info","ts":1624647639.0301006,"caller":"snapshot/v3_snapshot.go:127","msg":"fetching snapshot","endpoint":"https://10.0.0.5:2379"}
   {"level":"info","ts":"2021-06-25T19:00:40.215Z","caller":"clientv3/maintenance.go:208","msg":"completed snapshot read; closing"}
   {"level":"info","ts":1624647640.6032252,"caller":"snapshot/v3_snapshot.go:142","msg":"fetched snapshot","endpoint":"https://10.0.0.5:2379","size":"114 MB","took":1.584090459}
   {"level":"info","ts":1624647640.6047094,"caller":"snapshot/v3_snapshot.go:152","msg":"saved","path":"/home/core/assets/backup/snapshot_2021-06-25_190035.db"}
   Snapshot saved at /home/core/assets/backup/snapshot_2021-06-25_190035.db
   {"hash":3866667823,"revision":31407,"totalKey":12828,"totalSize":114446336}
   snapshot db and kube resources are successfully saved to /home/core/assets/backup

   在这个示例中，在 control plane 主机上的 /home/core/assets/backup/ 目录中创建了两个文件：

   • snapshot_<datetimestamp>.db：这个文件是 etcd 快照。cluster-backup.sh 脚本确认其有效。

   • static_kuberesources_<datetimestamp>.tar.gz：此文件包含静态 pod 的资源。如果启用了 etcd 加密，它也包含 etcd 快照的加密密钥。

     注意

     如果启用了 etcd 加密，建议出于安全考虑，将第二个文件与 etcd 快照分开保存。但是，需要这个文件才能从 etcd 快照中进行恢复。

     请记住，etcd 仅对值进行加密，而不对键进行加密。这意味着资源类型、命名空间和对象名称是不加密的。

流程

1. 确定哪个 etcd 成员是领导成员，因为领导会进行最后的碎片处理。

   1. 获取 etcd pod 列表：

      $ oc get pods -n openshift-etcd -o wide | grep -v quorum-guard | grep etcd

      输出示例

      etcd-ip-10-0-159-225.example.redhat.com                3/3     Running     0          175m   10.0.159.225   ip-10-0-159-225.example.redhat.com   <none>           <none>
      etcd-ip-10-0-191-37.example.redhat.com                 3/3     Running     0          173m   10.0.191.37    ip-10-0-191-37.example.redhat.com    <none>           <none>
      etcd-ip-10-0-199-170.example.redhat.com                3/3     Running     0          176m   10.0.199.170   ip-10-0-199-170.example.redhat.com   <none>           <none>

   2. 选择 pod 并运行以下命令来确定哪个 etcd 成员是领导：

      $ oc rsh -n openshift-etcd etcd-ip-10-0-159-225.example.redhat.com etcdctl endpoint status --cluster -w table

      输出示例

      Defaulting container name to etcdctl.
      Use 'oc describe pod/etcd-ip-10-0-159-225.example.redhat.com -n openshift-etcd' to see all of the containers in this pod.
      +---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
      |         ENDPOINT          |        ID        | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
      +---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
      |  https://10.0.191.37:2379 | 251cd44483d811c3 |   3.4.9 |  104 MB |     false |      false |         7 |      91624 |              91624 |        |
      | https://10.0.159.225:2379 | 264c7c58ecbdabee |   3.4.9 |  104 MB |     false |      false |         7 |      91624 |              91624 |        |
      | https://10.0.199.170:2379 | 9ac311f93915cc79 |   3.4.9 |  104 MB |      true |      false |         7 |      91624 |              91624 |        |
      +---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+

      基于此输出的 IS LEADER 列，https://10.0.199.170:2379 端点是领导。与上一步输出匹配此端点，领导的 pod 名称为 etcd-ip-10-0-199-170.example.redhat.com。

2. 清理 etcd 成员。

   1. 连接到正在运行的 etcd 容器，传递 不是 领导的 pod 的名称：

      $ oc rsh -n openshift-etcd etcd-ip-10-0-159-225.example.redhat.com

   2. 取消设置 ETCDCTL_ENDPOINTS 环境变量：

      sh-4.4# unset ETCDCTL_ENDPOINTS

   3. 清理 etcd 成员：

      sh-4.4# etcdctl --command-timeout=30s --endpoints=https://localhost:2379 defrag

      输出示例

      Finished defragmenting etcd member[https://localhost:2379]

      如果发生超时错误，增加 --command-timeout 的值，直到命令成功为止。

   4. 验证数据库大小是否已缩小：

      sh-4.4# etcdctl endpoint status -w table --cluster

      输出示例

      +---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
      |         ENDPOINT          |        ID        | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
      +---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
      |  https://10.0.191.37:2379 | 251cd44483d811c3 |   3.4.9 |  104 MB |     false |      false |         7 |      91624 |              91624 |        |
      | https://10.0.159.225:2379 | 264c7c58ecbdabee |   3.4.9 |   41 MB |     false |      false |         7 |      91624 |              91624 |        | 1
      | https://10.0.199.170:2379 | 9ac311f93915cc79 |   3.4.9 |  104 MB |      true |      false |         7 |      91624 |              91624 |        |
      +---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+

      本例显示这个 etcd 成员的数据库大小现在为 41 MB，而起始大小为 104 MB。

   5. 重复这些步骤以连接到其他 etcd 成员并进行碎片处理。最后才对领导进行碎片清除。

      至少要在碎片处理操作之间等待一分钟，以便 etcd pod 可以恢复。在 etcd pod 恢复前，etcd 成员不会响应。

3. 如果因为超过空间配额而触发任何 NOSPACE 警告，请清除它们。

   1. 检查是否有 NOSPACE 警告：

      sh-4.4# etcdctl alarm list

      输出示例

      memberID:12345678912345678912 alarm:NOSPACE

   2. 清除警告：

      sh-4.4# etcdctl alarm disarm

流程

1. 选择一个要用作恢复主机的 control plane 主机。这是您要在其中运行恢复操作的主机。

2. 建立到每个 control plane 节点（包括恢复主机）的 SSH 连接。

   恢复过程启动后，Kubernetes API 服务器将无法访问，因此您无法访问 control plane 节点。因此，建议在一个单独的终端中建立到每个control plane 主机的 SSH 连接。

   重要

   如果没有完成这个步骤，将无法访问 control plane 主机来完成恢复过程，您将无法从这个状态恢复集群。

3. 将 etcd 备份目录复制复制到恢复 control plane 主机上。

   此流程假设您将 backup 目录（其中包含 etcd 快照和静态 pod 资源）复制到恢复 control plane 主机的 /home/core/ 目录中。

4. 在任何其他 control plane 节点上停止静态 pod。

   注意

   不需要手动停止恢复主机上的 pod。恢复脚本将停止恢复主机上的 pod。

   1. 访问不是恢复主机的 control plane 主机。

   2. 将现有 etcd pod 文件从 Kubelet 清单目录中移出：

      $ sudo mv /etc/kubernetes/manifests/etcd-pod.yaml /tmp

   3. 验证 etcd pod 是否已停止。

      $ sudo crictl ps | grep etcd | grep -v operator

      命令输出应该为空。如果它不是空的，请等待几分钟后再重新检查。

   4. 将现有 Kubernetes API 服务器 pod 文件移出 kubelet 清单目录中：

      $ sudo mv /etc/kubernetes/manifests/kube-apiserver-pod.yaml /tmp

   5. 验证 Kubernetes API 服务器 pod 是否已停止。

      $ sudo crictl ps | grep kube-apiserver | grep -v operator

      命令输出应该为空。如果它不是空的，请等待几分钟后再重新检查。

   6. 将 etcd 数据目录移到不同的位置：

      $ sudo mv /var/lib/etcd/ /tmp

   7. 在其他不是恢复主机的 control plane 主机上重复此步骤。
5. 访问恢复 control plane 主机。

6. 如果启用了集群范围的代理，请确定已导出了 NO_PROXY、HTTP_PROXY和 HTTPS_PROXY 环境变量。

   提示

   您可以通过查看 oc get proxy cluster -o yaml 的输出来检查代理是否已启用。如果 httpProxy、httpsProxy和 noProxy 字段设置了值，则会启用代理。

7. 在恢复 control plane 主机上运行恢复脚本，提供到 etcd 备份目录的路径：

   $ sudo -E /usr/local/bin/cluster-restore.sh /home/core/backup

   脚本输出示例

   ...stopping kube-scheduler-pod.yaml
   ...stopping kube-controller-manager-pod.yaml
   ...stopping etcd-pod.yaml
   ...stopping kube-apiserver-pod.yaml
   Waiting for container etcd to stop
   .complete
   Waiting for container etcdctl to stop
   .............................complete
   Waiting for container etcd-metrics to stop
   complete
   Waiting for container kube-controller-manager to stop
   complete
   Waiting for container kube-apiserver to stop
   ..........................................................................................complete
   Waiting for container kube-scheduler to stop
   complete
   Moving etcd data-dir /var/lib/etcd/member to /var/lib/etcd-backup
   starting restore-etcd static pod
   starting kube-apiserver-pod.yaml
   static-pod-resources/kube-apiserver-pod-7/kube-apiserver-pod.yaml
   starting kube-controller-manager-pod.yaml
   static-pod-resources/kube-controller-manager-pod-7/kube-controller-manager-pod.yaml
   starting kube-scheduler-pod.yaml
   static-pod-resources/kube-scheduler-pod-8/kube-scheduler-pod.yaml

   注意

   如果在上次 etcd 备份后更新了节点，则恢复过程可能会导致节点进入 NotReady 状态。

8. 检查节点以确保它们处于 Ready 状态。

   1. 运行以下命令:

      $ oc get nodes -w

      输出示例

      NAME                STATUS  ROLES          AGE     VERSION
      host-172-25-75-28   Ready   master         3d20h   v1.23.3+e419edf
      host-172-25-75-38   Ready   infra,worker   3d20h   v1.23.3+e419edf
      host-172-25-75-40   Ready   master         3d20h   v1.23.3+e419edf
      host-172-25-75-65   Ready   master         3d20h   v1.23.3+e419edf
      host-172-25-75-74   Ready   infra,worker   3d20h   v1.23.3+e419edf
      host-172-25-75-79   Ready   worker         3d20h   v1.23.3+e419edf
      host-172-25-75-86   Ready   worker         3d20h   v1.23.3+e419edf
      host-172-25-75-98   Ready   infra,worker   3d20h   v1.23.3+e419edf

      所有节点都可能需要几分钟时间报告其状态。

   2. 如果有任何节点处于 NotReady 状态，登录到节点，并从每个节点上的 /var/lib/kubelet/pki 目录中删除所有 PEM 文件。您可以 SSH 到节点，或使用 web 控制台中的终端窗口。

      $  ssh -i <ssh-key-path> core@<master-hostname>

      pki 目录示例

      sh-4.4# pwd
      /var/lib/kubelet/pki
      sh-4.4# ls
      kubelet-client-2022-04-28-11-24-09.pem  kubelet-server-2022-04-28-11-24-15.pem
      kubelet-client-current.pem              kubelet-server-current.pem

9. 在所有 control plane 主机上重启 kubelet 服务。

   1. 在恢复主机中运行以下命令：

      $ sudo systemctl restart kubelet.service

   2. 在所有其他 control plane 主机上重复此步骤。

10. 批准待处理的 CSR：

    1. 获取当前 CSR 列表：

       $ oc get csr

       输出示例

       NAME        AGE    SIGNERNAME                                    REQUESTOR                                                                   CONDITION
       csr-2s94x   8m3s   kubernetes.io/kubelet-serving                 system:node:<node_name>                                                     Pending 1
       csr-4bd6t   8m3s   kubernetes.io/kubelet-serving                 system:node:<node_name>                                                     Pending 2
       csr-4hl85   13m    kubernetes.io/kube-apiserver-client-kubelet   system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending 3
       csr-zhhhp   3m8s   kubernetes.io/kube-apiserver-client-kubelet   system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending 4
       ...

       1 1 2

       一个待处理的 kubelet 服务 CSR（用于用户置备的安装）。

       3 4

       一个待处理的 node-bootstrapper CSR。

    2. 查看一个 CSR 的详细信息以验证其是否有效：

       $ oc describe csr <csr_name> 1

       1

       <csr_name> 是当前 CSR 列表中 CSR 的名称。

    3. 批准每个有效的 node-bootstrapper CSR：

       $ oc adm certificate approve <csr_name>

    4. 对于用户置备的安装，请批准每个有效的 kubelet 服务 CSR：

       $ oc adm certificate approve <csr_name>

11. 确认单个成员 control plane 已被成功启动。

    1. 从恢复主机上，验证 etcd 容器是否正在运行。

       $ sudo crictl ps | grep etcd | grep -v operator

       输出示例

       3ad41b7908e32       36f86e2eeaaffe662df0d21041eb22b8198e0e58abeeae8c743c3e6e977e8009                                                         About a minute ago   Running             etcd                                          0                   7c05f8af362f0

    2. 从恢复主机上，验证 etcd pod 是否正在运行。

       $ oc get pods -n openshift-etcd | grep -v etcd-quorum-guard | grep etcd

       注意

       如果您试图在运行这个命令前运行 oc login 并接收以下错误，请等待一些时间以便身份验证控制器启动并再次尝试。

       Unable to connect to the server: EOF

       输出示例

       NAME                                             READY   STATUS      RESTARTS   AGE
       etcd-ip-10-0-143-125.ec2.internal                1/1     Running     1          2m47s

       如果状态是 Pending，或者输出中列出了多个正在运行的 etcd pod，请等待几分钟，然后再次检查。

    3. 对不是恢复主机的每个已丢失的 control plane 主机重复此步骤。

12. 逐个删除并重新创建其他非恢复 control plane 机器。重新创建此机器后，会强制一个新修订版本并自动扩展 etcd。

    如果您正在运行安装程序置备的基础架构，或者您使用 Machine API 创建机器，请按照以下步骤执行。否则，您必须使用最初创建控制平面节点时使用的相同方法创建新的控制平面。

    警告

    不要为恢复主机删除和重新创建计算机。

    1. 为丢失的 control plane 主机之一获取机器。

       在一个终端中使用 cluster-admin 用户连接到集群，运行以下命令：

       $ oc get machines -n openshift-machine-api -o wide

       输出示例：

       NAME                                        PHASE     TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
       clustername-8qw5l-master-0                  Running   m4.xlarge   us-east-1   us-east-1a   3h37m   ip-10-0-131-183.ec2.internal   aws:///us-east-1a/i-0ec2782f8287dfb7e   stopped 1
       clustername-8qw5l-master-1                  Running   m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-143-125.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
       clustername-8qw5l-master-2                  Running   m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-154-194.ec2.internal    aws:///us-east-1c/i-02626f1dba9ed5bba  running
       clustername-8qw5l-worker-us-east-1a-wbtgd   Running   m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
       clustername-8qw5l-worker-us-east-1b-lrdxb   Running   m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
       clustername-8qw5l-worker-us-east-1c-pkg26   Running   m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running

       1

       这是用于丢失的 control plane 主机 ip-10-0-131-183.ec2.internal 的 control plane 机器。

    2. 将机器配置保存到文件系统中的一个文件中：

       $ oc get machine clustername-8qw5l-master-0 \ 1
           -n openshift-machine-api \
           -o yaml \
           > new-master-machine.yaml

       1

       为丢失的 control plane 主机指定 control plane 机器的名称。

    3. 编辑上一步中创建的 new-master-machine.yaml 文件，以分配新名称并删除不必要的字段。

       1. 删除整个 status 部分：

          status:
            addresses:
            - address: 10.0.131.183
              type: InternalIP
            - address: ip-10-0-131-183.ec2.internal
              type: InternalDNS
            - address: ip-10-0-131-183.ec2.internal
              type: Hostname
            lastUpdated: "2020-04-20T17:44:29Z"
            nodeRef:
              kind: Node
              name: ip-10-0-131-183.ec2.internal
              uid: acca4411-af0d-4387-b73e-52b2484295ad
            phase: Running
            providerStatus:
              apiVersion: awsproviderconfig.openshift.io/v1beta1
              conditions:
              - lastProbeTime: "2020-04-20T16:53:50Z"
                lastTransitionTime: "2020-04-20T16:53:50Z"
                message: machine successfully created
                reason: MachineCreationSucceeded
                status: "True"
                type: MachineCreation
              instanceId: i-0fdb85790d76d0c3f
              instanceState: stopped
              kind: AWSMachineProviderStatus

       2. 将 metadata.name 字段更改为新名称。

          建议您保留与旧机器相同的基础名称，并将结束号码改为下一个可用数字。在本例中，clustername-8qw5l-master-0 被改为 clustername-8qw5l-master-3 ：

          apiVersion: machine.openshift.io/v1beta1
          kind: Machine
          metadata:
            ...
            name: clustername-8qw5l-master-3
            ...

       3. 删除 spec.providerID 字段：

          providerID: aws:///us-east-1a/i-0fdb85790d76d0c3f

       4. 删除 metadata.annotations 和 metadata.generation 字段：

          annotations:
            machine.openshift.io/instance-state: running
          ...
          generation: 2

       5. 删除 metadata.resourceVersion 和 metadata.uid 字段：

          resourceVersion: "13291"
          uid: a282eb70-40a2-4e89-8009-d05dd420d31a

    4. 删除丢失的 control plane 主机的机器：

       $ oc delete machine -n openshift-machine-api clustername-8qw5l-master-0 1

       1

       为丢失的 control plane 主机指定 control plane 机器的名称。

    5. 验证机器是否已删除：

       $ oc get machines -n openshift-machine-api -o wide

       输出示例：

       NAME                                        PHASE     TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
       clustername-8qw5l-master-1                  Running   m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-143-125.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
       clustername-8qw5l-master-2                  Running   m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-154-194.ec2.internal   aws:///us-east-1c/i-02626f1dba9ed5bba  running
       clustername-8qw5l-worker-us-east-1a-wbtgd   Running   m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
       clustername-8qw5l-worker-us-east-1b-lrdxb   Running   m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
       clustername-8qw5l-worker-us-east-1c-pkg26   Running   m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running

    6. 使用 new-master-machine.yaml 文件创建新机器：

       $ oc apply -f new-master-machine.yaml

    7. 验证新机器是否已创建：

       $ oc get machines -n openshift-machine-api -o wide

       输出示例：

       NAME                                        PHASE          TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
       clustername-8qw5l-master-1                  Running        m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-143-125.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
       clustername-8qw5l-master-2                  Running        m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-154-194.ec2.internal    aws:///us-east-1c/i-02626f1dba9ed5bba  running
       clustername-8qw5l-master-3                  Provisioning   m4.xlarge   us-east-1   us-east-1a   85s     ip-10-0-173-171.ec2.internal    aws:///us-east-1a/i-015b0888fe17bc2c8  running 1
       clustername-8qw5l-worker-us-east-1a-wbtgd   Running        m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
       clustername-8qw5l-worker-us-east-1b-lrdxb   Running        m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
       clustername-8qw5l-worker-us-east-1c-pkg26   Running        m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running

       1

       新机器 clustername-8qw5l-master-3 会被创建，并在阶段从 Provisioning 变为 Running 后就绪。

       创建新机器可能需要几分钟时间。当机器或节点返回一个健康状态时，etcd cluster Operator 将自动同步。

    8. 对不是恢复主机的每个已丢失的 control plane 主机重复此步骤。

13. 在一个单独的终端窗口中，使用以下命令以具有 cluster-admin 角色的用户身份登录到集群：

    $ oc login -u <cluster_admin> 1

    1

    对于 <cluster_admin>，使用 cluster-admin 角色指定一个用户名。

14. 强制 etcd 重新部署。

    在一个终端中使用 cluster-admin 用户连接到集群，运行以下命令：

    $ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge 1

    1

    forceRedeploymentReason 值必须是唯一的，这就是为什么附加时间戳的原因。

    当 etcd cluster Operator 执行重新部署时，现有节点开始使用与初始 bootstrap 扩展类似的新 pod。

15. 验证所有节点是否已更新至最新的修订版本。

    在一个终端中使用 cluster-admin 用户连接到集群，运行以下命令：

    $ oc get etcd -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'

    查看 etcd 的NodeInstallerProgressing 状态条件，以验证所有节点是否处于最新的修订。在更新成功后，输出会显示 AllNodesAtLatestRevision：

    AllNodesAtLatestRevision
    3 nodes are at revision 7 1

    1

    在本例中，最新的修订版本号是 7。

    如果输出包含多个修订号，如 2 个节点为修订版本 6；1 个节点为修订版本 7，这意味着更新仍在进行中。等待几分钟后重试。

16. 在重新部署 etcd 后，为 control plane 强制进行新的 rollout。由于 kubelet 使用内部负载平衡器连接到 API 服务器，因此 Kubernetes API 将在其他节点上重新安装自己。

    在一个终端中使用 cluster-admin 用户连接到集群，运行以下命令。

    1. 为 Kubernetes API 服务器强制进行新的推出部署：

       $ oc patch kubeapiserver cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge

       验证所有节点是否已更新至最新的修订版本。

       $ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'

       查看 NodeInstallerProgressing 状态条件，以验证所有节点是否处于最新版本。在更新成功后，输出会显示 AllNodesAtLatestRevision：

       AllNodesAtLatestRevision
       3 nodes are at revision 7 1

       1

       在本例中，最新的修订版本号是 7。

       如果输出包含多个修订号，如 2 个节点为修订版本 6；1 个节点为修订版本 7，这意味着更新仍在进行中。等待几分钟后重试。

    2. 为 Kubernetes 控制器管理器强制进行新的推出部署：

       $ oc patch kubecontrollermanager cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge

       验证所有节点是否已更新至最新的修订版本。

       $ oc get kubecontrollermanager -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'

       查看 NodeInstallerProgressing 状态条件，以验证所有节点是否处于最新版本。在更新成功后，输出会显示 AllNodesAtLatestRevision：

       AllNodesAtLatestRevision
       3 nodes are at revision 7 1

       1

       在本例中，最新的修订版本号是 7。

       如果输出包含多个修订号，如 2 个节点为修订版本 6；1 个节点为修订版本 7，这意味着更新仍在进行中。等待几分钟后重试。

    3. 为 Kubernetes 调度程序强制进行新的推出部署：

       $ oc patch kubescheduler cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge

       验证所有节点是否已更新至最新的修订版本。

       $ oc get kubescheduler -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'

       查看 NodeInstallerProgressing 状态条件，以验证所有节点是否处于最新版本。在更新成功后，输出会显示 AllNodesAtLatestRevision：

       AllNodesAtLatestRevision
       3 nodes are at revision 7 1

       1

       在本例中，最新的修订版本号是 7。

       如果输出包含多个修订号，如 2 个节点为修订版本 6；1 个节点为修订版本 7，这意味着更新仍在进行中。等待几分钟后重试。

17. 验证所有 control plane 主机是否已启动并加入集群。

    在一个终端中使用 cluster-admin 用户连接到集群，运行以下命令：

    $ oc get pods -n openshift-etcd | grep -v etcd-quorum-guard | grep etcd

    输出示例

    etcd-ip-10-0-143-125.ec2.internal                2/2     Running     0          9h
    etcd-ip-10-0-154-194.ec2.internal                2/2     Running     0          9h
    etcd-ip-10-0-173-171.ec2.internal                2/2     Running     0          9h

1. 使用类似以下示例的对象定义来创建 YAML 文件：

   apiVersion: policy/v1 1
   kind: PodDisruptionBudget
   metadata:
     name: my-pdb
   spec:
     minAvailable: 2  2
     selector:  3
       matchLabels:
         foo: bar

   1

   PodDisruptionBudget 是 policy/v1 API 组的一部分。

   2

   必须同时可用的最小 pod 数量。这可以是整数，也可以是指定百分比的字符串（如 20％）。

   3

   对一组资源进行的标签查询。matchLabels 和 matchExpressions 的结果在逻辑上是联合的。将此参数留空，如 selector {}，以选择项目中的所有 pod。

   或者：

   apiVersion: policy/v1 1
   kind: PodDisruptionBudget
   metadata:
     name: my-pdb
   spec:
     maxUnavailable: 25% 2
     selector: 3
       matchLabels:
         foo: bar

   1

   PodDisruptionBudget 是 policy/v1 API 组的一部分。

   2

   同时不能使用的最多的 pod 数量。这可以是整数，也可以是指定百分比的字符串（如 20％）。

   3

   对一组资源进行的标签查询。matchLabels 和 matchExpressions 的结果在逻辑上是联合的。将此参数留空，如 selector {}，以选择项目中的所有 pod。

2. 运行以下命令，将对象添加到项目中：

   $ oc create -f </path/to/file> -n <project_name>

流程

1. 在 web 控制台的 Administrator 视角中，导航到 Workloads → Secrets。

2. 在 Secrets 页面的表中，找到您的云供应商的 root secret。

   平台	Secret 名称
   AWS	aws-creds
   Azure	azure-credentials
   GCP	gcp-credentials
   RHOSP	openstack-credentials
   RHV	ovirt-credentials
   VMware vSphere	vsphere-creds

3. 点击与 secret 相同的行 中的 Options 菜单，然后选择 Edit Secret。
4. 记录 Value 字段的内容。您可以使用这些信息验证在更新凭证后该值是否不同。
5. 使用云供应商的新身份验证信息更新 Value 字段的文本，然后点 Save。

6. 如果您要为没有启用 vSphere CSI Driver Operator 的 vSphere 集群更新凭证，您必须强制推出 Kubernetes 控制器管理器以应用更新的凭证。

   注意

   如果启用了 vSphere CSI Driver Operator，则不需要这一步。

   要应用更新的 vSphere 凭证，请以具有 cluster-admin 角色的用户身份登录到 OpenShift Container Platform CLI，并运行以下命令：

   $ oc patch kubecontrollermanager cluster \
     -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date )"'"}}' \
     --type=merge

   当凭证被推出时，Kubernetes Controller Manager Operator 的状态会报告 Progressing=true。要查看状态，请运行以下命令：

   $ oc get co kube-controller-manager

7. 如果集群的 CCO 配置为使用 mint 模式，请删除各个 CredentialsRequest 对象引用的每个组件 secret。

   1. 以具有 cluster-admin 角色的用户身份登录 OpenShift Container Platform CLI。

   2. 获取所有引用的组件 secret 的名称和命名空间：

      $ oc -n openshift-cloud-credential-operator get CredentialsRequest \
        -o json | jq -r '.items[] | select (.spec.providerSpec.kind=="<provider_spec>") | .spec.secretRef'

      其中 <provider_spec> 是您的云供应商的对应值：

      • AWS: AWSProviderSpec
      • GCP: GCPProviderSpec

      AWS 输出的部分示例

      {
        "name": "ebs-cloud-credentials",
        "namespace": "openshift-cluster-csi-drivers"
      }
      {
        "name": "cloud-credential-operator-iam-ro-creds",
        "namespace": "openshift-cloud-credential-operator"
      }

   3. 删除每个引用的组件 secret：

      $ oc delete secret <secret_name> \1
        -n <secret_namespace> 2

      1

      指定 secret 的名称。

      2

      指定包含 secret 的命名空间。

      删除 AWS secret 示例

      $ oc delete secret ebs-cloud-credentials -n openshift-cluster-csi-drivers

      您不需要从供应商控制台手动删除凭证。删除引用的组件 secret 将导致 CCO 从平台中删除现有凭证并创建新凭证。

1. 在 web 控制台的 Administrator 视角中，导航到 Workloads → Secrets。
2. 验证 Value 字段的内容已改变。

流程

1. 在 web 控制台的 Administrator 视角中，导航到 Workloads → Secrets。

2. 在 Secrets 页面的表中，找到您的云供应商的 root secret。

   平台	Secret 名称
   AWS	aws-creds
   GCP	gcp-credentials

3. 点击与 secret 相同的行 中的 Options 菜单，然后选择 Delete Secret。

流程

1. 访问被镜像（mirror）的特定镜像流的镜像，例如：

   $ oc get is <imagestream> -n openshift -o json | jq .spec.tags[].from.name | grep registry.redhat.io

2. 将 registry.redhat.io 中与您在受限网络环境中需要的任何镜像流关联的镜像，镜像 (mirror) 成一个定义的镜像 (mirror)：

   $ oc image mirror registry.redhat.io/rhscl/ruby-25-rhel7:latest ${MIRROR_ADDR}/rhscl/ruby-25-rhel7:latest

3. 创建集群的镜像配置对象：

   $ oc create configmap registry-config --from-file=${MIRROR_ADDR_HOSTNAME}..5000=$path/ca.crt -n openshift-config

4. 在集群的镜像配置对象中，为镜像添加所需的可信 CA：

   $ oc patch image.config.openshift.io/cluster --patch '{"spec":{"additionalTrustedCA":{"name":"registry-config"}}}' --type=merge

5. 更新 Cluster Samples Operator 配置对象中的 samplesRegistry 字段，使其包含镜像配置中定义的镜像位置的 hostname 部分：

   $ oc edit configs.samples.operator.openshift.io -n openshift-cluster-samples-operator

   注意

   这是必要的，因为镜像流导入过程在此刻不使用镜像（mirro）或搜索机制。

6. 将所有未镜像的镜像流添加到 Cluster Samples Operator 配置对象的 skippedImagestreams 字段。或者，如果您不想支持任何示例镜像流，在 Cluster Samples Operator 配置对象中将 Cluster Samples Operator 设置为 Removed。

   注意

   如果镜像流导入失败，Cluster Samples Operator 会发出警告，但 Cluster Samples Operator 会定期重试，或看起来并没有重试它们。

   openshift 命名空间中的许多模板都引用镜像流。因此，使用 Removed 清除镜像流和模板，将避免在因为缺少镜像流而导致镜像流和模板无法正常工作时使用它们。

流程

1. 如果您还没有将镜像 registry 的可信 CA 添加到集群的镜像配置对象中，作为 Cluster Samples Operator 配置的一部分，请执行以下步骤：

   1. 创建集群的镜像配置对象：

      $ oc create configmap registry-config --from-file=${MIRROR_ADDR_HOSTNAME}..5000=$path/ca.crt -n openshift-config

   2. 在集群的镜像配置对象中，为镜像添加所需的可信 CA：

      $ oc patch image.config.openshift.io/cluster --patch '{"spec":{"additionalTrustedCA":{"name":"registry-config"}}}' --type=merge

2. 从您的安装有效负载中导入默认 must-gather 镜像：

   $ oc import-image is/must-gather -n openshift

流程

1. 确保机器上具有集群的 kubeconfig 文件，以及用于安装集群的安装程序。若要实现这一目标，一种方法是使用安装集群时所用的同一台机器。
2. 配置机器，以访问您计划用作计算机器的所有 RHEL 主机。您可以使用公司允许的任何方法，包括使用 SSH 代理或 VPN 的堡垒主机。

3. 在运行 playbook 的机器上配置一个用户，该用户对所有 RHEL 主机具有 SSH 访问权限。

   重要

   如果使用基于 SSH 密钥的身份验证，您必须使用 SSH 代理来管理密钥。

4. 如果还没有这样做，请使用 RHSM 注册机器，并为它附加一个带有 OpenShift 订阅的池：

   1. 使用 RHSM 注册机器：

      # subscription-manager register --username=<user_name> --password=<password>

   2. 从 RHSM 获取最新的订阅数据：

      # subscription-manager refresh

   3. 列出可用的订阅：

      # subscription-manager list --available --matches '*OpenShift*'

   4. 在上一命令的输出中，找到 OpenShift Container Platform 订阅的池 ID 并附加该池：

      # subscription-manager attach --pool=<pool_id>

5. 启用 OpenShift Container Platform 4.8 所需的存储库：

   # subscription-manager repos \
       --enable="rhel-7-server-rpms" \
       --enable="rhel-7-server-extras-rpms" \
       --enable="rhel-7-server-ansible-2.9-rpms" \
       --enable="rhel-7-server-ose-4.8-rpms"

6. 安装所需的软件包，包括 openshift-ansible:

   # yum install openshift-ansible openshift-clients jq

   openshift-ansible 软件包提供了安装实用程序，并且会拉取将 RHEL 计算节点添加到集群所需要的其他软件包，如 Ansible、playbook 和相关的配置文件。openshift-clients 提供 oc CLI，jq 软件包则可改善命令行中 JSON 输出的显示。

1. 在每一主机上进行 RHSM 注册：

   # subscription-manager register --username=<user_name> --password=<password>

2. 从 RHSM 获取最新的订阅数据：

   # subscription-manager refresh

3. 列出可用的订阅：

   # subscription-manager list --available --matches '*OpenShift*'

4. 在上一命令的输出中，找到 OpenShift Container Platform 订阅的池 ID 并附加该池：

   # subscription-manager attach --pool=<pool_id>

5. 禁用所有 yum 存储库：

   1. 禁用所有已启用的 RHSM 存储库：

      # subscription-manager repos --disable="*"

   2. 列出剩余的 yum 存储库，并记录它们在 repo id 下的名称（若有）：

      # yum repolist

   3. 使用 yum-config-manager 禁用剩余的 yum 存储库：

      # yum-config-manager --disable <repo_id>

      或者，禁用所有存储库：

      # yum-config-manager --disable \*

      请注意，有大量可用存储库时可能需要花费几分钟

6. 仅启用 OpenShift Container Platform 4.8 需要的存储库：

   # subscription-manager repos \
       --enable="rhel-7-server-rpms" \
       --enable="rhel-7-fast-datapath-rpms" \
       --enable="rhel-7-server-extras-rpms" \
       --enable="rhel-7-server-optional-rpms" \
       --enable="rhel-7-server-ose-4.8-rpms"

7. 停止并禁用主机上的防火墙：

   # systemctl disable --now firewalld.service

   注意

   请不要在以后启用防火墙。如果这样做，则无法访问 worker 上的 OpenShift Container Platform 日志。

1. 创建一个名为 /<path>/inventory/hosts 的 Ansible 清单文件，以定义您的计算机器主机和必要的变量：

   [all:vars]
   ansible_user=root 1
   #ansible_become=True 2
   
   openshift_kubeconfig_path="~/.kube/config" 3
   
   [new_workers] 4
   mycluster-rhel7-0.example.com
   mycluster-rhel7-1.example.com

   1

   指定要在远程计算机器上运行 Ansible 任务的用户名。

   2

   如果不将 root 指定为 ansible_user，您必须将 ansible_become 设置为 True，并为该用户分配 sudo 权限。

   3

   指定集群的 kubeconfig 文件的路径和文件名。

   4

   列出要添加到集群中的每台 RHEL 机器。必须为每个主机提供完全限定域名。此名称是集群用来访问机器的主机名，因此请设置用于访问机器的正确公共或私有名称。

2. 进入到 Ansible playbook 目录：

   $ cd /usr/share/ansible/openshift-ansible

3. 运行 playbook：

   $ ansible-playbook -i /<path>/inventory/hosts playbooks/scaleup.yml 1

   1

   对于<path> ，指定您创建的Ansible库存文件的路径。

流程

1. 查看机器列表并记录 RHCOS 计算机器的节点名称：

   $ oc get nodes -o wide

2. 对于每一台 RHCOS 计算机器，删除其节点：

   1. 通过运行 oc adm cordon 命令，将节点标记为不可调度：

      $ oc adm cordon <node_name> 1

      1

      指定其中一台 RHCOS 计算机器的节点名称。

   2. 清空节点中的所有 Pod：

      $ oc adm drain <node_name> --force --delete-emptydir-data --ignore-daemonsets 1

      1

      指定您隔离的 RHCOS 计算机器的节点名称。

   3. 删除节点：

      $ oc delete nodes <node_name> 1

      1

      指定您清空的 RHCOS 计算机器的节点名称。

3. 查看计算机器的列表，以确保仅保留 RHEL 节点：

   $ oc get nodes -o wide

4. 从集群的计算机器的负载均衡器中删除 RHCOS 机器。您可以删除虚拟机或重新制作 RHCOS 计算机器物理硬件的镜像。

流程

1. 使用 ISO 文件在更多计算机器上安装 RHCOS。在安装集群前，使用创建机器时使用的相同方法：

   • 将 ISO 镜像刻录到磁盘并直接启动。
   • 在 LOM 接口中使用 ISO 重定向。
2. 实例启动后，按 TAB 或 E 键编辑内核命令行。

3. 将参数添加到内核命令行：

   coreos.inst.install_dev=sda 1
   coreos.inst.ignition_url=http://example.com/worker.ign 2

   1

   指定要安装到的系统块设备。

   2

   指定计算 Ignition 配置文件的 URL。只支持 HTTP 和 HTTPS 协议。

4. 按 Enter 键完成安装。安装 RHCOS 后，系统会重启。系统重启后，它会应用您指定的 Ignition 配置文件。
5. 继续为集群创建更多计算机器。

流程

1. 确认 RHCOS 镜像的 PXE 或 iPXE 安装正确。

   • 对于 PXE：

     DEFAULT pxeboot
     TIMEOUT 20
     PROMPT 0
     LABEL pxeboot
         KERNEL http://<HTTP_server>/rhcos-<version>-live-kernel-<architecture> 1
         APPEND initrd=http://<HTTP_server>/rhcos-<version>-live-initramfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/worker.ign coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img 2

     1

     指定上传到 HTTP 服务器的 live kernel 文件位置。

     2

     指定上传到 HTTP 服务器的 RHCOS 文件的位置。initrd 参数值是 live initramfs 文件的位置，coreos.inst.ignition_url 参数值是 worker Ignition 配置文件的位置，coreos.live.rootfs_url 参数值是 live rootfs 文件的位置。coreos.inst.ignition_url 和 coreos.live.rootfs_url 参数仅支持 HTTP 和 HTTPS。

1. 使用 PXE 或 iPXE 基础架构为集群创建所需的计算机器。

流程

1. 确认集群可以识别这些机器：

   $ oc get nodes

   输出示例

   NAME      STATUS    ROLES   AGE  VERSION
   master-0  Ready     master  63m  v1.21.0
   master-1  Ready     master  63m  v1.21.0
   master-2  Ready     master  64m  v1.21.0

   输出中列出了您创建的所有机器。

   注意

   在有些 CSR 被批准前，前面的输出可能不包括计算节点（也称为 worker 节点）。

2. 检查待处理的 CSR，并确保添加到集群中的每台机器都有 Pending 或 Approved 状态的客户端请求：

   $ oc get csr

   输出示例

   NAME        AGE     REQUESTOR                                                                   CONDITION
   csr-8b2br   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
   csr-8vnps   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
   ...

   在本例中，两台机器加入集群。您可能会在列表中看到更多已批准的 CSR。

3. 如果 CSR 没有获得批准，在您添加的机器的所有待处理 CSR 都处于 Pending 状态 后，请批准集群机器的 CSR：

   注意

   由于 CSR 会自动轮转，因此请在将机器添加到集群后一小时内批准您的 CSR。如果没有在一小时内批准它们，证书将会轮转，每个节点会存在多个证书。您必须批准所有这些证书。批准客户端 CSR 后，Kubelet 为服务证书创建一个二级 CSR，这需要手动批准。然后，如果 Kubelet 请求具有相同参数的新证书，则后续提供证书续订请求由 machine-approver 自动批准。

   注意

   对于在未启用机器 API 的平台上运行的集群，如裸机和其他用户置备的基础架构，您必须实施一种方法来自动批准 kubelet 提供证书请求(CSR)。如果没有批准请求，则 oc exec、ocrsh 和 oc logs 命令将无法成功，因为 API 服务器连接到 kubelet 时需要服务证书。与 Kubelet 端点联系的任何操作都需要此证书批准。该方法必须监视新的 CSR，确认 CSR 由 system: node 或 system:admin 组中的 node-bootstrapper 服务帐户提交，并确认节点的身份。

   • 要单独批准，请对每个有效的 CSR 运行以下命令：

     $ oc adm certificate approve <csr_name> 1

     1

     <csr_name> 是当前 CSR 列表中 CSR 的名称。

   • 要批准所有待处理的 CSR，请运行以下命令：

     $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approve

     注意

     在有些 CSR 被批准前，一些 Operator 可能无法使用。

4. 现在，您的客户端请求已被批准，您必须查看添加到集群中的每台机器的服务器请求：

   $ oc get csr

   输出示例

   NAME        AGE     REQUESTOR                                                                   CONDITION
   csr-bfd72   5m26s   system:node:ip-10-0-50-126.us-east-2.compute.internal                       Pending
   csr-c57lv   5m26s   system:node:ip-10-0-95-157.us-east-2.compute.internal                       Pending
   ...

5. 如果剩余的 CSR 没有被批准，且处于 Pending 状态，请批准集群机器的 CSR：

   • 要单独批准，请对每个有效的 CSR 运行以下命令：

     $ oc adm certificate approve <csr_name> 1

     1

     <csr_name> 是当前 CSR 列表中 CSR 的名称。

   • 要批准所有待处理的 CSR，请运行以下命令：

     $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve

6. 批准所有客户端和服务器 CSR 后，机器将 处于 Ready 状态。运行以下命令验证：

   $ oc get nodes

   输出示例

   NAME      STATUS    ROLES   AGE  VERSION
   master-0  Ready     master  73m  v1.21.0
   master-1  Ready     master  73m  v1.21.0
   master-2  Ready     master  74m  v1.21.0
   worker-0  Ready     worker  11m  v1.21.0
   worker-1  Ready     worker  11m  v1.21.0

   注意

   批准服务器 CSR 后可能需要几分钟时间让机器过渡到 Ready 状态。

流程

1. 创建一个 healthcheck.yml 文件，其中包含您的机器健康检查的定义。

2. 将 healthcheck.yml 文件应用到您的集群：

   $ oc apply -f healthcheck.yml

流程

1. 查看集群中的机器集：

   $ oc get machinesets -n openshift-machine-api

   机器集以 <clusterid>-worker-<aws-region-az> 的形式列出。

2. 查看集群中的机器：

   $ oc get machine -n openshift-machine-api

3. 在您要删除的机器上设置注解：

   $ oc annotate machine/<machine_name> -n openshift-machine-api machine.openshift.io/cluster-api-delete-machine="true"

4. 进行 cordon 操作，排空您要删除的节点：

   $ oc adm cordon <node_name>
   $ oc adm drain <node_name>

5. 扩展机器集：

   $ oc scale --replicas=2 machineset <machineset> -n openshift-machine-api

   或者：

   $ oc edit machineset <machineset> -n openshift-machine-api

   提示

   您还可以应用以下 YAML 来扩展机器集：

   apiVersion: machine.openshift.io/v1beta1
   kind: MachineSet
   metadata:
     name: <machineset>
     namespace: openshift-machine-api
   spec:
     replicas: 2

   您可以扩展或缩减机器集。需要过几分钟以后新机器才可用。

先决条件

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：

   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=large-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

   这应该会显示 status: "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. 编辑 worker 机器配置池：

   $ oc edit machineconfigpool worker

2. 将 maxUnavailable 设置为您需要的值：

   spec:
     maxUnavailable: <node_count>

   重要

   当设置该值时，请考虑无法使用的 worker 节点数量，而不影响在集群中运行的应用程序。

流程

1. 可选：标记节点：

   # oc label node perf-node.example.com cpumanager=true

2. 编辑启用 CPU Manager 的节点的 MachineConfigPool 。在这个示例中，所有 worker 都启用了 CPU Manager：

   # oc edit machineconfigpool worker

3. 为 worker 机器配置池添加标签：

   metadata:
     creationTimestamp: 2020-xx-xxx
     generation: 3
     labels:
       custom-kubelet: cpumanager-enabled

4. 创建 KubeletConfig，cpumanager-kubeletconfig.yaml，自定义资源 (CR) 。请参阅上一步中创建的标签，以便使用新的 kubelet 配置更新正确的节点。请参见 MachineConfigPoolSelector 部分：

   apiVersion: machineconfiguration.openshift.io/v1
   kind: KubeletConfig
   metadata:
     name: cpumanager-enabled
   spec:
     machineConfigPoolSelector:
       matchLabels:
         custom-kubelet: cpumanager-enabled
     kubeletConfig:
        cpuManagerPolicy: static 1
        cpuManagerReconcilePeriod: 5s 2

   1

   指定一个策略：

   • none.这个策略明确启用了现有的默认 CPU 关联性方案，从而不会出现超越调度程序自动进行的关联性。
   • static。此策略允许具有某些资源特征的 pod 获得提高 CPU 关联性和节点上专用的 pod。

   2

   可选。指定 CPU Manager 协调频率。默认值为 5s。

5. 创建动态 kubelet 配置：

   # oc create -f cpumanager-kubeletconfig.yaml

   这会在 kubelet 配置中添加 CPU Manager 功能，如果需要，Machine Config Operator（MCO）将重启节点。要启用 CPU Manager，则不需要重启。

6. 检查合并的 kubelet 配置：

   # oc get machineconfig 99-worker-XXXXXX-XXXXX-XXXX-XXXXX-kubelet -o json | grep ownerReference -A7

   输出示例

          "ownerReferences": [
               {
                   "apiVersion": "machineconfiguration.openshift.io/v1",
                   "kind": "KubeletConfig",
                   "name": "cpumanager-enabled",
                   "uid": "7ed5616d-6b72-11e9-aae1-021e1ce18878"
               }
           ]

7. 检查 worker 是否有更新的 kubelet.conf：

   # oc debug node/perf-node.example.com
   sh-4.2# cat /host/etc/kubernetes/kubelet.conf | grep cpuManager

   输出示例

   cpuManagerPolicy: static        1
   cpuManagerReconcilePeriod: 5s   2

   1 2

   当创建 KubeletConfig CR 时会定义这些设置。

8. 创建请求一个或多个内核的 pod。限制和请求都必须将其 CPU 值设置为一个整数。这是专用于此 pod 的内核数：

   # cat cpumanager-pod.yaml

   输出示例

   apiVersion: v1
   kind: Pod
   metadata:
     generateName: cpumanager-
   spec:
     containers:
     - name: cpumanager
       image: gcr.io/google_containers/pause-amd64:3.0
       resources:
         requests:
           cpu: 1
           memory: "1G"
         limits:
           cpu: 1
           memory: "1G"
     nodeSelector:
       cpumanager: "true"

9. 创建 pod：

   # oc create -f cpumanager-pod.yaml

10. 确定为您标记的节点调度了 pod：

    # oc describe pod cpumanager

    输出示例

    Name:               cpumanager-6cqz7
    Namespace:          default
    Priority:           0
    PriorityClassName:  <none>
    Node:  perf-node.example.com/xxx.xx.xx.xxx
    ...
     Limits:
          cpu:     1
          memory:  1G
        Requests:
          cpu:        1
          memory:     1G
    ...
    QoS Class:       Guaranteed
    Node-Selectors:  cpumanager=true

11. 确认正确配置了 cgroups。获取 pause 进程的进程 ID（PID）：

    # ├─init.scope
    │ └─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 17
    └─kubepods.slice
      ├─kubepods-pod69c01f8e_6b74_11e9_ac0f_0a2b62178a22.slice
      │ ├─crio-b5437308f1a574c542bdf08563b865c0345c8f8c0b0a655612c.scope
      │ └─32706 /pause

    服务质量（QoS）等级为 Guaranteed 的 pod 被放置到 kubepods.slice 中。其它 QoS 等级的 pod 会位于 kubepods 的子 cgroups 中：

    # cd /sys/fs/cgroup/cpuset/kubepods.slice/kubepods-pod69c01f8e_6b74_11e9_ac0f_0a2b62178a22.slice/crio-b5437308f1ad1a7db0574c542bdf08563b865c0345c86e9585f8c0b0a655612c.scope
    # for i in `ls cpuset.cpus tasks` ; do echo -n "$i "; cat $i ; done

    输出示例

    cpuset.cpus 1
    tasks 32706

12. 检查任务允许的 CPU 列表：

    # grep ^Cpus_allowed_list /proc/32706/status

    输出示例

     Cpus_allowed_list:    1

13. 确认系统中的另一个 pod（在这个示例中，QoS 等级为 burstable 的 pod）不能在为等级为Guaranteed 的 pod 分配的内核中运行：

    # cat /sys/fs/cgroup/cpuset/kubepods.slice/kubepods-besteffort.slice/kubepods-besteffort-podc494a073_6b77_11e9_98c0_06bba5c387ea.slice/crio-c56982f57b75a2420947f0afc6cafe7534c5734efc34157525fa9abbf99e3849.scope/cpuset.cpus
    0
    # oc describe node perf-node.example.com

    输出示例

    ...
    Capacity:
     attachable-volumes-aws-ebs:  39
     cpu:                         2
     ephemeral-storage:           124768236Ki
     hugepages-1Gi:               0
     hugepages-2Mi:               0
     memory:                      8162900Ki
     pods:                        250
    Allocatable:
     attachable-volumes-aws-ebs:  39
     cpu:                         1500m
     ephemeral-storage:           124768236Ki
     hugepages-1Gi:               0
     hugepages-2Mi:               0
     memory:                      7548500Ki
     pods:                        250
    -------                               ----                           ------------  ----------  ---------------  -------------  ---
      default                                 cpumanager-6cqz7               1 (66%)       1 (66%)     1G (12%)         1G (12%)       29m
    
    Allocated resources:
      (Total limits may be over 100 percent, i.e., overcommitted.)
      Resource                    Requests          Limits
      --------                    --------          ------
      cpu                         1440m (96%)       1 (66%)

    这个 VM 有两个 CPU 内核。system-reserved 设置保留 500 millicores，这代表一个内核中的一半被从节点的总容量中减小，以达到 Node Allocatable 的数量。您可以看到 Allocatable CPU 是 1500 毫秒。这意味着您可以运行一个 CPU Manager pod，因为每个 pod 需要一个完整的内核。一个完整的内核等于 1000 毫秒。如果您尝试调度第二个 pod，系统将接受该 pod，但不会调度它：

    NAME                    READY   STATUS    RESTARTS   AGE
    cpumanager-6cqz7        1/1     Running   0          33m
    cpumanager-7qc2t        0/1     Pending   0          11s

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

   1. 查看机器配置：

      # oc describe machineconfig <name>

      例如：

      # oc describe machineconfig 00-worker

      输出示例

      Name:         00-worker
      Namespace:
      Labels:       machineconfiguration.openshift.io/role=worker 1

      1

      设备管理器所需标签。

流程

1. 为配置更改创建自定义资源 (CR)。

   设备管理器 CR 配置示例

   apiVersion: machineconfiguration.openshift.io/v1
   kind: KubeletConfig
   metadata:
     name: devicemgr 1
   spec:
     machineConfigPoolSelector:
       matchLabels:
          machineconfiguration.openshift.io: devicemgr 2
     kubeletConfig:
       feature-gates:
         - DevicePlugins=true 3

   1

   为 CR 分配一个名称。

   2

   输入来自机器配置池的标签。

   3

   将 DevicePlugins 设为“true”。

2. 创建设备管理器：

   $ oc create -f devicemgr.yaml

   输出示例

   kubeletconfig.machineconfiguration.openshift.io/devicemgr created

3. 通过确认节点上已创建了 /var/lib/kubelet/device-plugins/kubelet.sock，确保已启用了设备管理器。这是设备管理器 gRPC 服务器在其上侦听新插件注册的 UNIX 域套接字。只有启用了设备管理器，才会在 Kubelet 启动时创建此 sock 文件。

1. 如果为 control plane 节点（也称为 master 节点）添加了一个 NoSchedule 污点，则节点必须具有 node-role.kubernetes.io/master=:NoSchedule 污点，该污点会被默认添加。

   例如：

   apiVersion: v1
   kind: Node
   metadata:
     annotations:
       machine.openshift.io/machine: openshift-machine-api/ci-ln-62s7gtb-f76d1-v8jxv-master-0
       machineconfiguration.openshift.io/currentConfig: rendered-master-cdc1ab7da414629332cc4c3926e6e59c
   ...
   spec:
     taints:
     - effect: NoSchedule
       key: node-role.kubernetes.io/master
   ...

流程

1. 通过编辑 Pod spec 使其包含 tolerations 小节来向 pod 添加容限：

   使用 Equal 运算符的 pod 配置文件示例

   spec:
     tolerations:
     - key: "key1" 1
       value: "value1"
       operator: "Equal"
       effect: "NoExecute"
       tolerationSeconds: 3600 2

   1

   容限参数，如 Taint 和 toleration 组件表中所述。

   2

   tolerationSeconds 参数指定 pod 在被驱除前可以保持与节点绑定的时长。

   例如：

   使用 Exists 运算符的 pod 配置文件示例

   spec:
      tolerations:
       - key: "key1"
         operator: "Exists" 1
         effect: "NoExecute"
         tolerationSeconds: 3600

   1

   Exists 运算符不会接受一个 value。

   本例在 node1 上放置一个键为 key1 且值为 value1 的污点，污点效果是 NoExecute。

2. 通过以下命令，使用 Taint 和 toleration 组件表中描述的参数为节点添加污点：

   $ oc adm taint nodes <node_name> <key>=<value>:<effect>

   例如：

   $ oc adm taint nodes node1 key1=value1:NoExecute

   此命令在 node1 上放置一个键为 key1，值为 value1 的污点，其效果是 NoExecute。

   注意

   如果为 control plane 节点（也称为 master 节点）添加了一个 NoSchedule 污点，则节点必须具有 node-role.kubernetes.io/master=:NoSchedule 污点，该污点会被默认添加。

   例如：

   apiVersion: v1
   kind: Node
   metadata:
     annotations:
       machine.openshift.io/machine: openshift-machine-api/ci-ln-62s7gtb-f76d1-v8jxv-master-0
       machineconfiguration.openshift.io/currentConfig: rendered-master-cdc1ab7da414629332cc4c3926e6e59c
   ...
   spec:
     taints:
     - effect: NoSchedule
       key: node-role.kubernetes.io/master
   ...

   pod 上的容限与节点上的污点匹配。具有任一容限的 pod 可以调度到 node1 上。

流程

1. 通过编辑 Pod spec 使其包含 tolerations 小节来向 pod 添加容限：

   使用 Equal 运算符的 pod 配置文件示例

   spec:
     tolerations:
     - key: "key1" 1
       value: "value1"
       operator: "Equal"
       effect: "NoExecute"
       tolerationSeconds: 3600 2

   1

   容限参数，如 Taint 和 toleration 组件表中所述。

   2

   tolerationSeconds 参数指定 pod 在被驱除前与节点绑定的时长。

   例如：

   使用 Exists 运算符的 pod 配置文件示例

   spec:
     tolerations:
     - key: "key1"
       operator: "Exists"
       effect: "NoExecute"
       tolerationSeconds: 3600

2. 将污点添加到 MachineSet 对象：

   1. 为您想要污点的节点编辑 MachineSet YAML，也可以创建新 MachineSet 对象：

      $ oc edit machineset <machineset>

   2. 将污点添加到 spec.template.spec 部分：

      机器集规格中的污点示例

      spec:
      ....
        template:
      ....
          spec:
            taints:
            - effect: NoExecute
              key: key1
              value: value1
      ....

      本例在节点上放置一个键为 key1，值为 value1 的污点，污点效果是 NoExecute。

   3. 将机器缩减为 0:

      $ oc scale --replicas=0 machineset <machineset> -n openshift-machine-api

      提示

      您还可以应用以下 YAML 来扩展机器集：

      apiVersion: machine.openshift.io/v1beta1
      kind: MachineSet
      metadata:
        name: <machineset>
        namespace: openshift-machine-api
      spec:
        replicas: 0

      等待机器被删除。

   4. 根据需要扩展机器设置：

      $ oc scale --replicas=2 machineset <machineset> -n openshift-machine-api

      或者：

      $ oc edit machineset <machineset> -n openshift-machine-api

      等待机器启动。污点添加到与 MachineSet 对象关联的节点上。

1. 为这些节点添加对应的污点：

   例如：

   $ oc adm taint nodes node1 dedicated=groupName:NoSchedule

   提示

   您还可以应用以下 YAML 来添加污点：

   kind: Node
   apiVersion: v1
   metadata:
     name: <node_name>
     labels:
       ...
   spec:
     taints:
       - key: dedicated
         value: groupName
         effect: NoSchedule

2. 通过编写自定义准入控制器，为 pod 添加容限。

1. 为需要特殊硬件的 pod 添加容限。

   例如：

   spec:
     tolerations:
       - key: "disktype"
         value: "ssd"
         operator: "Equal"
         effect: "NoSchedule"
         tolerationSeconds: 3600

2. 使用以下命令之一，给拥有特殊硬件的节点添加污点：

   $ oc adm taint nodes <node-name> disktype=ssd:NoSchedule

   或者：

   $ oc adm taint nodes <node-name> disktype=ssd:PreferNoSchedule

   提示

   您还可以应用以下 YAML 来添加污点：

   kind: Node
   apiVersion: v1
   metadata:
     name: <node_name>
     labels:
       ...
   spec:
     taints:
       - key: disktype
         value: ssd
         effect: PreferNoSchedule

1. 从节点移除污点：

   $ oc adm taint nodes <node-name> <key>-

   例如：

   $ oc adm taint nodes ip-10-0-132-248.ec2.internal key1-

   输出示例

   node/ip-10-0-132-248.ec2.internal untainted

2. 要从 pod 移除某一容限，请编辑 Pod 规格来移除该容限：

   spec:
     tolerations:
     - key: "key2"
       operator: "Exists"
       effect: "NoExecute"
       tolerationSeconds: 3600

1. 在 cpumanager-enabled 自定义资源（CR）中配置拓扑管理器分配策略。

   $ oc edit KubeletConfig cpumanager-enabled

   apiVersion: machineconfiguration.openshift.io/v1
   kind: KubeletConfig
   metadata:
     name: cpumanager-enabled
   spec:
     machineConfigPoolSelector:
       matchLabels:
         custom-kubelet: cpumanager-enabled
     kubeletConfig:
        cpuManagerPolicy: static 1
        cpuManagerReconcilePeriod: 5s
        topologyManagerPolicy: single-numa-node 2

   1

   此参数必须是 static。

   2

   指定所选拓扑管理器分配策略。在这里，策略是 single-numa-node。有效值为：default、best-effort、restricted、single-numa-node。

1. 在 OpenShift Container Platform web 控制台中进入 Home → Projects

   1. 点击 Create Project。
   2. 指定 clusterresourceoverride-operator 作为项目的名称。
   3. 点击 Create。

2. 进入 Operators → OperatorHub。

   1. 从可用 Operator 列表中选择 ClusterResourceOverride Operator，再点击 Install。
   2. 在 Install Operator 页面中，确保为 Installation Mode 选择了 A specific Namespace on the cluster。
   3. 确保为 Installed Namespace 选择了 clusterresourceoverride-operator。
   4. 指定更新频道和批准策略。
   5. 点击 Install。

3. 在 Installed Operators 页面中，点 ClusterResourceOverride。

   1. 在 ClusterResourceOverride Operator 详情页面中，点 Create Instance。

   2. 在 Create ClusterResourceOverride 页面 中，编辑 YAML 模板以根据需要设置过量使用值：

      apiVersion: operator.autoscaling.openshift.io/v1
      kind: ClusterResourceOverride
      metadata:
        name: cluster 1
      spec:
        podResourceOverride:
          spec:
            memoryRequestToLimitPercent: 50 2
            cpuRequestToLimitPercent: 25 3
            limitCPUToMemoryPercent: 200 4

      1

      名称必须是 cluster。

      2

      可选。指定在 1-100 之间覆盖容器内存限值的百分比（如果使用的话）。默认值为 50.

      3

      可选。指定在 1-100 之间覆盖容器 CPU 限值的百分比（如果使用的话）。默认值为 25。

      4

      可选。如果使用，请指定覆盖容器内存限值的百分比。以 100% 扩展 1Gi RAM， 等于 1 个 CPU 内核。这会在覆盖 CPU 请求前进行处理（如果已配置）。默认值为 200。

   3. 点击 Create。

4. 通过检查集群自定义资源的状态来检查准入 Webhook 的当前状态：

   1. 在 ClusterResourceOverride Operator 页面中，点击 cluster。

   2. 在 ClusterResourceOverride Details 页中，点 YAML。当 webhook 被调用时，mutatingWebhookConfigurationRef 项会出现。

      apiVersion: operator.autoscaling.openshift.io/v1
      kind: ClusterResourceOverride
      metadata:
        annotations:
          kubectl.kubernetes.io/last-applied-configuration: |
            {"apiVersion":"operator.autoscaling.openshift.io/v1","kind":"ClusterResourceOverride","metadata":{"annotations":{},"name":"cluster"},"spec":{"podResourceOverride":{"spec":{"cpuRequestToLimitPercent":25,"limitCPUToMemoryPercent":200,"memoryRequestToLimitPercent":50}}}}
        creationTimestamp: "2019-12-18T22:35:02Z"
        generation: 1
        name: cluster
        resourceVersion: "127622"
        selfLink: /apis/operator.autoscaling.openshift.io/v1/clusterresourceoverrides/cluster
        uid: 978fc959-1717-4bd1-97d0-ae00ee111e8d
      spec:
        podResourceOverride:
          spec:
            cpuRequestToLimitPercent: 25
            limitCPUToMemoryPercent: 200
            memoryRequestToLimitPercent: 50
      status:
      
      ....
      
          mutatingWebhookConfigurationRef: 1
            apiVersion: admissionregistration.k8s.io/v1beta1
            kind: MutatingWebhookConfiguration
            name: clusterresourceoverrides.admission.autoscaling.openshift.io
            resourceVersion: "127621"
            uid: 98b3b8ae-d5ce-462b-8ab5-a729ea8f38f3
      
      ....

      1

      引用 ClusterResourceOverride 准入Webhook。

1. 为 Cluster Resource Override Operator 创建命名空间：

   1. 为 Cluster Resource Override Operator 创建一个 Namespace 空间对象 YAML 文件（如 cro-namespace.yaml）:

      apiVersion: v1
      kind: Namespace
      metadata:
        name: clusterresourceoverride-operator

   2. 创建命名空间：

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

      例如：

      $ oc create -f cro-namespace.yaml

2. 创建一个 Operator 组：

   1. 为 Cluster Resource Override Operator 创建一个 OperatorGroup 对象 YAML 文件（如 cro-og.yaml）:

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: clusterresourceoverride-operator
        namespace: clusterresourceoverride-operator
      spec:
        targetNamespaces:
          - clusterresourceoverride-operator

   2. 创建 Operator 组：

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

      例如：

      $ oc create -f cro-og.yaml

3. 创建一个订阅：

   1. 为 Cluster Resourceoverride Operator 创建一个 Subscription 对象 YAML 文件（如 cro-sub.yaml):

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: clusterresourceoverride
        namespace: clusterresourceoverride-operator
      spec:
        channel: "4.8"
        name: clusterresourceoverride
        source: redhat-operators
        sourceNamespace: openshift-marketplace

   2. 创建订阅：

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

      例如：

      $ oc create -f cro-sub.yaml

4. 在 clusterresourceoverride-operator 命名空间中创建 ClusterResourceOverride 自定义资源（CR）对象：

   1. 进入 clusterresourceoverride-operator 命名空间。

      $ oc project clusterresourceoverride-operator

   2. 为 Cluster Resourceoverride Operator 创建 ClusterResourceOverride 对象 YAML 文件（如 cro-cr.yaml):

      apiVersion: operator.autoscaling.openshift.io/v1
      kind: ClusterResourceOverride
      metadata:
          name: cluster 1
      spec:
        podResourceOverride:
          spec:
            memoryRequestToLimitPercent: 50 2
            cpuRequestToLimitPercent: 25 3
            limitCPUToMemoryPercent: 200 4

      1

      名称必须是 cluster。

      2

      可选。指定在 1-100 之间覆盖容器内存限值的百分比（如果使用的话）。默认值为 50.

      3

      可选。指定在 1-100 之间覆盖容器 CPU 限值的百分比（如果使用的话）。默认值为 25。

      4

      可选。如果使用，请指定覆盖容器内存限值的百分比。以 100% 扩展 1Gi RAM， 等于 1 个 CPU 内核。这会在覆盖 CPU 请求前进行处理（如果已配置）。默认值为 200。

   3. 创建 ClusterResourceOverride 对象：

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

      例如：

      $ oc create -f cro-cr.yaml

5. 通过检查集群自定义资源的状态来验证准入 Webhook 的当前状态。

   $ oc get clusterresourceoverride cluster -n clusterresourceoverride-operator -o yaml

   当 webhook 被调用时，mutatingWebhookConfigurationRef 项会出现。

   输出示例

   apiVersion: operator.autoscaling.openshift.io/v1
   kind: ClusterResourceOverride
   metadata:
     annotations:
       kubectl.kubernetes.io/last-applied-configuration: |
         {"apiVersion":"operator.autoscaling.openshift.io/v1","kind":"ClusterResourceOverride","metadata":{"annotations":{},"name":"cluster"},"spec":{"podResourceOverride":{"spec":{"cpuRequestToLimitPercent":25,"limitCPUToMemoryPercent":200,"memoryRequestToLimitPercent":50}}}}
     creationTimestamp: "2019-12-18T22:35:02Z"
     generation: 1
     name: cluster
     resourceVersion: "127622"
     selfLink: /apis/operator.autoscaling.openshift.io/v1/clusterresourceoverrides/cluster
     uid: 978fc959-1717-4bd1-97d0-ae00ee111e8d
   spec:
     podResourceOverride:
       spec:
         cpuRequestToLimitPercent: 25
         limitCPUToMemoryPercent: 200
         memoryRequestToLimitPercent: 50
   status:
   
   ....
   
       mutatingWebhookConfigurationRef: 1
         apiVersion: admissionregistration.k8s.io/v1beta1
         kind: MutatingWebhookConfiguration
         name: clusterresourceoverrides.admission.autoscaling.openshift.io
         resourceVersion: "127621"
         uid: 98b3b8ae-d5ce-462b-8ab5-a729ea8f38f3
   
   ....

   1

   引用 ClusterResourceOverride 准入Webhook。

1. 编辑 ClusterResourceOverride CR:

   apiVersion: operator.autoscaling.openshift.io/v1
   kind: ClusterResourceOverride
   metadata:
       name: cluster
   spec:
     podResourceOverride:
       spec:
         memoryRequestToLimitPercent: 50 1
         cpuRequestToLimitPercent: 25 2
         limitCPUToMemoryPercent: 200 3

   1

   可选。指定在 1-100 之间覆盖容器内存限值的百分比（如果使用的话）。默认值为 50.

   2

   可选。指定在 1-100 之间覆盖容器 CPU 限值的百分比（如果使用的话）。默认值为 25。

   3

   可选。如果使用，请指定覆盖容器内存限值的百分比。以 100% 扩展 1Gi RAM， 等于 1 个 CPU 内核。这会在覆盖 CPU 请求前进行处理（如果已配置）。默认值为 200。

2. 确保在每个您希望 Cluster Resourceoverride Operator 来控制过量使用的项目中都添加了以下标识：

   apiVersion: v1
   kind: Namespace
   metadata:
   
    ...
   
     labels:
       clusterresourceoverrides.admission.autoscaling.openshift.io/enabled: "true" 1
   
    ...

   1

   把这个标识添加到每个项目。