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. 根据您的环境解码和替换脚本中的设备名称。

   #!/bin/bash
   set -uo pipefail
   
   for device in <device_type_glob>; do 1
   /usr/sbin/blkid $device &> /dev/null
    if [ $? == 2  ]; then
       echo "secondary device found $device"
       echo "creating filesystem for etcd mount"
       mkfs.xfs -L var-lib-etcd -f $device &> /dev/null
       udevadm settle
       touch /etc/var-lib-etcd-mount
       exit
    fi
   done
   echo "Couldn't find secondary block device!" >&2
   exit 77

   1

   将 <device_type_glob> 替换为您的块设备类型的 shell glob。对于 SCSI 或 SATA 驱动器，使用 /dev/sd*; 对于虚拟驱动器，使用 /dev/vd*; 对于 NVMe 驱动器，使用 /dev/nvme*[0-9]*n*。

3. 创建名为 etcd-mc.yml 的 MachineConfig YAML 文件，其内容如下：

   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: master
     name: 98-var-lib-etcd
   spec:
     config:
       ignition:
         version: 3.1.0
       storage:
         files:
           - path: /etc/find-secondary-device
             mode: 0755
             contents:
               source: data:text/plain;charset=utf-8;base64,<encoded_etc_find_secondary_device_script> 1
       systemd:
         units:
           - name: find-secondary-device.service
             enabled: true
             contents: |
               [Unit]
               Description=Find secondary device
               DefaultDependencies=false
               After=systemd-udev-settle.service
               Before=local-fs-pre.target
               ConditionPathExists=!/etc/var-lib-etcd-mount
   
               [Service]
               RemainAfterExit=yes
               ExecStart=/etc/find-secondary-device
   
               RestartForceExitStatus=77
   
               [Install]
               WantedBy=multi-user.target
           - name: var-lib-etcd.mount
             enabled: true
             contents: |
               [Unit]
               Before=local-fs.target
   
               [Mount]
               What=/dev/disk/by-label/var-lib-etcd
               Where=/var/lib/etcd
               Type=xfs
               TimeoutSec=120s
   
               [Install]
               RequiredBy=local-fs.target
           - name: sync-var-lib-etcd-to-etcd.service
             enabled: true
             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=/usr/sbin/setsebool -P rsync_full_access 1
               ExecStart=/bin/rsync -ar /sysroot/ostree/deploy/rhcos/var/lib/etcd/ /var/lib/etcd/
               ExecStart=/usr/sbin/semanage fcontext -a -t container_var_lib_t '/var/lib/etcd(/.*)?'
               ExecStart=/usr/sbin/setsebool -P rsync_full_access 0
               TimeoutSec=0
   
               [Install]
               WantedBy=multi-user.target graphical.target
           - name: restorecon-var-lib-etcd.service
             enabled: true
             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

   1

   使用之前创建的编码字符串，并将其替换为您记下的编码脚本。

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.15"
        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.15.2   numaresources-operator   4.15.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. 创建 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: ""

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

      $ oc create -f nrop.yaml

流程

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

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

      apiVersion: performance.openshift.io/v2
      kind: PerformanceProfile
      metadata:
        name: perfprof-nrop
      spec:
        cpu: 1
          isolated: "4-51,56-103"
          reserved: "0,1,2,3,52,53,54,55"
        nodeSelector:
          node-role.kubernetes.io/worker: ""
        numa:
          topologyPolicy: single-numa-node

      1

      cpu.isolated 和 cpu.reserved 规格定义了隔离和保留 CPU 的范围。输入 CPU 配置的有效值。有关配置性能配置集的更多信息，请参阅附加资源部分。

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

      $ oc create -f nro-perfprof.yaml

      输出示例

      performanceprofile.performance.openshift.io/perfprof-nrop created

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-rhel9:v4.15"
        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. 运行以下命令验证性能配置集是否已应用：

   $ oc describe performanceprofile <performance-profile-name>

2. 运行以下命令验证所需资源是否已成功部署：

   $ oc get all -n openshift-numaresources

   输出示例

   NAME                                                    READY   STATUS    RESTARTS   AGE
   pod/numaresources-controller-manager-7575848485-bns4s   1/1     Running   0          13m
   pod/numaresourcesoperator-worker-dvj4n                  2/2     Running   0          16m
   pod/numaresourcesoperator-worker-lcg4t                  2/2     Running   0          16m
   pod/secondary-scheduler-56994cf6cf-7qf4q                1/1     Running   0          16m
   NAME                                          DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR                     AGE
   daemonset.apps/numaresourcesoperator-worker   2         2         2       2            2           node-role.kubernetes.io/worker=   16m
   NAME                                               READY   UP-TO-DATE   AVAILABLE   AGE
   deployment.apps/numaresources-controller-manager   1/1     1            1           13m
   deployment.apps/secondary-scheduler                1/1     1            1           16m
   NAME                                                          DESIRED   CURRENT   READY   AGE
   replicaset.apps/numaresources-controller-manager-7575848485   1         1         1       13m
   replicaset.apps/secondary-scheduler-56994cf6cf                1         1         1       16m

流程

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. 可选：创建 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.15"
        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/v1
   kind: NUMAResourcesScheduler
   metadata:
     name: numaresourcesscheduler
   spec:
     imageSpec: "registry.redhat.io/openshift4/noderesourcetopology-scheduler-container-rhel8:v4.15"
     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.13 或更高版本中，当对裸机事件使用 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. 按照 "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. 将 per-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.15 \
   --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 频率是所有内核在运行的频率，当内核完全占用时。

流程

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. 确定在您要配置的主机的 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 节点中的所有可用内核。