1. 创建 YAML 配置文件 cluster-monitoring-config.yaml。例如：

   apiVersion: v1
   kind: ConfigMap
   data:
     config.yaml: |
       prometheusK8s:
         retention: {{PROMETHEUS_RETENTION_PERIOD}} 1
         nodeSelector:
           node-role.kubernetes.io/infra: ""
         volumeClaimTemplate:
           spec:
             storageClassName: {{STORAGE_CLASS}} 2
             resources:
               requests:
                 storage: {{PROMETHEUS_STORAGE_SIZE}} 3
       alertmanagerMain:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
         volumeClaimTemplate:
           spec:
             storageClassName: {{STORAGE_CLASS}} 4
             resources:
               requests:
                 storage: {{ALERTMANAGER_STORAGE_SIZE}} 5
   metadata:
     name: cluster-monitoring-config
     namespace: openshift-monitoring

   1

   Prometheus 保留的默认值为 PROMETHEUS_RETENTION_PERIOD=15d。时间单位使用以下后缀之一 : s 、m 、h 、d。

   2 4

   集群的存储类。

   3

   一个典型的值是 PROMETHEUS_STORAGE_SIZE=2000Gi。存储值可以是一个纯整数，也可以是带有以下后缀之一的整数: E 、P 、T 、G 、M 、K。您也可以使用以下效果相同的后缀：Ei 、Pi 、Ti 、Gi 、Mi 、Ki。

   5

   一个典型的值 是 alertmanager_STORAGE_SIZE=20Gi。存储值可以是一个纯整数，也可以是带有以下后缀之一的整数: E 、P 、T 、G 、M 、K。您也可以使用以下效果相同的后缀：Ei 、Pi 、Ti 、Gi 、Mi 、Ki。

2. 为保留周期、存储类和存储大小添加值。
3. 保存该文件。

4. 运行以下命令应用这些更改：

   $ oc create -f cluster-monitoring-config.yaml

步骤

1. 在一个 debug shell 中，使用 lsblk 命令，将新磁盘添加到集群中，并验证节点中是否检测到磁盘：

   $ oc debug node/<node_name>

   # lsblk

   记录下 lsblk 命令报告的新磁盘的设备名称。

2. 创建名为 etcd-mc.yml 的 MachineConfig YAML 文件，其内容如下，将 <new_disk_name> 实例替换为记录的设备名称：

   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: master
     name: 98-var-lib-etcd
   spec:
     config:
       ignition:
         version: 3.2.0
       systemd:
         units:
         - contents: |
             [Unit]
             Description=Make File System on /dev/<new_disk_name>
             DefaultDependencies=no
             BindsTo=dev-<new_disk_name>.device
             After=dev-<new_disk_name>.device var.mount
             Before=systemd-fsck@dev-<new_disk_name>.service
   
             [Service]
             Type=oneshot
             RemainAfterExit=yes
             ExecStart=/usr/lib/systemd/systemd-makefs xfs /dev/<new_disk_name>
             TimeoutSec=0
   
             [Install]
             WantedBy=var-lib-containers.mount
           enabled: true
           name: systemd-mkfs@dev-<new_disk_name>.service
         - contents: |
             [Unit]
             Description=Mount /dev/<new_disk_name> to /var/lib/etcd
             Before=local-fs.target
             Requires=systemd-mkfs@dev-<new_disk_name>.service
             After=systemd-mkfs@dev-<new_disk_name>.service var.mount
   
             [Mount]
             What=/dev/<new_disk_name>
             Where=/var/lib/etcd
             Type=xfs
             Options=defaults,prjquota
   
             [Install]
             WantedBy=local-fs.target
           enabled: true
           name: var-lib-etcd.mount
         - contents: |
             [Unit]
             Description=Sync etcd data if new mount is empty
             DefaultDependencies=no
             After=var-lib-etcd.mount var.mount
             Before=crio.service
   
             [Service]
             Type=oneshot
             RemainAfterExit=yes
             ExecCondition=/usr/bin/test ! -d /var/lib/etcd/member
             ExecStart=semanage fcontext -a -e /sysroot/ostree/deploy/rhcos/var/lib/etcd/ /var/lib/etcd/
             ExecStart=/bin/rsync -ar /sysroot/ostree/deploy/rhcos/var/lib/etcd/ /var/lib/etcd/
             TimeoutSec=0
   
             [Install]
             WantedBy=multi-user.target graphical.target
           enabled: true
           name: sync-var-lib-etcd-to-etcd.service
         - contents: |
             [Unit]
             Description=Restore recursive SELinux security contexts
             DefaultDependencies=no
             After=var-lib-etcd.mount
             Before=crio.service
   
             [Service]
             Type=oneshot
             RemainAfterExit=yes
             ExecStart=/sbin/restorecon -R /var/lib/etcd/
             TimeoutSec=0
   
             [Install]
             WantedBy=multi-user.target graphical.target
           enabled: true
           name: restorecon-var-lib-etcd.service

3. 以具有 cluster-admin 权限的用户身份登录集群并创建机器配置：

   $ oc login -u <username> -p <password>

   $ oc create -f etcd-mc.yml

   节点已更新并重启。重启完成后，会出现以下事件：

   • XFS 文件系统是在指定磁盘中创建的。
   • 磁盘挂载到 /var/lib/etcd。
   • 来自 /sysroot/ostree/deploy/rhcos/var/lib/etcd 的内容同步到 /var/lib/etcd。
   • 对于 /var/lib/etcd，强制恢复 SELinux 标签。
   • 旧内容不会被删除。

4. 节点位于独立磁盘后，使用如下内容更新 etcd-mc.yml 文件，将 <new_disk_name> 实例替换为记录的设备名称：

   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: master
     name: 98-var-lib-etcd
   spec:
     config:
       ignition:
         version: 3.2.0
       systemd:
         units:
         - contents: |
             [Unit]
             Description=Mount /dev/<new_disk_name> to /var/lib/etcd
             Before=local-fs.target
             Requires=systemd-mkfs@dev-<new_disk_name>.service
             After=systemd-mkfs@dev-<new_disk_name>.service var.mount
   
             [Mount]
             What=/dev/<new_disk_name>
             Where=/var/lib/etcd
             Type=xfs
             Options=defaults,prjquota
   
             [Install]
             WantedBy=local-fs.target
           enabled: true
           name: var-lib-etcd.mount

5. 应用修改的版本，删除创建和同步设备的逻辑，以防止节点重新引导：

   $ oc replace -f etcd-mc.yml

1. 带有基准性能为 3000 IOPS 和 125 MiB 每秒的 gp3 磁盘用于 control plane/etcd 节点，因为 etcd 对延迟敏感。gp3 卷不使用突发性能。
2. Infra 节点用于托管 Monitoring、Ingress 和 Registry 组件，以确保它们有足够资源可大规模运行。
3. 工作负载节点专用于运行性能和可扩展工作负载生成器。
4. 使用更大的磁盘，以便有足够的空间存储在运行性能和可扩展性测试期间收集的大量数据。
5. 在迭代中扩展了集群，且性能和可扩展性测试是在指定节点数中执行的。

1. 带有 120 / 10 IOPS 的 io1 磁盘用于 control plane/etcd 节点，因为 etcd 非常大，且敏感延迟。
2. Infra 节点用于托管 Monitoring、Ingress 和 Registry 组件，以确保它们有足够资源可大规模运行。
3. 工作负载节点专用于运行性能和可扩展工作负载生成器。
4. 使用更大的磁盘，以便有足够的空间存储在运行性能和可扩展性测试期间收集的大量数据。
5. 在迭代中扩展了集群。

1. 节点在两个逻辑控制单元 (LCU) 之间分发，以优化 control plane/etcd 节点的磁盘 I/O 负载，因为 etcd 非常大，且对延迟敏感。etcd I/O 需求不应干扰其他工作负载。
2. 四个计算节点用于运行同时具有 100/250/500 pod 的多个迭代的测试。首先，使用闲置 pod 来评估 pod 是否可以实例。接下来，使用网络和 CPU 要求客户端/服务器工作负载来评估系统在压力下的稳定性。客户端和服务器 pod 是部署范围，每个对分布在两个计算节点上。
3. 没有单独的工作负载节点。工作负载在两个计算节点之间模拟微服务工作负载。
4. 使用的物理处理器数量是 6 个用于 Linux (IFL)的集成设施。
5. 使用的总物理内存为 512 GiB。

流程

1. 将以下 MCO 示例配置集复制到 YAML 文件中。例如，enable-rfs.yaml：

   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: worker
     name: 50-enable-rfs
   spec:
     config:
       ignition:
         version: 2.2.0
       storage:
         files:
         - contents:
             source: data:text/plain;charset=US-ASCII,%23%20turn%20on%20Receive%20Flow%20Steering%20%28RFS%29%20for%20all%20network%20interfaces%0ASUBSYSTEM%3D%3D%22net%22%2C%20ACTION%3D%3D%22add%22%2C%20RUN%7Bprogram%7D%2B%3D%22/bin/bash%20-c%20%27for%20x%20in%20/sys/%24DEVPATH/queues/rx-%2A%3B%20do%20echo%208192%20%3E%20%24x/rps_flow_cnt%3B%20%20done%27%22%0A
           filesystem: root
           mode: 0644
           path: /etc/udev/rules.d/70-persistent-net.rules
         - contents:
             source: data:text/plain;charset=US-ASCII,%23%20define%20sock%20flow%20enbtried%20for%20%20Receive%20Flow%20Steering%20%28RFS%29%0Anet.core.rps_sock_flow_entries%3D8192%0A
           filesystem: root
           mode: 0644
           path: /etc/sysctl.d/95-enable-rps.conf

2. 创建 MCO 配置集：

   $ oc create -f enable-rfs.yaml

3. 验证是否列出了名为 50-enable-rfs 的条目：

   $ oc get mc

4. 要取消激活，请输入：

   $ oc delete mc 50-enable-rfs

流程

1. 将以下 MCO 示例配置集复制到 control plane 节点的 YAML 文件中。例如，05-master-kernelarg-hpav.yaml:

   $ cat 05-master-kernelarg-hpav.yaml
   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: master
     name: 05-master-kernelarg-hpav
   spec:
     config:
       ignition:
         version: 3.1.0
     kernelArguments:
       - rd.dasd=800-805

2. 将以下 MCO 示例配置集复制到计算节点的 YAML 文件中。例如，05-worker-kernelarg-hpav.yaml:

   $ cat 05-worker-kernelarg-hpav.yaml
   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: worker
     name: 05-worker-kernelarg-hpav
   spec:
     config:
       ignition:
         version: 3.1.0
     kernelArguments:
       - rd.dasd=800-805

   注意

   您必须修改 rd.dasd 参数以适合设备 ID。

3. 创建 MCO 配置集：

   $ oc create -f 05-master-kernelarg-hpav.yaml

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

4. 要取消激活，请输入：

   $ oc delete -f 05-master-kernelarg-hpav.yaml

   $ oc delete -f 05-worker-kernelarg-hpav.yaml

流程

1. 使用您选择的编辑器打开 /etc/libvirt/qemu.conf。
2. 转至 cgroup_controllers 行。
3. 复制整行并从副本中删除前导编号符号(#)。

4. 删除 cpuset 条目，如下所示：

   cgroup_controllers = [ "cpu", "devices", "memory", "blkio", "cpuacct" ]

5. 要使新设置生效，您必须重启 libvirtd 守护进程：

   1. 停止所有虚拟机。

   2. 运行以下命令:

      # systemctl restart libvirtd

   3. 重新启动虚拟机。

流程

1. 为 NUMA Resources Operator 创建命名空间：

   1. 将以下 YAML 保存到 nro-namespace.yaml 文件中：

      apiVersion: v1
      kind: Namespace
      metadata:
        name: openshift-numaresources

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

      $ oc create -f nro-namespace.yaml

2. 为 NUMA Resources Operator 创建 operator 组：

   1. 在 nro-operatorgroup.yaml 文件中保存以下 YAML：

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

   2. 运行以下命令来创建 OperatorGroup CR:

      $ oc create -f nro-operatorgroup.yaml

3. 为 NUMA Resources Operator 创建订阅：

   1. 将以下 YAML 保存到 nro-sub.yaml 文件中：

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

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

      $ oc create -f nro-sub.yaml

验证

1. 通过检查 openshift-numaresources 命名空间中的 CSV 资源来验证安装是否成功。运行以下命令:

   $ oc get csv -n openshift-numaresources

   输出示例

   NAME                             DISPLAY                  VERSION   REPLACES   PHASE
   numaresources-operator.v4.12.2   numaresources-operator   4.12.2               Succeeded

步骤

1. 为 NUMA Resources Operator 创建命名空间：

   1. 在 OpenShift Container Platform web 控制台中，点 Administration → Namespaces。
   2. 点 Create Namespace，在 Name 字段中输入 openshift-numaresources，然后点 Create。

2. 安装 NUMA Resources Operator：

   1. 在 OpenShift Container Platform Web 控制台中，点击 Operators → OperatorHub。
   2. 从可用的 Operator 列表中选择 NUMA Resources Operator，然后点 Install。
   3. 在 Installed Namespaces 字段中，选择 openshift-numaresources 命名空间，然后点 Install。

3. 可选：验证 NUMA Resources Operator 是否已成功安装：

   1. 切换到 Operators → Installed Operators 页面。

   2. 确保 openshift-numaresources 命名空间中列出 NUMA Resources Operator，Status 为 InstallSucceeded。

      注意

      在安装过程中，Operator 可能会显示 Failed 状态。如果安装过程结束后有 InstallSucceeded 信息，您可以忽略这个 Failed 信息。

      如果 Operator 没有被成功安装，请按照以下步骤进行故障排除：

      • 进入 Operators → Installed Operators 页面，检查 Operator Subscriptions 和 Install Plans 选项卡中的 Status 项中是否有任何错误。
      • 进入 Workloads → Pods 页面，检查 default 项目中的 pod 的日志。

步骤

1. 创建 MachineConfigPool 自定义资源，为 worker 节点启用自定义 kubelet 配置：

   1. 将以下 YAML 保存到 nro-machineconfig.yaml 文件中：

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfigPool
      metadata:
        labels:
          cnf-worker-tuning: enabled
          machineconfiguration.openshift.io/mco-built-in: ""
          pools.operator.machineconfiguration.openshift.io/worker: ""
        name: worker
      spec:
        machineConfigSelector:
          matchLabels:
            machineconfiguration.openshift.io/role: worker
        nodeSelector:
          matchLabels:
            node-role.kubernetes.io/worker: ""

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

      $ oc create -f nro-machineconfig.yaml

2. 创建 NUMAResourcesOperator 自定义资源：

   1. 将以下 YAML 保存到 nrop.yaml 文件中：

      apiVersion: nodetopology.openshift.io/v1alpha1
      kind: NUMAResourcesOperator
      metadata:
        name: numaresourcesoperator
      spec:
        nodeGroups:
        - machineConfigPoolSelector:
            matchLabels:
              pools.operator.machineconfiguration.openshift.io/worker: "" 1

      1

      应该与相关 MachineConfigPool CR 中的 worker 节点匹配。

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

      $ oc create -f nrop.yaml

流程

1. 创建 KubeletConfig 自定义资源，为机器配置集配置 pod admittance 策略：

   1. 将以下 YAML 保存到 nro-kubeletconfig.yaml 文件中：

      apiVersion: machineconfiguration.openshift.io/v1
      kind: KubeletConfig
      metadata:
        name: cnf-worker-tuning
      spec:
        machineConfigPoolSelector:
          matchLabels:
            cnf-worker-tuning: enabled
        kubeletConfig:
          cpuManagerPolicy: "static" 1
          cpuManagerReconcilePeriod: "5s"
          reservedSystemCPUs: "0,1"
          memoryManagerPolicy: "Static" 2
          evictionHard:
            memory.available: "100Mi"
          kubeReserved:
            memory: "512Mi"
          reservedMemory:
            - numaNode: 0
              limits:
                memory: "1124Mi"
          systemReserved:
            memory: "512Mi"
          topologyManagerPolicy: "single-numa-node" 3
          topologyManagerScope: "pod"

      1

      对于 cpuManagerPolicy，static 必须使用小写 s。

      2

      对于 memoryManagerPolicy，Static 必须使用大写 S。

      3

      topologyManagerPolicy 必须设置为 single-numa-node。

   2. 运行以下命令来创建 KubeletConfig 自定义资源 (CR)：

      $ oc create -f nro-kubeletconfig.yaml

2. 创建 NUMAResourcesScheduler 自定义资源来部署 NUMA 感知自定义 pod 调度程序：

   1. 将以下 YAML 保存到 nro-scheduler.yaml 文件中：

      apiVersion: nodetopology.openshift.io/v1alpha1
      kind: NUMAResourcesScheduler
      metadata:
        name: numaresourcesscheduler
      spec:
        imageSpec: "registry.redhat.io/openshift4/noderesourcetopology-scheduler-container-rhel8:v4.12"

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

      $ oc create -f nro-scheduler.yaml

流程

1. 运行以下命令，获取集群中部署的 NUMA 感知调度程序名称：

   $ oc get numaresourcesschedulers.nodetopology.openshift.io numaresourcesscheduler -o json | jq '.status.schedulerName'

   输出示例

   topo-aware-scheduler

2. 创建一个 Deployment CR，它使用名为 topo-aware-scheduler 的调度程序，例如：

   1. 将以下 YAML 保存到 nro-deployment.yaml 文件中：

      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: numa-deployment-1
        namespace: openshift-numaresources
      spec:
        replicas: 1
        selector:
          matchLabels:
            app: test
        template:
          metadata:
            labels:
              app: test
          spec:
            schedulerName: topo-aware-scheduler 1
            containers:
            - name: ctnr
              image: quay.io/openshifttest/hello-openshift:openshift
              imagePullPolicy: IfNotPresent
              resources:
                limits:
                  memory: "100Mi"
                  cpu: "10"
                requests:
                  memory: "100Mi"
                  cpu: "10"
            - name: ctnr2
              image: registry.access.redhat.com/rhel:latest
              imagePullPolicy: IfNotPresent
              command: ["/bin/sh", "-c"]
              args: [ "while true; do sleep 1h; done;" ]
              resources:
                limits:
                  memory: "100Mi"
                  cpu: "8"
                requests:
                  memory: "100Mi"
                  cpu: "8"

      1

      schedulerName 必须与集群中部署的 NUMA 感知调度程序的名称匹配，如 topo-aware-scheduler。

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

      $ oc create -f nro-deployment.yaml

验证

1. 验证部署是否成功：

   $ oc get pods -n openshift-numaresources

   输出示例

   NAME                                                READY   STATUS    RESTARTS   AGE
   numa-deployment-1-56954b7b46-pfgw8                  2/2     Running   0          129m
   numaresources-controller-manager-7575848485-bns4s   1/1     Running   0          15h
   numaresourcesoperator-worker-dvj4n                  2/2     Running   0          18h
   numaresourcesoperator-worker-lcg4t                  2/2     Running   0          16h
   secondary-scheduler-56994cf6cf-7qf4q                1/1     Running   0          18h

2. 运行以下命令，验证 topo-aware-scheduler 是否在调度部署的 pod：

   $ oc describe pod numa-deployment-1-56954b7b46-pfgw8 -n openshift-numaresources

   输出示例

   Events:
     Type    Reason          Age   From                  Message
     ----    ------          ----  ----                  -------
     Normal  Scheduled       130m  topo-aware-scheduler  Successfully assigned openshift-numaresources/numa-deployment-1-56954b7b46-pfgw8 to compute-0.example.com

   注意

   请求的资源超过可用于调度的部署将失败，并显示 MinimumReplicasUnavailable 错误。当所需资源可用时，部署会成功。Pod 会一直处于 Pending 状态，直到所需资源可用。

3. 验证是否为节点列出了预期的分配资源。运行以下命令:

   $ oc describe noderesourcetopologies.topology.node.k8s.io

   输出示例

   ...
   
   Zones:
     Costs:
       Name:   node-0
       Value:  10
       Name:   node-1
       Value:  21
     Name:     node-0
     Resources:
       Allocatable:  39
       Available:    21 1
       Capacity:     40
       Name:         cpu
       Allocatable:  6442450944
       Available:    6442450944
       Capacity:     6442450944
       Name:         hugepages-1Gi
       Allocatable:  134217728
       Available:    134217728
       Capacity:     134217728
       Name:         hugepages-2Mi
       Allocatable:  262415904768
       Available:    262206189568
       Capacity:     270146007040
       Name:         memory
     Type:           Node

   1

   由于已分配给有保证 pod 的资源，可用的容量会减少。

   通过保证 pod 使用的资源从 noderesourcetopologies.topology.node.k8s.io 中列出的可用节点资源中减去。

4. 对具有 Best-effort 或 Burstable 服务质量 (qosClass) 的pod 的资源分配不会反映在 noderesourcetopologies.topology.node.k8s.io 下的 NUMA 节点资源中。如果 pod 消耗的资源没有反映在节点资源计算中，请运行以下命令验证 pod 的 Guaranteed 具有 qosClass：

   $ oc get pod <pod_name> -n <pod_namespace> -o jsonpath="{ .status.qosClass }"

   输出示例

   Guaranteed

流程

1. 可选：创建 MachineConfigPool 自定义资源，为 worker 节点启用自定义 kubelet 配置：

   注意

   默认情况下，OpenShift Container Platform 为集群中的 worker 节点创建一个 MachineConfigPool 资源。如果需要，您可以创建自定义 MachineConfigPool 资源。

   1. 将以下 YAML 保存到 nro-machineconfig.yaml 文件中：

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfigPool
      metadata:
        labels:
          cnf-worker-tuning: enabled
          machineconfiguration.openshift.io/mco-built-in: ""
          pools.operator.machineconfiguration.openshift.io/worker: ""
        name: worker
      spec:
        machineConfigSelector:
          matchLabels:
            machineconfiguration.openshift.io/role: worker
        nodeSelector:
          matchLabels:
            node-role.kubernetes.io/worker: ""

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

      $ oc create -f nro-machineconfig.yaml

2. 创建 NUMAResourcesOperator 自定义资源：

   1. 将以下 YAML 保存到 nrop.yaml 文件中：

      apiVersion: nodetopology.openshift.io/v1
      kind: NUMAResourcesOperator
      metadata:
        name: numaresourcesoperator
      spec:
        nodeGroups:
        - machineConfigPoolSelector:
            matchLabels:
              pools.operator.machineconfiguration.openshift.io/worker: "" 1

      1

      应该与相关 MachineConfigPool CR 中的 worker 节点匹配。

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

      $ oc create -f nrop.yaml

流程

1. 创建 KubeletConfig 自定义资源，为机器配置集配置 pod admittance 策略：

   1. 将以下 YAML 保存到 nro-kubeletconfig.yaml 文件中：

      apiVersion: machineconfiguration.openshift.io/v1
      kind: KubeletConfig
      metadata:
        name: cnf-worker-tuning
      spec:
        machineConfigPoolSelector:
          matchLabels:
            cnf-worker-tuning: enabled
        kubeletConfig:
          cpuManagerPolicy: "static" 1
          cpuManagerReconcilePeriod: "5s"
          reservedSystemCPUs: "0,1"
          memoryManagerPolicy: "Static" 2
          evictionHard:
            memory.available: "100Mi"
          reservedMemory:
            - numaNode: 0
              limits:
                memory: "1124Mi"
          systemReserved:
            memory: "512Mi"
          topologyManagerPolicy: "single-numa-node" 3
          topologyManagerScope: "pod"

      1

      对于 cpuManagerPolicy，static 必须使用小写 s。

      2

      对于 memoryManagerPolicy，Static 必须使用大写 S。

      3

      topologyManagerPolicy 必须设置为 single-numa-node。

   2. 运行以下命令来创建 KubeletConfig 自定义资源 (CR)：

      $ oc create -f nro-kubeletconfig.yaml

2. 创建 NUMAResourcesScheduler 自定义资源来部署 NUMA 感知自定义 pod 调度程序：

   1. 将以下 YAML 保存到 nro-scheduler.yaml 文件中：

      apiVersion: nodetopology.openshift.io/v1
      kind: NUMAResourcesScheduler
      metadata:
        name: numaresourcesscheduler
      spec:
        imageSpec: "registry.redhat.io/openshift4/noderesourcetopology-scheduler-container-rhel8:v4.12"
        cacheResyncPeriod: "5s" 1

      1

      为调度程序缓存同步输入间隔值（以秒为单位）。值 5s 通常用于大多数实现。

      注意

      • 启用 cacheResyncPeriod 规格，以帮助 NUMA Resource Operator 通过监控节点上的待处理资源，并在调度程序缓存中同步此信息，以帮助 NUMA Resource Operator 报告更准确的资源可用性。这也有助于减少 Topology Affinity Error 错误，因为未优化调度决策。网络负载越低的时间间隔。cacheResyncPeriod 规格默认禁用。
      • 为 NUMAResourcesOperator CR 中的 podsFingerprinting 规格设置 Enabled 值是 cacheResyncPeriod 规格的实施要求。

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

      $ oc create -f nro-scheduler.yaml

流程

1. 运行以下命令，获取集群中部署的 NUMA 感知调度程序名称：

   $ oc get numaresourcesschedulers.nodetopology.openshift.io numaresourcesscheduler -o json | jq '.status.schedulerName'

   输出示例

   topo-aware-scheduler

2. 创建一个 Deployment CR，它使用名为 topo-aware-scheduler 的调度程序，例如：

   1. 将以下 YAML 保存到 nro-deployment.yaml 文件中：

      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: numa-deployment-1
        namespace: openshift-numaresources
      spec:
        replicas: 1
        selector:
          matchLabels:
            app: test
        template:
          metadata:
            labels:
              app: test
          spec:
            schedulerName: topo-aware-scheduler 1
            containers:
            - name: ctnr
              image: quay.io/openshifttest/hello-openshift:openshift
              imagePullPolicy: IfNotPresent
              resources:
                limits:
                  memory: "100Mi"
                  cpu: "10"
                requests:
                  memory: "100Mi"
                  cpu: "10"
            - name: ctnr2
              image: registry.access.redhat.com/rhel:latest
              imagePullPolicy: IfNotPresent
              command: ["/bin/sh", "-c"]
              args: [ "while true; do sleep 1h; done;" ]
              resources:
                limits:
                  memory: "100Mi"
                  cpu: "8"
                requests:
                  memory: "100Mi"
                  cpu: "8"

      1

      schedulerName 必须与集群中部署的 NUMA 感知调度程序的名称匹配，如 topo-aware-scheduler。

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

      $ oc create -f nro-deployment.yaml

验证

1. 验证部署是否成功：

   $ oc get pods -n openshift-numaresources

   输出示例

   NAME                                                READY   STATUS    RESTARTS   AGE
   numa-deployment-1-56954b7b46-pfgw8                  2/2     Running   0          129m
   numaresources-controller-manager-7575848485-bns4s   1/1     Running   0          15h
   numaresourcesoperator-worker-dvj4n                  2/2     Running   0          18h
   numaresourcesoperator-worker-lcg4t                  2/2     Running   0          16h
   secondary-scheduler-56994cf6cf-7qf4q                1/1     Running   0          18h

2. 运行以下命令，验证 topo-aware-scheduler 是否在调度部署的 pod：

   $ oc describe pod numa-deployment-1-56954b7b46-pfgw8 -n openshift-numaresources

   输出示例

   Events:
     Type    Reason          Age   From                  Message
     ----    ------          ----  ----                  -------
     Normal  Scheduled       130m  topo-aware-scheduler  Successfully assigned openshift-numaresources/numa-deployment-1-56954b7b46-pfgw8 to compute-0.example.com

   注意

   请求的资源超过可用于调度的部署将失败，并显示 MinimumReplicasUnavailable 错误。当所需资源可用时，部署会成功。Pod 会一直处于 Pending 状态，直到所需资源可用。

3. 验证是否为节点列出了预期的分配资源。

   1. 运行以下命令识别运行部署 pod 的节点，将 <namespace> 替换为您在 Deployment CR 中指定的命名空间：

      $ oc get pods -n <namespace> -o wide

      输出示例

      NAME                                 READY   STATUS    RESTARTS   AGE   IP            NODE     NOMINATED NODE   READINESS GATES
      numa-deployment-1-65684f8fcc-bw4bw   0/2     Running   0          82m   10.128.2.50   worker-0   <none>  <none>

   2. 运行以下命令，将 <node_name> 替换为运行部署 pod 的该节点的名称：

      $ oc describe noderesourcetopologies.topology.node.k8s.io <node_name>

      输出示例

      ...
      
      Zones:
        Costs:
          Name:   node-0
          Value:  10
          Name:   node-1
          Value:  21
        Name:     node-0
        Resources:
          Allocatable:  39
          Available:    21 1
          Capacity:     40
          Name:         cpu
          Allocatable:  6442450944
          Available:    6442450944
          Capacity:     6442450944
          Name:         hugepages-1Gi
          Allocatable:  134217728
          Available:    134217728
          Capacity:     134217728
          Name:         hugepages-2Mi
          Allocatable:  262415904768
          Available:    262206189568
          Capacity:     270146007040
          Name:         memory
        Type:           Node

      1

      由于已分配给有保证 pod 的资源，可用的容量会减少。

      通过保证 pod 使用的资源从 noderesourcetopologies.topology.node.k8s.io 中列出的可用节点资源中减去。

4. 对具有 Best-effort 或 Burstable 服务质量 (qosClass) 的pod 的资源分配不会反映在 noderesourcetopologies.topology.node.k8s.io 下的 NUMA 节点资源中。如果 pod 消耗的资源没有反映在节点资源计算中，请验证 pod 的 Guaranteed 具有 qosClass，且 CPU 请求是一个整数值，而不是十进制值。您可以运行以下命令来验证 pod 是否具有 Guaranteed 的 qosClass ：

   $ oc get pod <pod_name> -n <pod_namespace> -o jsonpath="{ .status.qosClass }"

   输出示例

   Guaranteed

流程

1. 删除当前运行的 NUMAResourcesScheduler 资源：

   1. 运行以下命令来获取活跃的 NUMAResourcesScheduler ：

      $ oc get NUMAResourcesScheduler

      输出示例

      NAME                     AGE
      numaresourcesscheduler   90m

   2. 运行以下命令来删除二级调度程序资源：

      $ oc delete NUMAResourcesScheduler numaresourcesscheduler

      输出示例

      numaresourcesscheduler.nodetopology.openshift.io "numaresourcesscheduler" deleted

2. 将以下 YAML 保存到文件 nro-scheduler-debug.yaml 中。本例将日志级别更改为 Debug ：

   apiVersion: nodetopology.openshift.io/v1alpha1
   kind: NUMAResourcesScheduler
   metadata:
     name: numaresourcesscheduler
   spec:
     imageSpec: "registry.redhat.io/openshift4/noderesourcetopology-scheduler-container-rhel8:v4.12"
     logLevel: Debug

3. 运行以下命令，创建更新的 Debug logging NUMAResourcesScheduler 资源：

   $ oc create -f nro-scheduler-debug.yaml

   输出示例

   numaresourcesscheduler.nodetopology.openshift.io/numaresourcesscheduler created

验证步骤

1. 检查 NUMA-aware 调度程序是否已成功部署：

   1. 运行以下命令检查 CRD 是否已创建成功：

      $ oc get crd | grep numaresourcesschedulers

      输出示例

      NAME                                                              CREATED AT
      numaresourcesschedulers.nodetopology.openshift.io                 2022-02-25T11:57:03Z

   2. 运行以下命令，检查新的自定义调度程序是否可用：

      $ oc get numaresourcesschedulers.nodetopology.openshift.io

      输出示例

      NAME                     AGE
      numaresourcesscheduler   3h26m

2. 检查调度程序的日志是否显示增加的日志级别：

   1. 运行以下命令，获取在 openshift-numaresources 命名空间中运行的 pod 列表：

      $ oc get pods -n openshift-numaresources

      输出示例

      NAME                                               READY   STATUS    RESTARTS   AGE
      numaresources-controller-manager-d87d79587-76mrm   1/1     Running   0          46h
      numaresourcesoperator-worker-5wm2k                 2/2     Running   0          45h
      numaresourcesoperator-worker-pb75c                 2/2     Running   0          45h
      secondary-scheduler-7976c4d466-qm4sc               1/1     Running   0          21m

   2. 运行以下命令，获取二级调度程序 pod 的日志：

      $ oc logs secondary-scheduler-7976c4d466-qm4sc -n openshift-numaresources

      输出示例

      ...
      I0223 11:04:55.614788       1 reflector.go:535] k8s.io/client-go/informers/factory.go:134: Watch close - *v1.Namespace total 11 items received
      I0223 11:04:56.609114       1 reflector.go:535] k8s.io/client-go/informers/factory.go:134: Watch close - *v1.ReplicationController total 10 items received
      I0223 11:05:22.626818       1 reflector.go:535] k8s.io/client-go/informers/factory.go:134: Watch close - *v1.StorageClass total 7 items received
      I0223 11:05:31.610356       1 reflector.go:535] k8s.io/client-go/informers/factory.go:134: Watch close - *v1.PodDisruptionBudget total 7 items received
      I0223 11:05:31.713032       1 eventhandlers.go:186] "Add event for scheduled pod" pod="openshift-marketplace/certified-operators-thtvq"
      I0223 11:05:53.461016       1 eventhandlers.go:244] "Delete event for scheduled pod" pod="openshift-marketplace/certified-operators-thtvq"

流程

1. 获取由 NUMA Resources Operator 管理的守护进程集（daemonset）。每个守护进程在 NUMAResourcesOperator CR 中有一个对应的 nodeGroup。运行以下命令:

   $ oc get numaresourcesoperators.nodetopology.openshift.io numaresourcesoperator -o jsonpath="{.status.daemonsets[0]}"

   输出示例

   {"name":"numaresourcesoperator-worker","namespace":"openshift-numaresources"}

2. 使用上一步中的 name 值获取所需的守护进程集的标签：

   $ oc get ds -n openshift-numaresources numaresourcesoperator-worker -o jsonpath="{.spec.selector.matchLabels}"

   输出示例

   {"name":"resource-topology"}

3. 运行以下命令，使用 resource-topology 标签获取 pod：

   $ oc get pods -n openshift-numaresources -l name=resource-topology -o wide

   输出示例

   NAME                                 READY   STATUS    RESTARTS   AGE    IP            NODE
   numaresourcesoperator-worker-5wm2k   2/2     Running   0          2d1h   10.135.0.64   compute-0.example.com
   numaresourcesoperator-worker-pb75c   2/2     Running   0          2d1h   10.132.2.33   compute-1.example.com

4. 检查与您要故障排除的节点对应的 worker pod 上运行的 resource-topology-exporter 容器的日志。运行以下命令:

   $ oc logs -n openshift-numaresources -c resource-topology-exporter numaresourcesoperator-worker-pb75c

   输出示例

   I0221 13:38:18.334140       1 main.go:206] using sysinfo:
   reservedCpus: 0,1
   reservedMemory:
     "0": 1178599424
   I0221 13:38:18.334370       1 main.go:67] === System information ===
   I0221 13:38:18.334381       1 sysinfo.go:231] cpus: reserved "0-1"
   I0221 13:38:18.334493       1 sysinfo.go:237] cpus: online "0-103"
   I0221 13:38:18.546750       1 main.go:72]
   cpus: allocatable "2-103"
   hugepages-1Gi:
     numa cell 0 -> 6
     numa cell 1 -> 1
   hugepages-2Mi:
     numa cell 0 -> 64
     numa cell 1 -> 128
   memory:
     numa cell 0 -> 45758Mi
     numa cell 1 -> 48372Mi

流程

1. 使用以下命令，比较 kubeletconfig 中的 spec.machineConfigPoolSelector.matchLabels 值和 MachineConfigPool (mcp) worker CR 中的 metadata.labels 的值：

   1. 运行以下命令来检查 kubeletconfig 标签：

      $ oc get kubeletconfig -o yaml

      输出示例

      machineConfigPoolSelector:
        matchLabels:
          cnf-worker-tuning: enabled

   2. 运行以下命令来检查 mcp 标签：

      $ oc get mcp worker -o yaml

      输出示例

      labels:
        machineconfiguration.openshift.io/mco-built-in: ""
        pools.operator.machineconfiguration.openshift.io/worker: ""

      cnf-worker-tuning: enabled 标签没有存在于 MachineConfigPool 对象中。

2. 编辑 MachineConfigPool CR 使其包含缺少的标签，例如：

   $ oc edit mcp worker -o yaml

   输出示例

   labels:
     machineconfiguration.openshift.io/mco-built-in: ""
     pools.operator.machineconfiguration.openshift.io/worker: ""
     cnf-worker-tuning: enabled

3. 应用标签更改并等待集群应用更新的配置。运行以下命令:

1. NetApp NFS 在使用 Trident 插件时支持动态 PV 置备。

流程

1. 使用以下 YAML 创建名为 mount_namespace_config.yaml 的文件：

   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: master
     name: 99-kubens-master
   spec:
     config:
       ignition:
         version: 3.2.0
       systemd:
         units:
         - enabled: true
           name: kubens.service
   ---
   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: worker
     name: 99-kubens-worker
   spec:
     config:
       ignition:
         version: 3.2.0
       systemd:
         units:
         - enabled: true
           name: kubens.service

2. 运行以下命令来应用挂载命名空间 MachineConfig CR：

   $ oc apply -f mount_namespace_config.yaml

   输出示例

   machineconfig.machineconfiguration.openshift.io/99-kubens-master created
   machineconfig.machineconfiguration.openshift.io/99-kubens-worker created

3. MachineConfig CR 最多可能需要 30 分钟才能完成在集群中应用。您可以运行以下命令来检查 MachineConfig CR 的状态：

   $ oc get mcp

   输出示例

   NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
   master   rendered-master-03d4bc4befb0f4ed3566a2c8f7636751   False     True       False      3              0                   0                     0                      45m
   worker   rendered-worker-10577f6ab0117ed1825f8af2ac687ddf   False     True       False      3              1                   1

4. 运行以下命令，等待所有 control plane 和 worker 节点成功应用 MachineConfig CR：

   $ oc wait --for=condition=Updated mcp --all --timeout=30m

   输出示例

   machineconfigpool.machineconfiguration.openshift.io/master condition met
   machineconfigpool.machineconfiguration.openshift.io/worker condition met

1. 打开集群主机的默认 shell:

   $ oc debug node/<node_name>

2. 打开 chroot 会话：

   sh-4.4# chroot /host

3. 检查 systemd 挂载命名空间：

   sh-4.4# readlink /proc/1/ns/mnt

   输出示例

   mnt:[4026531953]

4. 检查 kubelet 挂载命名空间：

   sh-4.4# readlink /proc/$(pgrep kubelet)/ns/mnt

   输出示例

   mnt:[4026531840]

5. 检查 CRI-O 挂载命名空间：

   sh-4.4# readlink /proc/$(pgrep crio)/ns/mnt

   输出示例

   mnt:[4026531840]

流程

1. 打开到集群主机的远程 SSH shell。例如：

   $ ssh core@<node_name>

2. 以 root 用户身份使用提供的 kubensenter 脚本运行命令。要在 Kubernetes 命名空间中运行单个命令，请为 kubensenter 脚本提供命令和任何参数。例如，要在 Kubernetes 命名空间中运行 findmnt 命令，请运行以下命令：

   [core@control-plane-1 ~]$ sudo kubensenter findmnt

   输出示例

   kubensenter: Autodetect: kubens.service namespace found at /run/kubens/mnt
   TARGET                                SOURCE                 FSTYPE     OPTIONS
   /                                     /dev/sda4[/ostree/deploy/rhcos/deploy/32074f0e8e5ec453e56f5a8a7bc9347eaa4172349ceab9c22b709d9d71a3f4b0.0]
   |                                                            xfs        rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota
                                         shm                    tmpfs
   ...

3. 要在 Kubernetes 命名空间中启动新的交互式 shell，请运行没有任何参数的 kubensenter 脚本：

   [core@control-plane-1 ~]$ sudo kubensenter

   输出示例

   kubensenter: Autodetect: kubens.service namespace found at /run/kubens/mnt

流程

1. 在 web 控制台中，导航到 Compute → Bare Metal Hosts。
2. 选择 Add Host → New with Dialog。
3. 为新的裸机主机指定唯一名称。
4. 设置 引导 MAC 地址。
5. 设置 基板管理控制台（BMC）地址.
6. 输入主机的基板管理控制器（BMC）的用户凭据。
7. 选择在创建后打开主机电源，然后选择 Create。
8. 向上扩展副本数，以匹配可用的裸机主机数量。导航到 Compute → MachineSets，然后从 Actions 下拉菜单中选择 Edit Machine count 来增加集群中的机器副本数量。

流程

1. 在 web 控制台中，导航到 Compute → Bare Metal Hosts。
2. 选择 Add Host → New from YAML。

3. 复制并粘贴以下 YAML，使用您的主机详情修改相关字段：

   apiVersion: metal3.io/v1alpha1
   kind: BareMetalHost
   metadata:
     name: <bare_metal_host_name>
   spec:
     online: true
     bmc:
       address: <bmc_address>
       credentialsName: <secret_credentials_name>  1
       disableCertificateVerification: True 2
     bootMACAddress: <host_boot_mac_address>

   1

   credentialsName 必须引用有效的 Secret CR。如果在 credentialsName 中没有引用有效的 Secret，则 baremetal-operator 无法管理裸机主机。如需有关 secret 以及如何创建 secret 的更多信息，请参阅了解 secret。

   2

   将 disableCertificateVerification 设置为 true 可禁用集群和基板管理控制器 (BMC) 之间的 TLS 主机验证。

4. 选择 Create 以保存 YAML 并创建新的裸机主机。

5. 向上扩展副本数，以匹配可用的裸机主机数量。导航到 Compute → MachineSets，然后从 Actions 下拉菜单中选择 Edit Machine count 来增加集群中的机器数量。

   注意

   您还可以使用 oc scale 命令和适当的裸机计算机器集来管理裸机节点的数量。

流程

1. 通过添加 metal3.io/autoscale-to-hosts 注解来注解您要配置的用于自动扩展的计算机器集。将 <machineset> 替换为计算机器设置的名称。

   $ oc annotate machineset <machineset> -n openshift-machine-api 'metal3.io/autoscale-to-hosts=<any_value>'

   等待新的缩放计算机启动。

流程

1. 通过添加 baremetalhost.metal3.io/detached 注解来注解您要从 provisioner 节点中删除的计算机器集。

   $ oc annotate machineset <machineset> -n openshift-machine-api 'baremetalhost.metal3.io/detached'

   等待新机器启动。

   注意

   当您使用 BareMetalHost 对象在集群中创建机器时，BareMetalHost 上更改了标签或选择器，BareMetalHost 对象仍然会根据创建 Machine 对象的 MachineSet 进行计数。

2. 在置备用例中，使用以下命令在重启完成后删除注解：

   $ oc annotate machineset <machineset> -n openshift-machine-api 'baremetalhost.metal3.io/detached-'

步骤

1. 为 Bare Metal Event Relay 创建命名空间。

   1. 将以下 YAML 保存到 bare-metal-events-namespace.yaml 文件中：

      apiVersion: v1
      kind: Namespace
      metadata:
        name: openshift-bare-metal-events
        labels:
          name: openshift-bare-metal-events
          openshift.io/cluster-monitoring: "true"

   2. 创建 Namespace CR：

      $ oc create -f bare-metal-events-namespace.yaml

2. 为 Bare Metal Event Relay Operator 创建 Operator 组。

   1. 将以下 YAML 保存到 bare-metal-events-operatorgroup.yaml 文件中：

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: bare-metal-event-relay-group
        namespace: openshift-bare-metal-events
      spec:
        targetNamespaces:
        - openshift-bare-metal-events

   2. 创建 OperatorGroup CR：

      $ oc create -f bare-metal-events-operatorgroup.yaml

3. 订阅裸机恢复事件中继。

   1. 将以下 YAML 保存到 bare-metal-events-sub.yaml 文件中：

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: bare-metal-event-relay-subscription
        namespace: openshift-bare-metal-events
      spec:
        channel: "stable"
        name: bare-metal-event-relay
        source: redhat-operators
        sourceNamespace: openshift-marketplace

   2. 创建 Subscription CR：

      $ oc create -f bare-metal-events-sub.yaml

步骤

1. 使用 OpenShift Container Platform Web 控制台安装 Bare Metal Event Relay：

   1. 在 OpenShift Container Platform Web 控制台中，点击 Operators → OperatorHub。
   2. 从可用的 Operator 列表中选择 Bare Metal Event Relay，然后点 Install。
   3. 在 Install Operator 页面中，选择或创建一个命名空间，选择 openshift-bare-metal-events，然后点 Install。

1. 切换到 Operators → Installed Operators 页面。

2. 确保项目中列出了 Bare Metal Event Relay，Status 为 InstallSucceeded。

   注意

   在安装过程中，Operator 可能会显示 Failed 状态。如果安装过程结束后有 InstallSucceeded 信息，您可以忽略这个 Failed 信息。

步骤

1. 通过运行以下 curl 命令确认节点硬件启用了 Redfish EventService ：

   $ curl https://<bmc_ip_address>/redfish/v1/EventService --insecure -H 'Content-Type: application/json' -u "<bmc_username>:<password>"

   其中：

   bmc_ip_address

   是生成 Redfish 事件的 BMC 的 IP 地址。

   输出示例

   {
      "@odata.context": "/redfish/v1/$metadata#EventService.EventService",
      "@odata.id": "/redfish/v1/EventService",
      "@odata.type": "#EventService.v1_0_2.EventService",
      "Actions": {
         "#EventService.SubmitTestEvent": {
            "EventType@Redfish.AllowableValues": ["StatusChange", "ResourceUpdated", "ResourceAdded", "ResourceRemoved", "Alert"],
            "target": "/redfish/v1/EventService/Actions/EventService.SubmitTestEvent"
         }
      },
      "DeliveryRetryAttempts": 3,
      "DeliveryRetryIntervalSeconds": 30,
      "Description": "Event Service represents the properties for the service",
      "EventTypesForSubscription": ["StatusChange", "ResourceUpdated", "ResourceAdded", "ResourceRemoved", "Alert"],
      "EventTypesForSubscription@odata.count": 5,
      "Id": "EventService",
      "Name": "Event Service",
      "ServiceEnabled": true,
      "Status": {
         "Health": "OK",
         "HealthRollup": "OK",
         "State": "Enabled"
      },
      "Subscriptions": {
         "@odata.id": "/redfish/v1/EventService/Subscriptions"
      }
   }

2. 运行以下命令，获取集群的 Bare Metal 事件中继服务路由：

   $ oc get route -n openshift-bare-metal-events

   输出示例

   NAME            HOST/PORT   PATH                                                                    SERVICES                 PORT   TERMINATION   WILDCARD
   hw-event-proxy              hw-event-proxy-openshift-bare-metal-events.apps.compute-1.example.com   hw-event-proxy-service   9087   edge          None

3. 创建一个 BMCEventSubscription 资源来订阅 Redfish 事件：

   1. 将以下 YAML 保存到 bmc_sub.yaml 文件中：

      apiVersion: metal3.io/v1alpha1
      kind: BMCEventSubscription
      metadata:
        name: sub-01
        namespace: openshift-machine-api
      spec:
         hostName: <hostname> 1
         destination: <proxy_service_url> 2
         context: ''

      1

      指定生成 Redfish 事件的 worker 节点的名称或 UUID。

      2

      指定裸机事件代理服务，例如 https://hw-event-proxy-openshift-bare-metal-events.apps.compute-1.example.com/webhook。

   2. 创建 BMCEventSubscription CR：

      $ oc create -f bmc_sub.yaml

4. 可选： 要删除 BMC 事件订阅，请运行以下命令：

   $ oc delete -f bmc_sub.yaml

5. 可选： 要在不创建 BMCEventSubscription CR 的情况下手动创建 Redfish 事件订阅，请运行以下 curl 命令并指定 BMC 用户名和密码。

   $ curl -i -k -X POST -H "Content-Type: application/json"  -d '{"Destination": "https://<proxy_service_url>", "Protocol" : "Redfish", "EventTypes": ["Alert"], "Context": "root"}' -u <bmc_username>:<password> 'https://<bmc_ip_address>/redfish/v1/EventService/Subscriptions' –v

   其中：

   proxy_service_url

   裸机事件代理服务，例如 https://hw-event-proxy-openshift-bare-metal-events.apps.compute-1.example.com/webhook。

   bmc_ip_address

   是生成 Redfish 事件的 BMC 的 IP 地址。

   输出示例

   HTTP/1.1 201 Created
   Server: AMI MegaRAC Redfish Service
   Location: /redfish/v1/EventService/Subscriptions/1
   Allow: GET, POST
   Access-Control-Allow-Origin: *
   Access-Control-Expose-Headers: X-Auth-Token
   Access-Control-Allow-Headers: X-Auth-Token
   Access-Control-Allow-Credentials: true
   Cache-Control: no-cache, must-revalidate
   Link: <http://redfish.dmtf.org/schemas/v1/EventDestination.v1_6_0.json>; rel=describedby
   Link: <http://redfish.dmtf.org/schemas/v1/EventDestination.v1_6_0.json>
   Link: </redfish/v1/EventService/Subscriptions>; path=
   ETag: "1651135676"
   Content-Type: application/json; charset=UTF-8
   OData-Version: 4.0
   Content-Length: 614
   Date: Thu, 28 Apr 2022 08:47:57 GMT

步骤

1. 运行以下 curl 命令，检查 BMC 的当前订阅：

   $ curl --globoff -H "Content-Type: application/json" -k -X GET --user <bmc_username>:<password> https://<bmc_ip_address>/redfish/v1/EventService/Subscriptions

   其中：

   bmc_ip_address

   是生成 Redfish 事件的 BMC 的 IP 地址。

   输出示例

   % Total % Received % Xferd Average Speed Time Time Time Current
   Dload Upload Total Spent Left Speed
   100 435 100 435 0 0 399 0 0:00:01 0:00:01 --:--:-- 399
   {
     "@odata.context": "/redfish/v1/$metadata#EventDestinationCollection.EventDestinationCollection",
     "@odata.etag": ""
     1651137375 "",
     "@odata.id": "/redfish/v1/EventService/Subscriptions",
     "@odata.type": "#EventDestinationCollection.EventDestinationCollection",
     "Description": "Collection for Event Subscriptions",
     "Members": [
     {
       "@odata.id": "/redfish/v1/EventService/Subscriptions/1"
     }],
     "Members@odata.count": 1,
     "Name": "Event Subscriptions Collection"
   }

   本例中配置了单个订阅：/redfish/v1/EventService/Subscriptions/1。

2. 可选： 要使用 curl 删除 /redfish/v1/EventService/Subscriptions/1 订阅，请运行以下命令并指定 BMC 用户名和密码：

   $ curl --globoff -L -w "%{http_code} %{url_effective}\n" -k -u <bmc_username>:<password >-H "Content-Type: application/json" -d '{}' -X DELETE https://<bmc_ip_address>/redfish/v1/EventService/Subscriptions/1

   其中：

   bmc_ip_address

   是生成 Redfish 事件的 BMC 的 IP 地址。

步骤

1. 创建 HardwareEvent 自定义资源(CR)：

   注意

   不允许多个 HardwareEvent 资源。

   1. 将以下 YAML 保存到 hw-event.yaml 文件中：

      apiVersion: "event.redhat-cne.org/v1alpha1"
      kind: "HardwareEvent"
      metadata:
        name: "hardware-event"
      spec:
        nodeSelector:
          node-role.kubernetes.io/hw-event: "" 1
        logLevel: "debug" 2
        msgParserTimeout: "10" 3

      1

      必需。使用 nodeSelector 字段来带有指定标签的目标节点，如 node-role.kubernetes.io/hw-event: ""。

      注意

      在 OpenShift Container Platform 4.12 或更高版本中，当对裸机事件使用 HTTP 传输时，您不需要在 HardwareEvent 资源中设置 spec.transportHost 字段。仅在裸机事件使用 AMQP 传输时设置 transportHost。

      2

      可选。默认值为 debug。在 hw-event-proxy 日志中设置日志级别。可用的日志级别如下： fatal、error、warning、info、debug、trace。

      3

      可选。为 Message Parser 设置超时值（毫秒）。如果在超时时间内没有响应消息解析请求，原始硬件事件信息会被传递给云原生事件框架。默认值为 10。

   2. 在集群中应用 HardwareEvent CR：

      $ oc create -f hardware-event.yaml

2. 创建一个 BMC 用户名和密码 Secret CR，使硬件事件代理能够访问裸机主机的 Redfish 消息 registry。

   1. 将以下 YAML 保存到 hw-event-bmc-secret.yaml 文件中：

      apiVersion: v1
      kind: Secret
      metadata:
        name: redfish-basic-auth
      type: Opaque
      stringData: 1
        username: <bmc_username>
        password: <bmc_password>
        # BMC host DNS or IP address
        hostaddr: <bmc_host_ip_address>

      1

      为 stringData 下的各种项目输入纯文本值。

   2. 创建 Secret CR：

      $ oc create -f hw-event-bmc-secret.yaml

1. 可选：在 OpenShift Container Platform 集群中添加节点。请参阅为系统调整设置 BIOS 参数。
2. 使用 oc 命令将标签 worker-rt 添加到需要实时功能的 worker 节点。

3. 为实时节点创建新机器配置池：

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

   请注意，为具有标签 worker-rt 标签的节点组创建一个机器配置池 worker-rt。

4. 使用节点角色标签将节点添加到正确的机器配置池。

   注意

   您必须决定使用实时工作负载配置哪些节点。您可以配置集群中的所有节点，或配置节点的子集。期望所有节点都是专用机器配置池的一部分的 Node Tuning Operator。如果使用所有节点，您必须将 Node Tuning Operator 指向 worker 节点角色标签。如果使用子集，您必须将节点分组到新机器配置池中。

5. 使用正确的 housekeeping 内核和 realTimeKernel: enabled: true 创建 PerformanceProfile。

6. 您必须在 PerformanceProfile 中设置 MachineConfigPoolSelector ：

     apiVersion: performance.openshift.io/v2
     kind: PerformanceProfile
     metadata:
      name: example-performanceprofile
     spec:
     ...
       realTimeKernel:
         enabled: true
       nodeSelector:
          node-role.kubernetes.io/worker-rt: ""
       machineConfigPoolSelector:
          machineconfiguration.openshift.io/role: worker-rt

7. 验证匹配的机器配置池是否存在一个标签：

   $ oc describe mcp/worker-rt

   输出示例

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

8. OpenShift Container Platform 将开始配置节点，这可能涉及多次重启。等待节点处于稳定状态。这个过程所需要的时间取决于您所使用的具体硬件，预计每个节点需要 20 分钟。
9. 验证所有内容是否按预期工作。

流程

1. 创建带有 Guaranteed 类 QoS 类的 pod。
2. 可选：禁用 DPDK 的 CPU 负载均衡。
3. 分配正确的节点选择器。

1. 创建 pod：

   $ oc  apply -f qos-pod.yaml --namespace=qos-example

2. 查看有关 pod 的详细信息：

   $ oc get pod qos-demo --namespace=qos-example --output=yaml

   输出示例

   spec:
     containers:
       ...
   status:
     qosClass: Guaranteed

   注意

   如果容器指定了自己的内存限值，但没有指定内存请求，OpenShift Container Platform 会自动分配与限制匹配的内存请求。同样，如果容器指定了自己的 CPU 限值，但没有指定 CPU 请求，OpenShift Container Platform 会自动分配与限制匹配的 CPU 请求。

1. 在性能配置集中设置离线 CPU 并保存 YAML 文件的内容：

   带有离线 CPU 的性能配置集示例

   apiVersion: performance.openshift.io/v2
   kind: PerformanceProfile
   metadata:
     name: performance
   spec:
     additionalKernelArgs:
     - nmi_watchdog=0
     - audit=0
     - mce=off
     - processor.max_cstate=1
     - intel_idle.max_cstate=0
     - idle=poll
     cpu:
       isolated: "2-23,26-47"
       reserved: "0,1,24,25"
       offlined: "48-59" 1
     nodeSelector:
       node-role.kubernetes.io/worker-cnf: ""
     numa:
       topologyPolicy: single-numa-node
     realTimeKernel:
       enabled: true

   1

   可选。您可以在 offlined 字段中列出 CPU，使指定的 CPU 离线。

2. 运行以下命令来应用更新的配置集：

   $ oc apply -f my-performance-profile.yaml

流程

1. 使用将每个 pod-power-management 设置为 true 来生成 PerformanceProfile ：

   $ podman run --entrypoint performance-profile-creator -v \
   /must-gather:/must-gather:z registry.redhat.io/openshift4/ose-cluster-node-tuning-operator:v4.12 \
   --mcp-name=worker-cnf --reserved-cpu-count=20 --rt-kernel=true \
   --split-reserved-cpus-across-numa=false --topology-manager-policy=single-numa-node \
   --must-gather-dir-path /must-gather -power-consumption-mode=low-latency \ 1
   --per-pod-power-management=true > my-performance-profile.yaml

   1

   当将 per-pod-power-management 设置为 true 时，power-consumption-mode 必须是 default 或 low-latency。

   带有 perPodPowerManagement的 PerformanceProfile 示例

   apiVersion: performance.openshift.io/v2
   kind: PerformanceProfile
   metadata:
        name: performance
   spec:
       [.....]
       workloadHints:
           realTime: true
           highPowerConsumption: false
           perPodPowerManagement: true

2. 在 PerformanceProfile 自定义资源(CR) 中将默认 cpufreq 调控器设置为附加内核参数：

   apiVersion: performance.openshift.io/v2
   kind: PerformanceProfile
   metadata:
        name: performance
   spec:
       ...
       additionalKernelArgs:
       - cpufreq.default_governor=schedutil 1

   1

   建议使用 schedutil 管理器，但您可以使用其他监管器，如 ondemand 或 powersave governors。

3. 在 Tuned PerformancePatch CR 中设置最大 CPU 频率：

   spec:
     profile:
     - data: |
         [sysfs]
         /sys/devices/system/cpu/intel_pstate/max_perf_pct = <x> 1

   1

   max_perf_pct 控制 cpufreq 驱动程序的最大频率，以最大百分比的形式设置支持的 cpu 频率。这个值适用于所有 CPU。您可以检查 /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq 中的最大支持频率。作为起点，您可以使用以 All Cores Turbo 频率封装所有 CPU 的百分比。All Cores Turbo 频率是所有内核在运行的频率，当内核完全占用时。

4. 将所需的注解添加到高优先级工作负载 pod。注解会覆盖默认设置。

   高优先级工作负载注解示例

   apiVersion: v1
   kind: Pod
   metadata:
     ...
     annotations:
       ...
       cpu-c-states.crio.io: "disable"
       cpu-freq-governor.crio.io: "<governor>"
       ...
     ...
   spec:
     ...
     runtimeClassName: performance-<profile_name>
     ...

5. 重启 pod。

流程

1. 以具有 cluster-admin 权限的用户身份登录 OpenShift Container Platform 集群。
2. 将性能配置集 apiVersion 设置为使用 performance.openshift.io/v2。
3. 删除 globallyDisableIrqLoadBalancing 字段，或把它设置为 false。

4. 设置适当的隔离 CPU 和保留的 CPU。以下片段演示了保留 2 个 CPU 的配置集。对于在 isolated CPU 集中运行的 pod，启用 IRQ 负载均衡：

   apiVersion: performance.openshift.io/v2
   kind: PerformanceProfile
   metadata:
     name: dynamic-irq-profile
   spec:
     cpu:
       isolated: 2-5
       reserved: 0-1
   ...

   注意

   当您配置保留的和隔离的 CPU 时，pod 中的 infra 容器将使用保留的 CPU,应用程序容器则使用隔离的 CPU。

5. 创建使用独有 CPU 的 pod，并将 irq-load-balancing.crio.io 和 cpu-quota.crio.io 注解设置为 disable。例如：

   apiVersion: v1
   kind: Pod
   metadata:
     name: dynamic-irq-pod
     annotations:
        irq-load-balancing.crio.io: "disable"
        cpu-quota.crio.io: "disable"
   spec:
     containers:
     - name: dynamic-irq-pod
       image: "registry.redhat.io/openshift4/cnf-tests-rhel8:v4.12"
       command: ["sleep", "10h"]
       resources:
         requests:
           cpu: 2
           memory: "200M"
         limits:
           cpu: 2
           memory: "200M"
     nodeSelector:
       node-role.kubernetes.io/worker-cnf: ""
     runtimeClassName: performance-dynamic-irq-profile
   ...

6. 以 performance-<profile_name> 格式输入 pod 的 runtimeClassName，其中 <profile_name> 是来自 PerformanceProfile YAML 的 name，在本例中是 performance-dynamic-irq-profile。
7. 将节点选择器设置为以 cnf-worker 为目标。

8. 确保 pod 正确运行。状态应该为 running，并应正确设置了 cnf-worker 节点：

   $ oc get pod -o wide

   预期输出

   NAME              READY   STATUS    RESTARTS   AGE     IP             NODE          NOMINATED NODE   READINESS GATES
   dynamic-irq-pod   1/1     Running   0          5h33m   <ip-address>   <node-name>   <none>           <none>

9. 获取为 IRQ 动态负载均衡配置的 pod 运行 CPU：

   $ oc exec -it dynamic-irq-pod -- /bin/bash -c "grep Cpus_allowed_list /proc/self/status | awk '{print $2}'"

   预期输出

   Cpus_allowed_list:  2-3

10. 确保正确应用节点配置。登录节点以验证配置。

    $ oc debug node/<node-name>

    预期输出

    Starting pod/<node-name>-debug ...
    To use host binaries, run `chroot /host`
    
    Pod IP: <ip-address>
    If you don't see a command prompt, try pressing enter.
    
    sh-4.4#

11. 验证可以使用节点文件系统：

    sh-4.4# chroot /host

    预期输出

    sh-4.4#

12. 确保默认系统 CPU 关联性掩码不包括 dynamic-irq-pod CPU，如 CPU 2 和 3。

    $ cat /proc/irq/default_smp_affinity

    输出示例

    33

13. 确定系统 IRQ 没有配置为在 dynamic-irq-pod CPU 中运行：

    find /proc/irq/ -name smp_affinity_list -exec sh -c 'i="$1"; mask=$(cat $i); file=$(echo $i); echo $file: $mask' _ {} \;

    输出示例

    /proc/irq/0/smp_affinity_list: 0-5
    /proc/irq/1/smp_affinity_list: 5
    /proc/irq/2/smp_affinity_list: 0-5
    /proc/irq/3/smp_affinity_list: 0-5
    /proc/irq/4/smp_affinity_list: 0
    /proc/irq/5/smp_affinity_list: 0-5
    /proc/irq/6/smp_affinity_list: 0-5
    /proc/irq/7/smp_affinity_list: 0-5
    /proc/irq/8/smp_affinity_list: 4
    /proc/irq/9/smp_affinity_list: 4
    /proc/irq/10/smp_affinity_list: 0-5
    /proc/irq/11/smp_affinity_list: 0
    /proc/irq/12/smp_affinity_list: 1
    /proc/irq/13/smp_affinity_list: 0-5
    /proc/irq/14/smp_affinity_list: 1
    /proc/irq/15/smp_affinity_list: 0
    /proc/irq/24/smp_affinity_list: 1
    /proc/irq/25/smp_affinity_list: 1
    /proc/irq/26/smp_affinity_list: 1
    /proc/irq/27/smp_affinity_list: 5
    /proc/irq/28/smp_affinity_list: 1
    /proc/irq/29/smp_affinity_list: 0
    /proc/irq/30/smp_affinity_list: 0-5

流程

1. 确定在您要配置的主机的 CPU 上运行哪些线程。

   您可以通过登录到集群并运行以下命令来查看在主机 CPU 上运行哪些线程：

   $ lscpu --all --extended

   输出示例

   CPU NODE SOCKET CORE L1d:L1i:L2:L3 ONLINE MAXMHZ    MINMHZ
   0   0    0      0    0:0:0:0       yes    4800.0000 400.0000
   1   0    0      1    1:1:1:0       yes    4800.0000 400.0000
   2   0    0      2    2:2:2:0       yes    4800.0000 400.0000
   3   0    0      3    3:3:3:0       yes    4800.0000 400.0000
   4   0    0      0    0:0:0:0       yes    4800.0000 400.0000
   5   0    0      1    1:1:1:0       yes    4800.0000 400.0000
   6   0    0      2    2:2:2:0       yes    4800.0000 400.0000
   7   0    0      3    3:3:3:0       yes    4800.0000 400.0000

   在这个示例中，在四个物理 CPU 内核中运行了八个逻辑 CPU 内核。CPU0 和 CPU4 在物理 Core0 中运行，CPU1 和 CPU5 在物理 Core 1 中运行，以此类推。

   另外要查看为特定物理 CPU 内核设定的线程（以下示例中的cpu0 ），打开命令提示符并运行以下命令：

   $ cat /sys/devices/system/cpu/cpu0/topology/thread_siblings_list

   输出示例

   0-4

2. 在 PerformanceProfile YAML 中应用隔离和保留的 CPU。例如，您可以将逻辑内核 CPU0 和 CPU4 设置为 isolated；将逻辑内核 CPU1 到 CPU3 以及 CPU5 到 CPU7 设置为 reserved。当您配置保留的和隔离的 CPU 时，pod 中的 infra 容器将使用保留的 CPU,应用程序容器则使用隔离的 CPU。

   ...
     cpu:
       isolated: 0,4
       reserved: 1-3,5-7
   ...

   注意

   保留和隔离的 CPU 池不得重叠，并且必须一起跨越 worker 节点中的所有可用内核。

流程

1. 按照 "Understanding workload hints" 的表，创建一个适合环境的硬件和拓扑的 PerformanceProfile。调整配置集以匹配预期的工作负载。在这个示例中，我们针对最低的延迟进行优化。

2. 添加 highPowerConsumption 和 realTime 工作负载提示。这里两者都设为 true。

       apiVersion: performance.openshift.io/v2
       kind: PerformanceProfile
       metadata:
         name: workload-hints
       spec:
         ...
         workloadHints:
           highPowerConsumption: true 1
           realTime: true 2

   1

   如果 highPowerConsumption 为 true，则节点将针对实现非常低的延迟进行调优，从而增加了电源消耗的成本。

   2

   禁用一些可能会影响系统延迟的调试和监控功能。

流程

1. 创建适合环境硬件和拓扑的性能配置集。

2. 使用您想要为 infra 和应用程序容器保留和隔离的 CPU 添加 reserved 和 isolated 参数：

   apiVersion: performance.openshift.io/v2
   kind: PerformanceProfile
   metadata:
     name: infra-cpus
   spec:
     cpu:
       reserved: "0-4,9" 1
       isolated: "5-8" 2
     nodeSelector: 3
       node-role.kubernetes.io/worker: ""

   1

   指定 infra 容器用于执行集群和操作系统日常任务的 CPU。

   2

   指定应用程序容器运行工作负载的 CPU。

   3

   可选：指定一个节点选择器，以将性能配置集应用到特定的节点。

流程

1. 以具有 cluster-admin 权限的用户身份登录运行 Node Tuning Operator 的 OpenShift Container Platform 集群。
2. 创建并应用适合您的硬件和拓扑的性能配置集。有关创建配置集的指南，请参阅"创建性能配置集"部分。

3. 编辑这个创建的性能配置集：

   $ oc edit -f <your_profile_name>.yaml

4. 使用 net 对象填充 spec 字段。对象列表可以包含两个字段：

   • userLevelNetworking 是一个必需字段，指定为布尔值标记。如果 userLevelNetworking 为 true，则队列数将设置为所有支持设备的保留 CPU 计数。默认值为 false。

   • devices 是一个可选字段，指定队列设置为保留 CPU 数的设备列表。如果设备列表为空，则配置适用于所有网络设备。配置如下：

     • interfaceName：此字段指定接口名称，并支持 shell 样式的通配符，可以是正数或负数。

       • 通配符语法示例如下： <string> .*
       • 负规则的前缀为感叹号。要将网络队列更改应用到排除列表以外的所有设备，请使用 !<device>。例如 !eno1。
     • vendorID：网络设备供应商 ID，以带有 0x 前缀的 16 位十六进制数字代表。

     • deviceID：网络设备 ID（model），以带有 0x 前缀的 16 位十六进制数字代表。

       注意

       当指定 deviceID 时，还必须定义 vendorID。与设备条目 interfaceName、vendorID 或 vendorID 加 deviceID 中指定的所有设备标识符相匹配的设备会被视为一个网络设备。然后，此网络设备的 net 队列数设置为保留的 CPU 计数。

       当指定了两个或多个设备时，网络队列数将设置为与其中一个设备匹配的任何网络设备。

5. 使用此示例性能配置集将所有设备的队列数设置为保留的 CPU 计数：

   apiVersion: performance.openshift.io/v2
   kind: PerformanceProfile
   metadata:
     name: manual
   spec:
     cpu:
       isolated: 3-51,55-103
       reserved: 0-2,52-54
     net:
       userLevelNetworking: true
     nodeSelector:
       node-role.kubernetes.io/worker-cnf: ""

6. 使用这个示例性能配置集，将所有与任何定义的设备标识符匹配的保留 CPU 数设置为保留的 CPU 计数：

   apiVersion: performance.openshift.io/v2
   kind: PerformanceProfile
   metadata:
     name: manual
   spec:
     cpu:
       isolated: 3-51,55-103
       reserved: 0-2,52-54
     net:
       userLevelNetworking: true
       devices:
       - interfaceName: "eth0"
       - interfaceName: "eth1"
       - vendorID: "0x1af4"
         deviceID: "0x1000"
     nodeSelector:
       node-role.kubernetes.io/worker-cnf: ""

7. 使用这个示例性能配置集，将所有以接口名称 eth 开头的设备的队列数设置为保留的 CPU 计数：

   apiVersion: performance.openshift.io/v2
   kind: PerformanceProfile
   metadata:
     name: manual
   spec:
     cpu:
       isolated: 3-51,55-103
       reserved: 0-2,52-54
     net:
       userLevelNetworking: true
       devices:
       - interfaceName: "eth*"
     nodeSelector:
       node-role.kubernetes.io/worker-cnf: ""

8. 使用这个示例性能配置集。将所有设备的队列数设置为保留的 CPU 计数，该接口具有 eno1 以外的任何接口：

   apiVersion: performance.openshift.io/v2
   kind: PerformanceProfile
   metadata:
     name: manual
   spec:
     cpu:
       isolated: 3-51,55-103
       reserved: 0-2,52-54
     net:
       userLevelNetworking: true
       devices:
       - interfaceName: "!eno1"
     nodeSelector:
       node-role.kubernetes.io/worker-cnf: ""

9. 使用这个示例性能配置集，将所有具有接口名称 eth0，vendorID 为 0x1af4、deviceID 为 0x1000 的设备的队列数设置为保留 CPU 数：

   apiVersion: performance.openshift.io/v2
   kind: PerformanceProfile
   metadata:
     name: manual
   spec:
     cpu:
       isolated: 3-51,55-103
       reserved: 0-2,52-54
     net:
       userLevelNetworking: true
       devices:
       - interfaceName: "eth0"
       - vendorID: "0x1af4"
         deviceID: "0x1000"
     nodeSelector:
       node-role.kubernetes.io/worker-cnf: ""

10. 应用更新的性能配置集：

    $ oc apply -f <your_profile_name>.yaml

1. 关联的机器配置池处于降级状态：

   # oc get mcp

   输出示例

   NAME         CONFIG                                                 UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
   master       rendered-master-2ee57a93fa6c9181b546ca46e1571d2d       True      False      False      3              3                   3                     0                      2d21h
   worker       rendered-worker-d6b2bdc07d9f5a59a6b68950acf25e5f       True      False      False      2              2                   2                     0                      2d21h
   worker-cnf   rendered-worker-cnf-6c838641b8a08fff08dbd8b02fb63f7c   False     True       True       2              1                   1                     1                      2d20h

2. MCP 的 describe 部分包括了原因：

   # oc describe mcp worker-cnf

   输出示例

     Message:               Node node-worker-cnf is reporting: "prepping update:
     machineconfig.machineconfiguration.openshift.io \"rendered-worker-cnf-40b9996919c08e335f3ff230ce1d170\" not
     found"
       Reason:                1 nodes are reporting degraded status on sync

3. 降级状态也应该出现在标记为 degraded = true 的性能配置集的 status 字段中：

   # oc describe performanceprofiles performance

   输出示例

   Message: Machine config pool worker-cnf Degraded Reason: 1 nodes are reporting degraded status on sync.
   Machine config pool worker-cnf Degraded Message: Node yquinn-q8s5v-w-b-z5lqn.c.openshift-gce-devel.internal is
   reporting: "prepping update: machineconfig.machineconfiguration.openshift.io
   \"rendered-worker-cnf-40b9996919c08e335f3ff230ce1d170\" not found".    Reason:  MCPDegraded
      Status:  True
      Type:    Degraded

流程

1. 进入存储 must-gather 数据的目录。

2. 使用一个或多个 --image 或 --image-stream 参数运行 oc adm must-gather 命令。例如，使用以下命令可收集默认集群数据和 Node Tuning Operator 特定信息：

   $ oc adm must-gather \
    --image-stream=openshift/must-gather \ 1
   
    --image=registry.redhat.io/openshift4/performance-addon-operator-must-gather-rhel8:v4.12 2

   1

   默认 OpenShift Container Platform must-gather 镜像。

   2

   低延迟调整诊断的 must-gather 镜像。

3. 从工作目录中创建的 must-gather 目录创建一个压缩文件。例如，在使用 Linux 操作系统的计算机上运行以下命令：

    $ tar cvaf must-gather.tar.gz must-gather.local.5421342344627712289/ 1

   1

   将 must-gather-local.5421342344627712289/ 替换为实际目录名称。

4. 在红帽客户门户中为您的问题单附上压缩文件。