可伸缩性和性能

OpenShift Container Platform 4.10

扩展 OpenShift Container Platform 集群并调整产品环境的性能

Red Hat OpenShift Documentation Team

摘要

本文档提供了扩展集群和优化 OpenShift Container Platform 环境性能的说明。

第 4 章 使用 Node Tuning Operator

了解 Node Tuning Operator，以及如何使用它通过编排 tuned 守护进程以管理节点级别的性能优化。

4.1. 关于 Node Tuning Operator

Node Tuning Operator 可以帮助您通过编排 TuneD 守护进程来管理节点级别的性能优化。大多数高性能应用程序都需要一定程度的内核级性能优化。Node Tuning Operator 为用户提供了一个统一的、节点一级的 sysctl 管理接口，并可以根据具体用户的需要灵活地添加自定义性能优化设置。

Operator 将为 OpenShift Container Platform 容器化 TuneD 守护进程作为一个 Kubernetes 守护进程集进行管理。它保证了自定义性能优化设置以可被守护进程支持的格式传递到在集群中运行的所有容器化的 TuneD 守护进程中。相应的守护进程会在集群的所有节点上运行，每个节点上运行一个。

在发生触发配置集更改的事件时，或通过接收和处理终止信号安全终止容器化 TuneD 守护进程时，容器化 TuneD 守护进程所应用的节点级设置将被回滚。

在版本 4.1 及更高版本中，OpenShift Container Platform 标准安装中包含了 Node Tuning Operator。

4.2. 访问 Node Tuning Operator 示例规格

使用此流程来访问 Node Tuning Operator 的示例规格。

流程

  1. 运行： 

    $ oc get Tuned/default -o yaml -n openshift-cluster-node-tuning-operator

默认 CR 旨在为 OpenShift Container Platform 平台提供标准的节点级性能优化，它只能被修改来设置 Operator Management 状态。Operator 将覆盖对默认 CR 的任何其他自定义更改。若进行自定义性能优化，请创建自己的 Tuned CR。新创建的 CR 将与默认的 CR 合并，并基于节点或 pod 标识和配置文件优先级对节点应用自定义调整。

警告

虽然在某些情况下，对 pod 标识的支持可以作为自动交付所需调整的一个便捷方式，但我们不鼓励使用这种方法，特别是在大型集群中。默认 Tuned CR 并不带有 pod 标识匹配。如果创建了带有 pod 标识匹配的自定义配置集，则该功能将在此时启用。在以后的 Node Tuning Operator 版本中可能会弃用 pod 标识功能。

4.3. 在集群中设置默认配置集

以下是在集群中设置的默认配置集。 

apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: default
  namespace: openshift-cluster-node-tuning-operator
spec:
  recommend:
  - profile: "openshift-control-plane"
    priority: 30
    match:
    - label: "node-role.kubernetes.io/master"
    - label: "node-role.kubernetes.io/infra"

  - profile: "openshift-node"
    priority: 40

从 OpenShift Container Platform 4.9 开始，所有 OpenShift TuneD 配置集都随 TuneD 软件包一起提供。您可以使用 oc exec 命令查看这些配置集的内容： 

$ oc exec $tuned_pod -n openshift-cluster-node-tuning-operator -- find /usr/lib/tuned/openshift{,-control-plane,-node} -name tuned.conf -exec grep -H ^ {} \;

4.4. 验证是否应用了 TuneD 配置集

验证应用到集群节点的 TuneD 配置集。 

$ oc get profile -n openshift-cluster-node-tuning-operator

输出示例

NAME             TUNED                     APPLIED   DEGRADED   AGE
master-0         openshift-control-plane   True      False      6h33m
master-1         openshift-control-plane   True      False      6h33m
master-2         openshift-control-plane   True      False      6h33m
worker-a         openshift-node            True      False      6h28m
worker-b         openshift-node            True      False      6h28m

  • NAME：配置集（Profile）对象的名称。每个节点有一个 Profile 对象，其名称相互匹配。
  • TUNED：要应用的 TuneD 配置集的名称。
  • APPLIED：如果 TuneD 守护进程应用了所需的配置集，则为 True。（True/False/Unknown）。
  • DEGRADED：如果在应用 TuneD 配置集时报告了任何错误则为 True（True/False/Unknown）。
  • AGE：创建 Profile 对象后经过的时间。

4.5. 自定义调整规格

Operator 的自定义资源 (CR) 包含两个主要部分。第一部分是 profile:，这是 TuneD 配置集及其名称的列表。第二部分是 recommend:，用来定义配置集选择逻辑。

多个自定义调优规格可以共存，作为 Operator 命名空间中的多个 CR。Operator 会检测到是否存在新 CR 或删除了旧 CR。所有现有的自定义性能优化设置都会合并，同时更新容器化 TuneD 守护进程的适当对象。

管理状态

通过调整默认的 Tuned CR 来设置 Operator Management 状态。默认情况下，Operator 处于 Managed 状态，默认的 Tuned CR 中没有 spec.managementState 字段。Operator Management 状态的有效值如下：

  • Managed: Operator 会在配置资源更新时更新其操作对象
  • Unmanaged: Operator 将忽略配置资源的更改
  • Removed: Operator 将移除 Operator 置备的操作对象和资源

配置集数据

profile: 部分列出了 TuneD 配置集及其名称。 

profile:
- name: tuned_profile_1
  data: |
    # TuneD profile specification
    [main]
    summary=Description of tuned_profile_1 profile

    [sysctl]
    net.ipv4.ip_forward=1
    # ... other sysctl's or other TuneD daemon plugins supported by the containerized TuneD

# ...

- name: tuned_profile_n
  data: |
    # TuneD profile specification
    [main]
    summary=Description of tuned_profile_n profile

    # tuned_profile_n profile settings

建议的配置集

profile: 选择逻辑通过 CR 的 recommend: 部分来定义。recommend: 部分是根据选择标准推荐配置集的项目列表。 

recommend:
<recommend-item-1>
# ...
<recommend-item-n>

列表中的独立项： 

- machineConfigLabels: 1
    <mcLabels> 2
  match: 3
    <match> 4
  priority: <priority> 5
  profile: <tuned_profile_name> 6
  operand: 7
    debug: <bool> 8
1
可选。
2
MachineConfig 标签的键/值字典。键必须是唯一的。
3
如果省略，则会假设配置集匹配，除非设置了优先级更高的配置集，或设置了 machineConfigLabels。
4
可选列表。
5
配置集排序优先级。较低数字表示优先级更高（0 是最高优先级）。
6
在匹配项中应用的 TuneD 配置集。例如 tuned_profile_1。
7
可选操作对象配置。
8
为 TuneD 守护进程打开或关闭调试。true 为打开，false 为关闭。默认值为 false。

<match> 是一个递归定义的可选数组，如下所示： 

- label: <label_name> 1
  value: <label_value> 2
  type: <label_type> 3
    <match> 4
1
节点或 pod 标签名称。
2
可选的节点或 pod 标签值。如果省略，<label_name> 足以匹配。
3
可选的对象类型（node 或 pod）。如果省略，会使用 node。
4
可选的 <match> 列表。

如果不省略 <match>，则所有嵌套的 <match> 部分也必须评估为 true。否则会假定 false，并且不会应用或建议具有对应 <match> 部分的配置集。因此，嵌套（子级 <match> 部分）会以逻辑 AND 运算来运作。反之，如果匹配 <match> 列表中任何一项，整个 <match> 列表评估为 true。因此，该列表以逻辑 OR 运算来运作。

如果定义 了 machineConfigLabels，基于机器配置池的匹配会对给定的 recommend: 列表项打开。<mcLabels> 指定机器配置标签。机器配置会自动创建，以在配置集 <tuned_profile_name> 中应用主机设置，如内核引导参数。这包括使用与 <mcLabels> 匹配的机器配置选择器查找所有机器配置池，并在分配了找到的机器配置池的所有节点上设置配置集 <tuned_profile_name>。要针对同时具有 master 和 worker 角色的节点，您必须使用 master 角色。

列表项 match 和 machineConfigLabels 由逻辑 OR 操作符连接。match 项首先以短电路方式评估。因此，如果它被评估为 true，则不考虑 MachineConfigLabels 项。

重要

当使用基于机器配置池的匹配时，建议将具有相同硬件配置的节点分组到同一机器配置池中。不遵循这个原则可能会导致在共享同一机器配置池的两个或者多个节点中 TuneD 操作对象导致内核参数冲突。

示例：基于节点或 pod 标签的匹配

- match:
  - label: tuned.openshift.io/elasticsearch
    match:
    - label: node-role.kubernetes.io/master
    - label: node-role.kubernetes.io/infra
    type: pod
  priority: 10
  profile: openshift-control-plane-es
- match:
  - label: node-role.kubernetes.io/master
  - label: node-role.kubernetes.io/infra
  priority: 20
  profile: openshift-control-plane
- priority: 30
  profile: openshift-node

根据配置集优先级，以上 CR 针对容器化 TuneD 守护进程转换为 recommend.conf 文件。优先级最高 (10) 的配置集是 openshift-control-plane-es，因此会首先考虑它。在给定节点上运行的容器化 TuneD 守护进程会查看同一节点上是否在运行设有 tuned.openshift.io/elasticsearch 标签的 pod。如果没有，则整个 <match> 部分评估为 false。如果存在具有该标签的 pod，为了让 <match> 部分评估为 true，节点标签也需要是 node-role.kubernetes.io/master 或 node-role.kubernetes.io/infra。

如果这些标签对优先级为 10 的配置集而言匹配，则应用 openshift-control-plane-es 配置集，并且不考虑其他配置集。如果节点/pod 标签组合不匹配，则考虑优先级第二高的配置集 (openshift-control-plane)。如果容器化 TuneD Pod 在具有标签 node-role.kubernetes.io/master 或 node-role.kubernetes.io/infra 的节点上运行，则应用此配置集。

最后，配置集 openshift-node 的优先级最低 (30)。它没有 <match> 部分，因此始终匹配。如果给定节点上不匹配任何优先级更高的配置集，它会作为一个适用于所有节点的配置集来设置 openshift-node 配置集。

决定工作流

示例：基于机器配置池的匹配

apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: openshift-node-custom
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
  - data: |
      [main]
      summary=Custom OpenShift node profile with an additional kernel parameter
      include=openshift-node
      [bootloader]
      cmdline_openshift_node_custom=+skew_tick=1
    name: openshift-node-custom

  recommend:
  - machineConfigLabels:
      machineconfiguration.openshift.io/role: "worker-custom"
    priority: 20
    profile: openshift-node-custom

为尽量减少节点的重新引导情况，为目标节点添加机器配置池将匹配的节点选择器标签，然后创建上述 Tuned CR，最后创建自定义机器配置池。

4.6. 自定义调整示例

从默认 CR 中使用 TuneD 配置集

以下 CR 对带有标签 tuned.openshift.io/ingress-node-label 的 OpenShift Container Platform 节点应用节点一级的自定义调整。

示例：使用 openshift-control-plane TuneD 配置集进行自定义性能优化

apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: ingress
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
  - data: |
      [main]
      summary=A custom OpenShift ingress profile
      include=openshift-control-plane
      [sysctl]
      net.ipv4.ip_local_port_range="1024 65535"
      net.ipv4.tcp_tw_reuse=1
    name: openshift-ingress
  recommend:
  - match:
    - label: tuned.openshift.io/ingress-node-label
    priority: 10
    profile: openshift-ingress

重要

对于开发自定义配置集的人员。我们强烈建议包括在默认 Tuned CR 中提供的默认 TuneD 守护进程配置集。上面的示例使用默认 openshift-control-plane 配置集。

使用内置 TuneD 配置集

由于 NTO 管理的守护进程集已被成功推出，TuneD 操作对象会管理 TuneD 守护进程的同一版本。要列出守护进程支持的内置 TuneD 配置集，请以以下方式查询任何 TuneD pod： 

$ oc exec $tuned_pod -n openshift-cluster-node-tuning-operator -- find /usr/lib/tuned/ -name tuned.conf -printf '%h\n' | sed 's|^.*/||'

您可以使用自定义调优规格中检索的配置集名称。

示例：使用内置 hpc-compute TuneD 配置集

apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: openshift-node-hpc-compute
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
  - data: |
      [main]
      summary=Custom OpenShift node profile for HPC compute workloads
      include=openshift-node,hpc-compute
    name: openshift-node-hpc-compute

  recommend:
  - match:
    - label: tuned.openshift.io/openshift-node-hpc-compute
    priority: 20
    profile: openshift-node-hpc-compute

除了内置的 hpc-compute 配置集外，上面的示例还包括默认 Tuned CR 中提供的 openshift-node TuneD 守护进程配置集，以对计算节点使用特定于 OpenShift 的调优。

4.7. 支持的 TuneD 守护进程插件

在使用 Tuned CR 的 profile: 部分中定义的自定义配置集时，以下 TuneD 插件都受到支持，但 [main] 部分除外：

  • audio
  • cpu
  • disk
  • eeepc_she
  • modules
  • mounts
  • net
  • scheduler
  • scsi_host
  • selinux
  • sysctl
  • sysfs
  • usb
  • video
  • vm
  • bootloader

其中一些插件提供了不受支持的动态性能优化功能。目前不支持以下 TuneD 插件：

  • script
  • systemd
注意

TuneD bootloader 插件只支持 Red Hat Enterprise Linux CoreOS (RHCOS) worker 节点。

其他参考资源

第 5 章 使用 CPU Manager 和拓扑管理器

CPU Manager 管理 CPU 组并限制特定 CPU 的负载。

CPU Manager 对于有以下属性的负载有用：

  • 需要尽可能多的 CPU 时间。
  • 对处理器缓存丢失非常敏感。
  • 低延迟网络应用程序。
  • 需要与其他进程协调，并从共享一个处理器缓存中受益。

拓扑管理器（Topology Manager）从 CPU Manager、设备管理器和其他 Hint 提供者收集提示信息，以匹配相同非统一 内存访问（NUMA）节点上的所有 QoS 类的 pod 资源（如 CPU、SR-IOV VF 和其他设备资源）。

拓扑管理器使用收集来的提示信息中获得的拓扑信息，根据配置的 Topology Manager 策略以及请求的 Pod 资源，决定节点是否被节点接受或拒绝。

拓扑管理器对希望使用硬件加速器来支持对工作延迟有极高要求的操作及高吞吐并发计算的负载很有用。

要使用拓扑管理器，您必须使用 静态 策略配置 CPU Manager。

5.1. 设置 CPU Manager

流程

  1. 可选：标记节点： 

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

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

    # oc edit machineconfigpool worker

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

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

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

    apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: cpumanager-enabled
spec:
  machineConfigPoolSelector:
    matchLabels:
      custom-kubelet: cpumanager-enabled
  kubeletConfig:
     cpuManagerPolicy: static 1
     cpuManagerReconcilePeriod: 5s 2
    1
    指定一个策略：
    • none.这个策略明确启用了现有的默认 CPU 关联性方案，从而不会出现超越调度程序自动进行的关联性。这是默认策略。
    • static。此策略允许保证 pod 中的容器具有整数 CPU 请求。它还限制对节点上的专用 CPU 的访问。如果为 static，则需要使用一个小些 s。
    2
    可选的。指定 CPU Manager 协调频率。默认值为 5s。

  5. 创建动态 kubelet 配置： 

    # oc create -f cpumanager-kubeletconfig.yaml

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

  6. 检查合并的 kubelet 配置： 

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

    输出示例

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

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

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

    输出示例

    cpuManagerPolicy: static        1
cpuManagerReconcilePeriod: 5s   2

    1
    在创建 KubeletConfig CR 时，会定义 cpuManagerPolicy。
    2
    在创建 KubeletConfig CR 时，会定义 cpuManagerReconcilePeriod。

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

    # cat cpumanager-pod.yaml

    输出示例

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

  9. 创建 pod： 

    # oc create -f cpumanager-pod.yaml

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

    # oc describe pod cpumanager

    输出示例

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

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

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

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

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

    输出示例

    cpuset.cpus 1
tasks 32706

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

    # grep ^Cpus_allowed_list /proc/32706/status

    输出示例

     Cpus_allowed_list:    1

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

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

    输出示例

    ...
Capacity:
 attachable-volumes-aws-ebs:  39
 cpu:                         2
 ephemeral-storage:           124768236Ki
 hugepages-1Gi:               0
 hugepages-2Mi:               0
 memory:                      8162900Ki
 pods:                        250
Allocatable:
 attachable-volumes-aws-ebs:  39
 cpu:                         1500m
 ephemeral-storage:           124768236Ki
 hugepages-1Gi:               0
 hugepages-2Mi:               0
 memory:                      7548500Ki
 pods:                        250
-------                               ----                           ------------  ----------  ---------------  -------------  ---
  default                                 cpumanager-6cqz7               1 (66%)       1 (66%)     1G (12%)         1G (12%)       29m

Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource                    Requests          Limits
  --------                    --------          ------
  cpu                         1440m (96%)       1 (66%)

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

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

5.2. 拓扑管理器策略

拓扑管理器通过从 Hint 提供者（如 CPU Manager 和设备管理器）收集拓扑提示来调整所有级别服务质量（QoS）的 Pod 资源，并使用收集的提示来匹配 Pod 资源。

拓扑管理器支持四个分配策略，这些策略在名为 cpumanager-enabled 的 KubeletConfig 自定义资源 (CR) 中分配：

none 策略
这是默认策略，不执行任何拓扑对齐调整。
best-effort 策略
对于带有 best-effort 拓扑管理策略的 pod 中的每个容器，kubelet 会调用每个 Hint 提供者来发现其资源的可用性。使用这些信息，拓扑管理器会保存那个容器的首选 NUMA 节点关联性设置。如果关联性没有被首选设置，则拓扑管理器会保存这个设置，并把 pod 分配给节点。
restricted 策略
对于带有 restricted 拓扑管理策略的 pod 中的每个容器，kubelet 会调用每个 Hint 提供者来发现其资源的可用性。使用这些信息，拓扑管理器会保存那个容器的首选 NUMA 节点关联性设置。如果关联性没有被首选，则拓扑管理器会从节点拒绝这个 pod，从而导致 pod 处于 Terminated 状态，且 pod 准入失败。
single-numa-node 策略
对于带有 single-numa-node 拓扑管理策略的 pod 中的每个容器，kubelet 会调用每个 Hint 提供者来发现其资源的可用性。使用这个信息，拓扑管理器会决定单个 NUMA 节点关联性是否可能。如果是，pod 将会分配给该节点。如果无法使用单一 NUMA 节点关联性，则拓扑管理器会拒绝来自节点的 pod。这会导致 pod 处于 Terminated 状态，且 pod 准入失败。

5.3. 设置拓扑管理器

要使用拓扑管理器，您必须在名为 cpumanager-enabled 的 KubeletConfig 自定义资源 (CR) 中配置分配策略。如果您设置了 CPU Manager，则该文件可能会存在。如果这个文件不存在，您可以创建该文件。

先决条件

  • 将 CPU Manager 策略配置为 static。

流程

激活 Topolgy Manager:

  1. 在自定义资源中配置拓扑管理器分配策略。 

    $ oc edit KubeletConfig cpumanager-enabled
    apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: cpumanager-enabled
spec:
  machineConfigPoolSelector:
    matchLabels:
      custom-kubelet: cpumanager-enabled
  kubeletConfig:
     cpuManagerPolicy: static 1
     cpuManagerReconcilePeriod: 5s
     topologyManagerPolicy: single-numa-node 2
    1
    这个参数必须是 static，s 为小写。
    2
    指定所选拓扑管理器分配策略。在这里，策略是 single-numa-node。有效值为：default、best-effort、restricted、single-numa-node。

5.4. Pod 与拓扑管理器策略的交互

以下的 Pod specs 示例演示了 Pod 与 Topology Manager 的交互。

因为没有指定资源请求或限制，以下 pod 以 BestEffort QoS 类运行。 

spec:
  containers:
  - name: nginx
    image: nginx

因为请求小于限制，下一个 pod 以 Burstable QoS 类运行。 

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
      requests:
        memory: "100Mi"

如果所选策略不是 none，则拓扑管理器将不考虑其中任何一个 Pod 规格。

因为请求等于限制，最后一个 pod 以 Guaranteed QoS 类运行。 

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "2"
        example.com/device: "1"
      requests:
        memory: "200Mi"
        cpu: "2"
        example.com/device: "1"

拓扑管理器将考虑这个 pod。拓扑管理器会参考 CPU Manager 和设备管理器的 hint 供应商，以获取 pod 的拓扑提示。

拓扑管理器将使用此信息存储该容器的最佳拓扑。在本 pod 中，CPU Manager 和设备管理器将在资源分配阶段使用此存储的信息。

第 6 章 调度 NUMA 感知工作负载

了解 NUMA 感知调度以及如何使用它来在 OpenShift Container Platform 集群中部署高性能工作负载。

重要

NUMA 感知调度只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议（SLA）支持，且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能，并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的更多信息，请参阅技术预览功能支持范围。

NUMA Resources Operator 允许您在相同的 NUMA 区域中调度高性能工作负载。它部署一个节点资源导出代理，该代理在可用的集群节点 NUMA 资源以及管理工作负载的辅助调度程序上报告。

6.1. 关于 NUMA 感知调度

非统一内存访问 (NUMA) 是一个计算平台架构，允许不同的 CPU 以不同速度访问不同区域。NUMA 资源拓扑引用与计算节点上相互相对的 CPU、内存和 PCI 设备的位置。在一起的资源表示在同一 NUMA 区域中。对于高性能应用程序，集群需要处理单个 NUMA 区域中的 pod 工作负载。

NUMA 架构允许有多个内存控制器的 CPU 在 CPU 复杂间使用任何可用内存，无论内存所处的位置。这可以以牺牲性能为代价来增加灵活性。使用位于 NUMA 区域以外的内存的 CPU 处理工作负载的速度比单个 NUMA 区域处理的工作负载要慢。另外，对于对 I/O 有限制的工作负载，在远程的 NUMA 区域中的网络接口会减慢访问应用程序的速度。高性能工作负载（如电信工作负载）无法在这些条件下达到操作要求。NUMA 感知调度会调整同一 NUMA 区域中请求的集群计算资源（CPU、内存、设备），以有效地处理对延迟敏感的工作负责或高性能工作负载。NUMA 感知调度还提高了每个计算节点的 pod 密度，以提高资源效率。

默认的 OpenShift Container Platform pod 调度程序调度逻辑考虑整个计算节点的可用资源，而不是单个 NUMA 区域。如果在 kubelet 拓扑管理器中请求最严格的资源协调，则会在将 pod 传递给节点时出现错误条件。相反，如果没有请求限制性最严格的资源协调，则 pod 可以在没有正确的资源协调的情况下被节点接受，从而导致性能更差或无法达到预期。例如，当 pod 调度程序通过不知道 pod 请求的资源可用而导致做出非最佳的调度决定时，pod 创建可能会出现 Topology Affinity Error 状态。调度不匹配决策可能会导致 pod 启动延迟。另外，根据集群状态和资源分配，pod 调度决策可能会因为启动失败而对集群造成额外的负载。

NUMA Resources Operator 部署了一个自定义 NUMA 资源辅助调度程序和其他资源，以缓解默认 OpenShift Container Platform pod 调度程序的缩写。下图显示了 NUMA 感知 pod 调度的高级概述。

图 6.1. NUMA 感知调度概述

NUMA 感知调度图，显示各种组件如何在集群中相互交互
NodeResourceTopology API
NodeResourceTopology API 描述了每个计算节点上可用的 NUMA 区资源。
NUMA 感知调度程序
NUMA 感知辅助调度程序从 NodeResourceTopology API 接收有关可用 NUMA 区域的信息，并在可以最佳处理的节点上调度高性能工作负载。
节点拓扑 exporter
节点拓扑 exporter 会公开每个计算节点的可用 NUMA 区资源到 NodeResourceTopology API。节点拓扑 exporter 守护进程使用 PodResources API 跟踪来自 kubelet 的资源分配。
PodResources API
对于每个节点，PodResources API 是本地的，并向 kubelet 公开资源拓扑和可用资源。

其他资源

6.2. 安装 NUMA Resources Operator

NUMA Resources Operator 部署资源，供您调度 NUMA 感知工作负载和部署。您可以使用 OpenShift Container Platform CLI 或 Web 控制台安装 NUMA Resources Operator。

6.2.1. 使用 CLI 安装 NUMA Resources Operator

作为集群管理员，您可以使用 CLI 安装 Operator。

先决条件

  • 安装 OpenShift CLI（oc）。
  • 以具有 cluster-admin 特权的用户身份登录。

流程

  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: "{product-version}"
  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.10.0  NUMA Resources Operator      4.10.0               Succeeded

6.2.2. 使用 Web 控制台安装 NUMA Resources Operator

作为集群管理员，您可以使用 Web 控制台安装 NUMA Resources Operator。

流程

  1. 使用 OpenShift Container Platform Web 控制台安装 NUMA Resources Operator：

    1. 在 OpenShift Container Platform Web 控制台中，点击 Operators → OperatorHub。
    2. 从可用的 Operator 列表中选择 NUMA Resources Operator，然后点 Install。

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

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

    2. 确保 NUMA Resources Operator 在 default 项目中列出，Status 为 InstallSucceeded。

      注意

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

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

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

6.3. 创建 NUMAResourcesOperator 自定义资源

安装 NUMA Resources Operator 后，创建 NUMAResourcesOperator 自定义资源 (CR) 来指示 NUMA Resources Operator 安装支持 NUMA 感知调度程序所需的所有集群基础架构，包括守护进程集和 API。

先决条件

  • 安装 OpenShift CLI（oc）。
  • 以具有 cluster-admin 特权的用户身份登录。
  • 安装 NUMA Resources Operator。

流程

  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

验证

运行以下命令，验证 NUMA Resources Operator 是否已成功部署： 

$ oc get numaresourcesoperators.nodetopology.openshift.io

输出示例

NAME                    AGE
numaresourcesoperator   10m

6.4. 部署 NUMA 感知辅助 pod 调度程序

安装 NUMA Resources Operator 后，执行以下操作来部署 NUMA 感知辅助 pod 调度程序：

  • 为所需机器配置集配置 pod admittance 策略
  • 创建所需的机器配置池
  • 部署 NUMA 感知二级调度程序

先决条件

  • 安装 OpenShift CLI（oc）。
  • 以具有 cluster-admin 特权的用户身份登录。
  • 安装 NUMA Resources Operator。

流程

  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.10"

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

      $ oc create -f nro-scheduler.yaml

验证

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

$ 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

6.5. 使用 NUMA 感知调度程序调度工作负载

您可以使用 Deployment CR 将工作负载调度到 NUMA 感知调度程序，该 CR 指定处理工作负载的最低所需资源。

以下示例部署使用 NUMA 感知调度示例工作负载。

先决条件

  • 安装 OpenShift CLI（oc）。
  • 以具有 cluster-admin 特权的用户身份登录。
  • 安装 NUMA Resources Operator 并部署 NUMA 感知辅助调度程序。

流程

  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

6.6. 对 NUMA 感知调度进行故障排除

要排除 NUMA 感知 pod 调度的常见问题，请执行以下步骤。

先决条件

  • 安装 OpenShift Container Platform CLI（oc）。
  • 以具有 cluster-admin 权限的用户身份登录。
  • 安装 NUMA Resources Operator 并部署 NUMA 感知辅助调度程序。

流程

  1. 运行以下命令，验证 noderesourcetopologies CRD 是否已在集群中部署： 

    $ oc get crd | grep noderesourcetopologies

    输出示例

    NAME                                                              CREATED AT
noderesourcetopologies.topology.node.k8s.io                       2022-01-18T08:28:06Z

  2. 运行以下命令，检查 NUMA-aware 调度程序名称是否与 NUMA 感知工作负载中指定的名称匹配： 

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

    输出示例

    topo-aware-scheduler

  3. 验证 NUMA-aware scheduable 节点是否应用了 noderesourcetopologies CR。运行以下命令: 

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

    输出示例

    NAME                    AGE
compute-0.example.com   17h
compute-1.example.com   17h

    注意

    节点数应该等于机器配置池 (mcp) worker 定义中配置的 worker 节点数量。

  4. 运行以下命令，验证所有 scheduable 节点的 NUMA 区粒度： 

    $ oc get noderesourcetopologies.topology.node.k8s.io -o yaml

    输出示例

    apiVersion: v1
items:
- apiVersion: topology.node.k8s.io/v1alpha1
  kind: NodeResourceTopology
  metadata:
    annotations:
      k8stopoawareschedwg/rte-update: periodic
    creationTimestamp: "2022-06-16T08:55:38Z"
    generation: 63760
    name: worker-0
    resourceVersion: "8450223"
    uid: 8b77be46-08c0-4074-927b-d49361471590
  topologyPolicies:
  - SingleNUMANodeContainerLevel
  zones:
  - costs:
    - name: node-0
      value: 10
    - name: node-1
      value: 21
    name: node-0
    resources:
    - allocatable: "38"
      available: "38"
      capacity: "40"
      name: cpu
    - allocatable: "134217728"
      available: "134217728"
      capacity: "134217728"
      name: hugepages-2Mi
    - allocatable: "262352048128"
      available: "262352048128"
      capacity: "270107316224"
      name: memory
    - allocatable: "6442450944"
      available: "6442450944"
      capacity: "6442450944"
      name: hugepages-1Gi
    type: Node
  - costs:
    - name: node-0
      value: 21
    - name: node-1
      value: 10
    name: node-1
    resources:
    - allocatable: "268435456"
      available: "268435456"
      capacity: "268435456"
      name: hugepages-2Mi
    - allocatable: "269231067136"
      available: "269231067136"
      capacity: "270573244416"
      name: memory
    - allocatable: "40"
      available: "40"
      capacity: "40"
      name: cpu
    - allocatable: "1073741824"
      available: "1073741824"
      capacity: "1073741824"
      name: hugepages-1Gi
    type: Node
- apiVersion: topology.node.k8s.io/v1alpha1
  kind: NodeResourceTopology
  metadata:
    annotations:
      k8stopoawareschedwg/rte-update: periodic
    creationTimestamp: "2022-06-16T08:55:37Z"
    generation: 62061
    name: worker-1
    resourceVersion: "8450129"
    uid: e8659390-6f8d-4e67-9a51-1ea34bba1cc3
  topologyPolicies:
  - SingleNUMANodeContainerLevel
  zones: 1
  - costs:
    - name: node-0
      value: 10
    - name: node-1
      value: 21
    name: node-0
    resources: 2
    - allocatable: "38"
      available: "38"
      capacity: "40"
      name: cpu
    - allocatable: "6442450944"
      available: "6442450944"
      capacity: "6442450944"
      name: hugepages-1Gi
    - allocatable: "134217728"
      available: "134217728"
      capacity: "134217728"
      name: hugepages-2Mi
    - allocatable: "262391033856"
      available: "262391033856"
      capacity: "270146301952"
      name: memory
    type: Node
  - costs:
    - name: node-0
      value: 21
    - name: node-1
      value: 10
    name: node-1
    resources:
    - allocatable: "40"
      available: "40"
      capacity: "40"
      name: cpu
    - allocatable: "1073741824"
      available: "1073741824"
      capacity: "1073741824"
      name: hugepages-1Gi
    - allocatable: "268435456"
      available: "268435456"
      capacity: "268435456"
      name: hugepages-2Mi
    - allocatable: "269192085504"
      available: "269192085504"
      capacity: "270534262784"
      name: memory
    type: Node
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

    1
    zones 下的每个小节都描述了单个 NUMA 区域的资源。
    2
    resources 描述了 NUMA 区域资源的当前状态。检查 items.zones.resources.available 下列出的资源是否与分配给每个有保证的 pod 的独有的 NUMA 区资源对应。

6.6.1. 检查 NUMA 感知调度程序日志

通过查看日志来排除 NUMA 感知调度程序的问题。如果需要，可以通过修改 NUMAResourcesScheduler 资源的 spec.logLevel 字段来增加调度程序日志级别。可接受值为 Normal、Debug 和 Trace，其中 Trace 是最详细的选项。

注意

要更改辅助调度程序的日志级别，请删除正在运行的调度程序资源，并使用更改后的日志级别重新部署它。在此停机期间，调度程序无法调度新的工作负载。

先决条件

  • 安装 OpenShift CLI（oc）。
  • 以具有 cluster-admin 特权的用户身份登录。

流程

  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.10"
  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"

6.6.2. 对资源拓扑 exporter 进行故障排除

通过检查对应的 resource-topology-exporter 日志，对发生意外结果的 noderesourcetopologlogies 对象进行故障排除。

注意

建议为它们引用的节点命名 NUMA 资源拓扑导出器实例。例如，名为 worker 的 worker 节点应具有对应的 noderesourcetopologies 对象，称为 worker。

先决条件

  • 安装 OpenShift CLI（oc）。
  • 以具有 cluster-admin 特权的用户身份登录。

流程

  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

6.6.3. 更正缺少的资源拓扑 exporter 配置映射

如果您在配置了集群设置的集群中安装 NUMA Resources Operator，在有些情况下，Operator 会显示为 active，但资源拓扑 exporter (RTE) 守护进程集 pod 的日志显示 RTE 的配置缺失，例如： 

Info: couldn't find configuration in "/etc/resource-topology-exporter/config.yaml"

此日志消息显示集群中未正确应用带有所需配置的 kubeletconfig，从而导致缺少 RTE configmap。例如，以下集群缺少 numaresourcesoperator-worker configmap 自定义资源 (CR)： 

$ oc get configmap

输出示例

NAME                           DATA   AGE
0e2a6bd3.openshift-kni.io      0      6d21h
kube-root-ca.crt               1      6d21h
openshift-service-ca.crt       1      6d21h
topo-aware-scheduler-config    1      6d18h

在正确配置的集群中，oc get configmap 也会返回一个 numaresourcesoperator-worker configmap CR。

先决条件

  • 安装 OpenShift Container Platform CLI（oc）。
  • 以具有 cluster-admin 权限的用户身份登录。
  • 安装 NUMA Resources Operator 并部署 NUMA 感知辅助调度程序。

流程

  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. 应用标签更改并等待集群应用更新的配置。运行以下命令:

验证

  • 检查是否应用了缺少的 numaresourcesoperator-worker configmap CR: 

    $ oc get configmap

    输出示例

    NAME                           DATA   AGE
0e2a6bd3.openshift-kni.io      0      6d21h
kube-root-ca.crt               1      6d21h
numaresourcesoperator-worker   1      5m
openshift-service-ca.crt       1      6d21h
topo-aware-scheduler-config    1      6d18h

第 7 章 扩展 Cluster Monitoring Operator

OpenShift Container Platform 会提供 Cluster Monitoring Operator 在基于 Prometheus 的监控堆栈中收集并存储的数据。作为管理员，您可以在一个 dashboard 接口（Grafana）中查看系统资源、容器和组件指标。

7.1. Prometheus 数据库存储要求

红帽对不同的扩展大小进行了各种测试。

注意

以下 Prometheus 存储要求并不具有规定性。取决于工作负载活动和资源使用情况，集群中可能会观察到更高资源消耗。

表 7.1. Prometheus 数据库的存储要求取决于集群中的节点/pod 数量

节点数量pod 数量每天增加的 Prometheus 存储每 15 天增加的 Prometheus 存储RAM 空间（每个缩放大小）网络（每个 tsdb 块）

50

1800

6.3 GB

94 GB

6 GB

16 MB

100

3600

13 GB

195 GB

10 GB

26 MB

150

5400

19 GB

283 GB

12 GB

36 MB

200

7200

25 GB

375 GB

14 GB

46 MB

大约 20％的预期大小被添加为开销，以保证存储要求不会超过计算的值。

上面的计算用于默认的 OpenShift Container Platform Cluster Monitoring Operator。

注意

CPU 利用率会有轻微影响。这个比例为在每 50 个节点和 1800 个 pod 的 40 个内核中大约有 1 个。

针对 OpenShift Container Platform 的建议

  • 至少使用三个基础架构（infra）节点。
  • 至少使用三个带有 NVMe（non-volatile memory express）驱动的 openshift-container-storage 节点。

7.2. 配置集群监控

您可以为集群监控堆栈中的 Prometheus 组件增加存储容量。

流程

为 Prometheus 增加存储容量：

  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_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

第 8 章 根据对象限制规划您的环境

在规划 OpenShift Container Platform 集群时，请考虑以下对象限制。

这些限制基于最大可能的集群。对于较小的集群，最大值限制会较低。很多因素会影响指定的阈值，包括 etcd 版本或者存储数据格式。

重要

这些指南适用于带有软件定义网络（SDN）而不是开放虚拟网络（OVN）的 OpenShift Container Platform。

在大多数情况下，超过这些限制会降低整体性能。它不一定意味着集群会出现错误。

警告

对于快速变化的集群（如集群中包括多个启动和停止的 pod）可能会有比记录中小的实际最大大小。

8.1. OpenShift Container Platform 为主发行版本测试了集群最大值

为 OpenShift Container Platform 3.x 测试的云平台： Red Hat OpenStack Platform（RHOSP）、Amazon Web Services 和 Microsoft Azure。为 OpenShift Container Platform 4.x 测试的云平台： Amazon Web Services、Microsoft Azure 和 Google Cloud Platform。

最大类型3.x 测试的最大值4.x 测试的最大值

节点数

2,000

2,000 [1]

pod 数量 [2]

150,000

150,000

每个节点的 pod 数量

250

500 [3]

每个内核的 pod 数量

没有默认值。

没有默认值。

命名空间数量 [4]

10,000

10,000

构建（build）数

10,000（默认 pod RAM 512 Mi）- 管道 (Pipeline) 策略

10,000（默认 pod RAM 512 Mi）- Source-to-Image (S2I) 构建策略

每个命名空间的 pod 数量 [5]

25,000

25,000

每个 Ingress Controller 的路由和后端数量

每个路由器 2,000 个

每个路由器 2,000 个

secret 的数量

80,000

80,000

配置映射数量

90,000

90,000

服务数 [6]

10,000

10,000

每个命名空间的服务数

5,000

5,000

每个服务中的后端数

5,000

5,000

每个命名空间的部署数量 [5]

2,000

2,000

构建配置数

12,000

12,000

自定义资源定义 (CRD) 的数量

没有默认值。

512 [7]

  1. 部署暂停 Pod 以在 2000 个节点规模下对 OpenShift Container Platform 的 control plane 组件进行压力测试。
  2. 这里的 pod 数量是 test pod 的数量。实际的 pod 数量取决于应用程序的内存、CPU 和存储要求。
  3. 这在一个有 100 个 work 节点，每个 worker 节点有 500 个 pod 的集群中测试。默认 maxPods 仍为 250。要获得 500 maxPods，则必须使用自定义 kubelet 配置将 maxPods 设置为 500 来创建集群。如果需要 500 个用户 Pod，则需要 hostPrefix 为 22，因为节点上已经运行了 10-15 个系统 pod。带有 Persistent VolumeClaim (PVC) 的最大 pod 数量取决于分配 PVC 的后端存储。在我们的测试中，只有 OpenShift Data Foundation v4(OCS v4)能够满足本文档中提到的每个节点的 pod 数量。
  4. 当有大量活跃的项目时，如果键空间增长过大并超过空间配额，etcd 的性能将会受到影响。强烈建议您定期维护 etcd 存储（包括整理碎片）来释放 etcd 存储。
  5. 系统中有一些控制循环，它们必须对给定命名空间中的所有对象进行迭代，以作为对一些状态更改的响应。在单一命名空间中有大量给定类型的对象可使这些循环的运行成本变高，并降低对给定状态变化的处理速度。限制假设系统有足够的 CPU 、内存和磁盘来满足应用程序的要求。
  6. 每个服务端口和每个服务后端在 iptables 中都有对应条目。给定服务的后端数量会影响端点对象的大小，这会影响到整个系统发送的数据大小。
  7. OpenShift Container Platform 的限制是 512 个总自定义资源定义(CRD)，其中包括由 OpenShift Container Platform 安装的产品、与 OpenShift Container Platform 集成并创建了 CRD 的产品。如果创建超过 512 CRD，则 oc 命令请求可能会节流。
注意

红帽不提供针对 OpenShift Container Platform 集群大小调整的直接指导。这是因为，判断集群是否在 OpenShift Container Platform 支持的边界内，需要仔细考虑限制集群扩展的所有多维因素。

8.2. 测试集群最大值的 OpenShift Container Platform 环境和配置

8.2.1. AWS 云平台

节点FlavorvCPURAM(GiB)磁盘类型磁盘大小(GiB)/IOS数量区域

control plane/etcd [1]

r5.4xlarge

16

128

gp3

220

3

us-west-2

Infra [2]

m5.12xlarge

48

192

gp3

100

3

us-west-2

Workload [3]

m5.4xlarge

16

64

gp3

500 [4]

1

us-west-2

Compute

m5.2xlarge

8

32

gp3

100

3/25/250/500 [5]

us-west-2

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

8.2.2. IBM Power 平台

节点vCPURAM(GiB)磁盘类型磁盘大小(GiB)/IOS数量

control plane/etcd [1]

16

32

io1

每个 GiB 120 / 10 IOPS

3

Infra [2]

16

64

gp2

120

2

Workload [3]

16

256

gp2

120 [4]

1

Compute

16

64

gp2

120

2 到 100 [5]

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

8.2.3. IBM Z 平台

节点vCPU [4]RAM(GiB)[5]磁盘类型磁盘大小(GiB)/IOS数量

Control plane/etcd [1,2]

8

32

ds8k

300 / LCU 1

3

Compute [1,3]

8

32

ds8k

150 / LCU 2

4 节点（每个节点扩展到 100/250/500 pod）

  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。

8.3. 如何根据经过测试的集群限制规划您的环境

重要

在节点中过度订阅物理资源会影响在 pod 放置过程中对 Kubernetes 调度程序的资源保证。了解可以采取什么措施避免内存交换。

某些限制只在单一维度中扩展。当很多对象在集群中运行时，它们会有所不同。

本文档中给出的数字基于红帽的测试方法、设置、配置和调整。这些数字会根据您自己的设置和环境而有所不同。

在规划您的环境时，请确定每个节点会运行多少 个 pod ： 

required pods per cluster / pods per node = total number of nodes needed

每个节点上的 Pod 数量做多为 250。而在某个节点中运行的 pod 的具体数量取决于应用程序本身。请参阅 如何根据应用程序要求规划您的环境 中的内容来计划应用程序的内存、CPU 和存储要求。

示例情境

如果您计划把集群的规模限制在有 2200 个 pod，则需要至少有五个节点，假设每个节点最多有 500 个 pod： 

2200 / 500 = 4.4

如果将节点数量增加到 20，那么 pod 的分布情况将变为每个节点有 110 个 pod： 

2200 / 20 = 110

其中： 

required pods per cluster / total number of nodes = expected pods per node

8.4. 如何根据应用程序要求规划您的环境

考虑应用程序环境示例：

pod 类型pod 数量最大内存CPU 内核持久性存储

Apache

100

500 MB

0.5

1 GB

node.js

200

1 GB

1

1 GB

postgresql

100

1 GB

2

10 GB

JBoss EAP

100

1 GB

1

1 GB

推断的要求: 550 个 CPU 内核、450GB RAM 和 1.4TB 存储。

根据您的具体情况，节点的实例大小可以被增大或降低。在节点上通常会使用资源过度分配。在这个部署场景中，您可以选择运行多个额外的较小节点，或数量更少的较大节点来提供同样数量的资源。在做出决定前应考虑一些因素，如操作的灵活性以及每个实例的成本。

节点类型数量CPURAM (GB)

节点（选择 1）

100

4

16

节点（选择 2）

50

8

32

节点（选择 3）

25

16

64

有些应用程序很适合于过度分配的环境，有些则不适合。大多数 Java 应用程序以及使用巨页的应用程序都不允许使用过度分配功能。它们的内存不能用于其他应用程序。在上面的例子中，环境大约会出现 30％ 过度分配的情况，这是一个常见的比例。

应用程序 pod 可以使用环境变量或 DNS 访问服务。如果使用环境变量，当 pod 在节点上运行时，对于每个活跃服务，则 kubelet 的变量都会注入。集群感知 DNS 服务器监视 Kubernetes API 提供了新服务，并为每个服务创建一组 DNS 记录。如果整个集群中启用了 DNS，则所有 pod 都应自动根据其 DNS 名称解析服务。如果您必须超过 5000 服务，可以使用 DNS 进行服务发现。当使用环境变量进行服务发现时，参数列表超过了命名空间中 5000 服务后允许的长度，则 pod 和部署将失败。要解决这个问题，请禁用部署的服务规格文件中的服务链接： 

---
apiVersion: template.openshift.io/v1
kind: Template
metadata:
  name: deployment-config-template
  creationTimestamp:
  annotations:
    description: This template will create a deploymentConfig with 1 replica, 4 env vars and a service.
    tags: ''
objects:
- apiVersion: apps.openshift.io/v1
  kind: DeploymentConfig
  metadata:
    name: deploymentconfig${IDENTIFIER}
  spec:
    template:
      metadata:
        labels:
          name: replicationcontroller${IDENTIFIER}
      spec:
        enableServiceLinks: false
        containers:
        - name: pause${IDENTIFIER}
          image: "${IMAGE}"
          ports:
          - containerPort: 8080
            protocol: TCP
          env:
          - name: ENVVAR1_${IDENTIFIER}
            value: "${ENV_VALUE}"
          - name: ENVVAR2_${IDENTIFIER}
            value: "${ENV_VALUE}"
          - name: ENVVAR3_${IDENTIFIER}
            value: "${ENV_VALUE}"
          - name: ENVVAR4_${IDENTIFIER}
            value: "${ENV_VALUE}"
          resources: {}
          imagePullPolicy: IfNotPresent
          capabilities: {}
          securityContext:
            capabilities: {}
            privileged: false
        restartPolicy: Always
        serviceAccount: ''
    replicas: 1
    selector:
      name: replicationcontroller${IDENTIFIER}
    triggers:
    - type: ConfigChange
    strategy:
      type: Rolling
- apiVersion: v1
  kind: Service
  metadata:
    name: service${IDENTIFIER}
  spec:
    selector:
      name: replicationcontroller${IDENTIFIER}
    ports:
    - name: serviceport${IDENTIFIER}
      protocol: TCP
      port: 80
      targetPort: 8080
    clusterIP: ''
    type: ClusterIP
    sessionAffinity: None
  status:
    loadBalancer: {}
parameters:
- name: IDENTIFIER
  description: Number to append to the name of resources
  value: '1'
  required: true
- name: IMAGE
  description: Image to use for deploymentConfig
  value: gcr.io/google-containers/pause-amd64:3.0
  required: false
- name: ENV_VALUE
  description: Value to use for environment variables
  generate: expression
  from: "[A-Za-z0-9]{255}"
  required: false
labels:
  template: deployment-config-template

可在命名空间中运行的应用程序 pod 数量取决于服务数量以及环境变量用于服务发现时的服务名称长度。系统中的ARG_MAX 为新进程定义最大参数长度，默认设置为 2097152 KiB。Kubelet 将环境变量注入到要在命名空间中运行的每个 pod 中，包括：

  • <SERVICE_NAME>_SERVICE_HOST=<IP>
  • <SERVICE_NAME>_SERVICE_PORT=<PORT>
  • <SERVICE_NAME>_PORT=tcp://<IP>:<PORT>
  • <SERVICE_NAME>_PORT_<PORT>_TCP=tcp://<IP>:<PORT>
  • <SERVICE_NAME>_PORT_<PORT>_TCP_PROTO=tcp
  • <SERVICE_NAME>_PORT_<PORT>_TCP_PORT=<PORT>
  • <SERVICE_NAME>_PORT_<PORT>_TCP_ADDR=<ADDR>

如果参数长度超过允许的值，服务名称中的字符数会受到影响，命名空间中的 pod 将开始失败。例如，在一个带有 5000 服务的命名空间中，服务名称的限制为 33 个字符，它可让您在命名空间中运行 5000 个 Pod。

第 9 章 优化存储

优化存储有助于最小化所有资源中的存储使用。通过优化存储，管理员可帮助确保现有存储资源以高效的方式工作。

9.1. 可用的持久性存储选项

了解持久性存储选项，以便可以优化 OpenShift Container Platform 环境。

表 9.1. 可用存储选项

存储类型描述例子

Block

  • 在操作系统 (OS) 中作为块设备
  • 适用于需要完全控制存储，并绕过文件系统在低层直接操作文件的应用程序
  • 也称为存储区域网络 (SAN)
  • 不可共享，这意味着，每次只有一个客户端可以挂载这种类型的端点

AWS EBS 和 VMware vSphere 支持在 OpenShift Container Platform 中的原生动态持久性卷 (PV)置备 。

File

  • 在 OS 中作为要挂载的文件系统导出
  • 也称为网络附加存储（Network Attached Storage，NAS）
  • 取决于不同的协议、实现、厂商及范围，其并行性、延迟、文件锁定机制和其它功能可能会有很大不同。

RHEL NFS、NetApp NFS [1] 和供应商 NFS

对象

  • 通过 REST API 端点访问
  • 可配置以在 OpenShift 镜像 registry 中使用
  • 应用程序必须在应用程序和（/或）容器中构建其驱动程序。

AWS S3

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

目前，OpenShift Container Platform 4.10 不支持 CNS。

9.3. 数据存储管理

下表总结了 OpenShift Container Platform 组件写入数据的主要目录。

表 9.3. 用于存储 OpenShift Container Platform 数据的主目录

目录备注大小预期增长

/var/log

所有组件的日志文件。

10 到 30 GB。

日志文件可能会快速增长 ; 大小可以通过增加磁盘或使用日志轮转来管理。

/var/lib/etcd

用于存储数据库的 etcd 存储。

小于 20 GB。

数据库可增大到 8 GB。

随着环境增长会缓慢增长。只存储元数据。

每多加 8 GB 内存需要额外 20-25 GB。

/var/lib/containers

这是 CRI-O 运行时的挂载点。用于活跃容器运行时的存储，包括 Pod 和本地镜像存储。不适用于 registry 存储。

有 16 GB 内存的节点需要 50 GB。请注意，这个大小不应该用于决定最小集群要求。

每多加 8 GB 内存需要额外 20-25 GB。

增长受运行容器容量的限制。

/var/lib/kubelet

pod 的临时卷（Ephemeral volume）存储。这包括在运行时挂载到容器的任何外部存储。包括环境变量、kube secret 和不受持久性卷支持的数据卷。

可变

如果需要存储的 pod 使用持久性卷，则最小。如果使用临时存储，可能会快速增长。

9.4. 为 Microsoft Azure 优化存储性能

OpenShift Container Platform 和 Kubernetes 对磁盘性能敏感，建议使用更快的存储，特别是 control plane 节点上的 etcd。

对于生产环境 Azure 集群和带有密集型工作负载的集群，control plane 机器的虚拟机操作系统磁盘应该可以保持经过测试和推荐的最小吞吐量 5000 IOPS / 200MBps。此吞吐量可以通过至少 1 TiB Premium SSD (P30) 提供。在 Azure 和 Azure Stack Hub 中，磁盘性能直接依赖于 SSD 磁盘大小。要达到 Standard_D8s_v3 虚拟机或者其它类似机器类型，目标为 5000 IOPS，至少需要 P30 磁盘。

在读取数据时，主机缓存必须设置为 ReadOnly，以实现低延迟和高 IOPS 和吞吐量。从缓存中读取数据（在虚拟机内存或本地 SSD 磁盘上）比从磁盘读取速度要快得多，而这在 blob 存储中。

第 10 章 优化路由

OpenShift Container Platform HAProxy 路由器可以扩展或配置以优化性能。

10.1. Ingress Controller（router）性能的基线

OpenShift Container Platform Ingress Controller 或路由器是使用路由和入口配置的应用程序和服务的入口流量的入站点。

当根据每秒处理的 HTTP 请求来评估单个 HAProxy 路由器性能时，其性能取决于多个因素。特别是：

  • HTTP keep-alive/close 模式
  • 路由类型
  • 对 TLS 会话恢复客户端的支持
  • 每个目标路由的并行连接数
  • 目标路由数
  • 后端服务器页面大小
  • 底层基础结构（网络/SDN 解决方案、CPU 等）

具体环境中的性能会有所不同，红帽实验室在一个有 4 个 vCPU/16GB RAM 的公共云实例中进行测试。一个 HAProxy 路由器处理由后端终止的 100 个路由服务提供 1kB 静态页面，每秒处理以下传输数。

在 HTTP 的 keep-alive 模式下：

EncryptionLoadBalancerServiceHostNetwork

none

21515

29622

edge

16743

22913

passthrough

36786

53295

re-encrypt

21583

25198

在 HTTP 关闭（无 keep-alive）情境中：

EncryptionLoadBalancerServiceHostNetwork

none

5719

8273

edge

2729

4069

passthrough

4121

5344

re-encrypt

2320

2941

默认 Ingress Controller 配置用于将 spec.tuningOptions.threadCount 字段设置为 4。测试了两个不同的端点发布策略： Load Balancer Service 和 Host Network。TLS 会话恢复用于加密路由。使用 HTTP keep-alive 设置，单个 HAProxy 路由器可在页面大小小到 8 kB 时充满 1 Gbit NIC。

当在使用现代处理器的裸机中运行时，性能可以期望达到以上公共云实例测试性能的大约两倍。这个开销是由公有云的虚拟化层造成的，基于私有云虚拟化的环境也会有类似的开销。下表是有关在路由器后面的应用程序数量的指导信息：

应用程序数量应用程序类型

5-10

静态文件/web 服务器或者缓存代理

100-1000

生成动态内容的应用程序

取决于所使用的技术，HAProxy 通常可支持最多 1000 个程序的路由。Ingress Controller 性能可能会受其后面的应用程序的能力和性能的限制，如使用的语言，静态内容或动态内容。

如果有多个服务于应用程序的 Ingress 或路由器，则应该使用路由器分片（router sharding）以帮助横向扩展路由层。

如需有关 Ingress 分片的更多信息，请参阅使用路由标签和使用命名空间标签配置 Ingress Controller 分片。

有关 tuningOptions 的更多信息，请参阅 Ingress Controller 配置参数。

您可以修改 Ingress Controller 部署，根据 Setting Ingress Controller thread count（对于线程）和 Ingress Controller configuration parameters（对于超时）的内容，以及其他 Ingress Controller 规格中的其他调优配置。

第 11 章 优化网络

OpenShift SDN 使用 OpenvSwitch、虚拟可扩展 LAN(VXLAN)隧道、OpenFlow 规则和 iptables。这个网络可以通过使用 jumbo 帧、网络接口控制器 (NIC) 卸载、多队列和 ethtool 设置来调节。

OVN-Kubernetes 使用 Geneve（通用网络虚拟化封装）而不是 VXLAN 作为隧道协议。

VXLAN 提供通过 VLAN 的好处，比如网络从 4096 增加到一千六百万，以及跨物理网络的第 2 层连接。这允许服务后的所有 pod 相互通信，即使它们在不同系统中运行也是如此。

VXLAN 在用户数据报协议（UDP）数据包中封装所有隧道流量。但是，这会导致 CPU 使用率增加。这些外部数据包和内部数据包集都遵循常规的校验规则，以保证在传输过程中不会损坏数据。根据 CPU 性能，这种额外的处理开销可能会降低吞吐量，与传统的非覆盖网络相比会增加延迟。

云、虚拟机和裸机 CPU 性能可以处理很多 Gbps 网络吞吐量。当使用高带宽链接（如 10 或 40 Gbps）时，性能可能会降低。基于 VXLAN 的环境里存在一个已知问题，它并不适用于容器或 OpenShift Container Platform。由于 VXLAN 的实现，任何依赖于 VXLAN 隧道的网络都会有相似的性能。

如果您希望超过 Gbps，可以：

  • 试用采用不同路由技术的网络插件，比如边框网关协议（BGP）。
  • 使用 VXLAN-offload 功能的网络适配器。VXLAN-offload 将数据包校验和相关的 CPU 开销从系统 CPU 移动到网络适配器的专用硬件中。这会释放 Pod 和应用程序使用的 CPU 周期，并允许用户利用其网络基础架构的全部带宽。

VXLAN-offload 不会降低延迟。但是，即使延迟测试也会降低 CPU 使用率。

11.1. 为您的网络优化 MTU

有两个重要的最大传输单元 (MTU)：网络接口控制器 (NIC) MTU 和集群网络 MTU。

NIC MTU 仅在 OpenShift Container Platform 安装时进行配置。MTU 必须小于或等于您网络 NIC 的最大支持值。如果您要优化吞吐量，请选择最大可能的值。如果您要优化最小延迟，请选择一个较低值。

OpenShift SDN 网络插件覆盖 MTU 必须至少小于 NIC MTU 50 字节。此帐户用于 SDN overlay 标头。因此，在普通以太网网络中，应该将其设置为 1450。在巨型帧以太网网络中，这应设置为 8950。这些值应该由 Cluster Network Operator 根据 NIC 配置的 MTU 自动设置。因此，集群管理员通常不会更新这些值。Amazon Web Services (AWS) 和裸机环境支持巨型帧以太网网络。此设置可以帮助吞吐量，特别是传输控制协议 (TCP)。

对于 OVN 和 Geneve，MTU 必须至少小于 NIC MTU 100 字节。

注意

这个 50 字节覆盖标头与 OpenShift SDN 网络插件相关。其他 SDN 解决方案可能需要该值更大或更少。

11.3. IPsec 的影响

因为加密和解密节点主机使用 CPU 电源，所以启用加密时，无论使用的 IP 安全系统是什么，性能都会影响节点上的吞吐量和 CPU 使用量。

IPsec 在到达 NIC 前，会在 IP 有效负载级别加密流量，以保护用于 NIC 卸载的字段。这意味着，在启用 IPSec 时，一些 NIC 加速功能可能无法使用，并可能导致吞吐量降低并增加 CPU 用量。

其他资源

第 12 章 管理裸机主机

在裸机集群中安装 OpenShift Container Platform 时，您可以使用机器（machine）和机器集（machineset）自定义资源（CR）为集群中存在的裸机主机置备和管理裸机节点。

12.1. 关于裸机主机和节点

要将 Red Hat Enterprise Linux CoreOS（RHCOS）裸机主机置备为集群中的节点，首先创建一个与裸机主机硬件对应的 MachineSet 自定义资源（CR）对象。裸机主机机器集描述了特定于您的配置的基础架构组件。将特定的 Kubernetes 标签应用于这些机器集，然后将基础架构组件更新为仅在那些机器上运行。

当您扩展包含 metal3.io/autoscale-to-hosts 注解的相关 MachineSet 时，Machine CR 会被自动创建。OpenShift Container Platform 使用 Machine CR 来置备与 MachineSet CR 中指定的主机对应的裸机节点。

12.2. 维护裸机主机

您可从 OpenShift Container Platform Web 控制台维护集群中的裸机主机详情。导航到 Compute → Bare Metal Hosts，然后从 Actions 下拉菜单中选择一个任务。您可以在此处管理诸如 BMC 详情、主机的引导 MAC 地址、启用电源管理等项目。您还可以查看主机的网络接口和驱动器详情。

您可以将裸机主机移入维护模式。当您将主机移入维护模式时，调度程序会将所有受管工作负载从对应的裸机节点中移出。在处于维护模式时不会调度新的工作负载。

您可以在 web 控制台中取消置备裸机主机。取消置备主机执行以下操作：

  1. 使用 cluster.k8s.io/delete-machine: true注解裸机主机 CR
  2. 缩减相关的机器集
注意

在不先将守护进程集和未管理的静态 pod 移动到另一节点的情况下，关闭主机电源可能会导致服务中断和数据丢失。

其他资源

12.2.1. 使用 web 控制台在集群中添加裸机主机

您可以在 web 控制台中在集群中添加裸机主机。

先决条件

  • 在裸机上安装 RHCOS 集群。
  • 以具有 cluster-admin 特权的用户身份登录。

流程

  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 来增加集群中的机器副本数量。
注意

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

12.2.2. 在 web 控制台中使用 YAML 在集群中添加裸机主机

您可以使用描述裸机主机的 YAML 文件在 web 控制台中在集群中添加裸机主机。

先决条件

  • 在裸机基础架构上安装 RHCOS 计算机器，以便在集群中使用。
  • 以具有 cluster-admin 特权的用户身份登录。
  • 为裸机主机创建 Secret CR。

流程

  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 命令和适当的裸机机器集来管理裸机节点的数量。

12.2.3. 自动将机器扩展到可用的裸机主机数量

要自动创建与可用 BareMetalHost 对象数量匹配的 Machine 对象数量，请在 MachineSet 对象中添加 metal3.io/autoscale-to-hosts 注解。

先决条件

  • 安装 RHCOS 裸机计算机器以在集群中使用，并创建对应的 BareMetalHost 对象。
  • 安装 OpenShift Container Platform CLI（oc）。
  • 以具有 cluster-admin 特权的用户身份登录。

流程

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

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

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

注意

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

12.2.4. 从 provisioner 节点中删除裸机主机

在某些情况下，您可能想要从 provisioner 节点临时删除裸机主机。例如，在使用 OpenShift Container Platform 管理控制台或机器配置池更新触发裸机主机重启时，OpenShift Container Platform 日志会登录到集成的 Dell Remote Access Controller (iDrac)，并发出删除作业队列。

要防止管理与可用 BareMetalHost 对象数量匹配的 Machine 对象数量，请在 MachineSet 对象中添加 baremetalhost.metal3.io/detached 注解。

注意

这个注解只适用于处于 Provisioned, ExternallyProvisioned 或 Ready/Available 状态的 BareMetalHost 对象。

先决条件

  • 安装 RHCOS 裸机计算机器以在集群中使用，并创建对应的 BareMetalHost 对象。
  • 安装 OpenShift Container Platform CLI（oc）。
  • 以具有 cluster-admin 特权的用户身份登录。

流程

  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-'

其他资源

第 13 章 巨页的作用及应用程序如何使用它们

13.1. 巨页的作用

内存在块（称为页）中进行管理。在大多数系统中，页的大小为 4Ki。1Mi 内存相当于 256 个页，1Gi 内存相当于 256,000 个页。CPU 有内置的内存管理单元，可在硬件中管理这些页的列表。Translation Lookaside Buffer (TLB) 是虚拟页到物理页映射的小型硬件缓存。如果在硬件指令中包括的虚拟地址可以在 TLB 中找到，则其映射信息可以被快速获得。如果没有包括在 TLN 中，则称为 TLB miss。系统将会使用基于软件的，速度较慢的地址转换机制，从而出现性能降低的问题。因为 TLB 的大小是固定的，因此降低 TLB miss 的唯一方法是增加页的大小。

巨页指一个大于 4Ki 的内存页。在 x86_64 构架中，有两个常见的巨页大小: 2Mi 和 1Gi。在其它构架上的大小会有所不同。要使用巨页，必须写相应的代码以便应用程序了解它们。Transparent Huge Pages（THP）试图在应用程序不需要了解的情况下自动管理巨页，但这个技术有一定的限制。特别是，它的页大小会被限为 2Mi。当有较高的内存使用率时，THP 可能会导致节点性能下降，或出现大量内存碎片（因为 THP 的碎片处理）导致内存页被锁定。因此，有些应用程序可能更适用于（或推荐）使用预先分配的巨页，而不是 THP。

在 OpenShift Container Platform 中，pod 中的应用程序可以分配并消耗预先分配的巨页。

13.2. 应用程序如何使用巨页

节点必须预先分配巨页以便节点报告其巨页容量。一个节点只能预先分配一个固定大小的巨页。

巨页可以使用名为 hugepages-<size> 的容器一级的资源需求被消耗。其中 size 是特定节点上支持的整数值的最精简的二进制标记。例如：如果某个节点支持 2048KiB 页大小，它将会有一个可调度的资源 hugepages-2Mi。与 CPU 或者内存不同，巨页不支持过量分配。 

apiVersion: v1
kind: Pod
metadata:
  generateName: hugepages-volume-
spec:
  containers:
  - securityContext:
      privileged: true
    image: rhel7:latest
    command:
    - sleep
    - inf
    name: example
    volumeMounts:
    - mountPath: /dev/hugepages
      name: hugepage
    resources:
      limits:
        hugepages-2Mi: 100Mi 1
        memory: "1Gi"
        cpu: "1"
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages
1
为巨页指定要分配的准确内存数量。不要将这个值指定为巨页内存大小乘以页的大小。例如，巨页的大小为 2MB，如果应用程序需要使用由巨页组成的 100MB 的内存，则需要分配 50 个巨页。OpenShift Container Platform 会进行相应的计算。如上例所示，您可以直接指定 100MB 。

分配特定大小的巨页

有些平台支持多个巨页大小。要分配指定大小的巨页，在巨页引导命令参数前使用巨页大小选择参数hugepagesz=<size>。<size> 的值必须以字节为单位，并可以使用一个可选的后缀 [kKmMgG]。默认的巨页大小可使用 default_hugepagesz=<size> 引导参数定义。

巨页要求

  • 巨页面请求必须等于限制。如果指定了限制，则它是默认的，但请求不是。
  • 巨页在 pod 范围内被隔离。容器隔离功能计划在以后的版本中推出。
  • 后端为巨页的 EmptyDir 卷不能消耗大于 pod 请求的巨页内存。
  • 通过带有 SHM_HUGETLB 的 shmget() 来使用巨页的应用程序，需要运行一个匹配 proc/sys/vm/hugetlb_shm_group 的 supplemental 组。

13.3. 使用 Downward API 消耗巨页资源

您可以使用 Downward API 注入容器消耗的巨页资源的信息。

您可以将资源分配作为环境变量、卷插件或两者都注入。您在容器中开发和运行的应用可以通过读取指定卷中的环境变量或文件来确定可用的资源。

流程

  1. 创建一个类似以下示例的 hugepages-volume-pod.yaml 文件： 

    apiVersion: v1
kind: Pod
metadata:
  generateName: hugepages-volume-
  labels:
    app: hugepages-example
spec:
  containers:
  - securityContext:
      capabilities:
        add: [ "IPC_LOCK" ]
    image: rhel7:latest
    command:
    - sleep
    - inf
    name: example
    volumeMounts:
    - mountPath: /dev/hugepages
      name: hugepage
    - mountPath: /etc/podinfo
      name: podinfo
    resources:
      limits:
        hugepages-1Gi: 2Gi
        memory: "1Gi"
        cpu: "1"
      requests:
        hugepages-1Gi: 2Gi
    env:
    - name: REQUESTS_HUGEPAGES_1GI <.>
      valueFrom:
        resourceFieldRef:
          containerName: example
          resource: requests.hugepages-1Gi
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages
  - name: podinfo
    downwardAPI:
      items:
        - path: "hugepages_1G_request" <.>
          resourceFieldRef:
            containerName: example
            resource: requests.hugepages-1Gi
            divisor: 1Gi

    <.> 指定从 requests.hugepages-1Gi 读取资源使用，并将值公开为 REQUESTS_HUGEPAGES_1GI 环境变量。< .> 指定从 requests.hugepages-1Gi 读取资源使用,并将值公开为文件 /etc/podinfo/hugepages_1G_request。

  2. 从 hugepages-volume-pod.yaml 文件创建 pod： 

    $ oc create -f hugepages-volume-pod.yaml

验证

  1. 检查 REQUESTS_HUGEPAGES_1GI 环境变量的值： 

    $ oc exec -it $(oc get pods -l app=hugepages-example -o jsonpath='{.items[0].metadata.name}') \
     -- env | grep REQUESTS_HUGEPAGES_1GI

    输出示例

    REQUESTS_HUGEPAGES_1GI=2147483648

  2. 检查 /etc/podinfo/hugepages_1G_request 文件的值： 

    $ oc exec -it $(oc get pods -l app=hugepages-example -o jsonpath='{.items[0].metadata.name}') \
     -- cat /etc/podinfo/hugepages_1G_request

    输出示例

    2

其他资源

13.4. 配置巨页

节点必须预先分配在 OpenShift Container Platform 集群中使用的巨页。保留巨页的方法有两种： 在引导时和在运行时。在引导时进行保留会增加成功的可能性，因为内存还没有很大的碎片。Node Tuning Operator 目前支持在特定节点上分配巨页。

13.4.1. 在引导时

流程

要减少节点重启的情况，请按照以下步骤顺序进行操作：

  1. 通过标签标记所有需要相同巨页设置的节点。 

    $ oc label node <node_using_hugepages> node-role.kubernetes.io/worker-hp=

  2. 创建一个包含以下内容的文件，并把它命名为 hugepages_tuning.yaml： 

    apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: hugepages 1
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile: 2
  - data: |
      [main]
      summary=Boot time configuration for hugepages
      include=openshift-node
      [bootloader]
      cmdline_openshift_node_hugepages=hugepagesz=2M hugepages=50 3
    name: openshift-node-hugepages

  recommend:
  - machineConfigLabels: 4
      machineconfiguration.openshift.io/role: "worker-hp"
    priority: 30
    profile: openshift-node-hugepages
    1
    将 Tuned 资源的 name 设置为 hugepages。
    2
    将 profile 部分设置为分配巨页。
    3
    请注意，参数顺序是非常重要的，因为有些平台支持各种大小的巨页。
    4
    启用基于机器配置池的匹配。

  3. 创建 Tuned hugepages 对象 

    $ oc create -f hugepages-tuned-boottime.yaml

  4. 创建一个带有以下内容的文件，并把它命名为 hugepages-mcp.yaml： 

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

  5. 创建机器配置池： 

    $ oc create -f hugepages-mcp.yaml

因为有足够的非碎片内存，worker-hp 机器配置池中的所有节点现在都应分配 50 个 2Mi 巨页。 

$ oc get node <node_using_hugepages> -o jsonpath="{.status.allocatable.hugepages-2Mi}"
100Mi
注意

TuneD bootloader 插件只支持 Red Hat Enterprise Linux CoreOS (RHCOS) worker 节点。

13.5. 禁用透明巨页

Transparent Huge Pages (THP) 会试图自动执行创建、管理和使用巨页的大部分方面。由于 THP 自动管理巨页，因此并不始终对所有类型的工作负载进行最佳处理。THP 可能会导致性能下降，因为许多应用程序都自行处理巨页。因此，请考虑禁用 THP。以下步骤描述了如何使用 Node Tuning Operator (NTO)禁用 THP。

流程

  1. 使用以下内容创建文件，并将其命名为 thp-disable-tuned.yaml ： 

    apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: thp-workers-profile
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
  - data: |
      [main]
      summary=Custom tuned profile for OpenShift to turn off THP on worker nodes
      include=openshift-node

      [vm]
      transparent_hugepages=never
    name: openshift-thp-never-worker

  recommend:
  - match:
    - label: node-role.kubernetes.io/worker
    priority: 25
    profile: openshift-thp-never-worker

  2. 创建 Tuned 对象： 

    $ oc create -f thp-disable-tuned.yaml

  3. 检查活跃配置集列表： 

    $ oc get profile -n openshift-cluster-node-tuning-operator

验证

  • 登录到其中一个节点，并执行常规 THP 检查来验证节点是否成功应用了配置集： 

    $ cat /sys/kernel/mm/transparent_hugepage/enabled

    输出示例

    always madvise [never]

第 14 章 低延迟节点的 Performance Addon Operator

14.1. 了解低延迟

在 Telco / 5G 领域，Edge 计算对于减少延迟和拥塞问题，以及提高应用程序性能方面扮演了关键角色。

简单地说，延迟决定了数据（packets）从发送方到接收方的速度，以及在接收方处理后返回到发送方的速度。显然，维护一个最低延迟速度的网络构架是满足 5G 的网络性能要求的关键。对于 4G 技术，它的平均延迟为 50ms，与之相比，5G 的目标是达到 1ms 或更少的延迟。这个对延迟的降低会将无线网络的吞吐量提高 10 倍。

很多在 Telco 空间部署的应用程序都需要低延迟，它们只能容忍零数据包丢失。针对零数据包丢失进行调节有助于缓解降低网络性能的固有问题。如需更多信息，请参阅 Red Hat OpenStack Platform(RHOSP)中的 Zero Packet Los 调节。

Edge 计算也可用于降低延迟率。它位于云的边缘，并且更接近用户。这可大大减少用户和远程数据中心之间的距离，从而减少应用程序响应时间和性能延迟。

管理员必须能够集中管理多个 Edge 站点和本地服务，以便所有部署都可以以最低的管理成本运行。它们还需要一个简便的方法来部署和配置其集群的某些节点，以实现实时低延迟和高性能目的。低延迟节点对于如 Cloud-native Network Functions（CNF）和 Data Plane Development Kit（DPDK） 等应用程序非常有用。

OpenShift Container Platform 目前提供在 OpenShift Container Platform 集群上调整软件的机制，以获取实时运行和低延迟时间（响应时间小于 20 微秒）。这包括调整内核和 OpenShift Container Platform 设置值、安装内核和重新配置机器。但是这个方法需要设置四个不同的 Operator，并执行很多配置，这些配置在手动完成时比较复杂，并容易出错。

OpenShift Container Platform 提供了一个 Performance Addon Operator 来实现自动性能优化，从而实现 OpenShift 应用程序的低延迟性能。集群管理员使用此性能配置集配置，这有助于以更可靠的方式进行更改。管理员可以指定是否要将内核更新至 kernel-rt，为集群和操作系统日常任务保留 CPU（包括 pod infra 容器），以及隔离 CPU，以便应用程序容器运行工作负载。

14.1.1. 关于低延迟和实时应用程序超线程

超线程是一个 Intel 处理器技术，它允许物理 CPU 处理器内核作为两个逻辑内核同时执行两个独立的线程。超线程可以为并行处理很有用的某些工作负载类型的系统吞吐量提供更好的系统吞吐量。默认的 OpenShift Container Platform 配置需要默认启用超线程。

对于电信领域的应用程序，设计您的应用程序架构非常重要，以尽量减小延迟。超线程会降低性能，并严重影响需要低延迟的计算负载的吞吐量。禁用超线程可确保性能的可预测性，并可减少这些工作负载的处理时间。

注意

超线程实现和配置会因运行 OpenShift Container Platform 的硬件而异。如需了解特定于该硬件的超线程实现的更多详情，请参考相关的主机硬件调节信息。禁用超线程可以增加集群的每个内核的成本。

其他资源

14.2. 安装 Performance Addon Operator

Performance Addon Operator 提供了在一组节点上启用高级节点性能调整的功能。作为集群管理员，您可以使用 OpenShift Container Platform CLI 或 Web 控制台安装 Performance Addon Operator。

14.2.1. 使用 CLI 安装 Operator

作为集群管理员，您可以使用 CLI 安装 Operator。

先决条件

  • 在裸机硬件上安装的集群。
  • 安装 OpenShift CLI（oc）。
  • 以具有 cluster-admin 特权的用户身份登录。

流程

  1. 通过完成以下操作，为 Performance Addon Operator 创建命名空间：

    1. 创建用于定义 openshift-performance-addon-operator 命名空间的以下 Namespace 自定义资源（CR），然后在 pao-namespace.yaml 文件中保存 YAML： 

      apiVersion: v1
kind: Namespace
metadata:
  name: openshift-performance-addon-operator
  annotations:
    workload.openshift.io/allowed: management

    2. 运行以下命令创建命名空间： 

      $ oc create -f pao-namespace.yaml

  2. 通过创建以下对象，在您上一步创建的命名空间中安装 Performance Addon Operator:

    1. 创建以下 OperatorGroup CR，并在 pao-operatorgroup.yaml 文件中保存 YAML: 

      apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: openshift-performance-addon-operator
  namespace: openshift-performance-addon-operator

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

      $ oc create -f pao-operatorgroup.yaml

    3. 运行以下命令获取下一步所需的 channel 值。 

      $ oc get packagemanifest performance-addon-operator -n openshift-marketplace -o jsonpath='{.status.defaultChannel}'

      输出示例

      4.10

    4. 创建以下订阅 CR，并将 YAML 保存到 pao-sub.yaml 文件中：

      订阅示例

      apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: openshift-performance-addon-operator-subscription
  namespace: openshift-performance-addon-operator
spec:
  channel: "<channel>" 1
  name: performance-addon-operator
  source: redhat-operators 2
  sourceNamespace: openshift-marketplace

      1
      使用在前一步中获得的值指定 .status.defaultChannel 参数。
      2
      您必须指定 redhat-operators 值。

    5. 运行以下命令创建订阅对象： 

      $ oc create -f pao-sub.yaml

    6. 进入 openshift-performance-addon-operator 项目： 

      $ oc project openshift-performance-addon-operator

14.2.2. 使用 Web 控制台安装 Performance Addon Operator

作为集群管理员，您可以使用 web 控制台安装 Performance Addon Operator。

注意

如上一节所述，您必须创建 Namespace CR 和 OperatorGroup CR。

流程

  1. 使用 OpenShift Container Platform Web 控制台安装 Performance Addon Operator:

    1. 在 OpenShift Container Platform Web 控制台中，点击 Operators → OperatorHub。
    2. 从可用的 Operator 列表中选择 Performance Addon Operator，然后点 Install。
    3. 在 Install Operator 页面中，选择 All namespaces on the cluster。然后点击 Install。

  2. 可选：验证 performance-addon-operator 是否已成功安装：

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

    2. 确保 openshift-operators 项目中列出的 Performance Addon Operator 的 Status 为 Succeeded。

      注意

      在安装过程中，Operator 可能会显示 Failed 状态。如果后续安装成功并显示 Succeeded 信息，您可以忽略 Failed 信息。

      如果 Operator 没有被安装，您可以进一步排除故障：

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

14.3. 升级 Performance Addon Operator

您可以手动升级到 Performance Addon Operator 的下一个次版本，并使用 web 控制台监控更新的状态。

14.3.1. 关于升级 Performance Addon Operator

  • 您可以使用 OpenShift Container Platform web 控制台更改 Operator 订阅的频道把 Performance Addon Operator 升级到下一个次要版本。
  • 您可在安装 Performance Addon Operator 的过程中启用自动 z-stream 更新功能。
  • 更新通过 Marketplace Operator 实现，该 Operator 会在 OpenShift Container Platform 安装过程中部署。Marketplace Operator 使外部 Operator 可供集群使用。
  • 更新完成所需时间取决于您的网络连接情况。大部分自动更新可在十五分钟内完成。

14.3.1.1. Performance Addon Operator 升级对您的集群有什么影响

  • 低延迟性能和巨页均不会受到影响。
  • 更新 Operator 应该不会造成任何意外重启。

14.3.1.2. 将 Performance Addon Operator 升级到下一个次版本

您可以使用 OpenShift Container Platform Web 控制台修改 Operator 订阅的频道，将 Performance Addon Operator 手动升级到下一个次版本 。

先决条件

  • 使用具有 cluster-admin 角色的用户访问集群。

流程

  1. 访问 Web 控制台，进入 Operators → Installed Operators。
  2. 点击Performance Addon Operator 打开 Operator Details 页面。
  3. 单击 Subscription 选项卡，以打开 Subscription 详情页面。
  4. 在 Update 频道窗格中，点击版本号右侧的铅笔图标打开 Change Subscription 更新频道窗口。
  5. 选择下一个次要版本。例如，如果要升级到 Performance Addon Operator 4.10，请选择 4.10。
  6. 点击 Save。

  7. 通过导航到 Operators → Installed Operators 来检查升级的状态。您还可以通过运行以下 oc 命令来检查状态： 

    $ oc get csv -n openshift-performance-addon-operator

14.3.1.3. 当以前安装到特定命名空间时，升级 Performance Addon Operator

如果您之前已将 Performance Addon Operator 安装到集群中的特定命名空间中，如 openshift-performance-addon-operator，修改 OperatorGroup 对象以在升级前删除 targetNamespaces 条目。

先决条件

  • 安装 OpenShift Container Platform CLI（oc）。
  • 以具有 cluster-admin 权限的用户身份登录 OpenShift 集群。

流程

  1. 运行以下命令，编辑 Performance Addon Operator OperatorGroup CR 并删除包含 targetNamespaces 条目的 spec 元素： 

    $ oc patch operatorgroup -n openshift-performance-addon-operator openshift-performance-addon-operator --type json -p '[{ "op": "remove", "path": "/spec" }]'
  2. 等待 Operator Lifecycle Manager（OLM）处理更改。

  3. 验证 OperatorGroup CR 更改是否已成功应用。检查 OperatorGroup CR spec 元素是否已删除： 

    $ oc describe -n openshift-performance-addon-operator og openshift-performance-addon-operator
  4. 执行 Performance Addon Operator 升级。

14.3.2. 监控升级状态

监控 Performance Addon Operator 升级状态的最佳方法是查看 ClusterServiceVersion（CSV） PHASE。您还可以在 web 控制台中或通过运行 oc get csv 命令来监控 CSV 状况。

注意

PHASE 和状况值均是基于可用信息的近似值。

先决条件

  • 使用具有 cluster-admin 角色的用户访问集群。
  • 安装 OpenShift CLI（oc）。

流程

  1. 运行以下命令： 

    $ oc get csv

  2. 查看输出，检查 PHASE 字段。例如： 

    VERSION    REPLACES                                         PHASE
4.10.0      performance-addon-operator.v4.10.0                Installing
4.8.0                                                       Replacing

  3. 再次运行 get csv 以验证输出： 

    # oc get csv

    输出示例

    NAME                                DISPLAY                      VERSION   REPLACES                            PHASE
performance-addon-operator.v4.10.0   Performance Addon Operator   4.10.0     performance-addon-operator.v4.8.0   Succeeded

14.4. 置备实时和低延迟工作负载

很多行业和机构需要非常高的计算性能，并需要低且可预测的延迟，特别是银行和电信业。对于这些行业，它们有其特殊的要求，OpenShift Container Platform 提供了一个 Performance Addon Operator 来实现自动调整，以便为 OpenShift Container Platform 应用程序实现低延迟性能和响应时间。

集群管理员可以使用此性能配置集配置以更可靠的方式进行这些更改。管理员可以指定是否将内核更新至 kernel-rt（实时），为集群和操作系统日常任务保留 CPU（包括 pod infra 容器），以及隔离 CPU，以便应用程序容器运行工作负载。

警告

将执行探测与需要保证 CPU 的应用配合使用可能会导致延迟激增。建议使用其他探测（如正确配置的一组网络探测作为替代方案）。

14.4.1. 已知的实时限制

注意

在大多数部署中，只有使用具有三个 control plane 节点和三个 worker 节点的标准集群时，仅在 worker 节点上支持 kernel-rt。OpenShift Container Platform 部署中的紧凑和单一节点会有例外。对于在单一节点上的安装， kernel-rt 在单个 control plane 节点上被支持。

要充分利用实时模式，容器必须使用升级的权限运行。如需了解有关授予特权的信息，请参阅为容器设置能力。

OpenShift Container Platform 会限制允许的功能，因此您可能需要创建 SecurityContext。

注意

使用 Red Hat Enterprise Linux CoreOS（RHCOS）系统的裸机安装完全支持此步骤。

在确定正确的性能预期时，应该意识到实时内核并不是万能的。它的目的是提供一个持续的、低延迟的确定性机制，从而提供可预测的响应时间。在系统中，会存在与实时内核关联的额外内核开销。这是因为在单独调度的线程中处理硬件中断。某些增加的工作负载开销会导致整个吞吐量下降。实际的影响依赖于特定的负载，范围从 0% 到 30%。然而，这是获得确定性所需要付出的代价。

14.4.2. 使用实时功能置备 worker

  1. 在集群上安装 Performance Addon Operator。
  2. 可选：在 OpenShift Container Platform 集群中添加节点。请参阅设置 BIOS 参数。
  3. 使用 oc 命令将标签 worker-rt 添加到需要实时功能的 worker 节点。

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

    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。

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

    注意

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

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

  7. 您必须在 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

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

    $ oc describe mcp/worker-rt

    输出示例

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

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

14.4.3. 验证实时内核安装

使用这个命令确定安装了实时内核： 

$ oc get node -o wide

记录带有角色 worker-rt 的 worker，其中包含字符串 4.18.0-305.30.1.rt7.102.el8_4.x86_64 cri-o://1.23.0-99.rhaos4.10.gitc3131de.el8 ： 

NAME                               	STATUS   ROLES           	AGE 	VERSION                  	INTERNAL-IP
EXTERNAL-IP   OS-IMAGE                                       	KERNEL-VERSION
CONTAINER-RUNTIME
rt-worker-0.example.com	          Ready	 worker,worker-rt   5d17h   v1.23.0
128.66.135.107   <none>    	        Red Hat Enterprise Linux CoreOS 46.82.202008252340-0 (Ootpa)
4.18.0-305.30.1.rt7.102.el8_4.x86_64   cri-o://1.23.0-99.rhaos4.10.gitc3131de.el8
[...]

14.4.4. 创建一个实时工作负载

使用以下步骤准备一个使用实时功能的工作负载。

流程

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

在编写应用程序时，请遵循应用程序调整和部署中的常规建议。

14.4.5. 创建带有 Guaranteed 类 QoS 类的 pod

在创建带有 Guaranteed 类的 QoS 类的 pod 时请注意以下几点：

  • pod 中的每个容器都必须具有内存限制和内存请求，且它们必须相同。
  • pod 中的每个容器都必须具有 CPU 限制和 CPU 请求，且它们必须相同。

以下示例显示了一个容器的 pod 的配置文件。容器设置了内存限制和内存请求，均为 200 MiB。容器具有 CPU 限制和 CPU 请求，均为 1 CPU。 

apiVersion: v1
kind: Pod
metadata:
  name: qos-demo
  namespace: qos-example
spec:
  containers:
  - name: qos-demo-ctr
    image: <image-pull-spec>
    resources:
      limits:
        memory: "200Mi"
        cpu: "1"
      requests:
        memory: "200Mi"
        cpu: "1"

  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 请求。

14.4.6. 可选：禁用 DPDK 的 CPU 负载均衡

禁用或启用 CPU 负载均衡的功能在 CRI-O 级别实现。CRI-O 下的代码仅在满足以下要求时禁用或启用 CPU 负载均衡。

  • pod 必须使用 performance-<profile-name> 运行时类。您可以通过查看性能配置集的状态来获得正确的名称，如下所示： 

    apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
...
status:
  ...
  runtimeClass: performance-manual
  • pod 必须具有 cpu-load-balancing.crio.io: true 注解。

Performance Addon Operator 负责在相关节点下创建高性能运行时处理器配置片断，并在集群下创建高性能运行时类。它具有与默认运行时处理相同的内容，但它启用了 CPU 负载均衡配置功能。

要禁用 pod 的 CPU 负载均衡，Pod 规格必须包括以下字段： 

apiVersion: v1
kind: Pod
metadata:
  ...
  annotations:
    ...
    cpu-load-balancing.crio.io: "disable"
    ...
  ...
spec:
  ...
  runtimeClassName: performance-<profile_name>
  ...
注意

仅在启用了 CPU 管理器静态策略，以及带有保证 QoS 使用整个 CPU 的 pod 时，禁用 CPU 负载均衡。否则，禁用 CPU 负载均衡会影响集群中其他容器的性能。

14.4.7. 分配适当的节点选择器

为节点分配 pod 的首选方法是使用与性能配置集相同的节点选择器，如下所示： 

apiVersion: v1
kind: Pod
metadata:
  name: example
spec:
  # ...
  nodeSelector:
    node-role.kubernetes.io/worker-rt: ""

如需更多信息，请参阅使用节点选择器将 pod 放置到特定的节点上。

14.4.8. 将工作负载调度到具有实时功能的 worker

使用与附加到机器配置的节点匹配的标签选择器，这些选择器是为低延迟配置的。如需更多信息，请参阅将 pod 分配给节点。

14.4.9. 管理设备中断处理保证 pod 隔离 CPU

Performance Addon Operator 可以通过将主机 CPU 划分为保留的 CPU 来管理主机 CPU，以进行集群和操作系统日常任务（包括 pod infra 容器），以及用于应用程序容器运行工作负载的隔离 CPU。这可让您将低延迟工作负载的 CPU 设置为隔离状态。

设备中断在所有隔离和保留 CPU 之间平衡负载，以避免出现 CPU 超载问题，但运行有保证 pod 的 CPU 除外。当为 pod 设置相关注解时，保证 pod CPU 无法处理设备中断。

在性能配置集中，globallyDisableIrqLoadBalancing 用于管理设备中断是否被处理。对于某些工作负载，保留 CPU 并不总是足以处理设备中断，因此不会在隔离的 CPU 上禁用设备中断。默认情况下，Performance Addon Operator 不会禁用隔离 CPU 上的设备中断。

要实现低延迟，有些（而非全部）pod 需要它们运行的 CPU 不处理设备中断。pod 注解 irq-load-balancing.crio.io 用于定义是否处理设备中断。配置后，CRI-O 仅在 pod 正在运行时禁用设备中断。

14.4.9.1. 禁用 CPU CFS 配额

要减少单独保证 pod 的 CPU 节流，创建一个带有注解 cpu-quota.crio.io: "disable" 的 pod 规格。此注释在 pod 运行时禁用 CPU 完全公平调度程序(CFS)配额。以下 pod 规格包含此注解： 

apiVersion: performance.openshift.io/v2
kind: Pod
metadata:
  annotations:
      cpu-quota.crio.io: "disable"
spec:
    runtimeClassName: performance-<profile_name>
...
注意

仅在启用了 CPU 管理器静态策略，以及带有保证 QoS 使用整个 CPU 的 pod 时禁用 CPU CFS 配额。否则，禁用 CPU CFS 配额可能会影响集群中其他容器的性能。

14.4.9.2. 禁用 Performance Addon Operator 中的全局设备中断处理

要将 Performance Addon Operator 配置为禁用隔离 CPU 集的全局设备中断，将 performance 配置集中的 globallyDisableIrqLoadBalancing 字段设置为 true。在为 true 时，会忽略有冲突的 pod 注解。在为 false 时，IRQ 负载会在所有 CPU 之间平衡。

一个性能配置集片段演示了这个设置： 

apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
  name: manual
spec:
  globallyDisableIrqLoadBalancing: true
...

14.4.9.3. 禁用单个 pod 的中断处理

要禁用单个 pod 的中断处理，确保在性能配置集中将 globallyDisableIrqLoadBalancing 设置为 false。然后，在 pod 规格中，将 irq-load-balancing.crio.io pod 注解设置为 disable。以下 pod 规格包含此注解： 

apiVersion: performance.openshift.io/v2
kind: Pod
metadata:
  annotations:
      irq-load-balancing.crio.io: "disable"
spec:
    runtimeClassName: performance-<profile_name>
...

14.4.10. 升级性能配置集以使用设备中断处理

当您将 Performance Addon Operator 性能配置集自定义资源定义（CRD）从 v1 或 v1alpha1 升级到 v2 时，现有配置集会将 globallyDisableIrqLoadBalancing 设置为 true。

注意

globallyDisableIrqLoadBalancing 切换用于 Isolated CPU 集是否禁用了 IRQ 负载均衡。当选项设置为 true 时，它会禁用 Isolated CPU 集的 IRQ 负载均衡。将选项设置为 false 允许在所有 CPU 之间平衡 IRQ。

14.4.10.1. 支持的 API 版本

Performance Addon Operator 在性能配置集 apiVersion 字段中支持 v2、v1 和 v1alpha1。v1 和 v1alpha1 API 相同。v2 API 包括一个可选的布尔值项 globallyDisableIrqLoadBalancing，默认值为 false。

14.4.10.1.1. 将 Performance Addon Operator API 从 v1alpha1 升级到 v1

当将 Performance Addon Operator API 版本从 v1alpha1 升级到 v1 时,，v1alpha1 性能配置集会通过"None" Conversion 策略自行转换，并提供给带有 API 版本 v1 的 Performance Addon Operator。

14.4.10.1.2. 将 Performance Addon Operator API 从 v1alpha1 或 v1 升级到 v2

当从旧的 Performance Addon Operator API 版本升级时，现有的 v1 和 v1alpha1 性能配置集将使用转换 Webhook 转换，它将注入 globallyDisableIrqLoadBalancing 字段，值为 true。

14.4.11. 为 IRQ 动态负载平衡配置节点

要将集群节点配置为处理 IRQ 动态负载平衡，请执行以下操作：

  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.10"
    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. 确保正确应用节点配置。SSH 到节点以验证配置。 

    $ 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

一些 IRQ 控制器不支持 IRQ 重新平衡，并将始终将所有在线 CPU 公开为 IRQ 掩码。这些 IRQ 控制器在 CPU 0 上运行。如需了解主机配置的更多信息，请 SSH 到主机并运行以下命令，将 <irq-num> 替换为您要查询的 CPU 号码： 

$ cat /proc/irq/<irq-num>/effective_affinity

14.4.12. 为集群配置超线程

要为 OpenShift Container Platform 集群配置超线程，请将性能配置集中的 CPU 线程设置为为保留或隔离的 CPU 池配置的相同内核。

注意

如果您配置了性能配置集，然后更改主机的超线程配置，请确保更新 PerformanceProfile YAML 中的 CPU isolated 和 reserved字段以匹配新配置。

警告

禁用之前启用的主机超线程配置可能会导致 PerformanceProfile YAML 中列出的 CPU 内核 ID 错误。此不正确的配置可能会导致节点不可用，因为无法找到列出的 CPU。

先决条件

  • 使用具有 cluster-admin 角色的用户访问集群。
  • 安装 OpenShift CLI（oc）。

流程

  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 节点中的所有可用内核。

重要

大多数 Intel 处理器上默认启用超线程。如果启用超线程，特定内核处理的所有线程都必须被隔离或者在同一个内核中处理。

14.4.12.1. 禁用低延迟应用程序超线程

在为低延迟进程配置集群时，请考虑是否要在部署集群前禁用超线程。要禁用超线程，请执行以下操作：

  1. 创建一个适合您的硬件和拓扑的性能配置集。

  2. 将 nosmt 设为附加内核参数。以下示例的性能配置集演示了此设置： 

    apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
  name: example-performanceprofile
spec:
  additionalKernelArgs:
    - nmi_watchdog=0
    - audit=0
    - mce=off
    - processor.max_cstate=1
    - idle=poll
    - intel_idle.max_cstate=0
    - nosmt
  cpu:
    isolated: 2-3
    reserved: 0-1
  hugepages:
    defaultHugepagesSize: 1G
    pages:
      - count: 2
        node: 0
        size: 1G
  nodeSelector:
    node-role.kubernetes.io/performance: ''
  realTimeKernel:
    enabled: true
    注意

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

14.5. 使用性能配置集调整节点以实现低延迟

性能配置集可让您控制属于特定机器配置池的节点的延迟调整方面。指定设置后，PerformanceProfile 对象将编译为执行实际节点级别调整的多个对象：

  • 操作节点的 MachineConfig 文件。
  • 用于配置拓扑管理器、CPU Manager 和 OpenShift Container Platform 节点的 KubeletConfig 文件。
  • 配置 Node Tuning Operator 的 Tuned 配置集。

您可以使用性能配置集指定是否将内核更新至 kernel-rt，分配大页面，以及划分 CPU 以执行内务处理或运行工作负载。

注意

您可以手动创建 PerformanceProfile 对象，或使用 Performance Profile Creator (PPC) 生成性能配置集。有关 PPC 的更多信息，请参见以下的其他资源。

性能配置集示例

apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
 name: performance
spec:
 cpu:
  isolated: "4-15" 1
  reserved: "0-3" 2
 hugepages:
  defaultHugepagesSize: "1G"
  pages:
  - size: "1G"
    count: 16
    node: 0
 realTimeKernel:
  enabled: true  3
 numa:  4
  topologyPolicy: "best-effort"
 nodeSelector:
  node-role.kubernetes.io/worker-cnf: "" 5

1
使用此字段隔离要用于工作负载的应用容器的特定 CPU。设置一个偶数的隔离 CPU 数量，以便在启用超线程时运行 pod 不会出现错误。
2
使用此字段保留要用于 infra 容器进行内务的特定 CPU。
3
使用此字段在节点上安装实时内核。有效值为 true 或者 false。设置 true 值将安装实时内核。
4
使用此字段配置拓扑管理器策略。有效值为 none （默认）、best-effort、restricted 和 single-numa-node。如需更多信息，请参阅拓扑管理器策略。
5
使用此字段指定节点选择器，将性能配置集应用到特定的节点。

其他资源

  • 有关使用 Performance Profile Creator (PPC) 生成性能配置集的详情，请参考创建性能配置集。

14.5.1. 配置巨页

节点必须预先分配在 OpenShift Container Platform 集群中使用的巨页。使用 Performance Addon Operator 在指定节点上分配巨页。

OpenShift Container Platform 提供了创建和分配巨页的方法。Performance Addon Operator 提供了一种更易于使用性能配置集的方法。

例如，在性能配置集的 hugepages pages 部分，您可以指定多个块的 size、count 以及可选的 node: 

hugepages:
   defaultHugepagesSize: "1G"
   pages:
   - size:  "1G"
     count:  4
     node:  0 1
1
node 是分配巨页的 NUMA 节点。如果省略了 node，该页面将平均分布在所有 NUMA 节点中。
注意

等待显示更新已完成的相关机器配置池状态。

这些是分配巨页的唯一配置步骤。

验证

  • 要验证配置，请查看节点上的 /proc/meminfo 文件： 

    $ oc debug node/ip-10-0-141-105.ec2.internal
    # grep -i huge /proc/meminfo

    输出示例

    AnonHugePages:    ###### ##
ShmemHugePages:        0 kB
HugePages_Total:       2
HugePages_Free:        2
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       #### ##
Hugetlb:            #### ##

  • 使用 oc describe 报告新大小： 

    $ oc describe node worker-0.ocp4poc.example.com | grep -i huge

    输出示例

                                       hugepages-1g=true
 hugepages-###:  ###
 hugepages-###:  ###

14.5.2. 分配多个巨页大小

您可以在同一容器下请求具有不同大小的巨页。这样，您可以定义由具有不同巨页大小的容器组成的更复杂的 pod。

例如，您可以把大小定义为 1G 和 2M，Performance Addon Operator 会在节点上配置这两个大小，如下所示： 

spec:
  hugepages:
    defaultHugepagesSize: 1G
    pages:
    - count: 1024
      node: 0
      size: 2M
    - count: 4
      node: 1
      size: 1G

14.5.3. 为 infra 和应用程序容器限制 CPU

通用内务处理和工作负载任务使用 CPU 的方式可能会影响对延迟敏感的进程。默认情况下，容器运行时使用所有在线 CPU 一起运行所有容器，这可能导致上下文切换和延迟激增。对 CPU 进行分区可防止无状态进程通过相互分离来干扰对延迟敏感的进程。下表描述了在使用 Performance Add-On Operator 调整节点后在 CPU 上运行的进程：

表 14.1. 进程的 CPU 分配

进程类型详情

Burstable 和 BestEffort pod

在除了运行低延迟工作负载外的任意 CPU 上运行

基础架构 pod

在除了运行低延迟工作负载外的任意 CPU 上运行

中断

重定向到保留的 CPU（OpenShift Container Platform 4.7 及更新的版本中的可选）

内核进程

固定保留的 CPU

对延迟敏感的工作负载 pod

固定到隔离池中的特定专用 CPU

OS 进程/systemd 服务

固定保留的 CPU

在一个节点上的对于所有 QoS 进程类型（ Burstable、BestEffort 或 Guaranteed ）的 pod 的可分配容量等于隔离池的容量。保留池的容量已从节点的总内核容量中删除，供集群和操作系统日常任务使用。

示例 1

节点具有 100 个内核的容量。通过使用性能配置集，集群管理员将 50 个内核分配给隔离池，将 50 个内核分配给保留池。集群管理员为 QoS 为 BestEffort 或 Burstable 的 pod 分配 25 个内核，为 Guaranteed 的 pod 分配 25 个内核。这与隔离池的容量匹配。

示例 2

节点具有 100 个内核的容量。通过使用性能配置集，集群管理员将 50 个内核分配给隔离池，将 50 个内核分配给保留池。集群管理员为 QoS 为 BestEffort 或 Burstable 的 pod 分配一个内核，为 Guaranteed 的 pod 分配 50 个内核。这超过了隔离池容量一个内核。Pod 调度因为 CPU 容量不足而失败。

使用的确切分区模式取决于许多因素，如硬件、工作负载特性和预期的系统负载。以下是一些用例示例：

  • 如果对延迟敏感的工作负载使用特定的硬件，如网络接口控制器(NIC)，请确保隔离池中的 CPU 尽可能地与这个硬件接近。至少，您应该将工作负载放在同一个非统一内存访问 (NUMA) 节点中。
  • 保留的池用于处理所有中断。根据系统网络，分配一个足够大小的保留池来处理所有传入的数据包中断。在 4.10 及更新的版本中，工作负载可以被标记为敏感。

在决定哪些特定 CPU 用于保留和隔离分区时，需要详细分析和测量。设备和内存的 NUMA 紧密度等因素扮演了角色。选择也取决于工作负载架构和具体的用例。

重要

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

为确保内务处理任务和工作负载不会相互干扰，请在性能配置集的 spec 部分指定两组 CPU。

  • isolated - 指定应用程序容器工作负载的 CPU。这些 CPU 的延迟最低。这个组中的进程没有中断，例如，可以达到更高的 DPDK 零数据包丢失带宽。
  • reserved - 为集群和操作系统日常任务指定 CPU。reserved 组中的线程经常会比较繁忙。不要在 reserved 组中运行对延迟敏感的应用程序。对延迟敏感的应用程序在 isolated 组中运行。

流程

  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
    可选：指定一个节点选择器，以将性能配置集应用到特定的节点。

其他资源

14.6. 使用 Performance Addon Operator 减少 NIC 队列

Performance Addon Operator 允许您通过配置性能配置集来调整每个网络设备的网络接口控制器 (NIC) 队列计数。设备网络队列允许在不同物理队列之间分布数据包，每个队列获得用于数据包处理的独立线程。

在实时或低延迟系统中，固定到隔离 CPU 的所有不必要的中断请求行（IRQ）必须移到保留或日常 CPU。

在部署需要系统、OpenShift Container Platform 网络或使用 Data Plane Development Kit（DPDK）工作负载的混合部署中，需要多个队列才能实现良好的吞吐量，并且 NIC 队列的数量应该会调整或保持不变。例如，为了实现低延迟，应该将基于 DPDK 的工作负载的 NIC 队列数量减少到仅保留或日常 CPU 的数量。

默认情况下，每个 CPU 会创建太多的队列，在为低延迟调优时，这些队列不适用于托管 CPU 的中断表中。减少队列数量可以进行正确的调优。数量较小的队列意味着在 IRQ 表中包括较少数量的中断。

14.6.1. 使用性能配置集调整 NIC 队列

通过性能配置集，您可以调整每个网络设备的队列计数。

支持的网络设备：

  • 非虚拟网络设备
  • 支持多个队列的网络设备（通道）

不支持的网络设备：

  • 纯软件网络接口
  • 块设备
  • Intel DPDK 虚拟功能

先决条件

  • 使用具有 cluster-admin 角色的用户访问集群。
  • 安装 OpenShift CLI（oc）。

流程

  1. 以具有 cluster-admin 权限的用户身份登录运行 Performance Addon 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,54-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,54-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,54-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,54-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,54-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

其他资源

14.6.2. 验证队列状态

在这一部分中，一些示例演示了不同的性能配置集以及如何验证是否应用了更改。

示例 1

在本例中，网络队列数为所有支持的设备设置为保留 CPU 数（2）。

性能配置集中的相关部分是： 

apiVersion: performance.openshift.io/v2
metadata:
  name: performance
spec:
  kind: PerformanceProfile
  spec:
    cpu:
      reserved: 0-1  #total = 2
      isolated: 2-8
    net:
      userLevelNetworking: true
# ...

  • 使用以下命令显示与设备关联的队列状态：

    注意

    在应用了性能配置集的节点中运行这个命令。 

    $ ethtool -l <device>

  • 在应用配置集前验证队列状态： 

    $ ethtool -l ens4

    输出示例

    Channel parameters for ens4:
Pre-set maximums:
RX:         0
TX:         0
Other:      0
Combined:   4
Current hardware settings:
RX:         0
TX:         0
Other:      0
Combined:   4

  • 应用配置集后验证队列状态： 

    $ ethtool -l ens4

    输出示例

    Channel parameters for ens4:
Pre-set maximums:
RX:         0
TX:         0
Other:      0
Combined:   4
Current hardware settings:
RX:         0
TX:         0
Other:      0
Combined:   2 1

1
该组合通道显示为所有支持的设备保留 CPU 的总数为 2。这与性能配置集中配置的内容匹配。

示例 2

在本例中，针对具有特定 vendorID 的所有受支持的网络设备，网络队列数设置为保留 CPU 数（2）。

性能配置集中的相关部分是： 

apiVersion: performance.openshift.io/v2
metadata:
  name: performance
spec:
  kind: PerformanceProfile
  spec:
    cpu:
      reserved: 0-1  #total = 2
      isolated: 2-8
    net:
      userLevelNetworking: true
      devices:
      - vendorID = 0x1af4
# ...

  • 使用以下命令显示与设备关联的队列状态：

    注意

    在应用了性能配置集的节点中运行这个命令。 

    $ ethtool -l <device>

  • 应用配置集后验证队列状态： 

    $ ethtool -l ens4

    输出示例

    Channel parameters for ens4:
Pre-set maximums:
RX:         0
TX:         0
Other:      0
Combined:   4
Current hardware settings:
RX:         0
TX:         0
Other:      0
Combined:   2 1

1
带有 vendorID=0x1af4 的所有支持设备的预留 CPU 总数为 2。例如，如果存在另一个网络设备 ens2，其 vendorID=0x1af4 也具有总计的网络队列为 2。这与性能配置集中配置的内容匹配。

示例 3

在本例中，针对与任何定义的设备标识符匹配的所有受支持网络设备，网络队列数设置为保留 CPU 数（2）。

命令 udevadm info 提供了有关设备的详细报告。在这个示例中，设备是： 

# udevadm info -p /sys/class/net/ens4
...
E: ID_MODEL_ID=0x1000
E: ID_VENDOR_ID=0x1af4
E: INTERFACE=ens4
...
# udevadm info -p /sys/class/net/eth0
...
E: ID_MODEL_ID=0x1002
E: ID_VENDOR_ID=0x1001
E: INTERFACE=eth0
...

  • 对于 interfaceName 等于 eth0 的设备，以及具有 vendorID=0x1af4 的设备，并使用以下性能配置集，将网络队列设置为 2： 

    apiVersion: performance.openshift.io/v2
metadata:
  name: performance
spec:
  kind: PerformanceProfile
    spec:
      cpu:
        reserved: 0-1  #total = 2
        isolated: 2-8
      net:
        userLevelNetworking: true
        devices:
        - interfaceName = eth0
        - vendorID = 0x1af4
...

  • 应用配置集后验证队列状态： 

    $ ethtool -l ens4

    输出示例

    Channel parameters for ens4:
Pre-set maximums:
RX:         0
TX:         0
Other:      0
Combined:   4
Current hardware settings:
RX:         0
TX:         0
Other:      0
Combined:   2 1

    1
    带有 vendorID=0x1af4 的所有支持设备的预留 CPU 总数设置为 2。例如，如果存在另一个带有 vendorID=0x1af4 的网络设备 ens2，则其总子网队列也将设置为 2。类似地，interfaceName 等于 eth0 的设备会将总网络队列设置为 2。

14.6.3. 与调整 NIC 队列关联的日志记录

详细说明所分配设备的日志消息记录在相应的 Tuned 守护进程日志中。以下信息可能会记录到 /var/log/tuned/tuned.log 文件中：

  • 记录了一个 INFO 信息，详细描述了成功分配的设备： 

    INFO tuned.plugins.base: instance net_test (net): assigning devices ens1, ens2, ens3

  • 如果无法分配任何设备，则会记录 WARNING 信息： 

    WARNING  tuned.plugins.base: instance net_test: no matching devices available

14.7. 调试低延迟 CNF 调整状态

PerformanceProfile 自定义资源（CR）包含报告调整状态和调试延迟降级问题的状态字段。这些字段报告描述 Operator 协调功能状态的条件。

当附加到性能配置集的机器配置池处于降级状态时会出现一个典型的问题，从而导致 PerformanceProfile 状态降级。在这种情况下，机器配置池会给出一个失败信息。

Performance Addon Operator 包含 performanceProfile.spec.status.Conditions status 字段： 

Status:
  Conditions:
    Last Heartbeat Time:   2020-06-02T10:01:24Z
    Last Transition Time:  2020-06-02T10:01:24Z
    Status:                True
    Type:                  Available
    Last Heartbeat Time:   2020-06-02T10:01:24Z
    Last Transition Time:  2020-06-02T10:01:24Z
    Status:                True
    Type:                  Upgradeable
    Last Heartbeat Time:   2020-06-02T10:01:24Z
    Last Transition Time:  2020-06-02T10:01:24Z
    Status:                False
    Type:                  Progressing
    Last Heartbeat Time:   2020-06-02T10:01:24Z
    Last Transition Time:  2020-06-02T10:01:24Z
    Status:                False
    Type:                  Degraded

Status 字段包含指定 Type 值来指示性能配置集状态的 Conditions：

Available
所有机器配置和 Tuned 配置集都已被成功创建，且集群组件可用于处理它们（NTO、MCO、Kubelet）。
Upgradeable
代表 Operator 维护的资源是否处于可安全升级的状态。
Progressing
表示已从性能配置集启动部署过程。
Degraded

如果出现以下情况代表错误：

  • 验证性能配置集失败。
  • 创建所有相关组件未能成功完成。

每个类型都包括以下字段：

状态
特定类型的状态（true 或 false）。
Timestamp
事务的时间戳。
Reason string
机器可读的原因。
Message string
描述状态和错误详情的人类可读的原因信息（如果存在）。

14.7.1. 机器配置池

性能配置集及其创建的产品会根据关联的机器配置池（MCP）应用到节点。MCP 包含有关应用由性能附加组件创建的机器配置的有价值的信息，它包括了内核 arg、Kube 配置、巨页分配和 rt-kernel 部署。性能附加控制器监控 MCP 中的更改，并相应地更新性能配置集状态。

MCP 返回到性能配置集状态的唯一条件是 MCP 处于 Degraded 状态，这会导致 performaceProfile.status.condition.Degraded = true。

示例

以下示例是创建关联机器配置池（worker-cnf）的性能配置集：

  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

14.8. 为红帽支持收集调试数据延迟

在提交问题单时同时提供您的集群信息，可以帮助红帽支持为您进行排除故障。

您可使用 must-gather 工具来收集有关 OpenShift Container Platform 集群的诊断信息，包括节点调整、NUMA 拓扑和其他调试延迟设置问题所需的信息。

为了获得快速支持，请提供 OpenShift Container Platform 和低延迟调整的诊断信息。

14.8.1. 关于 must-gather 工具

oc adm must-gather CLI 命令可收集最有助于解决问题的集群信息，如：

  • 资源定义
  • 审计日志
  • 服务日志

您在运行该命令时，可通过包含 --image 参数来指定一个或多个镜像。指定镜像后，该工具便会收集有关相应功能或产品的信息。在运行 oc adm must-gather 时，集群上会创建一个新 pod。在该 pod 上收集数据，并保存至以 must-gather.local 开头的一个新目录中。该目录在当前工作目录中创建。

14.8.2. 关于收集低延迟数据

使用 oc adm must-gather CLI 命令来收集有关集群的信息，包括与低延迟性能优化相关的功能和对象，包括：

  • Performance Addon Operator 命名空间和子对象。
  • MachineConfigPool 和关联的 MachineConfig 对象。
  • Node Tuning Operator 和关联的 Tuned 对象。
  • Linux 内核命令行选项。
  • CPU 和 NUMA 拓扑
  • 基本 PCI 设备信息和 NUMA 本地性。

要使用 must-gather 来收集 Performance Addon Operator 调试信息，您必须指定 Performance Addon Operator must-gather 镜像： 

--image=registry.redhat.io/openshift4/performance-addon-operator-must-gather-rhel8:v4.10.

14.8.3. 收集有关特定功能的数据

您可通过将 oc adm must-gather CLI 命令与 --image 或 --image-stream 参数结合使用来收集有关特定功能的调试信息。must-gather 工具支持多个镜像，这样您便可通过运行单个命令收集多个功能的数据。

注意

要收集除特定功能数据外的默认 must-gather 数据，请添加 --image-stream=openshift/must-gather 参数。

先决条件

  • 使用具有 cluster-admin 角色的用户访问集群。
  • 安装了 OpenShift Container Platform CLI（oc）。

流程

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

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

    $ oc adm must-gather \
 --image-stream=openshift/must-gather \ 1

 --image=registry.redhat.io/openshift4/performance-addon-operator-must-gather-rhel8:v4.10 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. 在红帽客户门户中为您的问题单附上压缩文件。

其他资源

第 15 章 为平台验证执行延迟测试

您可以使用 Cloud-native Network Function (CNF) 测试镜像在启用了 CNF 的 OpenShift Container Platform 集群上运行延迟测试，其中安装了运行 CNF 工作负载所需的所有组件。运行延迟测试以验证工作负载的节点调整。

cnf-tests 容器镜像位于 registry.redhat.io/openshift4/cnf-tests-rhel8:v4.10 中。

重要

cnf-tests 镜像还包含了红帽不支持的多个测试。红帽只支持延迟测试。

15.1. 运行延迟测试的先决条件

运行延迟测试前，集群必须满足以下要求：

  1. 已使用 Performance Addon Operator 配置一个性能配置集。
  2. 已在集群中应用了所有所需的 CNF 配置。
  3. 已在集群中应用了已存在的 MachineConfigPool CR。默认 worker 池为 worker-cnf。

其他资源

15.2. 关于延迟测试的发现模式

使用发现模式在不更改其配置的情况下验证集群的功能。在测试时使用现有环境配置。测试可以找到所需的配置项目，并使用这些项目来执行测试。如果没有找到运行特定测试所需的资源，则会跳过测试，为用户提供正确的信息。测试完成后，不会清理预配置的配置项目，测试环境可立即用于另一个测试运行。

重要

在运行延迟测试时，始终使用 -e DISCOVERY_MODE=true 和 -ginkgo.focus 设置为适当的延迟测试。如果您没有以发现模式运行延迟测试，则测试运行修改现有的实时集群性能配置集配置。

限制测试过程中使用的节点

通过指定 NODES_SELECTOR 环境变量来限制执行测试的节点，例如 -e NODES_SELECTOR=node-role.kubernetes.io/worker-cnf。测试创建的任何资源都仅限于具有匹配标签的节点。

注意

如果要覆盖默认 worker 池，请将 -e ROLE_WORKER_CNF=<custom_worker_pool> 变量传递给指定适当标签的命令。

15.3. 测量延迟

cnf-tests 镜像使用三种工具来测量系统的延迟：

  • hwlatdetect
  • cyclictest
  • oslat

每个工具都有特定的用途。按顺序使用工具来获取可靠的测试结果。

hwlatdetect
测量裸机硬件可达到的基准。在继续执行下一个延迟测试前，请确保 hwlatdetect 报告的延迟满足所需的阈值，因为您无法通过操作系统调整来修复硬件延迟高峰。
cyclictest
在 hwlatdetect 验证后验证实时内核调度程序延迟。cyclictest 工具调度重复的计时器，并测量所需与实际触发时间之间的差别。这种差别可以发现与中断或进程优先级导致的调优相关的基本问题。该工具必须在实时内核中运行。
oslat
行为与 CPU 密集型 DPDK 应用程序类似，并测量模拟 CPU 繁重数据处理的忙碌循环和中断。

测试引入了以下环境变量：

表 15.1. 延迟测试环境变量

环境变量描述

LATENCY_TEST_DELAY

指定测试开始运行的时间（以秒为单位）。您可以使用变量来允许 CPU 管理器协调循环来更新默认的 CPU 池。默认值为 0。

LATENCY_TEST_CPUS

指定运行延迟测试的 pod 使用的 CPU 数量。如果没有设置变量，则默认配置包含所有隔离的 CPU。

LATENCY_TEST_RUNTIME

指定延迟测试必须运行的时间（以秒为单位）。默认值为 300 秒。

HWLATDETECT_MAXIMUM_LATENCY

指定工作负载和操作系统的最大可接受硬件延迟（微秒）。如果您没有设置 HWLATDETECT_MAXIMUM_LATENCY 或 MAXIMUM_LATENCY 的值，该工具会比较默认预期阈值(20μs)和工具本身中实际的最大延迟。然后，测试会失败或成功。

CYCLICTEST_MAXIMUM_LATENCY

指定 cyclictest 运行期间所有线程期望的微秒级延迟的最大延迟。如果您没有设置 CYCLICTEST_MAXIMUM_LATENCY 或 MAXIMUM_LATENCY 的值，该工具会跳过预期和实际最大延迟的比较。

OSLAT_MAXIMUM_LATENCY

指定 oslat 测试结果的最大可接受延迟（微秒）。如果您没有设置 OSLAT_MAXIMUM_LATENCY 或 MAXIMUM_LATENCY 的值，该工具会跳过预期和实际最大延迟的比较。

MAXIMUM_LATENCY

指定以微秒为单位的最大可接受的延迟的统一变量。适用于所有可用延迟工具。

LATENCY_TEST_RUN

指明测试是否应该运行的布尔值参数。LATENCY_TEST_RUN 默认设置为 false。要运行延迟测试，请将此值设置为 true。

注意

特定于延迟工具的变量优先于统一变量。例如，如果 OSLAT_MAXIMUM_LATENCY 设置为 30 微秒，而 MAXIMUM_LATENCY 被设置为 10 微秒，则 oslat 测试将以最大可接受的延迟 30 微秒运行。

15.4. 运行延迟测试

运行集群延迟测试，以验证 Cloud-native Network Function (CNF) 工作负载的节点调整。

重要

始终使用 DISCOVERY_MODE=true 设置运行延迟测试。如果没有，测试套件将对正在运行的集群配置进行更改。

注意

当以非 root 用户或非特权用户执行 podman 命令时，挂载路径可能会失败，错误为 permission denied。要使 podman 命令正常工作，请将 :Z 附加到卷创建中，例如 -v $(pwd)/:/kubeconfig:Z。这允许 podman 进行正确的 SELinux 重新标记。

流程

  1. 在包含 kubeconfig 文件的目录中打开 shell 提示符。

    您可以在当前目录中为测试镜像提供 kubeconfig 文件，及其相关的 $KUBECONFIG 环境变量（通过卷挂载）。这允许运行的容器使用容器内的 kubeconfig 文件。

  2. 输入以下命令运行延迟测试： 

    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
-e LATENCY_TEST_RUN=true -e DISCOVERY_MODE=true registry.redhat.io/openshift4/cnf-tests-rhel8:v4.10 \
/usr/bin/test-run.sh -ginkgo.focus="\[performance\]\ Latency\ Test"
  3. 可选：附加 -ginkgo.dryRun 以空运行模式运行延迟测试。这对于检查测试运行的内容非常有用。
  4. 可选： 附加 -ginkgo.v 用来运行测试，并增加详细程度。

  5. 可选： 要针对特定的性能配置集运行延迟测试，请运行以下命令，替换适当的值： 

    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
-e LATENCY_TEST_RUN=true -e LATENCY_TEST_RUNTIME=600 -e MAXIMUM_LATENCY=20 \
-e PERF_TEST_PROFILE=<performance_profile> registry.redhat.io/openshift4/cnf-tests-rhel8:v4.10 \
/usr/bin/test-run.sh -ginkgo.focus="[performance]\ Latency\ Test"

    其中：

    <performance_profile>
    是您要对其运行延迟测试的性能配置集的名称。
    重要

    如需有效延迟测试结果，请至少运行测试 12 小时。

15.4.1. 运行 hwlatdetect

hwlatdetect 工具位于 rt-kernel 软件包中，带有常规订阅 Red Hat Enterprise Linux (RHEL) 8.x。

重要

始终使用 DISCOVERY_MODE=true 设置运行延迟测试。如果没有，测试套件将对正在运行的集群配置进行更改。

注意

当以非 root 用户或非特权用户执行 podman 命令时，挂载路径可能会失败，错误为 permission denied。要使 podman 命令正常工作，请将 :Z 附加到卷创建中，例如 -v $(pwd)/:/kubeconfig:Z。这允许 podman 进行正确的 SELinux 重新标记。

先决条件

  • 已在集群中安装了实时内核。
  • 您使用客户门户网站凭证登录到 registry.redhat.io。

流程

  • 要运行 hwlatdetect 测试，请运行以下命令，并根据情况替换变量值： 

    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
-e LATENCY_TEST_RUN=true -e DISCOVERY_MODE=true -e ROLE_WORKER_CNF=worker-cnf \
-e LATENCY_TEST_RUNTIME=600 -e MAXIMUM_LATENCY=20 \
registry.redhat.io/openshift4/cnf-tests-rhel8:v4.10 \
/usr/bin/test-run.sh -ginkgo.v -ginkgo.focus="hwlatdetect"

    hwlatdetect 测试运行了 10 分钟 (600 秒)。当最观察到的延迟低于 MAXIMUM_LATENCY (20 FORWARD) 时，测试会成功运行。

    如果结果超过延迟阈值，测试会失败。

    重要

    对于有效结果，测试应至少运行 12 小时。

    失败输出示例

    running /usr/bin/validationsuite -ginkgo.v -ginkgo.focus=hwlatdetect
I0210 17:08:38.607699       7 request.go:668] Waited for 1.047200253s due to client-side throttling, not priority and fairness, request: GET:https://api.ocp.demo.lab:6443/apis/apps.openshift.io/v1?timeout=32s
Running Suite: CNF Features e2e validation
==========================================
Random Seed: 1644512917
Will run 0 of 48 specs

SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
Ran 0 of 48 Specs in 0.001 seconds
SUCCESS! -- 0 Passed | 0 Failed | 0 Pending | 48 Skipped

PASS
Discovery mode enabled, skipping setup
running /usr/bin/cnftests -ginkgo.v -ginkgo.focus=hwlatdetect
I0210 17:08:41.179269      40 request.go:668] Waited for 1.046001096s due to client-side throttling, not priority and fairness, request: GET:https://api.ocp.demo.lab:6443/apis/storage.k8s.io/v1beta1?timeout=32s
Running Suite: CNF Features e2e integration tests
=================================================
Random Seed: 1644512920
Will run 1 of 151 specs

SSSSSSS
------------------------------
[performance] Latency Test with the hwlatdetect image
  should succeed
  /remote-source/app/vendor/github.com/openshift-kni/performance-addon-operators/functests/4_latency/latency.go:221
STEP: Waiting two minutes to download the latencyTest image
STEP: Waiting another two minutes to give enough time for the cluster to move the pod to Succeeded phase
Feb 10 17:10:56.045: [INFO]: found mcd machine-config-daemon-dzpw7 for node ocp-worker-0.demo.lab
Feb 10 17:10:56.259: [INFO]: found mcd machine-config-daemon-dzpw7 for node ocp-worker-0.demo.lab
Feb 10 17:11:56.825: [ERROR]: timed out waiting for the condition

• Failure [193.903 seconds]
[performance] Latency Test
/remote-source/app/vendor/github.com/openshift-kni/performance-addon-operators/functests/4_latency/latency.go:60
  with the hwlatdetect image
  /remote-source/app/vendor/github.com/openshift-kni/performance-addon-operators/functests/4_latency/latency.go:213
    should succeed [It]
    /remote-source/app/vendor/github.com/openshift-kni/performance-addon-operators/functests/4_latency/latency.go:221

    Log file created at: 2022/02/10 17:08:45
    Running on machine: hwlatdetect-cd8b6
    Binary: Built with gc go1.16.6 for linux/amd64
    Log line format: [IWEF]mmdd hh:mm:ss.uuuuuu threadid file:line] msg
    I0210 17:08:45.716288       1 node.go:37] Environment information: /proc/cmdline: BOOT_IMAGE=(hd0,gpt3)/ostree/rhcos-56fabc639a679b757ebae30e5f01b2ebd38e9fde9ecae91c41be41d3e89b37f8/vmlinuz-4.18.0-305.34.2.rt7.107.el8_4.x86_64 random.trust_cpu=on console=tty0 console=ttyS0,115200n8 ignition.platform.id=qemu ostree=/ostree/boot.0/rhcos/56fabc639a679b757ebae30e5f01b2ebd38e9fde9ecae91c41be41d3e89b37f8/0 root=UUID=56731f4f-f558-46a3-85d3-d1b579683385 rw rootflags=prjquota skew_tick=1 nohz=on rcu_nocbs=3-5 tuned.non_isolcpus=ffffffc7 intel_pstate=disable nosoftlockup tsc=nowatchdog intel_iommu=on iommu=pt isolcpus=managed_irq,3-5 systemd.cpu_affinity=0,1,2,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31 + +
    I0210 17:08:45.716782       1 node.go:44] Environment information: kernel version 4.18.0-305.34.2.rt7.107.el8_4.x86_64
    I0210 17:08:45.716861       1 main.go:50] running the hwlatdetect command with arguments [/usr/bin/hwlatdetect --threshold 1 --hardlimit 1 --duration 10 --window 10000000us --width 950000us]
    F0210 17:08:56.815204       1 main.go:53] failed to run hwlatdetect command; out: hwlatdetect:  test duration 10 seconds
       detector: tracer
       parameters:
            Latency threshold: 1us 1
            Sample window:     10000000us
            Sample width:      950000us
         Non-sampling period:  9050000us
            Output File:       None

    Starting test
    test finished
    Max Latency: 24us 2
    Samples recorded: 1
    Samples exceeding threshold: 1
    ts: 1644512927.163556381, inner:20, outer:24
    ; err: exit status 1
    goroutine 1 [running]:
    k8s.io/klog.stacks(0xc000010001, 0xc00012e000, 0x25b, 0x2710)
        /remote-source/app/vendor/k8s.io/klog/klog.go:875 +0xb9
    k8s.io/klog.(*loggingT).output(0x5bed00, 0xc000000003, 0xc0000121c0, 0x53ea81, 0x7, 0x35, 0x0)
        /remote-source/app/vendor/k8s.io/klog/klog.go:829 +0x1b0
    k8s.io/klog.(*loggingT).printf(0x5bed00, 0x3, 0x5082da, 0x33, 0xc000113f58, 0x2, 0x2)
        /remote-source/app/vendor/k8s.io/klog/klog.go:707 +0x153
    k8s.io/klog.Fatalf(...)
        /remote-source/app/vendor/k8s.io/klog/klog.go:1276
    main.main()
        /remote-source/app/cnf-tests/pod-utils/hwlatdetect-runner/main.go:53 +0x897

    goroutine 6 [chan receive]:
    k8s.io/klog.(*loggingT).flushDaemon(0x5bed00)
        /remote-source/app/vendor/k8s.io/klog/klog.go:1010 +0x8b
    created by k8s.io/klog.init.0
        /remote-source/app/vendor/k8s.io/klog/klog.go:411 +0xd8

    goroutine 7 [chan receive]:
    k8s.io/klog/v2.(*loggingT).flushDaemon(0x5bede0)
        /remote-source/app/vendor/k8s.io/klog/v2/klog.go:1169 +0x8b
    created by k8s.io/klog/v2.init.0
        /remote-source/app/vendor/k8s.io/klog/v2/klog.go:420 +0xdf
    Unexpected error:
        <*errors.errorString | 0xc000418ed0>: {
            s: "timed out waiting for the condition",
        }
        timed out waiting for the condition
    occurred

    /remote-source/app/vendor/github.com/openshift-kni/performance-addon-operators/functests/4_latency/latency.go:433
------------------------------
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
JUnit report was created: /junit.xml/cnftests-junit.xml


Summarizing 1 Failure:

[Fail] [performance] Latency Test with the hwlatdetect image [It] should succeed
/remote-source/app/vendor/github.com/openshift-kni/performance-addon-operators/functests/4_latency/latency.go:433

Ran 1 of 151 Specs in 222.254 seconds
FAIL! -- 0 Passed | 1 Failed | 0 Pending | 150 Skipped

--- FAIL: TestTest (222.45s)
FAIL

    1
    您可以使用 MAXIMUM_LATENCY 或 HWLATDETECT_MAXIMUM_LATENCY 环境变量来配置延迟阈值。
    2
    测试期间测量的最大延迟值。
hwlatdetect 测试结果示例

您可以捕获以下类型的结果：

  • 在每次运行后收集的粗略结果，以便对整个测试过程中所做的任何更改产生影响的历史记录。
  • 基本测试和配置设置的组合。

良好结果的示例

hwlatdetect: test duration 3600 seconds
detector: tracer
parameters:
Latency threshold: 10us
Sample window: 1000000us
Sample width: 950000us
Non-sampling period: 50000us
Output File: None

Starting test
test finished
Max Latency: Below threshold
Samples recorded: 0

hwlatdetect 工具仅在示例超过指定阈值时提供输出。

错误结果的示例

hwlatdetect: test duration 3600 seconds
detector: tracer
parameters:Latency threshold: 10usSample window: 1000000us
Sample width: 950000usNon-sampling period: 50000usOutput File: None

Starting tests:1610542421.275784439, inner:78, outer:81
ts: 1610542444.330561619, inner:27, outer:28
ts: 1610542445.332549975, inner:39, outer:38
ts: 1610542541.568546097, inner:47, outer:32
ts: 1610542590.681548531, inner:13, outer:17
ts: 1610543033.818801482, inner:29, outer:30
ts: 1610543080.938801990, inner:90, outer:76
ts: 1610543129.065549639, inner:28, outer:39
ts: 1610543474.859552115, inner:28, outer:35
ts: 1610543523.973856571, inner:52, outer:49
ts: 1610543572.089799738, inner:27, outer:30
ts: 1610543573.091550771, inner:34, outer:28
ts: 1610543574.093555202, inner:116, outer:63

hwlatdetect 的输出显示多个样本超过阈值。但是，相同的输出可能会根据以下因素显示不同的结果：

  • 测试的持续时间
  • CPU 内核数
  • 主机固件设置
警告

在继续执行下一个延迟测试前，请确保 hwlatdetect 报告的延迟满足所需的阈值。修复硬件带来的延迟可能需要您联系系统厂商支持。

并非所有延迟高峰都与硬件相关。确保调整主机固件以满足您的工作负载要求。如需更多信息，请参阅为系统调整设置固件参数。

15.4.2. 运行 cyclictest

cyclictest 工具测量指定 CPU 上的实时内核调度程序延迟。

重要

始终使用 DISCOVERY_MODE=true 设置运行延迟测试。如果没有，测试套件将对正在运行的集群配置进行更改。

注意

当以非 root 用户或非特权用户执行 podman 命令时，挂载路径可能会失败，错误为 permission denied。要使 podman 命令正常工作，请将 :Z 附加到卷创建中，例如 -v $(pwd)/:/kubeconfig:Z。这允许 podman 进行正确的 SELinux 重新标记。

先决条件

  • 您使用客户门户网站凭证登录到 registry.redhat.io。
  • 已在集群中安装了实时内核。
  • 已使用 Performance addon operator 应用了集群性能配置集。

流程

  • 要执行 cyclictest，请运行以下命令，并根据情况替换变量值： 

    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
-e LATENCY_TEST_RUN=true -e DISCOVERY_MODE=true -e ROLE_WORKER_CNF=worker-cnf \
-e LATENCY_TEST_CPUS=10 -e LATENCY_TEST_RUNTIME=600 -e MAXIMUM_LATENCY=20 \
registry.redhat.io/openshift4/cnf-tests-rhel8:v4.10 \
/usr/bin/test-run.sh -ginkgo.v -ginkgo.focus="cyclictest"

    该命令运行 cyclictest 工具 10 分钟（600 秒）。当观察到的延迟低于 MAXIMUM_LATENCY 时，测试会成功运行（在本例中，20 TOKENs）。对于电信 RAN 工作负载，对 20 个以上延迟的激增通常并不能接受。

    如果结果超过延迟阈值，测试会失败。

    重要

    对于有效结果，测试应至少运行 12 小时。

    失败输出示例

    Discovery mode enabled, skipping setup
running /usr/bin//cnftests -ginkgo.v -ginkgo.focus=cyclictest
I0811 15:02:36.350033      20 request.go:668] Waited for 1.049965918s due to client-side throttling, not priority and fairness, request: GET:https://api.cnfdc8.t5g.lab.eng.bos.redhat.com:6443/apis/machineconfiguration.openshift.io/v1?timeout=32s
Running Suite: CNF Features e2e integration tests
=================================================
Random Seed: 1628694153
Will run 1 of 138 specs

SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
------------------------------
[performance] Latency Test with the cyclictest image
  should succeed
  /go/src/github.com/openshift-kni/cnf-features-deploy/vendor/github.com/openshift-kni/performance-addon-operators/functests/4_latency/latency.go:200
STEP: Waiting two minutes to download the latencyTest image
STEP: Waiting another two minutes to give enough time for the cluster to move the pod to Succeeded phase
Aug 11 15:03:06.826: [INFO]: found mcd machine-config-daemon-wf4w8 for node cnfdc8.clus2.t5g.lab.eng.bos.redhat.com

• Failure [22.527 seconds]
[performance] Latency Test
/go/src/github.com/openshift-kni/cnf-features-deploy/vendor/github.com/openshift-kni/performance-addon-operators/functests/4_latency/latency.go:84
  with the cyclictest image
  /go/src/github.com/openshift-kni/cnf-features-deploy/vendor/github.com/openshift-kni/performance-addon-operators/functests/4_latency/latency.go:188
    should succeed [It]
    /go/src/github.com/openshift-kni/cnf-features-deploy/vendor/github.com/openshift-kni/performance-addon-operators/functests/4_latency/latency.go:200

    The current latency 27 is bigger than the expected one 20
    Expected
        <bool>: false
    to be true

    /go/src/github.com/openshift-kni/cnf-features-deploy/vendor/github.com/openshift-kni/performance-addon-operators/functests/4_latency/latency.go:219

Log file created at: 2021/08/11 15:02:51
Running on machine: cyclictest-knk7d
Binary: Built with gc go1.16.6 for linux/amd64
Log line format: [IWEF]mmdd hh:mm:ss.uuuuuu threadid file:line] msg
I0811 15:02:51.092254       1 node.go:37] Environment information: /proc/cmdline: BOOT_IMAGE=(hd0,gpt3)/ostree/rhcos-612d89f4519a53ad0b1a132f4add78372661bfb3994f5fe115654971aa58a543/vmlinuz-4.18.0-305.10.2.rt7.83.el8_4.x86_64 ip=dhcp random.trust_cpu=on console=tty0 console=ttyS0,115200n8 ostree=/ostree/boot.1/rhcos/612d89f4519a53ad0b1a132f4add78372661bfb3994f5fe115654971aa58a543/0 ignition.platform.id=openstack root=UUID=5a4ddf16-9372-44d9-ac4e-3ee329e16ab3 rw rootflags=prjquota skew_tick=1 nohz=on rcu_nocbs=1-3 tuned.non_isolcpus=000000ff,ffffffff,ffffffff,fffffff1 intel_pstate=disable nosoftlockup tsc=nowatchdog intel_iommu=on iommu=pt isolcpus=managed_irq,1-3 systemd.cpu_affinity=0,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103 default_hugepagesz=1G hugepagesz=2M hugepages=128 nmi_watchdog=0 audit=0 mce=off processor.max_cstate=1 idle=poll intel_idle.max_cstate=0
I0811 15:02:51.092427       1 node.go:44] Environment information: kernel version 4.18.0-305.10.2.rt7.83.el8_4.x86_64
I0811 15:02:51.092450       1 main.go:48] running the cyclictest command with arguments \
[-D 600 -95 1 -t 10 -a 2,4,6,8,10,54,56,58,60,62 -h 30 -i 1000 --quiet]
I0811 15:03:06.147253       1 main.go:54] succeeded to run the cyclictest command: # /dev/cpu_dma_latency set to 0us
# Histogram
000000 000000   000000  000000  000000  000000  000000  000000  000000  000000  000000
000001 000000   005561  027778  037704  011987  000000  120755  238981  081847  300186
000002 587440   581106  564207  554323  577416  590635  474442  357940  513895  296033
000003 011751   011441  006449  006761  008409  007904  002893  002066  003349  003089
000004 000527   001079  000914  000712  001451  001120  000779  000283  000350  000251

More histogram entries ...
# Min Latencies: 00002 00001 00001 00001 00001 00002 00001 00001 00001 00001
# Avg Latencies: 00002 00002 00002 00001 00002 00002 00001 00001 00001 00001
# Max Latencies: 00018 00465 00361 00395 00208 00301 02052 00289 00327 00114
# Histogram Overflows: 00000 00220 00159 00128 00202 00017 00069 00059 00045 00120
# Histogram Overflow at cycle number:
# Thread 0:
# Thread 1: 01142 01439 05305 … # 00190 others
# Thread 2: 20895 21351 30624 … # 00129 others
# Thread 3: 01143 17921 18334 … # 00098 others
# Thread 4: 30499 30622 31566 ... # 00172 others
# Thread 5: 145221 170910 171888 ...
# Thread 6: 01684 26291 30623 ...# 00039 others
# Thread 7: 28983 92112 167011 … 00029 others
# Thread 8: 45766 56169 56171 ...# 00015 others
# Thread 9: 02974 08094 13214 ... # 00090 others

cyclictest 结果示例

相同的输出可能会显示不同工作负载的结果。例如，spikes 最长为 18μs 对 4G DU 工作负载是可以接受的，但对于 5G DU 工作负载不能接受。

良好结果的示例

running cmd: cyclictest -q -D 10m -p 1 -t 16 -a 2,4,6,8,10,12,14,16,54,56,58,60,62,64,66,68 -h 30 -i 1000 -m
# Histogram
000000 000000   000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000
000001 000000   000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000
000002 579506   535967  418614  573648  532870  529897  489306  558076  582350  585188  583793  223781  532480  569130  472250  576043
More histogram entries ...
# Total: 000600000 000600000 000600000 000599999 000599999 000599999 000599998 000599998 000599998 000599997 000599997 000599996 000599996 000599995 000599995 000599995
# Min Latencies: 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002
# Avg Latencies: 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002
# Max Latencies: 00005 00005 00004 00005 00004 00004 00005 00005 00006 00005 00004 00005 00004 00004 00005 00004
# Histogram Overflows: 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000
# Histogram Overflow at cycle number:
# Thread 0:
# Thread 1:
# Thread 2:
# Thread 3:
# Thread 4:
# Thread 5:
# Thread 6:
# Thread 7:
# Thread 8:
# Thread 9:
# Thread 10:
# Thread 11:
# Thread 12:
# Thread 13:
# Thread 14:
# Thread 15:

错误结果的示例

running cmd: cyclictest -q -D 10m -p 1 -t 16 -a 2,4,6,8,10,12,14,16,54,56,58,60,62,64,66,68 -h 30 -i 1000 -m
# Histogram
000000 000000   000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000
000001 000000   000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000
000002 564632   579686  354911  563036  492543  521983  515884  378266  592621  463547  482764  591976  590409  588145  589556  353518
More histogram entries ...
# Total: 000599999 000599999 000599999 000599997 000599997 000599998 000599998 000599997 000599997 000599996 000599995 000599996 000599995 000599995 000599995 000599993
# Min Latencies: 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002
# Avg Latencies: 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002
# Max Latencies: 00493 00387 00271 00619 00541 00513 00009 00389 00252 00215 00539 00498 00363 00204 00068 00520
# Histogram Overflows: 00001 00001 00001 00002 00002 00001 00000 00001 00001 00001 00002 00001 00001 00001 00001 00002
# Histogram Overflow at cycle number:
# Thread 0: 155922
# Thread 1: 110064
# Thread 2: 110064
# Thread 3: 110063 155921
# Thread 4: 110063 155921
# Thread 5: 155920
# Thread 6:
# Thread 7: 110062
# Thread 8: 110062
# Thread 9: 155919
# Thread 10: 110061 155919
# Thread 11: 155918
# Thread 12: 155918
# Thread 13: 110060
# Thread 14: 110060
# Thread 15: 110059 155917

15.4.3. 运行 oslat

oslat 测试模拟 CPU 密集型 DPDK 应用程序，并测量所有中断和中断来测试集群处理 CPU 大量数据处理的方式。

重要

始终使用 DISCOVERY_MODE=true 设置运行延迟测试。如果没有，测试套件将对正在运行的集群配置进行更改。

注意

当以非 root 用户或非特权用户执行 podman 命令时，挂载路径可能会失败，错误为 permission denied。要使 podman 命令正常工作，请将 :Z 附加到卷创建中，例如 -v $(pwd)/:/kubeconfig:Z。这允许 podman 进行正确的 SELinux 重新标记。

先决条件

  • 您使用客户门户网站凭证登录到 registry.redhat.io。
  • 已使用 Performance addon operator 应用集群性能配置集。

流程

  • 要执行 oslat 测试，请运行以下命令，根据需要替换变量值： 

    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
-e LATENCY_TEST_RUN=true -e DISCOVERY_MODE=true -e ROLE_WORKER_CNF=worker-cnf \
-e LATENCY_TEST_CPUS=7 -e LATENCY_TEST_RUNTIME=600 -e MAXIMUM_LATENCY=20 \
registry.redhat.io/openshift4/cnf-tests-rhel8:v4.10 \
/usr/bin/test-run.sh -ginkgo.v -ginkgo.focus="oslat"

    LATENCY_TEST_CPUS 指定使用 oslat 命令测试的 CPU 列表。

    命令运行 oslat 工具 10 分钟（600 秒）。当最观察到的延迟低于 MAXIMUM_LATENCY (20 FORWARD) 时，测试会成功运行。

    如果结果超过延迟阈值，测试会失败。

    重要

    对于有效结果，测试应至少运行 12 小时。

    失败输出示例

    running /usr/bin//validationsuite -ginkgo.v -ginkgo.focus=oslat
I0829 12:36:55.386776       8 request.go:668] Waited for 1.000303471s due to client-side throttling, not priority and fairness, request: GET:https://api.cnfdc8.t5g.lab.eng.bos.redhat.com:6443/apis/authentication.k8s.io/v1?timeout=32s
Running Suite: CNF Features e2e validation
==========================================

Discovery mode enabled, skipping setup
running /usr/bin//cnftests -ginkgo.v -ginkgo.focus=oslat
I0829 12:37:01.219077      20 request.go:668] Waited for 1.050010755s due to client-side throttling, not priority and fairness, request: GET:https://api.cnfdc8.t5g.lab.eng.bos.redhat.com:6443/apis/snapshot.storage.k8s.io/v1beta1?timeout=32s
Running Suite: CNF Features e2e integration tests
=================================================
Random Seed: 1630240617
Will run 1 of 142 specs

SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
------------------------------
[performance] Latency Test with the oslat image
  should succeed
  /go/src/github.com/openshift-kni/cnf-features-deploy/vendor/github.com/openshift-kni/performance-addon-operators/functests/4_latency/latency.go:134
STEP: Waiting two minutes to download the latencyTest image
STEP: Waiting another two minutes to give enough time for the cluster to move the pod to Succeeded phase
Aug 29 12:37:59.324: [INFO]: found mcd machine-config-daemon-wf4w8 for node cnfdc8.clus2.t5g.lab.eng.bos.redhat.com

• Failure [49.246 seconds]
[performance] Latency Test
/go/src/github.com/openshift-kni/cnf-features-deploy/vendor/github.com/openshift-kni/performance-addon-operators/functests/4_latency/latency.go:59
  with the oslat image
  /go/src/github.com/openshift-kni/cnf-features-deploy/vendor/github.com/openshift-kni/performance-addon-operators/functests/4_latency/latency.go:112
    should succeed [It]
    /go/src/github.com/openshift-kni/cnf-features-deploy/vendor/github.com/openshift-kni/performance-addon-operators/functests/4_latency/latency.go:134

    The current latency 27 is bigger than the expected one 20 1
    Expected
        <bool>: false
    to be true
 /go/src/github.com/openshift-kni/cnf-features-deploy/vendor/github.com/openshift-kni/performance-addon-operators/functests/4_latency/latency.go:168

Log file created at: 2021/08/29 13:25:21
Running on machine: oslat-57c2g
Binary: Built with gc go1.16.6 for linux/amd64
Log line format: [IWEF]mmdd hh:mm:ss.uuuuuu threadid file:line] msg
I0829 13:25:21.569182       1 node.go:37] Environment information: /proc/cmdline: BOOT_IMAGE=(hd0,gpt3)/ostree/rhcos-612d89f4519a53ad0b1a132f4add78372661bfb3994f5fe115654971aa58a543/vmlinuz-4.18.0-305.10.2.rt7.83.el8_4.x86_64 ip=dhcp random.trust_cpu=on console=tty0 console=ttyS0,115200n8 ostree=/ostree/boot.0/rhcos/612d89f4519a53ad0b1a132f4add78372661bfb3994f5fe115654971aa58a543/0 ignition.platform.id=openstack root=UUID=5a4ddf16-9372-44d9-ac4e-3ee329e16ab3 rw rootflags=prjquota skew_tick=1 nohz=on rcu_nocbs=1-3 tuned.non_isolcpus=000000ff,ffffffff,ffffffff,fffffff1 intel_pstate=disable nosoftlockup tsc=nowatchdog intel_iommu=on iommu=pt isolcpus=managed_irq,1-3 systemd.cpu_affinity=0,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103 default_hugepagesz=1G hugepagesz=2M hugepages=128 nmi_watchdog=0 audit=0 mce=off processor.max_cstate=1 idle=poll intel_idle.max_cstate=0
I0829 13:25:21.569345       1 node.go:44] Environment information: kernel version 4.18.0-305.10.2.rt7.83.el8_4.x86_64
I0829 13:25:21.569367       1 main.go:53] Running the oslat command with arguments \
[--duration 600 --rtprio 1 --cpu-list 4,6,52,54,56,58 --cpu-main-thread 2]
I0829 13:35:22.632263       1 main.go:59] Succeeded to run the oslat command: oslat V 2.00
Total runtime:    600 seconds
Thread priority:  SCHED_FIFO:1
CPU list:     4,6,52,54,56,58
CPU for main thread:  2
Workload:     no
Workload mem:     0 (KiB)
Preheat cores:    6

Pre-heat for 1 seconds...
Test starts...
Test completed.

        Core:  4 6 52 54 56 58
    CPU Freq:  2096 2096 2096 2096 2096 2096 (Mhz)
    001 (us):  19390720316 19141129810 20265099129 20280959461 19391991159 19119877333
    002 (us):  5304 5249 5777 5947 6829 4971
    003 (us):  28 14 434 47 208 21
    004 (us):  1388 853 123568 152817 5576 0
    005 (us):  207850 223544 103827 91812 227236 231563
    006 (us):  60770 122038 277581 323120 122633 122357
    007 (us):  280023 223992 63016 25896 214194 218395
    008 (us):  40604 25152 24368 4264 24440 25115
    009 (us):  6858 3065 5815 810 3286 2116
    010 (us):  1947 936 1452 151 474 361
  ...
     Minimum:  1 1 1 1 1 1 (us)
     Average:  1.000 1.000 1.000 1.000 1.000 1.000 (us)
     Maximum:  37 38 49 28 28 19 (us)
     Max-Min:  36 37 48 27 27 18 (us)
    Duration:  599.667 599.667 599.667 599.667 599.667 599.667 (sec)

    1
    在本例中，测量的延迟超出了最大允许的值。

15.5. 生成延迟测试失败报告

使用以下步骤生成 JUnit 延迟测试输出和测试失败报告。

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 您已以具有 cluster-admin 权限的用户身份登录。

流程

  • 使用集群状态和资源的信息创建测试失败报告，通过传递 --report 参数并使用报告转储的路径来进行故障排除： 

    $ podman run -v $(pwd)/:/kubeconfig:Z -v $(pwd)/reportdest:<report_folder_path> \
-e KUBECONFIG=/kubeconfig/kubeconfig  -e DISCOVERY_MODE=true \
registry.redhat.io/openshift4/cnf-tests-rhel8:v4.10 \
/usr/bin/test-run.sh --report <report_folder_path> \
-ginkgo.focus="\[performance\]\ Latency\ Test"

    其中：

    <report_folder_path>
    是生成报告的文件夹的路径。

15.6. 生成 JUnit 延迟测试报告

使用以下步骤生成 JUnit 延迟测试输出和测试失败报告。

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 您已以具有 cluster-admin 权限的用户身份登录。

流程

  • 通过传递 --junit 参数和转储报告的路径来创建兼容 JUnit 的 XML 报告： 

    $ podman run -v $(pwd)/:/kubeconfig:Z -v $(pwd)/junitdest:<junit_folder_path> \
-e KUBECONFIG=/kubeconfig/kubeconfig  -e DISCOVERY_MODE=true \
registry.redhat.io/openshift4/cnf-tests-rhel8:v4.10 \
/usr/bin/test-run.sh --junit <junit_folder_path> \
-ginkgo.focus="\[performance\]\ Latency\ Test"

    其中：

    <junit_folder_path>
    是生成 junit 报告的文件夹的路径

15.7. 在单节点 OpenShift 集群上运行延迟测试

您可以在单节点 OpenShift 集群上运行延迟测试。

重要

始终使用 DISCOVERY_MODE=true 设置运行延迟测试。如果没有，测试套件将对正在运行的集群配置进行更改。

注意

当以非 root 用户或非特权用户执行 podman 命令时，挂载路径可能会失败，错误为 permission denied。要使 podman 命令正常工作，请将 :Z 附加到卷创建中，例如 -v $(pwd)/:/kubeconfig:Z。这允许 podman 进行正确的 SELinux 重新标记。

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 您已以具有 cluster-admin 权限的用户身份登录。

流程

  • 要在单节点 OpenShift 集群上运行延迟测试，请运行以下命令： 

    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
-e DISCOVERY_MODE=true -e ROLE_WORKER_CNF=master \
registry.redhat.io/openshift4/cnf-tests-rhel8:v4.10 \
/usr/bin/test-run.sh -ginkgo.focus="\[performance\]\ Latency\ Test"
    注意

    ROLE_WORKER_CNF=master 是必需的，因为 master 是唯一节点所属的机器池。有关为延迟测试设置所需的 MachineConfigPool 的更多信息，请参阅 "Prerequisites for running latency test"。

    运行测试套件后,，清理所有悬停的资源。

15.8. 在断开连接的集群中运行延迟测试

CNF 测试镜像可在无法访问外部 registry 的断开连接的集群中运行测试。这需要两个步骤：

  1. 将 cnf-tests 镜像镜像到自定义断开连接的 registry。
  2. 指示测试使用来自自定义断开连接的 registry 的镜像。

将镜像镜像(mirror)到集群可访问的自定义 registry

mirror 中提供了镜像可执行文件，以提供 oc 需要的输入来镜像运行测试到本地 registry 所需的镜像。

  1. 从可访问集群和 registry.redhat.io 的中间机器运行这个命令： 

    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
registry.redhat.io/openshift4/cnf-tests-rhel8:v4.10 \
/usr/bin/mirror -registry <disconnected_registry> | oc image mirror -f -

    其中：

    <disconnected_registry>
    是您配置的断开连接的镜像 registry，如 my.local.registry:5000/。

  2. 当您将 cnf-tests 镜像 mirror 到断开连接的 registry 中时，您必须覆盖用于运行测试时用来获取镜像的原始 registry，例如： 

    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
-e DISCOVERY_MODE=true -e IMAGE_REGISTRY="<disconnected_registry>" \
-e CNF_TESTS_IMAGE="cnf-tests-rhel8:v4.10" \
/usr/bin/test-run.sh -ginkgo.focus="\[performance\]\ Latency\ Test"

配置测试以使用自定义 registry 中的镜像

您可以使用 CNF_TESTS_IMAGE 和 IMAGE_REGISTRY 变量来使用自定义测试镜像和镜像 registry 运行延迟测试。

  • 要将延迟测试配置为使用自定义测试镜像和镜像 registry，请运行以下命令： 

    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
-e IMAGE_REGISTRY="<custom_image_registry>" \
-e CNF_TESTS_IMAGE="<custom_cnf-tests_image>" \
registry.redhat.io/openshift4/cnf-tests-rhel8:v4.10 /usr/bin/test-run.sh

    其中：

    <custom_image_registry>
    是自定义镜像 registry，如 custom.registry:5000/。
    <custom_cnf-tests_image>
    是自定义 cnf-tests 镜像，如 custom-cnf-tests-image:latest。

将镜像镜像 (mirror) 到集群 OpenShift 镜像 registry

OpenShift Container Platform 提供了一个内建的容器镜像 registry，它作为一个标准的工作负载在集群中运行。

流程

  1. 通过使用路由公开到 registry 的外部访问权限： 

    $ oc patch configs.imageregistry.operator.openshift.io/cluster --patch '{"spec":{"defaultRoute":true}}' --type=merge

  2. 运行以下命令来获取 registry 端点： 

    $ REGISTRY=$(oc get route default-route -n openshift-image-registry --template='{{ .spec.host }}')

  3. 创建用于公开镜像的命名空间： 

    $ oc create ns cnftests

  4. 使镜像流可供用于测试的所有命名空间使用。这需要允许 test 命名空间从 cnf-tests 镜像流中获取镜像。运行以下命令： 

    $ oc policy add-role-to-user system:image-puller system:serviceaccount:cnf-features-testing:default --namespace=cnftests
    $ oc policy add-role-to-user system:image-puller system:serviceaccount:performance-addon-operators-testing:default --namespace=cnftests

  5. 运行以下命令，检索 docker secret 名称和 auth 令牌： 

    $ SECRET=$(oc -n cnftests get secret | grep builder-docker | awk {'print $1'}
    $ TOKEN=$(oc -n cnftests get secret $SECRET -o jsonpath="{.data['\.dockercfg']}" | base64 --decode | jq '.["image-registry.openshift-image-registry.svc:5000"].auth')

  6. 创建 dockerauth.json 文件，例如： 

    $ echo "{\"auths\": { \"$REGISTRY\": { \"auth\": $TOKEN } }}" > dockerauth.json

  7. 对镜像进行 mirror： 

    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
registry.redhat.io/openshift4/cnf-tests-rhel8:4.10 \
/usr/bin/mirror -registry $REGISTRY/cnftests |  oc image mirror --insecure=true \
-a=$(pwd)/dockerauth.json -f -

  8. 运行测试： 

    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
-e DISCOVERY_MODE=true -e IMAGE_REGISTRY=image-registry.openshift-image-registry.svc:5000/cnftests \
cnf-tests-local:latest /usr/bin/test-run.sh -ginkgo.focus="\[performance\]\ Latency\ Test"

对不同的测试镜像进行镜像(mirror)

您可以选择更改对延迟测试镜像的默认上游镜像。

流程

  1. mirror 命令默认尝试对上游镜像进行 mirror。这可以通过向镜像传递带有以下格式的文件来覆盖： 

    [
    {
        "registry": "public.registry.io:5000",
        "image": "imageforcnftests:4.10"
    }
]

  2. 将文件传递给 mirror 命令，例如将其在本地保存为 images.json。使用以下命令，本地路径挂载到容器内的 /kubeconfig 中，并可传递给 mirror 命令。 

    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
registry.redhat.io/openshift4/cnf-tests-rhel8:v4.10 /usr/bin/mirror \
--registry "my.local.registry:5000/" --images "/kubeconfig/images.json" \
|  oc image mirror -f -

15.9. 对 cnf-tests 容器的错误进行故障排除

要运行延迟测试，集群必须从 cnf-tests 容器中访问。

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 您已以具有 cluster-admin 权限的用户身份登录。

流程

  • 运行以下命令，验证可以从 cnf-tests 容器中访问集群： 

    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
registry.redhat.io/openshift4/cnf-tests-rhel8:v4.10 \
oc get nodes

    如果这个命令无法正常工作，则可能会出现与跨 DNS、MTU 大小或防火墙访问相关的错误。

第 16 章 用于集群更新的拓扑 Aware Lifecycle Manager

您可以使用 Topology Aware Lifecycle Manager(TALM)来管理多个单节点 OpenShift 集群的软件生命周期。TALM 使用 Red Hat Advanced Cluster Management(RHACM)策略在目标集群中进行更改。

重要

Topology Aware Lifecycle Manager 只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议（SLA）支持，且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能，并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的更多信息，请参阅技术预览功能支持范围。

16.1. 关于 Topology Aware Lifecycle Manager 配置

Topology Aware Lifecycle Manager(TALM)管理一个或多个 OpenShift Container Platform 集群的部署 Red Hat Advanced Cluster Management(RHACM)策略。通过在大型集群网络中使用 TALM，可以使用有限制的批处理，在集群中逐步实施相关的策略。这有助于最大程度降低更新时可能造成的服务中断。使用 TALM，您可以控制以下操作：

  • 更新的时间
  • RHACM 管理的集群数量
  • 将策略应用到的受管集群的子集
  • 集群的更新顺序
  • 在集群中修复的一组策略
  • 在集群中修复的策略顺序

TALM 支持编排 OpenShift Container Platform y-stream 和 z-stream 更新，以及 y-streams 和 z-streams 上的 day-two 操作。

16.2. 关于用于 Topology Aware Lifecycle Manager 的受管策略

Topology Aware Lifecycle Manager(TALM)使用 RHACM 策略进行集群更新。

TALM 可以用来管理任何策略 CR 的推出，其中 remediationAction 字段被设置为 inform。支持的用例包括：

  • 手动创建用户策略 CR
  • 从 PolicyGenTemplate 自定义资源定义 (CRD) 自动生成的策略

对于使用手动批准更新 Operator 订阅的策略，TALM 提供了额外的功能来批准更新的 Operator 的安装。

有关受管策略的更多信息，请参阅 RHACM 文档中的策略概述。

如需有关 PolicyGenTemplate CRD 的更多信息，请参阅"使用策略和 PolicyGenTemplate 资源配置受管集群"中的"About the PolicyGenTemplate CRD"部分。

16.3. 使用 Web 控制台安装 Topology Aware Lifecycle Manager

您可以使用 OpenShift Container Platform Web 控制台安装 Topology Aware Lifecycle Manager。

先决条件

  • 安装最新版本的 RHACM Operator。
  • 使用断开连接的 regitry 设置 hub 集群。
  • 以具有 cluster-admin 特权的用户身份登录。

流程

  1. 在 OpenShift Container Platform Web 控制台中导航至 Operators → OperatorHub。
  2. 从可用的 Operator 列表中选择 Topology Aware Lifecycle Manager，然后点 Install。
  3. 保持默认的选择 Installation mode ["All namespaces on the cluster (default)"] 和 Installed Namespace ("openshift-operators") 以确保 Operator 已正确安装。
  4. 点 Install。

验证

确认安装成功：

  1. 进入到 Operators → Installed Operators 页面。
  2. 检查 Operator 是否在 All Namespaces 命名空间中，其状态为 Succeeded。

如果 Operator 没有成功安装：

  1. 导航到 Operators → Installed Operators 页面，并检查 Status 列中是否有任何错误或故障。
  2. 进入到 Workloads → Pods 页面，检查 cluster-group-upgrades-controller-manager pod 中报告问题的容器日志。

16.4. 使用 CLI 安装 Topology Aware Lifecycle Manager

您可以使用 OpenShift CLI(oc)安装 Topology Aware Lifecycle Manager(TALM)。

先决条件

  • 安装 OpenShift CLI (oc) 。
  • 安装最新版本的 RHACM Operator。
  • 使用断开连接的 registry 设置 hub 集群。
  • 以具有 cluster-admin 特权的用户身份登录。

流程

  1. 创建一个 Subscription CR：

    1. 定义 Subscription CR 并保存 YAML 文件，如 talm-subscription.yaml ： 

      apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: openshift-topology-aware-lifecycle-manager-subscription
  namespace: openshift-operators
spec:
  channel: "stable"
  name: topology-aware-lifecycle-manager
  source: redhat-operators
  sourceNamespace: openshift-marketplace

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

      $ oc create -f talm-subscription.yaml

验证

  1. 检查 CSV 资源来验证安装是否成功： 

    $ oc get csv -n openshift-operators

    输出示例

    NAME                                                      DISPLAY                            VERSION               REPLACES   PHASE
topology-aware-lifecycle-manager.4.10.0-202206301927      Topology Aware Lifecycle Manager   4.10.0-202206301927              Succeeded

  2. 验证 TALM 是否正在运行： 

    $ oc get deploy -n openshift-operators

    输出示例

    NAMESPACE                                          NAME                                             READY   UP-TO-DATE   AVAILABLE   AGE
openshift-operators                                cluster-group-upgrades-controller-manager        1/1     1            1           14s

16.5. 关于 ClusterGroupUpgrade CR

Topology Aware Lifecycle Manager(TALM)为一组集群从 ClusterGroupUpgrade CR 构建补救计划。您可以在 ClusterGroupUpgrade CR 中定义以下规格：

  • 组中的集群
  • 阻塞 ClusterGroupUpgrade CR
  • 适用的受管策略列表
  • 并发更新数
  • 适用的 Canary 更新
  • 更新前和更新之后执行的操作
  • 更新数据

当 TALM 通过对指定集群进行补救时，ClusterGroupUpgrade CR 可以具有以下状态：

  • UpgradeNotStarted
  • UpgradeCannotStart
  • UpgradeNotComplete
  • UpgradeTimedOut
  • UpgradeCompleted
  • PrecachingRequired
注意

当 TALM 完成集群更新后，集群不会在同一 ClusterGroupUpgrade CR 控制下再次更新。在以下情况下，必须创建新的 ClusterGroupUpgrade CR：

  • 当您需要再次更新集群时
  • 当集群在更新后变为与 inform 策略不符合时

16.5.1. UpgradeNotStarted 状态

ClusterGroupUpgrade CR 的初始状态是 UpgradeNotStarted。

TALM 根据以下字段构建补救计划：

  • clusterSelector 字段指定您要更新的集群标签。
  • clusters 字段指定要更新的集群列表。
  • canaries 字段指定集群进行 Canary 更新。
  • maxConcurrency 字段指定批处理中要更新的集群数量。

您可以组合使用 cluster 和 clusterSelector 字段来创建组合的集群列表。

补救计划从 canaries 字段中列出的集群开始。每个 canary 集群组成一个集群批处理。

注意

在更新 canary 集群的过程中任何错误都会停止更新过程。

在成功创建补救计划后，以及 enable 字段被设为 true 后，ClusterGroupUpgrade CR 转变为 UpgradeNotCompleted 状态 。此时，TALM 开始使用特定的受管策略更新不合规的集群。

注意

只有 ClusterGroupUpgrade CR 处于 UpgradeNotStarted 或 UpgradeCannotStart 状态时，才能更改 spec 字段。

UpgradeNotStarted 状态的 ClusterGroupUpgrade CR 示例

apiVersion: ran.openshift.io/v1alpha1
kind: ClusterGroupUpgrade
metadata:
  name: cgu-upgrade-complete
  namespace: default
spec:
  clusters: 1
  - spoke1
  enable: false
  managedPolicies: 2
  - policy1-common-cluster-version-policy
  - policy2-common-pao-sub-policy
  remediationStrategy: 3
    canaries: 4
      - spoke1
    maxConcurrency: 1 5
    timeout: 240
status: 6
  conditions:
  - message: The ClusterGroupUpgrade CR is not enabled
    reason: UpgradeNotStarted
    status: "False"
    type: Ready
  copiedPolicies:
  - cgu-upgrade-complete-policy1-common-cluster-version-policy
  - cgu-upgrade-complete-policy2-common-pao-sub-policy
  managedPoliciesForUpgrade:
  - name: policy1-common-cluster-version-policy
    namespace: default
  - name: policy2-common-pao-sub-policy
    namespace: default
  placementBindings:
  - cgu-upgrade-complete-policy1-common-cluster-version-policy
  - cgu-upgrade-complete-policy2-common-pao-sub-policy
  placementRules:
  - cgu-upgrade-complete-policy1-common-cluster-version-policy
  - cgu-upgrade-complete-policy2-common-pao-sub-policy
  remediationPlan:
  - - spoke1

1
定义要更新的集群列表。
2
列出要修复的用户定义的策略集合。
3
定义集群更新的具体信息。
4
定义可用于 canary 更新的集群。
5
定义批处理中的最大并发更新数。补救批处理数量是 canary 集群的数量，加上除 Canary 集群外的集群数量除以 maxConcurrency 值。已兼容所有受管策略的集群不包括在补救计划中。
6
显示更新状态的信息。

16.5.2. UpgradeCannotStart 状态

在 UpgradeCannotStart 状态下，因为以下原因，更新无法启动：

  • 阻塞系统中缺少的 CR
  • 阻塞还没有完成的 CR

16.5.3. UpgradeNotCompleted 状态

在 UpgradeNotCompleted 状态下，TALM 按照 UpgradeNotStarted 状态中定义的补救计划强制实施策略。

在当前批处理的所有集群与所有受管策略兼容后，对后续批处理的策略强制启动。如果批处理超时，TALM 会进入下一个批处理。批处理的超时值是 spec.timeout 字段除以补救计划中的批处理数量。

注意

受管策略会按照 ClusterGroupUpgrade CR 中的 managedPolicies 字段中列出的顺序进行应用。一个受管策略被应用于指定的集群。在指定的集群符合了当前的策略后，下一个受管策略将应用到下一个不合规的集群。

处于 UpgradeNotCompleted 状态的 ClusterGroupUpgrade CR 示例

apiVersion: ran.openshift.io/v1alpha1
kind: ClusterGroupUpgrade
metadata:
  name: cgu-upgrade-complete
  namespace: default
spec:
  clusters:
  - spoke1
  enable: true 1
  managedPolicies:
  - policy1-common-cluster-version-policy
  - policy2-common-pao-sub-policy
  remediationStrategy:
    maxConcurrency: 1
    timeout: 240
status: 2
  conditions:
  - message: The ClusterGroupUpgrade CR has upgrade policies that are still non compliant
    reason: UpgradeNotCompleted
    status: "False"
    type: Ready
  copiedPolicies:
  - cgu-upgrade-complete-policy1-common-cluster-version-policy
  - cgu-upgrade-complete-policy2-common-pao-sub-policy
  managedPoliciesForUpgrade:
  - name: policy1-common-cluster-version-policy
    namespace: default
  - name: policy2-common-pao-sub-policy
    namespace: default
  placementBindings:
  - cgu-upgrade-complete-policy1-common-cluster-version-policy
  - cgu-upgrade-complete-policy2-common-pao-sub-policy
  placementRules:
  - cgu-upgrade-complete-policy1-common-cluster-version-policy
  - cgu-upgrade-complete-policy2-common-pao-sub-policy
  remediationPlan:
  - - spoke1
  status:
    currentBatch: 1
    remediationPlanForBatch: 3
      spoke1: 0

1
当 spec.enable 字段的值为 true 时，更新会启动。
2
更新开始时，status 字段会相应变化。
3
列出批处理中的集群，以及当前应用于每个集群的策略的索引。策略的索引以 0 开头，索引遵循 status.managedPoliciesForUpgrade 列表的顺序。

16.5.4. UpgradeTimedOut 状态

在 UpgradeTimedOut 状态下，TALM 会每小时检查 ClusterGroupUpgrade CR 的所有策略是否合规。检查会一直进行，直到 ClusterGroupUpgrade CR 被删除或更新已完成。如果由于网络、CPU 或其他问题导致更新会延长，则定期检查允许更新完成。

在两个情况下，TALM 过渡到 UpgradeTimedOut 状态：

  • 在当前批处理包含 Canary 更新时，批处理中的集群不会遵循批处理超时中的所有受管策略。
  • 当集群不遵循 remediationStrategy 字段指定的 timeout 值中的受管策略时。

如果策略合规，TALM 会转换为 UpgradeCompleted 状态。

16.5.5. UpgradeCompleted 状态

在 UpgradeCompleted 状态中，集群更新已完成。

UpgradeCompleted 状态的 ClusterGroupUpgrade CR 示例

apiVersion: ran.openshift.io/v1alpha1
kind: ClusterGroupUpgrade
metadata:
  name: cgu-upgrade-complete
  namespace: default
spec:
  actions:
    afterCompletion:
      deleteObjects: true 1
  clusters:
  - spoke1
  enable: true
  managedPolicies:
  - policy1-common-cluster-version-policy
  - policy2-common-pao-sub-policy
  remediationStrategy:
    maxConcurrency: 1
    timeout: 240
status: 2
  conditions:
  - message: The ClusterGroupUpgrade CR has all clusters compliant with all the managed policies
    reason: UpgradeCompleted
    status: "True"
    type: Ready
  managedPoliciesForUpgrade:
  - name: policy1-common-cluster-version-policy
    namespace: default
  - name: policy2-common-pao-sub-policy
    namespace: default
  remediationPlan:
  - - spoke1
  status:
    remediationPlanForBatch:
      spoke1: -2 3

1
默认情况下，spec.action.afterCompletion.deleteObjects 字段的值为 true。更新完成后，TALM 删除更新期间创建的底层 RHACM 对象。这个选项是防止 RHACM hub 在成功更新后持续检查合规性。
2
status 字段显示更新成功完成。
3
显示所有策略都应用到集群。
<discreet><title>PrecachingRequired 状态</title>

在 PrecachingRequired 状态中，集群需要预先缓存的镜像，然后才能启动更新。有关预缓存功能的更多信息，请参阅"使用容器镜像预缓存功能"部分。

</discreet>

16.5.6. 阻塞 ClusterGroupUpgrade CR

您可以创建多个 ClusterGroupUpgrade CR，并控制应用程序的顺序。

例如，如果您创建了 ClusterGroupUpgrade CR C，它会阻塞 ClusterGroupUpgrade CR A 的启动，那么 ClusterGroupUpgrade CR A 将无法启动，直到 ClusterGroupUpgrade CR C 变为 UpgradeComplete 状态。

一个 ClusterGroupUpgrade CR 可以有多个阻塞 CR。在这种情况下，所有块 CR 都必须在升级当前 CR 升级前完成。

先决条件

  • 安装 Topology Aware Lifecycle Manager(TALM)。
  • 置备一个或多个受管集群。
  • 以具有 cluster-admin 特权的用户身份登录。
  • 在 hub 集群中创建 RHACM 策略。

流程

  1. 将 ClusterGroupUpgrade CR 的内容保存到 cgu-a.yaml、cgu-b.yaml 和 cgu-c.yaml 文件中。 

    apiVersion: ran.openshift.io/v1alpha1
kind: ClusterGroupUpgrade
metadata:
  name: cgu-a
  namespace: default
spec:
  blockingCRs: 1
  - name: cgu-c
    namespace: default
  clusters:
  - spoke1
  - spoke2
  - spoke3
  enable: false
  managedPolicies:
  - policy1-common-cluster-version-policy
  - policy2-common-pao-sub-policy
  - policy3-common-ptp-sub-policy
  remediationStrategy:
    canaries:
    - spoke1
    maxConcurrency: 2
    timeout: 240
status:
  conditions:
  - message: The ClusterGroupUpgrade CR is not enabled
    reason: UpgradeNotStarted
    status: "False"
    type: Ready
  copiedPolicies:
  - cgu-a-policy1-common-cluster-version-policy
  - cgu-a-policy2-common-pao-sub-policy
  - cgu-a-policy3-common-ptp-sub-policy
  managedPoliciesForUpgrade:
  - name: policy1-common-cluster-version-policy
    namespace: default
  - name: policy2-common-pao-sub-policy
    namespace: default
  - name: policy3-common-ptp-sub-policy
    namespace: default
  placementBindings:
  - cgu-a-policy1-common-cluster-version-policy
  - cgu-a-policy2-common-pao-sub-policy
  - cgu-a-policy3-common-ptp-sub-policy
  placementRules:
  - cgu-a-policy1-common-cluster-version-policy
  - cgu-a-policy2-common-pao-sub-policy
  - cgu-a-policy3-common-ptp-sub-policy
  remediationPlan:
  - - spoke1
  - - spoke2
    1
    定义阻塞 CR。cgu-a 更新无法启动，直到 cgu-c 完成后。 
    apiVersion: ran.openshift.io/v1alpha1
kind: ClusterGroupUpgrade
metadata:
  name: cgu-b
  namespace: default
spec:
  blockingCRs: 1
  - name: cgu-a
    namespace: default
  clusters:
  - spoke4
  - spoke5
  enable: false
  managedPolicies:
  - policy1-common-cluster-version-policy
  - policy2-common-pao-sub-policy
  - policy3-common-ptp-sub-policy
  - policy4-common-sriov-sub-policy
  remediationStrategy:
    maxConcurrency: 1
    timeout: 240
status:
  conditions:
  - message: The ClusterGroupUpgrade CR is not enabled
    reason: UpgradeNotStarted
    status: "False"
    type: Ready
  copiedPolicies:
  - cgu-b-policy1-common-cluster-version-policy
  - cgu-b-policy2-common-pao-sub-policy
  - cgu-b-policy3-common-ptp-sub-policy
  - cgu-b-policy4-common-sriov-sub-policy
  managedPoliciesForUpgrade:
  - name: policy1-common-cluster-version-policy
    namespace: default
  - name: policy2-common-pao-sub-policy
    namespace: default
  - name: policy3-common-ptp-sub-policy
    namespace: default
  - name: policy4-common-sriov-sub-policy
    namespace: default
  placementBindings:
  - cgu-b-policy1-common-cluster-version-policy
  - cgu-b-policy2-common-pao-sub-policy
  - cgu-b-policy3-common-ptp-sub-policy
  - cgu-b-policy4-common-sriov-sub-policy
  placementRules:
  - cgu-b-policy1-common-cluster-version-policy
  - cgu-b-policy2-common-pao-sub-policy
  - cgu-b-policy3-common-ptp-sub-policy
  - cgu-b-policy4-common-sriov-sub-policy
  remediationPlan:
  - - spoke4
  - - spoke5
  status: {}
    1
    cgu-b 更新无法启动，直到 cgu-a 完成后。 
    apiVersion: ran.openshift.io/v1alpha1
kind: ClusterGroupUpgrade
metadata:
  name: cgu-c
  namespace: default
spec: 1
  clusters:
  - spoke6
  enable: false
  managedPolicies:
  - policy1-common-cluster-version-policy
  - policy2-common-pao-sub-policy
  - policy3-common-ptp-sub-policy
  - policy4-common-sriov-sub-policy
  remediationStrategy:
    maxConcurrency: 1
    timeout: 240
status:
  conditions:
  - message: The ClusterGroupUpgrade CR is not enabled
    reason: UpgradeNotStarted
    status: "False"
    type: Ready
  copiedPolicies:
  - cgu-c-policy1-common-cluster-version-policy
  - cgu-c-policy4-common-sriov-sub-policy
  managedPoliciesCompliantBeforeUpgrade:
  - policy2-common-pao-sub-policy
  - policy3-common-ptp-sub-policy
  managedPoliciesForUpgrade:
  - name: policy1-common-cluster-version-policy
    namespace: default
  - name: policy4-common-sriov-sub-policy
    namespace: default
  placementBindings:
  - cgu-c-policy1-common-cluster-version-policy
  - cgu-c-policy4-common-sriov-sub-policy
  placementRules:
  - cgu-c-policy1-common-cluster-version-policy
  - cgu-c-policy4-common-sriov-sub-policy
  remediationPlan:
  - - spoke6
  status: {}
    1
    cgu-c 更新没有任何阻塞 CR。当 enable 字段设为 true 时，TALM 会启动 cgu-c 更新。

  2. 通过为每个相关 CR 运行以下命令创建 ClusterGroupUpgrade CR： 

    $ oc apply -f <name>.yaml

  3. 通过为每个相关 CR 运行以下命令启动更新过程： 

    $ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/<name> \
--type merge -p '{"spec":{"enable":true}}'

    以下示例显示 enable 字段设为 true 的 ClusterGroupUpgrade CR：

    带有阻塞 CR 的 cgu-a 示例

    apiVersion: ran.openshift.io/v1alpha1
kind: ClusterGroupUpgrade
metadata:
  name: cgu-a
  namespace: default
spec:
  blockingCRs:
  - name: cgu-c
    namespace: default
  clusters:
  - spoke1
  - spoke2
  - spoke3
  enable: true
  managedPolicies:
  - policy1-common-cluster-version-policy
  - policy2-common-pao-sub-policy
  - policy3-common-ptp-sub-policy
  remediationStrategy:
    canaries:
    - spoke1
    maxConcurrency: 2
    timeout: 240
status:
  conditions:
  - message: 'The ClusterGroupUpgrade CR is blocked by other CRs that have not yet
      completed: [cgu-c]' 1
    reason: UpgradeCannotStart
    status: "False"
    type: Ready
  copiedPolicies:
  - cgu-a-policy1-common-cluster-version-policy
  - cgu-a-policy2-common-pao-sub-policy
  - cgu-a-policy3-common-ptp-sub-policy
  managedPoliciesForUpgrade:
  - name: policy1-common-cluster-version-policy
    namespace: default
  - name: policy2-common-pao-sub-policy
    namespace: default
  - name: policy3-common-ptp-sub-policy
    namespace: default
  placementBindings:
  - cgu-a-policy1-common-cluster-version-policy
  - cgu-a-policy2-common-pao-sub-policy
  - cgu-a-policy3-common-ptp-sub-policy
  placementRules:
  - cgu-a-policy1-common-cluster-version-policy
  - cgu-a-policy2-common-pao-sub-policy
  - cgu-a-policy3-common-ptp-sub-policy
  remediationPlan:
  - - spoke1
  - - spoke2
  status: {}

    1
    显示阻塞 CR 的列表。

    带有阻塞 CR 的 cgu-b 示例

    apiVersion: ran.openshift.io/v1alpha1
kind: ClusterGroupUpgrade
metadata:
  name: cgu-b
  namespace: default
spec:
  blockingCRs:
  - name: cgu-a
    namespace: default
  clusters:
  - spoke4
  - spoke5
  enable: true
  managedPolicies:
  - policy1-common-cluster-version-policy
  - policy2-common-pao-sub-policy
  - policy3-common-ptp-sub-policy
  - policy4-common-sriov-sub-policy
  remediationStrategy:
    maxConcurrency: 1
    timeout: 240
status:
  conditions:
  - message: 'The ClusterGroupUpgrade CR is blocked by other CRs that have not yet
      completed: [cgu-a]' 1
    reason: UpgradeCannotStart
    status: "False"
    type: Ready
  copiedPolicies:
  - cgu-b-policy1-common-cluster-version-policy
  - cgu-b-policy2-common-pao-sub-policy
  - cgu-b-policy3-common-ptp-sub-policy
  - cgu-b-policy4-common-sriov-sub-policy
  managedPoliciesForUpgrade:
  - name: policy1-common-cluster-version-policy
    namespace: default
  - name: policy2-common-pao-sub-policy
    namespace: default
  - name: policy3-common-ptp-sub-policy
    namespace: default
  - name: policy4-common-sriov-sub-policy
    namespace: default
  placementBindings:
  - cgu-b-policy1-common-cluster-version-policy
  - cgu-b-policy2-common-pao-sub-policy
  - cgu-b-policy3-common-ptp-sub-policy
  - cgu-b-policy4-common-sriov-sub-policy
  placementRules:
  - cgu-b-policy1-common-cluster-version-policy
  - cgu-b-policy2-common-pao-sub-policy
  - cgu-b-policy3-common-ptp-sub-policy
  - cgu-b-policy4-common-sriov-sub-policy
  remediationPlan:
  - - spoke4
  - - spoke5
  status: {}

    1
    显示阻塞 CR 的列表。

    带有阻塞 CR 的 cgu-c 示例

    apiVersion: ran.openshift.io/v1alpha1
kind: ClusterGroupUpgrade
metadata:
  name: cgu-c
  namespace: default
spec:
  clusters:
  - spoke6
  enable: true
  managedPolicies:
  - policy1-common-cluster-version-policy
  - policy2-common-pao-sub-policy
  - policy3-common-ptp-sub-policy
  - policy4-common-sriov-sub-policy
  remediationStrategy:
    maxConcurrency: 1
    timeout: 240
status:
  conditions:
  - message: The ClusterGroupUpgrade CR has upgrade policies that are still non compliant 1
    reason: UpgradeNotCompleted
    status: "False"
    type: Ready
  copiedPolicies:
  - cgu-c-policy1-common-cluster-version-policy
  - cgu-c-policy4-common-sriov-sub-policy
  managedPoliciesCompliantBeforeUpgrade:
  - policy2-common-pao-sub-policy
  - policy3-common-ptp-sub-policy
  managedPoliciesForUpgrade:
  - name: policy1-common-cluster-version-policy
    namespace: default
  - name: policy4-common-sriov-sub-policy
    namespace: default
  placementBindings:
  - cgu-c-policy1-common-cluster-version-policy
  - cgu-c-policy4-common-sriov-sub-policy
  placementRules:
  - cgu-c-policy1-common-cluster-version-policy
  - cgu-c-policy4-common-sriov-sub-policy
  remediationPlan:
  - - spoke6
  status:
    currentBatch: 1
    remediationPlanForBatch:
      spoke6: 0

    1
    cgu-c 更新没有任何阻塞 CR。

16.6. 更新受管集群上的策略

Topology Aware Lifecycle Manager(TALM)修复了在 ClusterGroupUpgrade CR 中指定的集群的 inform 策略。TALM 通过生成受管 RHACM 策略的 enforce 副本来修复 inform 策略。每个复制的策略都有自己的对应的 RHACM 放置规则和 RHACM 放置绑定。

例如，TALM 将每个集群从当前批处理添加到与适用受管策略相对应的放置规则。如果集群已与策略兼容，TALM 会在兼容集群上跳过应用该策略。TALM 然后进入到将下一个策略应用到还没有合规的集群的步骤。TALM 在批处理中完成更新后，所有集群都会从与复制策略关联的放置规则中删除。然后，下一个批处理的更新会启动。

如果 spoke 集群没有向 RHACM 报告任何合规状态，则 hub 集群上的受管策略可能会缺少 TALM 需要的状态信息。TALM 通过以下方法处理这些情况：

  • 如果缺少策略的 status.compliant 字段，TALM 忽略策略并添加日志条目。然后，TALM 继续查看策略的 status.status 字段。
  • 如果缺少策略的 status.status，TALM 会生成错误。
  • 如果策略的 status.status 字段中缺少集群的合规状态，TALM 会将该集群视为与该策略不兼容。

有关 RHACM 策略的更多信息，请参阅策略概述。

其他资源

如需有关 PolicyGenTemplate CRD 的更多信息，请参阅关于 PolicyGenTemplate CRD。

16.6.1. 将更新策略应用到受管集群

您可以通过应用策略来更新受管集群。

先决条件

  • 安装 Topology Aware Lifecycle Manager(TALM)。
  • 置备一个或多个受管集群。
  • 以具有 cluster-admin 特权的用户身份登录。
  • 在 hub 集群中创建 RHACM 策略。

流程

  1. 将 ClusterGroupUpgrade CR 的内容保存到 cgu-1.yaml 文件中。 

    apiVersion: ran.openshift.io/v1alpha1
kind: ClusterGroupUpgrade
metadata:
  name: cgu-1
  namespace: default
spec:
  managedPolicies: 1
    - policy1-common-cluster-version-policy
    - policy2-common-pao-sub-policy
    - policy3-common-ptp-sub-policy
    - policy4-common-sriov-sub-policy
  enable: false
  clusters: 2
  - spoke1
  - spoke2
  - spoke5
  - spoke6
  remediationStrategy:
    maxConcurrency: 2 3
    timeout: 240 4
    1
    要应用的策略的名称。
    2
    要更新的集群列表。
    3
    maxConcurrency 字段表示同时更新的集群数量。
    4
    更新超时（以分钟为单位）。

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

    $ oc create -f cgu-1.yaml

    1. 运行以下命令，检查 hub 集群中是否已创建 ClusterGroupUpgrade CR： 

      $ oc get cgu --all-namespaces

      输出示例

      NAMESPACE   NAME      AGE
default     cgu-1     8m55s

    2. 运行以下命令检查更新的状态： 

      $ oc get cgu -n default cgu-1 -ojsonpath='{.status}' | jq

      输出示例

      {
  "computedMaxConcurrency": 2,
  "conditions": [
    {
      "lastTransitionTime": "2022-02-25T15:34:07Z",
      "message": "The ClusterGroupUpgrade CR is not enabled", 1
      "reason": "UpgradeNotStarted",
      "status": "False",
      "type": "Ready"
    }
  ],
  "copiedPolicies": [
    "cgu-policy1-common-cluster-version-policy",
    "cgu-policy2-common-pao-sub-policy",
    "cgu-policy3-common-ptp-sub-policy",
    "cgu-policy4-common-sriov-sub-policy"
  ],
  "managedPoliciesContent": {
    "policy1-common-cluster-version-policy": "null",
    "policy2-common-pao-sub-policy": "[{\"kind\":\"Subscription\",\"name\":\"performance-addon-operator\",\"namespace\":\"openshift-performance-addon-operator\"}]",
    "policy3-common-ptp-sub-policy": "[{\"kind\":\"Subscription\",\"name\":\"ptp-operator-subscription\",\"namespace\":\"openshift-ptp\"}]",
    "policy4-common-sriov-sub-policy": "[{\"kind\":\"Subscription\",\"name\":\"sriov-network-operator-subscription\",\"namespace\":\"openshift-sriov-network-operator\"}]"
  },
  "managedPoliciesForUpgrade": [
    {
      "name": "policy1-common-cluster-version-policy",
      "namespace": "default"
    },
    {
      "name": "policy2-common-pao-sub-policy",
      "namespace": "default"
    },
    {
      "name": "policy3-common-ptp-sub-policy",
      "namespace": "default"
    },
    {
      "name": "policy4-common-sriov-sub-policy",
      "namespace": "default"
    }
  ],
  "managedPoliciesNs": {
    "policy1-common-cluster-version-policy": "default",
    "policy2-common-pao-sub-policy": "default",
    "policy3-common-ptp-sub-policy": "default",
    "policy4-common-sriov-sub-policy": "default"
  },
  "placementBindings": [
    "cgu-policy1-common-cluster-version-policy",
    "cgu-policy2-common-pao-sub-policy",
    "cgu-policy3-common-ptp-sub-policy",
    "cgu-policy4-common-sriov-sub-policy"
  ],
  "placementRules": [
    "cgu-policy1-common-cluster-version-policy",
    "cgu-policy2-common-pao-sub-policy",
    "cgu-policy3-common-ptp-sub-policy",
    "cgu-policy4-common-sriov-sub-policy"
  ],
  "precaching": {
    "spec": {}
  },
  "remediationPlan": [
    [
      "spoke1",
      "spoke2"
    ],
    [
      "spoke5",
      "spoke6"
    ]
  ],
  "status": {}
}

      1
      ClusterGroupUpgrade CR 中的 spec.enable 字段设置为 false。

    3. 运行以下命令，检查策略的状态： 

      $ oc get policies -A

      输出示例

      NAMESPACE   NAME                                                 REMEDIATION ACTION   COMPLIANCE STATE   AGE
default     cgu-policy1-common-cluster-version-policy            enforce                                 17m 1
default     cgu-policy2-common-pao-sub-policy                    enforce                                 17m
default     cgu-policy3-common-ptp-sub-policy                    enforce                                 17m
default     cgu-policy4-common-sriov-sub-policy                  enforce                                 17m
default     policy1-common-cluster-version-policy                inform               NonCompliant       15h
default     policy2-common-pao-sub-policy                        inform               NonCompliant       15h
default     policy3-common-ptp-sub-policy                        inform               NonCompliant       18m
default     policy4-common-sriov-sub-policy                      inform               NonCompliant       18m

      1
      目前在集群中应用的策略的 spec.remediationAction 字段被设置为 enforce。在更新过程中，来自 ClusterGroupUpgrade CR 的 inform 模式的受管策略会处于 inform 模式。

  3. 运行以下命令，将 spec.enable 字段的值更改为 true ： 

    $ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-1 \
--patch '{"spec":{"enable":true}}' --type=merge

验证

  1. 运行以下命令，再次检查更新的状态： 

    $ oc get cgu -n default cgu-1 -ojsonpath='{.status}' | jq

    输出示例

    {
  "computedMaxConcurrency": 2,
  "conditions": [ 1
    {
      "lastTransitionTime": "2022-02-25T15:34:07Z",
      "message": "The ClusterGroupUpgrade CR has upgrade policies that are still non compliant",
      "reason": "UpgradeNotCompleted",
      "status": "False",
      "type": "Ready"
    }
  ],
  "copiedPolicies": [
    "cgu-policy1-common-cluster-version-policy",
    "cgu-policy2-common-pao-sub-policy",
    "cgu-policy3-common-ptp-sub-policy",
    "cgu-policy4-common-sriov-sub-policy"
  ],
  "managedPoliciesContent": {
    "policy1-common-cluster-version-policy": "null",
    "policy2-common-pao-sub-policy": "[{\"kind\":\"Subscription\",\"name\":\"performance-addon-operator\",\"namespace\":\"openshift-performance-addon-operator\"}]",
    "policy3-common-ptp-sub-policy": "[{\"kind\":\"Subscription\",\"name\":\"ptp-operator-subscription\",\"namespace\":\"openshift-ptp\"}]",
    "policy4-common-sriov-sub-policy": "[{\"kind\":\"Subscription\",\"name\":\"sriov-network-operator-subscription\",\"namespace\":\"openshift-sriov-network-operator\"}]"
  },
  "managedPoliciesForUpgrade": [
    {
      "name": "policy1-common-cluster-version-policy",
      "namespace": "default"
    },
    {
      "name": "policy2-common-pao-sub-policy",
      "namespace": "default"
    },
    {
      "name": "policy3-common-ptp-sub-policy",
      "namespace": "default"
    },
    {
      "name": "policy4-common-sriov-sub-policy",
      "namespace": "default"
    }
  ],
  "managedPoliciesNs": {
    "policy1-common-cluster-version-policy": "default",
    "policy2-common-pao-sub-policy": "default",
    "policy3-common-ptp-sub-policy": "default",
    "policy4-common-sriov-sub-policy": "default"
  },
  "placementBindings": [
    "cgu-policy1-common-cluster-version-policy",
    "cgu-policy2-common-pao-sub-policy",
    "cgu-policy3-common-ptp-sub-policy",
    "cgu-policy4-common-sriov-sub-policy"
  ],
  "placementRules": [
    "cgu-policy1-common-cluster-version-policy",
    "cgu-policy2-common-pao-sub-policy",
    "cgu-policy3-common-ptp-sub-policy",
    "cgu-policy4-common-sriov-sub-policy"
  ],
  "precaching": {
    "spec": {}
  },
  "remediationPlan": [
    [
      "spoke1",
      "spoke2"
    ],
    [
      "spoke5",
      "spoke6"
    ]
  ],
  "status": {
    "currentBatch": 1,
    "currentBatchStartedAt": "2022-02-25T15:54:16Z",
    "remediationPlanForBatch": {
      "spoke1": 0,
      "spoke2": 1
    },
    "startedAt": "2022-02-25T15:54:16Z"
  }
}

    1
    反映当前批处理的更新进度。再次运行该命令以接收有关进度的更新信息。

  2. 如果策略包含 Operator 订阅，您可以在单节点集群中直接检查安装进度。

    1. 运行以下命令，导出用于检查安装的单节点集群的 KUBECONFIG 文件： 

      $ export KUBECONFIG=<cluster_kubeconfig_absolute_path>

    2. 运行以下命令，检查单节点集群中存在的所有订阅，并在您要通过 ClusterGroupUpgrade CR 安装的策略中查找您要通过 ClusterGroupUpgrade CR 安装的订阅： 

      $ oc get subs -A | grep -i <subscription_name>

      cluster-logging 策略的输出示例

      NAMESPACE                              NAME                         PACKAGE                      SOURCE             CHANNEL
openshift-logging                      cluster-logging              cluster-logging              redhat-operators   stable

  3. 如果其中一个受管策略包含 ClusterVersion CR，则根据 spoke 集群运行以下命令来检查当前批处理中的平台更新状态： 

    $ oc get clusterversion

    输出示例

    NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.9.5     True        True          43s     Working towards 4.9.7: 71 of 735 done (9% complete)

  4. 运行以下命令检查 Operator 订阅： 

    $ oc get subs -n <operator-namespace> <operator-subscription> -ojsonpath="{.status}"

  5. 运行以下命令，检查与所需订阅关联的单节点集群中是否存在安装计划： 

    $ oc get installplan -n <subscription_namespace>

    cluster-logging Operator 的输出示例

    NAMESPACE                              NAME            CSV                                 APPROVAL   APPROVED
openshift-logging                      install-6khtw   cluster-logging.5.3.3-4             Manual     true 1

    1
    安装计划在 TALM 批准安装计划后将其 Approval 字段设置为 Manual，其 Approved 字段会从 false 改为 true。
    注意

    当 TALM 修复包含订阅的策略时，它会自动批准附加到该订阅的任何安装计划。如果需要多个安装计划将 Operator 升级到最新的已知版本，TALM 可能会批准多个安装计划，通过一个或多个中间版本进行升级以进入最终版本。

  6. 运行以下命令，检查正在安装 ClusterGroupUpgrade 的策略的 Operator 的集群服务版本是否已进入 Succeeded 阶段： 

    $ oc get csv -n <operator_namespace>

    OpenShift Logging Operator 的输出示例

    NAME                    DISPLAY                     VERSION   REPLACES   PHASE
cluster-logging.5.4.2   Red Hat OpenShift Logging   5.4.2                Succeeded

16.7. 使用容器镜像预缓存功能

集群可能具有有限的带宽来访问容器镜像 registry，这可能会在更新完成前造成超时。

注意

TALM 不会设置更新的时间。您可以在通过手动应用程序或外部自动化进行更新时应用 ClusterGroupUpgrade CR。

当 preCaching 字段在 ClusterGroupUpgrade CR 中被设置为 true 时，容器镜像预缓存会启动。在成功预缓存后，您可以启动补救策略。当 enable 字段设置为 true 时，补救操作会启动。

预缓存过程可以处于以下状态：

PrecacheNotStarted

这是所有集群在第一次协调时会自动分配给 ClusterGroupUpgrade CR 的初始状态。

在这个状态中，TALM 会删除来自之前更新中所有 spoke 集群的预缓存命名空间和 hub 查看资源。然后，TALM 为 spoke 创建一个新的 ManagedClusterView 资源，以便在 PrecachePreparing 状态验证删除。

PrecachePreparing
清理之前不完整更新中的所有剩余的资源，资源正在进行中。
PrecacheStarting
预缓存任务前提条件并创建了作业。
PrecacheActive
该作业的状态为"Active"状态。
PrecacheSucceeded
pre-cache（预缓存）作业已成功。
PrecacheTimeout
工件预预缓存已完成。
PrecacheUnrecoverableError
作业以非零退出代码结束。

16.7.1. 使用预缓存创建 ClusterGroupUpgrade CR

预缓存功能允许在更新开始前在 spoke 集群中显示所需的容器镜像。

先决条件

  • 安装 Topology Aware Lifecycle Manager(TALM)。
  • 置备一个或多个受管集群。
  • 以具有 cluster-admin 特权的用户身份登录。

流程

  1. 在 clustergroupupgrades-group-du.yaml 文件中将 preCaching 字段设置为 true 来保存 ClusterGroupUpgrade CR 的内容： 

    apiVersion: ran.openshift.io/v1alpha1
kind: ClusterGroupUpgrade
metadata:
  name: du-upgrade-4918
  namespace: ztp-group-du-sno
spec:
  preCaching: true 1
  clusters:
  - cnfdb1
  - cnfdb2
  enable: false
  managedPolicies:
  - du-upgrade-platform-upgrade
  remediationStrategy:
    maxConcurrency: 2
    timeout: 240
    1
    preCaching 字段设为 true，它允许 TALM 在开始更新前拉取容器镜像。

  2. 当您要启动更新时，通过运行以下命令应用 ClusterGroupUpgrade CR： 

    $ oc apply -f clustergroupupgrades-group-du.yaml

验证

  1. 运行以下命令，检查 hub 集群中是否存在 ClusterGroupUpgrade CR： 

    $ oc get cgu -A

    输出示例

    NAMESPACE          NAME              AGE
ztp-group-du-sno   du-upgrade-4918   10s 1

    1
    CR 被创建。

  2. 运行以下命令，检查预缓存任务的状态： 

    $ oc get cgu -n ztp-group-du-sno du-upgrade-4918 -o jsonpath='{.status}'

    输出示例

    {
  "conditions": [
    {
      "lastTransitionTime": "2022-01-27T19:07:24Z",
      "message": "Precaching is not completed (required)", 1
      "reason": "PrecachingRequired",
      "status": "False",
      "type": "Ready"
    },
    {
      "lastTransitionTime": "2022-01-27T19:07:24Z",
      "message": "Precaching is required and not done",
      "reason": "PrecachingNotDone",
      "status": "False",
      "type": "PrecachingDone"
    },
    {
      "lastTransitionTime": "2022-01-27T19:07:34Z",
      "message": "Pre-caching spec is valid and consistent",
      "reason": "PrecacheSpecIsWellFormed",
      "status": "True",
      "type": "PrecacheSpecValid"
    }
  ],
  "precaching": {
    "clusters": [
      "cnfdb1" 2
    ],
    "spec": {
      "platformImage": "image.example.io"},
    "status": {
      "cnfdb1": "Active"}
    }
}

    1
    显示更新正在进行中。
    2
    显示已识别的集群列表。

  3. 在 spoke 集群中运行以下命令来检查预缓存作业的状态： 

    $ oc get jobs,pods -n openshift-talm-pre-cache

    输出示例

    NAME                  COMPLETIONS   DURATION   AGE
job.batch/pre-cache   0/1           3m10s      3m10s

NAME                     READY   STATUS    RESTARTS   AGE
pod/pre-cache--1-9bmlr   1/1     Running   0          3m10s

  4. 运行以下命令，检查 ClusterGroupUpgrade CR 的状态： 

    $ oc get cgu -n ztp-group-du-sno du-upgrade-4918 -o jsonpath='{.status}'

    输出示例

    "conditions": [
    {
      "lastTransitionTime": "2022-01-27T19:30:41Z",
      "message": "The ClusterGroupUpgrade CR has all clusters compliant with all the managed policies",
      "reason": "UpgradeCompleted",
      "status": "True",
      "type": "Ready"
    },
    {
      "lastTransitionTime": "2022-01-27T19:28:57Z",
      "message": "Precaching is completed",
      "reason": "PrecachingCompleted",
      "status": "True",
      "type": "PrecachingDone" 1
    }

    1
    预缓存任务已完成。

16.8. 对 Topology Aware Lifecycle Manager 进行故障排除

Topology Aware Lifecycle Manager(TALM)是一个 OpenShift Container Platform Operator，用于修复 RHACM 策略。出现问题时，使用 oc adm must-gather 命令来收集详情和日志，并采取调试问题的步骤。

有关相关主题的更多信息，请参阅以下文档：

16.8.1. 常规故障排除

您可以通过查看以下问题来确定问题的原因：

为确保 ClusterGroupUpgrade 配置可以正常工作，您可以执行以下操作：

  1. 创建 ClusterGroupUpgrade CR，并将 spec.enable 字段设置为 false。
  2. 等待状态更新，再完成故障排除问题。
  3. 如果所有内容都如预期，在 ClusterGroupUpgrade CR 中将 spec.enable 字段设置为 true。
警告

在 ClusterUpgradeGroup CR 中将 spec.enable 字段设置为 true 后，更新过程会启动，您无法再编辑 CR 的 spec 字段。

16.8.2. 无法修改 ClusterUpgradeGroup CR

问题
在启用更新后，您无法编辑 ClusterUpgradeGroup CR。
解决方案

通过执行以下步骤来重启操作：

  1. 运行以下命令删除旧 ClusterGroupUpgrade CR： 

    $ oc delete cgu -n <ClusterGroupUpgradeCR_namespace> <ClusterGroupUpgradeCR_name>

  2. 检查并修复受管集群和策略的现有问题。

    1. 确保所有集群都是受管集群并可用。
    2. 确保所有策略都存在，并将 spec.remediationAction 字段设置为 inform。

  3. 使用正确的配置创建一个新的 ClusterGroupUpgrade CR。 

    $ oc apply -f <ClusterGroupUpgradeCR_YAML>

16.8.3. 受管策略

检查系统中的受管策略

问题
您需要检查系统中是否有正确的受管策略。
解决方案

运行以下命令: 

$ oc get cgu lab-upgrade -ojsonpath='{.spec.managedPolicies}'

输出示例

["group-du-sno-validator-du-validator-policy", "policy2-common-pao-sub-policy", "policy3-common-ptp-sub-policy"]

检查 remediationAction 模式

问题
您要检查在受管策略的 spec 中是否将 remediationAction 字段设置为 inform。
解决方案

运行以下命令: 

$ oc get policies --all-namespaces

输出示例

NAMESPACE   NAME                                                 REMEDIATION ACTION   COMPLIANCE STATE   AGE
default     policy1-common-cluster-version-policy                inform               NonCompliant       5d21h
default     policy2-common-pao-sub-policy                        inform               Compliant          5d21h
default     policy3-common-ptp-sub-policy                        inform               NonCompliant       5d21h
default     policy4-common-sriov-sub-policy                      inform               NonCompliant       5d21h

检查策略合规状态

问题
您需要检查策略的合规性状态。
解决方案

运行以下命令: 

$ oc get policies --all-namespaces

输出示例

NAMESPACE   NAME                                                 REMEDIATION ACTION   COMPLIANCE STATE   AGE
default     policy1-common-cluster-version-policy                inform               NonCompliant       5d21h
default     policy2-common-pao-sub-policy                        inform               Compliant          5d21h
default     policy3-common-ptp-sub-policy                        inform               NonCompliant       5d21h
default     policy4-common-sriov-sub-policy                      inform               NonCompliant       5d21h

16.8.4. Clusters

检查是否有受管集群
问题
您需要检查 ClusterGroupUpgrade CR 中的集群是受管集群。
解决方案

运行以下命令: 

$ oc get managedclusters

输出示例

NAME            HUB ACCEPTED   MANAGED CLUSTER URLS                    JOINED   AVAILABLE   AGE
local-cluster   true           https://api.hub.example.com:6443        True     Unknown     13d
spoke1          true           https://api.spoke1.example.com:6443     True     True        13d
spoke3          true           https://api.spoke3.example.com:6443     True     True        27h

  1. 或者，检查 TALM manager 日志：

    1. 运行以下命令，获取 TALM Manager 的名称： 

      $ oc get pod -n openshift-operators

      输出示例

      NAME                                                         READY   STATUS    RESTARTS   AGE
cluster-group-upgrades-controller-manager-75bcc7484d-8k8xp   2/2     Running   0          45m

    2. 运行以下命令检查 TALM manager 日志： 

      $ oc logs -n openshift-operators \
cluster-group-upgrades-controller-manager-75bcc7484d-8k8xp -c manager

      输出示例

      ERROR	controller-runtime.manager.controller.clustergroupupgrade	Reconciler error	{"reconciler group": "ran.openshift.io", "reconciler kind": "ClusterGroupUpgrade", "name": "lab-upgrade", "namespace": "default", "error": "Cluster spoke5555 is not a ManagedCluster"} 1
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem

      1
      错误消息显示集群不是受管集群。
检查受管集群是否可用
问题
您需要检查 ClusterGroupUpgrade CR 中指定的受管集群是否可用。
解决方案

运行以下命令: 

$ oc get managedclusters

输出示例

NAME            HUB ACCEPTED   MANAGED CLUSTER URLS                    JOINED   AVAILABLE   AGE
local-cluster   true           https://api.hub.testlab.com:6443        True     Unknown     13d
spoke1          true           https://api.spoke1.testlab.com:6443     True     True        13d 1
spoke3          true           https://api.spoke3.testlab.com:6443     True     True        27h 2

1 2
受管集群的 AVAILABLE 字段的值是 True。
检查 clusterSelector
问题
您需要检查 clusterSelector 字段是否至少在 ClusterGroupUpgrade CR 中指定。
解决方案

运行以下命令: 

$ oc get managedcluster --selector=upgrade=true 1
1
要更新的集群标签是 upgrade:true。

输出示例

NAME            HUB ACCEPTED   MANAGED CLUSTER URLS                     JOINED    AVAILABLE   AGE
spoke1          true           https://api.spoke1.testlab.com:6443      True     True        13d
spoke3          true           https://api.spoke3.testlab.com:6443      True     True        27h

检查是否有 canary 集群
问题

您要检查集群列表中是否存在 Canary 集群。

ClusterGroupUpgrade CR 示例

spec:
    clusters:
    - spoke1
    - spoke3
    clusterSelector:
    - upgrade2=true
    remediationStrategy:
        canaries:
        - spoke3
        maxConcurrency: 2
        timeout: 240

解决方案

运行以下命令： 

$ oc get cgu lab-upgrade -ojsonpath='{.spec.clusters}'

输出示例

["spoke1", "spoke3"]

  1. 运行以下命令，检查与 clusterSelector 标签匹配的集群列表中是否存在 canary 集群： 

    $ oc get managedcluster --selector=upgrade=true

    输出示例

    NAME            HUB ACCEPTED   MANAGED CLUSTER URLS   JOINED    AVAILABLE   AGE
spoke1          true           https://api.spoke1.testlab.com:6443   True     True        13d
spoke3          true           https://api.spoke3.testlab.com:6443   True     True        27h

注意

集群可以出现在 spec.clusters 中，还可与 spec.clusterSelecter 标签匹配。

检查 spoke 集群上的预缓存状态

  1. 在 spoke 集群中运行以下命令来检查预缓存的状态： 

    $ oc get jobs,pods -n openshift-talo-pre-cache

16.8.5. 补救策略

检查 ClusterGroupUpgrade CR 中是否存在 remediationStrategy
问题
您需要检查 ClusterGroupUpgrade CR 是否存在 remediationStrategy。
解决方案

运行以下命令: 

$ oc get cgu lab-upgrade -ojsonpath='{.spec.remediationStrategy}'

输出示例

{"maxConcurrency":2, "timeout":240}

检查 ClusterGroupUpgrade CR 中是否指定了 maxConcurrency
问题
您需要检查是否在 ClusterGroupUpgrade CR 中指定 maxConcurrency。
解决方案

运行以下命令: 

$ oc get cgu lab-upgrade -ojsonpath='{.spec.remediationStrategy.maxConcurrency}'

输出示例

2

16.8.6. Topology Aware Lifecycle Manager

检查 ClusterGroupUpgrade CR 中的条件消息和状态
问题
您要检查 ClusterGroupUpgrade CR 中的 status.conditions 字段的值。
解决方案

运行以下命令: 

$ oc get cgu lab-upgrade -ojsonpath='{.status.conditions}'

输出示例

{"lastTransitionTime":"2022-02-17T22:25:28Z", "message":"The ClusterGroupUpgrade CR has managed policies that are missing:[policyThatDoesntExist]", "reason":"UpgradeCannotStart", "status":"False", "type":"Ready"}

检查对应的复制策略
问题
您需要检查 status.managedPoliciesForUpgrade 的每个策略是否具有 status.copiedPolicies 对应的策略。
解决方案

运行以下命令: 

$ oc get cgu lab-upgrade -oyaml

输出示例

status:
  …
  copiedPolicies:
  - lab-upgrade-policy3-common-ptp-sub-policy
  managedPoliciesForUpgrade:
  - name: policy3-common-ptp-sub-policy
    namespace: default

检查 status.remediationPlan 是否已计算
问题
您需要检查 status.remediationPlan 是否被计算。
解决方案

运行以下命令: 

$ oc get cgu lab-upgrade -ojsonpath='{.status.remediationPlan}'

输出示例

[["spoke2", "spoke3"]]

TALM manager 容器中的错误
问题
您要检查 TALM 的 manager 容器的日志。
解决方案

运行以下命令: 

$ oc logs -n openshift-operators \
cluster-group-upgrades-controller-manager-75bcc7484d-8k8xp -c manager

输出示例

ERROR	controller-runtime.manager.controller.clustergroupupgrade	Reconciler error	{"reconciler group": "ran.openshift.io", "reconciler kind": "ClusterGroupUpgrade", "name": "lab-upgrade", "namespace": "default", "error": "Cluster spoke5555 is not a ManagedCluster"} 1
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem

1
显示错误。

其他资源

第 17 章 创建性能配置集

了解 Performance Profile Creator（PPC），以及如何使用它来创建性能配置集。

17.1. 关于性能配置集创建器

Performance Profile Creator（PPC）是一个命令行工具，附带 Performance Addon Operator，用于创建性能配置集。该工具消耗来自集群的 must-gather 数据以及几个用户提供的配置集参数。PPC 生成适合您的硬件和拓扑的性能配置集。

该工具使用以下方法之一运行：

  • 调用 podman
  • 调用一个打包程序脚本

17.1.1. 使用 must-gather 命令收集有关集群的数据

Performance Profile Creator（PPC）工具需要 must-gather 数据。作为集群管理员，运行 must-gather 命令来捕获集群的信息。

先决条件

  • 使用具有 cluster-admin 角色的用户访问集群。
  • 访问 Performance Addon Operator 镜像。
  • 已安装 OpenShift CLI（oc）。

流程

  1. 可选：验证匹配的机器配置池是否存在标签： 

    $ oc describe mcp/worker-rt

    输出示例

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

  2. 如果匹配的标签不存在，为与 MCP 名称匹配的机器配置池(MCP) 添加标签： 

    $ oc label mcp <mcp_name> <mcp_name>=""
  3. 进入要存储 must-gather 数据的目录。

  4. 在集群中运行 must-gather： 

    $ oc adm must-gather --image=<PAO_image> --dest-dir=<dir>
    注意

    must-gather 命令必须使用 performance-addon-operator-must-gather 镜像运行。输出可以被压缩（可选）。如果您正在运行性能配置集 Creator wrapper 脚本，则需要压缩输出。

    示例

    $ oc adm must-gather --image=registry.redhat.io/openshift4/performance-addon-operator-must-gather-rhel8:v4.10 --dest-dir=must-gather

  5. 从 must-gather 目录创建一个压缩文件： 

    $ tar cvaf must-gather.tar.gz must-gather/

17.1.2. 使用 podman 运行 Performance Profile Creator

作为集群管理员，您可以运行 podman 和 Performance Profile Creator 来创建性能配置集。

先决条件

  • 使用具有 cluster-admin 角色的用户访问集群。
  • 在裸机硬件上安装的集群。
  • 安装了 podman 和 OpenShift CLI（oc）的节点。

流程

  1. 检查机器配置池： 

    $ oc get mcp

    输出示例

    NAME         CONFIG                                                 UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
master       rendered-master-acd1358917e9f98cbdb599aea622d78b       True      False      False      3              3                   3                     0                      22h
worker-cnf   rendered-worker-cnf-1d871ac76e1951d32b2fe92369879826   False     True       False      2              1                   1                     0                      22h

  2. 使用 Podman 向 registry.redhat.io 进行身份验证： 

    $ podman login registry.redhat.io
    Username: <username>
Password: <password>

  3. 可选：显示 PPC 工具的帮助信息： 

    $ podman run --entrypoint performance-profile-creator registry.redhat.io/openshift4/performance-addon-rhel8-operator:v4.10 -h

    输出示例

    A tool that automates creation of Performance Profiles

Usage:
  performance-profile-creator [flags]

Flags:
      --disable-ht                        Disable Hyperthreading
  -h, --help                              help for performance-profile-creator
      --info string                       Show cluster information; requires --must-gather-dir-path, ignore the other arguments. [Valid values: log, json] (default "log")
      --mcp-name string                   MCP name corresponding to the target machines (required)
      --must-gather-dir-path string       Must gather directory path (default "must-gather")
      --power-consumption-mode string     The power consumption mode.  [Valid values: default, low-latency, ultra-low-latency] (default "default")
      --profile-name string               Name of the performance profile to be created (default "performance")
      --reserved-cpu-count int            Number of reserved CPUs (required)
      --rt-kernel                         Enable Real Time Kernel (required)
      --split-reserved-cpus-across-numa   Split the Reserved CPUs across NUMA nodes
      --topology-manager-policy string    Kubelet Topology Manager Policy of the performance profile to be created. [Valid values: single-numa-node, best-effort, restricted] (default "restricted")
      --user-level-networking             Run with User level Networking(DPDK) enabled

  4. 以发现模式运行 Performance Profile Creator 工具：

    注意

    发现模式使用 must-gather 的输出来检查您的集群。生成的输出包括以下信息：

    • 使用分配的 CPU ID 进行 NUMA 单元分区
    • 是否启用超线程

    使用此信息，您可以为提供给 Performance Profile Creator 工具的部分参数设置适当的值。 

    $ podman run --entrypoint performance-profile-creator -v /must-gather:/must-gather:z registry.redhat.io/openshift4/performance-addon-rhel8-operator:v4.10 --info log --must-gather-dir-path /must-gather
    注意

    此命令使用性能配置集创建器作为 podman 的新入口点。它将主机的 must-gather 数据映射到容器镜像，并调用所需的用户提供的配置集参数来生成 my-performance-profile.yaml 文件。

    -v 选项可以是到以下的任一路径：

    • must-gather 输出目录
    • 包含 must-gather 解压缩 tarball 的现有目录

    info 选项要求值指定输出格式。可能的值有 log 和 JSON。JSON 格式被保留用于调试。

  5. 运行 podman： 

    $ podman run --entrypoint performance-profile-creator -v /must-gather:/must-gather:z registry.redhat.io/openshift4/performance-addon-rhel8-operator:v4.10 --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=ultra-low-latency > my-performance-profile.yaml
    注意

    Performance Profile Creator 参数显示在 Performance Profile Creator 参数表中。需要以下参数：

    • reserved-cpu-count
    • mcp-name
    • rt-kernel

    本例中的 mcp-name 参数根据 oc get mcp 命令的输出设置为 worker-cnf。对于单节点 OpenShift，请使用 --mcp-name=master。

  6. 查看创建的 YAML 文件： 

    $ cat my-performance-profile.yaml

    输出示例

    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: 1,3,5,7,9,11,13,15,17,19-39,41,43,45,47,49,51,53,55,57,59-79
    reserved: 0,2,4,6,8,10,12,14,16,18,40,42,44,46,48,50,52,54,56,58
  nodeSelector:
    node-role.kubernetes.io/worker-cnf: ""
  numa:
    topologyPolicy: single-numa-node
  realTimeKernel:
    enabled: true

  7. 应用生成的配置集：

    注意

    在应用配置集前安装 Performance Addon Operator。 

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

17.1.2.1. 如何运行 podman 创建性能配置集

以下示例演示了如何运行 podman 来创建具有 20 个保留 CPU 的性能配置集，这些 CPU 将在 NUMA 节点之间拆分。

节点硬件配置：

  • 80 个 CPU
  • 启用超线程
  • 两个 NUMA 节点
  • 编号为偶数的 CPU 在 NUMA 节点 0 上运行，编号为奇数的 CPU 在 NUMA 节点 1 上运行

运行 podman 以创建性能配置集： 

$ podman run --entrypoint performance-profile-creator -v /must-gather:/must-gather:z registry.redhat.io/openshift4/performance-addon-rhel8-operator:v4.10 --mcp-name=worker-cnf --reserved-cpu-count=20 --rt-kernel=true --split-reserved-cpus-across-numa=true --must-gather-dir-path /must-gather > my-performance-profile.yaml

创建的配置集在以下 YAML 中描述： 

  apiVersion: performance.openshift.io/v2
  kind: PerformanceProfile
  metadata:
    name: performance
  spec:
    cpu:
      isolated: 10-39,50-79
      reserved: 0-9,40-49
    nodeSelector:
      node-role.kubernetes.io/worker-cnf: ""
    numa:
      topologyPolicy: restricted
    realTimeKernel:
      enabled: true
注意

在这种情况下，在 NUMA 节点 0 上保留 10 个 CPU，NUMA 节点 1 上保留 10 个 CPU。

17.1.3. 运行性能配置集 Creator wrapper 脚本

性能配置集打包程序脚本简化了性能配置文件 Creator（PPC）工具的运行。它隐藏了运行 podman 的复杂性并指定映射目录，它支持创建性能配置集。

先决条件

  • 访问 Performance Addon Operator 镜像。
  • 访问 must-gather tarball。

流程

  1. 在本地机器上创建一个文件，例如 run-perf-profile-creator.sh： 

    $ vi run-perf-profile-creator.sh

  2. 将以下代码粘贴到文件中： 

    #!/bin/bash

readonly CONTAINER_RUNTIME=${CONTAINER_RUNTIME:-podman}
readonly CURRENT_SCRIPT=$(basename "$0")
readonly CMD="${CONTAINER_RUNTIME} run --entrypoint performance-profile-creator"
readonly IMG_EXISTS_CMD="${CONTAINER_RUNTIME} image exists"
readonly IMG_PULL_CMD="${CONTAINER_RUNTIME} image pull"
readonly MUST_GATHER_VOL="/must-gather"

PAO_IMG="registry.redhat.io/openshift4/performance-addon-rhel8-operator:v4.10"
MG_TARBALL=""
DATA_DIR=""

usage() {
  print "Wrapper usage:"
  print "  ${CURRENT_SCRIPT} [-h] [-p image][-t path] -- [performance-profile-creator flags]"
  print ""
  print "Options:"
  print "   -h                 help for ${CURRENT_SCRIPT}"
  print "   -p                 Performance Addon Operator image"
  print "   -t                 path to a must-gather tarball"

  ${IMG_EXISTS_CMD} "${PAO_IMG}" && ${CMD} "${PAO_IMG}" -h
}

function cleanup {
  [ -d "${DATA_DIR}" ] && rm -rf "${DATA_DIR}"
}
trap cleanup EXIT

exit_error() {
  print "error: $*"
  usage
  exit 1
}

print() {
  echo  "$*" >&2
}

check_requirements() {
  ${IMG_EXISTS_CMD} "${PAO_IMG}" || ${IMG_PULL_CMD} "${PAO_IMG}" || \
      exit_error "Performance Addon Operator image not found"

  [ -n "${MG_TARBALL}" ] || exit_error "Must-gather tarball file path is mandatory"
  [ -f "${MG_TARBALL}" ] || exit_error "Must-gather tarball file not found"

  DATA_DIR=$(mktemp -d -t "${CURRENT_SCRIPT}XXXX") || exit_error "Cannot create the data directory"
  tar -zxf "${MG_TARBALL}" --directory "${DATA_DIR}" || exit_error "Cannot decompress the must-gather tarball"
  chmod a+rx "${DATA_DIR}"

  return 0
}

main() {
  while getopts ':hp:t:' OPT; do
    case "${OPT}" in
      h)
        usage
        exit 0
        ;;
      p)
        PAO_IMG="${OPTARG}"
        ;;
      t)
        MG_TARBALL="${OPTARG}"
        ;;
      ?)
        exit_error "invalid argument: ${OPTARG}"
        ;;
    esac
  done
  shift $((OPTIND - 1))

  check_requirements || exit 1

  ${CMD} -v "${DATA_DIR}:${MUST_GATHER_VOL}:z" "${PAO_IMG}" "$@" --must-gather-dir-path "${MUST_GATHER_VOL}"
  echo "" 1>&2
}

main "$@"

  3. 为这个脚本中的每个人添加执行权限： 

    $ chmod a+x run-perf-profile-creator.sh

  4. 可选：显示 run-perf-profile-creator.sh 命令用法： 

    $ ./run-perf-profile-creator.sh -h

    预期输出

    Wrapper usage:
  run-perf-profile-creator.sh [-h] [-p image][-t path] -- [performance-profile-creator flags]

Options:
   -h                 help for run-perf-profile-creator.sh
   -p                 Performance Addon Operator image 1
   -t                 path to a must-gather tarball 2

A tool that automates creation of Performance Profiles

   Usage:
     performance-profile-creator [flags]

   Flags:
         --disable-ht                        Disable Hyperthreading
     -h, --help                              help for performance-profile-creator
         --info string                       Show cluster information; requires --must-gather-dir-path, ignore the other arguments. [Valid values: log, json] (default "log")
         --mcp-name string                   MCP name corresponding to the target machines (required)
         --must-gather-dir-path string       Must gather directory path (default "must-gather")
         --power-consumption-mode string     The power consumption mode.  [Valid values: default, low-latency, ultra-low-latency] (default "default")
         --profile-name string               Name of the performance profile to be created (default "performance")
         --reserved-cpu-count int            Number of reserved CPUs (required)
         --rt-kernel                         Enable Real Time Kernel (required)
         --split-reserved-cpus-across-numa   Split the Reserved CPUs across NUMA nodes
         --topology-manager-policy string    Kubelet Topology Manager Policy of the performance profile to be created. [Valid values: single-numa-node, best-effort, restricted] (default "restricted")
         --user-level-networking             Run with User level Networking(DPDK) enabled

    注意

    有两个参数类型：

    • wrapper 参数，即 -h、-p 和 -t
    • PPC 参数
    1
    可选：指定 Performance Addon Operator 镜像。如果没有设置，则使用默认上游镜像： registry.redhat.io/openshift4/performance-addon-rhel8-operator:v4.10。
    2
    -t 是必需的打包程序脚本参数，并指定 must-gather tarball 的路径。

  5. 以发现模式运行性能配置集创建器工具：

    注意

    发现模式使用 must-gather 的输出来检查您的集群。生成的输出包括以下信息：

    • 使用分配的 CPU ID 进行 NUMA 单元分区
    • 是否启用超线程

    使用此信息，您可以为提供给 Performance Profile Creator 工具的部分参数设置适当的值。 

    $ ./run-perf-profile-creator.sh -t /must-gather/must-gather.tar.gz -- --info=log
    注意

    info 选项要求值指定输出格式。可能的值有 log 和 JSON。JSON 格式被保留用于调试。

  6. 检查机器配置池： 

    $ oc get mcp

    输出示例

    NAME         CONFIG                                                 UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
master       rendered-master-acd1358917e9f98cbdb599aea622d78b       True      False      False      3              3                   3                     0                      22h
worker-cnf   rendered-worker-cnf-1d871ac76e1951d32b2fe92369879826   False     True       False      2              1                   1                     0                      22h

  7. 创建性能配置集： 

    $ ./run-perf-profile-creator.sh -t /must-gather/must-gather.tar.gz -- --mcp-name=worker-cnf --reserved-cpu-count=2 --rt-kernel=true > my-performance-profile.yaml
    注意

    Performance Profile Creator 参数显示在 Performance Profile Creator 参数表中。需要以下参数：

    • reserved-cpu-count
    • mcp-name
    • rt-kernel

    本例中的 mcp-name 参数根据 oc get mcp 命令的输出设置为 worker-cnf。对于单节点 OpenShift，请使用 --mcp-name=master。

  8. 查看创建的 YAML 文件： 

    $ cat my-performance-profile.yaml

    输出示例

    apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
  name: performance
spec:
  cpu:
    isolated: 1-39,41-79
    reserved: 0,40
  nodeSelector:
    node-role.kubernetes.io/worker-cnf: ""
  numa:
    topologyPolicy: restricted
  realTimeKernel:
    enabled: false

  9. 应用生成的配置集：

    注意

    在应用配置集前安装 Performance Addon Operator。 

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

17.1.4. Performance Profile Creator 参数

表 17.1. Performance Profile Creator 参数

参数描述

disable-ht

禁用超线程。

可能的值： true 或 false。

默认值： false。

警告

如果此参数设为 true，则不应禁用 BIOS 中的超线程。禁用超线程通过内核命令行参数实现。

info

这会捕获集群信息，仅用于发现模式。发现模式还需要 must-gather-dir-path 参数。如果设置了任何其他参数，则忽略它们。

可能的值：

  • log

  • JSON

    注意

    这些选项定义输出格式，以保留用于调试的 JSON 格式。

默认： log。

mcp-name

MCP 名称（如 worker-cnf）与目标机器对应。这个参数是必需的。

must-gather-dir-path

必须收集目录路径。这个参数是必需的。

当用户使用 wrapper 脚本 must-gather 运行该工具时，脚本本身会提供该工具，用户不得指定它。

power-consumption-mode

电源功耗模式。

可能的值：

  • default
  • low-latency
  • ultra-low-latency

默认： default。

profile-name

要创建的性能配置集的名称。默认：performance.

reserved-cpu-count

保留 CPU 的数量。这个参数是必需的。

注意

这必须是一个自然数字。不允许使用 0 值。

rt-kernel

启用实时内核。这个参数是必需的。

可能的值： true 或 false。

split-reserved-cpus-across-numa

将保留的 CPU 划分到 NUMA 节点。

可能的值： true 或 false。

默认值： false。

topology-manager-policy

要创建的性能配置集的 kubelet Topology Manager 策略。

可能的值：

  • single-numa-node
  • best-effort
  • restricted

默认： restricted。

user-level-networking

在启用了用户级别网络（DPDK）的情况下运行。

可能的值： true 或 false。

默认值： false。

17.2. 其他资源

第 18 章 单节点 OpenShift 上的工作负载分区

在资源有限制的环境中，如单节点 OpenShift 部署，最好为您自己的工作负载保留大多数 CPU 资源，并将 OpenShift Container Platform 配置为在主机中的固定 CPU 数量上运行。在这些环境中，管理工作负载（包括 control plane）需要配置为使用少于普通集群中可能默认的资源使用的资源。您可以隔离 OpenShift Container Platform 服务、集群管理工作负载和基础架构 pod 在保留的一组 CPU 上运行。

使用工作负载分区时，OpenShift Container Platform 用于集群管理的 CPU 资源被隔离为单一节点集群中的一组分区 CPU 资源。此分区将集群管理功能隔离到定义的 CPU 数量。所有集群管理功能都仅在该 cpuset 配置上运行。

单一节点集群的管理分区所需的最小保留 CPU 数量是四个 CPU Hyper 线程(HT)。组成基准 OpenShift Container Platform 安装和一组典型的附加 Operator 的 pod 集合会被注解，以包含在管理工作负载分区中。这些 pod 通常在最小大小 cpuset 配置内运行。包含一组接受管理 pod 之外的 Operator 或工作负载需要在那个分区中添加额外的 CPU HT。

工作负载分区使用 Kubernetes 的常规调度功能将用户工作负载与平台工作负载隔离开来，以管理可放入这些内核的 pod 数量，并避免混合了集群管理工作负载和用户工作负载。

在使用工作负载分区时，您必须安装 Performance Addon Operator 并应用性能配置集：

  • 工作负载分区将 OpenShift Container Platform 基础架构 pod 固定到定义的 cpuset 配置。
  • Performance Addon Operator 性能配置集将 systemd 服务固定到定义的 cpuset 配置中。
  • 此 cpuset 配置必须匹配。

工作负载分区为每个定义的 CPU 池或 workload-type 增加了 <workload-type>.workload.openshift.io/cores 的新扩展资源。kubelet 在对应的资源而不是典型的 cpu 资源中的帐户由分配给池的 pod 公告这些新资源和 CPU 请求。启用工作负载分区时，<workload-type>.workload.openshift.io/cores 资源允许访问主机的 CPU 容量，而不仅仅是默认的 CPU 池。

18.1. 使用工作负载分区最大化 CPU 分配

在单节点 OpenShift 集群安装过程中，您必须启用工作负载分区。这限制了运行平台服务的内核数，从而最大程度提高应用程序有效负载的 CPU 内核。

注意

您只能在集群安装过程中启用工作负载分区。您不能在安装后禁用工作负载分区。但是，您可以通过更新您在性能配置集中定义的 cpu 值以及 MachineConfig 自定义资源 (CR) 中的相关 cpuset 值来重新配置工作负载分区。

  • 启用工作负载分区的 base64 编码的 CR，它包含管理工作负载受限制的 CPU 集。为 base64 中的 crio.conf 和 kubelet.conf 对特定于主机的值进行编码。必须调整此内容，以匹配集群性能配置集中指定的 CPU 集，且对于集群主机中的内核数必须准确。 

    apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: master
  name: 02-master-workload-partitioning
spec:
  config:
    ignition:
      version: 3.2.0
    storage:
      files:
      - contents:
          source: data:text/plain;charset=utf-8;base64,W2NyaW8ucnVudGltZS53b3JrbG9hZHMubWFuYWdlbWVudF0KYWN0aXZhdGlvbl9hbm5vdGF0aW9uID0gInRhcmdldC53b3JrbG9hZC5vcGVuc2hpZnQuaW8vbWFuYWdlbWVudCIKYW5ub3RhdGlvbl9wcmVmaXggPSAicmVzb3VyY2VzLndvcmtsb2FkLm9wZW5zaGlmdC5pbyIKcmVzb3VyY2VzID0geyAiY3B1c2hhcmVzIiA9IDAsICJjcHVzZXQiID0gIjAtMSw1Mi01MyIgfQo=
        mode: 420
        overwrite: true
        path: /etc/crio/crio.conf.d/01-workload-partitioning
        user:
          name: root
      - contents:
          source: data:text/plain;charset=utf-8;base64,ewogICJtYW5hZ2VtZW50IjogewogICAgImNwdXNldCI6ICIwLTEsNTItNTMiCiAgfQp9Cg==
        mode: 420
        overwrite: true
        path: /etc/kubernetes/openshift-workload-pinning
        user:
          name: root

  • 在集群主机上配置时，/etc/crio/crio.conf.d/01-workload-partitioning 的内容应该类似如下： 

    [crio.runtime.workloads.management]
activation_annotation = "target.workload.openshift.io/management"
annotation_prefix = "resources.workload.openshift.io"
[crio.runtime.workloads.management.resources]
cpushares = 0
cpuset = "0-1, 52-53" 1
    1
    cpuset 值因安装而异。

    如果启用了超线程，请为每个内核指定两个线程。cpuset 值必须与您在性能配置集中的 spec.cpu.reserved 字段中定义的保留 CPU 匹配。

  • 在集群中配置时，/etc/kubernetes/openshift-workload-pinning 的内容应如下所示： 

    {
  "management": {
    "cpuset": "0-1,52-53" 1
  }
}
    1
    cpuset 必须与 /etc/crio/crio.conf.d/01-workload-partitioning 中的 cpuset 值匹配。

第 19 章 处于边缘网络的集群

19.1. 网络边缘的挑战

在地理位置管理多个站点时，边缘计算带来了复杂的挑战。使用 ZTP 和 GitOps 在网络边缘置备和管理站点。

19.1.1. 克服网络边缘的挑战

今天，服务提供商希望在网络边缘部署其基础架构。这带来了显著的挑战：

  • 您怎样处理并行部署多个边缘站点的部署？
  • 当您需要在断开连接的环境中部署站点时，会出现什么情况？
  • 如何管理集群的生命周期？

零接触置备(ZTP)和 GitOps 通过允许您为裸机设备使用声明站点定义和配置来大规模置备远程边缘站点。模板或覆盖配置安装 CNF 工作负载所需的 OpenShift Container Platform 功能。安装和升级的完整生命周期通过 ZTP 管道处理。

ZTP 将 GitOps 用于基础架构部署。使用 GitOps，您可以使用声明 YAML 文件和其他存储在 Git 存储库中的其他定义模式。Red Hat Advanced Cluster Management (RHACM)使用 Git 存储库来驱动基础架构部署。

GitOps 提供可追溯性、基于角色的访问控制 (RBAC)，以及每个站点的所需状态的单一数据源。Git 方法可通过 webhook 解决可扩展性问题，以及事件驱动的操作。

您可以通过创建 ZTP 管道提供的声明性站点定义和配置自定义资源 (CR) 来启动 ZTP 工作流。

下图显示了 ZTP 如何在最边缘框架内工作。

ZTP 位于边缘网络

19.1.2. 使用 ZTP 在网络边缘置备集群

Red Hat Advanced Cluster Management (RHACM)在 hub 和 spoke 架构中管理集群，其中单个 hub 集群管理多个 spoke 集群。运行 RHACM 的 hub 集群使用零接触置备 (ZTP) 和安装 RHACM 时部署的辅助服务来置备和部署受管集群。

协助的服务处理在单一节点集群、三节点集群或裸机上运行的标准集群上 OpenShift Container Platform 置备。

使用 ZTP 的高级别概述来置备和维护使用 OpenShift Container Platform 的裸机主机，如下所示：

  • 运行 RHACM 的 hub 集群管理一个 OpenShift 镜像 registry，用于镜像 OpenShift Container Platform 发行镜像。RHACM 使用 OpenShift 镜像 registry 来置备受管集群。
  • 您以 YAML 格式清单文件管理裸机主机，并在 Git 存储库中版本。
  • 您可以使主机准备好作为受管集群置备，并使用 RHACM 和辅助服务在站点上安装裸机主机。

安装和部署集群分为两个阶段，涉及初始安装阶段和后续配置阶段。下图演示了这个工作流：

使用 GitOps 和 ZTP 安装和部署受管集群

19.1.3. 使用 SiteConfig 资源和 RHACM 安装受管集群

GitOps ZTP 使用 Git 存储库中的 SiteConfig 自定义资源 (CR) 来管理安装 OpenShift Container Platform 集群的进程。SiteConfig CR 包含安装所需的特定于集群的参数。它有在安装过程中应用所选配置 CR 的选项，包括用户定义的额外清单。

ZTP GitOps 插件处理 SiteConfig CR，以便在 hub 集群上生成 CR 集合。这会在 Red Hat Advanced Cluster Management (RHACM) 中触发辅助服务，以便在裸机主机上安装 OpenShift Container Platform。您可以在 hub 集群上的这些 CR 中找到安装状态和错误消息。

您可以手动置备单个集群，或使用 ZTP 批量置备单个集群：

置备单个集群
为集群创建单一 SiteConfig CR 及相关的安装和配置 CR，并在 hub 集群中应用它们以开始集群置备。这是在大规模部署前测试 CR 的好方法。
置备多个集群
通过在 Git 仓库中定义 SiteConfig 和相关 CR，以最多 400 的批处理中安装受管集群。ArgoCD 使用 SiteConfig CR 来部署站点。RHACM 策略生成器创建清单，并将其应用到 hub 集群。这将启动集群置备过程。

19.1.4. 使用策略和 PolicyGenTemplate 资源配置受管集群

ZTP 使用 Red Hat Advanced Cluster Management (RHACM) 使用基于策略的监管方法应用配置配置。

策略生成器或 PolicyGen 是 GitOps 操作器的一个插件，它允许从简洁的模板创建 RHACM 策略。该工具可将多个 CR 合并为一个策略，您可以生成多个策略应用到团队中集群的不同子集的策略。

注意

为了扩展并降低跨集群管理配置的复杂性，请尽可能使用配置 CR。

  • 在可能的情况下，使用机范围的通用策略应用配置 CR。
  • 下一个首选项是创建集群的逻辑分组，以在组策略下尽可能管理剩余的配置。
  • 当配置对单个站点是唯一的时，请使用 hub 集群上的 RHACM 模板将特定于站点的数据注入通用或组策略。或者，为站点应用单个站点策略。

下图显示了在集群部署配置阶段策略生成器如何与 GitOps 和 RHACM 交互。

策略生成器

对于大型集群群，在配置这些集群时通常具有高级别的一致性。

以下推荐的策略结构组合了配置 CR，以满足几个目标：

  • 描述一次通用配置，并应用到所有系统。
  • 最小化维护和管理策略的数量。
  • 支持集群变体的通用配置的灵活性。

表 19.1. 推荐的 PolicyGenTemplate 策略类别

策略类别描述

Common

一个存在于 common 类别中的策略被应用到该团队中的所有集群。使用通用 PolicyGenTemplate CR 在所有集群类型中应用通用安装设置。

组

组类别中存在的策略应用到一组集群。使用组 PolicyGenTemplate CR 管理单节点、三节点和标准集群安装的特定方面。集群组也可以遵循区域、硬件变体等。

Sites

站点类别中存在的策略应用到特定的集群站点。任何集群都可以维护自己的特定策略。

其他资源

  • 有关从 ztp-site-generate 容器镜像中提取参考 SiteConfig 和 PolicyGenTemplate CR 的更多信息，请参阅准备 ZTP Git 存储库。

19.2. 为 ZTP 准备 hub 集群

要在断开连接的环境中使用 RHACM，请创建一个镜像 registry，镜像 OpenShift Container Platform 发行镜像和包含所需 Operator 镜像的 Operator Lifecycle Manager (OLM) 目录。OLM 在集群中管理、安装和升级 Operator 及其依赖项。您还可以使用断开连接的镜像主机来提供用于置备裸机主机的 RHCOS ISO 和 RootFS 磁盘镜像。

19.2.1. Telco RAN 4.10 验证的解决方案软件版本

Red Hat Telco Radio Access Network (RAN) 版本 4.10 解决方案已使用以下红帽软件产品进行验证。

表 19.2. Telco RAN 4.10 验证的解决方案软件

产品软件版本

hub 集群 OpenShift Container Platform 版本

4.10

GitOps ZTP 插件

4.9 或 4.10

Red Hat Advanced Cluster Management (RHACM)

2.4 或 2.5

Red Hat OpenShift GitOps

1.4

Topology Aware Lifecycle Manager (TALM)

4.10 （技术预览）

19.2.2. 在断开连接的环境中安装 GitOps ZTP

在断开连接的环境中，使用 Red Hat Advanced Cluster Management (RHACM)、Red Hat OpenShift GitOps 和 Topology Aware Lifecycle Manager (TALM) 来管理多个受管集群的部署。

先决条件

  • 已安装 OpenShift Container Platform CLI (oc)。
  • 您已以具有 cluster-admin 权限的用户身份登录。

  • 您已配置了断开连接的镜像 registry 以在集群中使用。

    注意

    您创建的断开连接的镜像 registry 必须包含 TALM backup 和 pre-cache 镜像的版本，该镜像与 hub 集群中运行的 TALM 版本匹配。spoke 集群必须能够在断开连接的镜像 registry 中解析这些镜像。

流程

其他资源

19.2.3. 在断开连接的镜像主机中添加 RHCOS ISO 和 RootFS 镜像

在使用 Red Hat Advanced Cluster Management (RHACM) 在断开连接的环境中安装集群前，您必须首先托管 Red Hat Enterprise Linux CoreOS (RHCOS) 镜像供其使用。使用断开连接的镜像来托管 RHCOS 镜像。

先决条件

  • 部署和配置 HTTP 服务器以托管网络上的 RHCOS 镜像资源。您必须能够从计算机以及您创建的机器访问 HTTP 服务器。
重要

RHCOS 镜像可能不会随着 OpenShift Container Platform 的每个发行版本而改变。您必须下载最高版本的镜像，其版本号应小于或等于您安装的版本。如果可用，请使用与 OpenShift Container Platform 版本匹配的镜像版本。您需要 ISO 和 RootFS 镜像在主机上安装 RHCOS。此安装类型不支持 RHCOS QCOW2 镜像。

流程

  1. 登录到镜像主机。

  2. 从 mirror.openshift.com 获取 RHCOS ISO 和 RootFS 镜像，例如：

    1. 将所需的镜像名称和 OpenShift Container Platform 版本导出为环境变量： 

      $ export ISO_IMAGE_NAME=<iso_image_name> 1
      $ export ROOTFS_IMAGE_NAME=<rootfs_image_name> 1
      $ export OCP_VERSION=<ocp_version> 1
      1
      ISO 镜像名称，如 rhcos-4.10.1-x86_64-live.x86_64.iso
      1
      rootfs 镜像名称，如 rhcos-4.10.1-x86_64-live-rootfs.x86_64.img
      1
      OpenShift Container Platform verison，例如 4.10.1

    2. 下载所需的镜像： 

      $ sudo wget https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/4.10/${OCP_VERSION}/${ISO_IMAGE_NAME} -O /var/www/html/${ISO_IMAGE_NAME}
      $ sudo wget https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/4.10/${OCP_VERSION}/${ROOTFS_IMAGE_NAME} -O /var/www/html/${ROOTFS_IMAGE_NAME}

验证步骤

  • 验证下载的镜像是否成功，并在断开连接的镜像主机上提供，例如： 

    $ wget http://$(hostname)/${ISO_IMAGE_NAME}

    输出示例

    Saving to: rhcos-4.10.1-x86_64-live.x86_64.iso
rhcos-4.10.1-x86_64-live.x86_64.iso-  11%[====>    ]  10.01M  4.71MB/s

其他资源

19.2.4. 在 hub 集群上启用驱动程序更新服务并更新 AgentServiceConfig

Red Hat Advanced Cluster Management (RHACM)使用辅助服务来部署 OpenShift Container Platform 集群。当使用中央基础架构管理 (CIM) 启用 MultiClusterHub Operator 时，辅助服务会自动部署。当您在 hub 集群上启用了 CIM 时，您需要更新 AgentServiceConfig 自定义资源 (CR)，其引用托管在镜像 registry HTTP 服务器上的 ISO 和 RootFS 镜像。

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 已以具有 cluster-admin 权限的用户身份登录到 hub 集群。
  • 您已在 hub 集群中启用了辅助服务。如需更多信息，请参阅启用 CIM。

流程

  1. 运行以下命令来更新 AgentServiceConfig CR： 

    $ oc edit AgentServiceConfig

  2. 在 CR 的 items.spec.osImages 字段中添加以下条目： 

    - cpuArchitecture: x86_64
    openshiftVersion: "4.10"
    rootFSUrl: https://<host>/<path>/rhcos-live-rootfs.x86_64.img
    url: https://<mirror-registry>/<path>/rhcos-live.x86_64.iso

    其中：

    <host>
    是目标镜像 registry HTTP 服务器的完全限定域名 (FQDN)。
    <path>
    是目标镜像 registry 上镜像的路径。

    保存并退出编辑器以应用更改。

19.2.5. 将 hub 集群配置为使用断开连接的镜像 registry

您可以将 hub 集群配置为使用断开连接的镜像 registry 作为断开连接的环境。

先决条件

  • 已安装 Red Hat Advanced Cluster Management (RHACM) 2.4 的断开连接的 hub 集群安装。
  • 您已在 HTTP 服务器中托管 rootfs 和 iso 镜像。
警告

如果为 HTTP 服务器启用 TLS，您必须确认 root 证书由客户端信任的颁发机构签名，并验证 OpenShift Container Platform hub 和受管集群和 HTTP 服务器之间的可信证书链。使用配置了不受信任的证书的服务器可防止将镜像下载到创建镜像中。不支持使用不受信任的 HTTPS 服务器。

流程

  1. 创建包含镜像 registry 配置的 ConfigMap： 

    apiVersion: v1
kind: ConfigMap
metadata:
  name: assisted-installer-mirror-config
  namespace: assisted-installer
  labels:
    app: assisted-service
data:
  ca-bundle.crt: <certificate> 1
  registries.conf: |  2
    unqualified-search-registries = ["registry.access.redhat.com", "docker.io"]

    [[registry]]
      location = <mirror_registry_url>  3
      insecure = false
      mirror-by-digest-only = true
    1
    创建镜像 registry 时使用的镜像 registry 证书。
    2
    镜像 registry 的配置。
    3
    镜像 registry 的 URL。

    这会更新 AgentServiceConfig 自定义资源中的 mirrorRegistryRef，如下所示：

    输出示例

    apiVersion: agent-install.openshift.io/v1beta1
kind: AgentServiceConfig
metadata:
  name: agent
spec:
  databaseStorage:
    volumeName: <db_pv_name>
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: <db_storage_size>
  filesystemStorage:
    volumeName: <fs_pv_name>
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: <fs_storage_size>
  mirrorRegistryRef:
    name: 'assisted-installer-mirror-config'
  osImages:
    - openshiftVersion: <ocp_version>
      rootfs: <rootfs_url> 1
      url: <iso_url> 2

    1 2
    必须与 HTTPD 服务器的 URL 匹配。
重要

集群安装过程中需要一个有效的 NTP 服务器。确保有合适的 NTP 服务器可用，并可通过断开连接的网络从安装的系统访问。

19.2.6. 使用 ArgoCD 配置 hub 集群

您可以使用一组 ArgoCD 应用程序来配置 hub 集群，这些应用程序会根据 ZTP GitOps 流为每个站点生成所需的安装和策略自定义资源 (CR)。

先决条件

  • 已安装 Red Hat Advanced Cluster Management (RHACM) 和 Red Hat OpenShift GitOps 的 OpenShift Container Platform hub 集群。
  • 您已从 ZTP GitOps 插件容器中提取了引用部署，如 "Preparing the GitOps ZTP site configuration repository" 部分所述。提取引用部署会创建以下流程中引用的 out/argocd/deployment 目录。

流程

  1. 准备 ArgoCD 管道配置：

    1. 创建 Git 存储库，其目录结构类似于 example 目录。如需更多信息，请参阅"准备 GitOps ZTP 站点配置存储库"。

    2. 使用 ArgoCD UI 配置对存储库的访问。在 Settings 下配置以下内容：

      • Repositories - 添加连接信息。URL 必须以 .git 结尾，例如 https://repo.example.com/repo.git 和凭证。
      • 证书 - 如果需要，为存储库添加公共证书。

    3. 根据您的 Git 仓库修改两个 ArgoCD 应用程序, out/argocd/deployment/clusters-app.yaml 和 out/argocd/deployment/policies-app.yaml ：

      • 更新 URL 以指向 Git 存储库。URL 以 .git 结尾，例如 https://repo.example.com/repo.git。
      • targetRevision 表示要监控的 Git 存储库分支。
      • path 指定到 SiteConfig 和 PolicyGenTemplate CR 的路径。

  2. 要安装 ZTP GitOps 插件，您必须使用之前提取到 out/argocd/deployment/ 目录中的补丁文件来修补 hub 集群中的 ArgoCD 实例。运行以下命令: 

    $ oc patch argocd openshift-gitops \
-n openshift-gitops --type=merge \
--patch-file out/argocd/deployment/argocd-openshift-gitops-patch.json

  3. 使用以下命令将管道配置应用到 hub 集群： 

    $ oc apply -k out/argocd/deployment

其他资源

19.2.7. 准备 GitOps ZTP 站点配置存储库

在使用 ZTP GitOps 管道前，您需要准备 Git 存储库来托管站点配置数据。

先决条件

  • 已配置了 hub 集群 GitOps 应用程序来生成所需的安装和策略自定义资源 (CR)。
  • 您已使用 ZTP 部署受管集群。

流程

  1. 使用 SiteConfig 和 PolicyGenTemplate CR 的单独路径创建一个目录结构。

  2. 使用以下命令，从 ztp-site-generate 容器镜像导出 argocd 目录： 

    $ podman pull registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.10
    $ mkdir -p ./out
    $ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v{product-version} extract /home/ztp --tar | tar x -C ./out

  3. 检查 out 目录是否包含以下子目录：

    • out/extra-manifest 包含 SiteConfig 用来生成额外清单 configMap 的源 CR 文件。
    • out/source-crs 包含 PolicyGenTemplate 用来生成 Red Hat Advanced Cluster Management(RHACM)策略的源 CR 文件。
    • out/argocd/deployment 包含补丁和 YAML 文件，可在 hub 集群中应用，以便在此过程的下一步中使用。
    • out/argocd/example 包含代表推荐的配置的 siteConfig 和 PolicyGenTemplate 文件的示例。

out/argocd/example 下的目录结构充当 Git 存储库结构和内容的参考。示例包括用于单节点、三节点和标准集群的 SiteConfig 和 PolicyGenTemplate 引用 CR。删除您对未使用集群类型的引用。以下示例描述了单节点集群网络的一组 CR： 

example
├── policygentemplates
│   ├── common-ranGen.yaml
│   ├── example-sno-site.yaml
│   ├── group-du-sno-ranGen.yaml
│   ├── group-du-sno-validator-ranGen.yaml
│   ├── kustomization.yaml
│   └── ns.yaml
└── siteconfig
    ├── example-sno.yaml
    ├── KlusterletAddonConfigOverride.yaml
    └── kustomization.yaml

在单独的目录中，保持 SiteConfig 和 PolicyGenTemplate CR。SiteConfig 和 PolicyGenTemplate 目录必须包含一个 kustomization.yaml 文件，该文件明确包含该目录中的文件。

此目录结构以及 kustomization.yaml 文件必须提交并推送到 Git 存储库。初始推送到 Git 的推送应包含 kustomization.yaml 文件。在部署站点时，可以忽略 SiteConfig (example-sno.yaml) 和 PolicyGenTemplate (common-ranGen.yaml, group-du-sno*.yaml, and example-sno-site.yaml) 文件，并在以后需要时在推送它们。

只有在提交并推送到 Git 的一个或多个 SiteConfig CR 时，才需要 KlusterletAddonConfigOverride.yaml 文件。如需有关如何使用的示例，请参阅 example-sno.yaml。

19.3. 使用 RHACM 和 SiteConfig 资源安装受管集群

您可以使用辅助服务以及启用了 core-reduction 技术的 GitOps 插件策略生成器，以扩展 Red Hat Advanced Cluster Management (RHACM) 来大规模置备 OpenShift Container Platform 集群。ZTP 管道执行集群安装。ZTP 可以在断开连接的环境中使用。

19.3.1. GitOps ZTP 和 Topology Aware Lifecycle Manager

GitOps 零涉及置备(ZTP)从存储在 Git 中的清单生成安装和配置 CR。这些工件应用到一个中央化的 hub 集群，其中 Red Hat Advanced Cluster Management (RHACM)、辅助服务和 Topology Aware Lifecycle Manager (TALM) 使用 CR 来安装和配置受管集群。ZTP 管道的配置阶段使用 TALM 将配置 CR 的应用程序编排到集群。GitOps ZTP 和 TALM 之间有几个关键集成点。

通知策略
默认情况下，GitOps ZTP 创建所有带有 inform 的补救操作的策略。这些策略会导致 RHACM 报告与策略相关的集群合规性状态，但不会应用所需的配置。在 ZTP 过程中，在 OpenShift 安装后，TALM 步骤通过创建的 inform 策略，并在目标受管集群中强制实施它们。这会将配置应用到受管集群。在集群生命周期的 ZTP 阶段之外，这允许您在不立即将这些更改部署到受影响的受管集群的情况下更改策略。您可以使用 TALM 控制时间和修复的集群集合。
自动创建 ClusterGroupUpgrade CR

要自动执行新部署的集群的初始配置，TALM 会监控 hub 集群上所有 ManagedCluster CR 的状态。任何未应用 ztp-done 标签的 ManagedCluster CR，包括新创建的 ManagedCluster CR，会导致 TALM 自动创建一个具有以下特征的 ClusterGroupUpgrade CR：

  • 在 ztp-install 命名空间中创建并启用 ClusterGroupUpgrade CR。
  • ClusterGroupUpgrade CR 的名称与 ManagedCluster CR 的名称相同。
  • 集群选择器仅包括与该 ManagedCluster CR 关联的集群。
  • 受管策略集合包含 RHACM 在 ClusterGroupUpgrade 创建时绑定到集群的所有策略。
  • 禁用预缓存。
  • 超时设置为 4 小时（240 分钟）。

启用的 ClusterGroupUpgrade 的自动创建可确保初始零接触集群部署继续进行，而无需用户干预。另外，对任何没有 ztp-done 标签的 ManagedCluster 自动创建一个 ClusterGroupUpgrade CR，会允许失败的 ZTP 安装重新启动（删除集群的 ClusterGroupUpgrade CR）。

Waves

从 PolicyGenTemplate CR 生成的每个策略都包含一个 ztp-deploy-wave 注解。此注解基于来自每个 CR 的同一注解，该注解包含在该策略中。wave 注解用于对自动生成的 ClusterGroupUpgrade CR 中的策略进行排序。wave 注解没有用于自动生成的 ClusterGroupUpgrade CR。

注意

同一策略中的所有 CR 都必须具有 ztp-deploy-wave 注解的设置。在 PolicyGenTemplate 中，每个 CR 的此注解的默认值可以被覆盖。源 CR 中的 wave 注解用来决定和设置策略 wave 注解。此注解已从每个构建 CR 中删除，该 CR 在运行时包含在生成的策略中。

TALM 按照 wave 注解指定的顺序应用配置策略。在移至下一个策略前，TALM 会等待每个策略兼容。确保每个 CR 的 wave 注解考虑要应用到集群的任何 CR 的先决条件。例如，必须在 Operator 配置之前或同时安装 Operator。同样，Operator 的 CatalogSource 必须在 Operator Subscription 之前或同时安装 wave。每个 CR 的默认 wave 值会考虑这些先决条件。

多个 CR 和策略可以共享相同的 wave 编号。拥有较少的策略可缩短部署速度并降低 CPU 用量。将多个 CR 分组到相对较少的waves 是最佳实践方案。

要检查每个源 CR 中的默认 wave 值，请针对从 ztp-site-generate 容器镜像中提取的 out/source-crs 目录运行以下命令： 

$ grep -r "ztp-deploy-wave" out/source-crs
阶段标签

ClusterGroupUpgrade CR 会被自动创建，并包含在 ZTP 进程开始和结尾使用标签为 ManagedCluster CR 的说明。

当 ZTP 配置安装后启动时，ManagedCluster 会应用 ztp-running 标签。当所有策略都修复至集群并完全合规时，这些指令会导致 TALM 删除 ztp-running 标签并应用 ztp-done 标签。

对于使用 informDuValidator 策略的部署，当集群完全准备好部署应用程序时，会应用 ztp-done 标签。这包括 ZTP 应用的配置 CR 的所有协调并产生影响。ztp-done 标签会影响 TALM 创建自动 ClusterGroupUpgrade CR。不要在集群初始 ZTP 安装后操作此标签。

链接的 CR
自动创建的 ClusterGroupUpgrade CR 将所有者引用设置为派生于 ManagedCluster 的 ManagedCluster。此引用可确保删除 ManagedCluster CR 会导致 ClusterGroupUpgrade 的实例以及任何支持的资源被删除。

19.3.2. 使用 ZTP 部署受管集群概述

Red Hat Advanced Cluster Management(RHACM)利用零接触置备(ZTP)来部署单节点 OpenShift Container Platform 集群、三节点集群和标准集群。您可以在 Git 存储库中将站点配置数据作为 OpenShift Container Platform 自定义资源 (CR) 进行管理。ZTP 使用声明性 GitOps 方法进行开发一次，部署任意位置模型来部署受管集群。

集群部署包括：

  • 在空白服务器上安装主机操作系统 (RHCOS)
  • 部署 OpenShift Container Platform
  • 创建集群策略和站点订阅
  • 为服务器操作系统进行必要的网络配置
  • 部署配置集 Operator 并执行任何所需的软件相关配置，如性能配置集、PTP 和 SR-IOV
受管站点安装过程概述

在 hub 集群中应用受管站点自定义资源 (CR) 后，会自动执行以下操作：

  1. 在目标主机上生成并启动发现镜像 ISO 文件。
  2. 当 ISO 文件成功在目标主机上引导时，它会将主机硬件信息报告给 RHACM。
  3. 在所有主机被发现后，会安装 OpenShift Container Platform。
  4. 当 OpenShift Container Platform 完成安装后，hub 在目标集群上安装 klusterlet 服务。
  5. 请求的附加组件服务安装在目标集群中。

当在 hub 集群上创建受管集群的 Agent CR 时，发现镜像 ISO 过程已完成。

重要

目标裸机主机必须满足 vDU 应用程序工作负载的推荐单节点 OpenShift 集群配置中列出的网络、固件和硬件要求。

19.3.3. 创建受管裸机主机 secret

将受管裸机主机所需的 Secret 自定义资源 (CR) 添加到 hub 集群。您需要 ZTP 管道的 secret 来访问 Baseboard Management Controller (BMC) 和支持的安装程序服务的 secret，以便从 registry 中拉取集群安装镜像。

注意

secret 按名称从 SiteConfig CR 引用。命名空间必须与 SiteConfig 命名空间匹配。

流程

  1. 创建一个 YAML secret 文件，其中包含主机 Baseboard Management Controller (BMC) 和安装 OpenShift 和所有附加组件集群 Operator 所需的凭证：

    1. 将以下 YAML 保存为文件 example-sno-secret.yaml ： 

      apiVersion: v1
kind: Secret
metadata:
  name: example-sno-bmc-secret
  namespace: example-sno 1
data: 2
  password: <base64_password>
  username: <base64_username>
type: Opaque
---
apiVersion: v1
kind: Secret
metadata:
  name: pull-secret
  namespace: example-sno  3
data:
  .dockerconfigjson: <pull_secret> 4
type: kubernetes.io/dockerconfigjson
      1
      必须与相关 SiteConfig CR 中配置的命名空间匹配
      2
      password 和 username 的 base64 编码值
      3
      必须与相关 SiteConfig CR 中配置的命名空间匹配
      4
      Base64 编码的 pull secret
  2. 将到 example-sno-secret.yaml 的相对路径添加用于安装集群的 kustomization.yaml 文件中。

19.3.4. 使用 SiteConfig 和 ZTP 部署受管集群

使用以下步骤创建 SiteConfig 自定义资源 (CR) 和相关文件，并启动零接触置备 (ZTP) 集群部署。

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 已以具有 cluster-admin 权限的用户身份登录到 hub 集群。
  • 配置了 hub 集群来生成所需的安装和策略 CR。

  • 您创建了 Git 存储库，用于管理自定义站点配置数据。存储库必须可从 hub 集群访问，且必须将其配置为 ArgoCD 应用程序的源存储库。如需更多信息，请参阅"准备 GitOps ZTP 站点配置存储库"。

    注意

    在创建源存储库时，请确保使用从 ztp-site-generate 容器中提取的 argocd/deployment/argocd-openshift-gitops-patch.json patch-file 来修补 ArgoCD 应用程序。请参阅"使用 ArgoCD 配置 hub 集群"。

  • 要准备好置备受管集群，每个裸机主机都需要以下内容：

    网络连接
    您的网络需要 DNS。受管集群主机应该可从 hub 集群访问。确保 hub 集群和受管集群主机之间存在第 3 层连接。
    Baseboard Management Controller (BMC) 详情
    ZTP 使用 BMC 用户名和密码详情来在集群安装过程中连接到 BMC。GitOps ZTP 插件根据站点 Git 仓库中的 SiteConfig CR 管理 hub 集群上的 ManagedCluster CR。您可以手动为每个主机创建单独的 BMCSecret CR。

    流程

    1. 在 hub 集群中创建所需的受管集群 secret。这些资源必须位于名称与集群名称匹配的命名空间中。例如，在 out/argocd/example/siteconfig/example-sno.yaml 中，集群名称和命名空间是 example-sno。

      1. 运行以下命令来导出集群命名空间： 

        $ export CLUSTERNS=example-sno

      2. 创建命名空间： 

        $ oc create namespace $CLUSTERNS

    2. 为受管集群创建 pull secret 和 BMC Secret CR。pull secret 必须包含安装 OpenShift Container Platform 和其他需要安装的 Operator 所需的所有凭证。如需更多信息，请参阅"创建受管裸机主机 secret"。

      注意

      secret 根据名称从 SiteConfig 自定义资源 (CR) 引用。命名空间必须与 SiteConfig 命名空间匹配。

    3. 在 Git 存储库本地克隆中为集群创建一个 SiteConfig CR：

      1. 从 out/argocd/example/siteconfig/ 文件夹中选择适合您的 CR 示例。文件夹中包含单一节点、三节点和标准集群的示例文件：

        • example-sno.yaml
        • example-3node.yaml
        • example-standard.yaml

      2. 更改示例文件中的集群和主机详情，以匹配您想要的集群类型。例如：

        单节点 OpenShift 集群 SiteConfig CR 示例

        apiVersion: ran.openshift.io/v1
kind: SiteConfig
metadata:
  name: "<site_name>"
  namespace: "<site_name>"
spec:
  baseDomain: "example.com"
  pullSecretRef:
    name: "assisted-deployment-pull-secret" 1
  clusterImageSetNameRef: "openshift-4.10" 2
  sshPublicKey: "ssh-rsa AAAA..." 3
  clusters:
  - clusterName: "<site_name>"
    networkType: "OVNKubernetes"
    clusterLabels: 4
      common: true
      group-du-sno: ""
      sites : "<site_name>"
    clusterNetwork:
      - cidr: 1001:1::/48
        hostPrefix: 64
    machineNetwork:
      - cidr: 1111:2222:3333:4444::/64
    serviceNetwork:
      - 1001:2::/112
    additionalNTPSources:
      - 1111:2222:3333:4444::2
    #crTemplates:
    #  KlusterletAddonConfig: "KlusterletAddonConfigOverride.yaml" 5
    nodes:
      - hostName: "example-node.example.com" 6
        role: "master"
        #biosConfigRef:
        #  filePath: "example-hw.profile" 7
        bmcAddress: idrac-virtualmedia://<out_of_band_ip>/<system_id>/ 8
        bmcCredentialsName:
          name: "bmh-secret" 9
        bootMACAddress: "AA:BB:CC:DD:EE:11"
        bootMode: "UEFI" 10
        rootDeviceHints:
          wwn: "0x11111000000asd123"
        cpuset: "0-1,52-53"
        nodeNetwork: 11
          interfaces:
            - name: eno1
              macAddress: "AA:BB:CC:DD:EE:11"
          config:
            interfaces:
              - name: eno1
                type: ethernet
                state: up
                ipv4:
                  enabled: false
                ipv6: 12
                  enabled: true
                  address:
                  - ip: 1111:2222:3333:4444::aaaa:1
                    prefix-length: 64
            dns-resolver:
              config:
                search:
                - example.com
                server:
                - 1111:2222:3333:4444::2
            routes:
              config:
              - destination: ::/0
                next-hop-interface: eno1
                next-hop-address: 1111:2222:3333:4444::1
                table-id: 254

        1
        使用与 SiteConfig CR 相同的命名空间创建 assisted-deployment-pull-secret CR。
        2
        clusterImageSetNameRef 定义 hub 集群中可用的镜像集。要查看 hub 集群上支持的版本列表，请运行 oc get clusterimagesets。
        3
        配置用于访问集群的 SSH 公钥。
        4
        集群标签必须与您定义的 PolicyGenTemplate CR 中的 bindingRules 字段对应。例如，policygentemplates/common-ranGen.yaml 应用到所有带有 common: true 设置的集群，policygentemplates/group-du-sno-ranGen.yaml 应用到所有带有 group-du-sno: "" 设置的所有集群。
        5
        可选的。KlusterletAddonConfig 下的 CR specifed 用于覆盖为集群创建的默认 KlusterletAddonConfig。
        6
        对于单节点部署，请定义一个主机。对于三节点部署，请定义三个主机。对于标准部署，使用 role: master 定义三个主机，使用 role: worker 定义两个或更多主机。
        7
        可选的。使用 biosConfigRef 为主机配置所需的固件。
        8
        适用于所有集群类型。指定 BMC 地址。
        9
        创建指定 BMC 凭证的 bmh-secret CR。使用与 SiteConfig CR 相同的命名空间。
        10
        使用 UEFISecureBoot 在主机上启用安全引导。
        11
        指定节点的网络设置。
        12
        配置主机的 IPv6 地址。对于带有静态 IP 地址的单节点 OpenShift 集群，特定于节点的 API 和 Ingress IP 应该相同。
        注意

        有关 BMC 寻址的更多信息，请参阅"添加资源"部分。

      3. 您可以在 out/argocd/extra-manifest 中检查默认的 extra-manifest MachineConfig CR。它在安装时会自动应用到集群。
      4. 可选： 要在置备的集群中置备额外的安装清单，请在 Git 存储库中创建一个目录，如 sno-extra-manifest/，并将自定义清单 CR 添加到这个目录中。如果您的 SiteConfig.yaml 在 extraManifestPath 字段中引用这个目录，则这个引用目录中的所有 CR 都会被附加到默认的额外的清单集合中。
    4. 在 kustomization.yaml 文件中将 SiteConfig CR 添加到 generators 部分中 ，类似于 out/argocd/example/siteconfig/kustomization.yaml 中显示的示例。

    5. 在 Git 存储库中提交 SiteConfig CR 及关联的 kustomization.yaml 更改并推送更改。

      ArgoCD 管道检测到更改并开始受管集群部署。

其他资源

19.3.5. 监控受管集群安装进度

ArgoCD 管道使用 SiteConfig CR 生成集群配置 CR，并将其与 hub 集群同步。您可以在 ArgoCD 仪表板中监控此同步的进度。

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 已以具有 cluster-admin 权限的用户身份登录到 hub 集群。

流程

同步完成后，安装通常会按如下方式进行：

  1. Assisted Service Operator 会在集群中安装 OpenShift Container Platform。您可以运行以下命令来从 RHACM 仪表板或命令行监控集群安装进度：

    1. 导出集群名称： 

      $ export CLUSTER=<clusterName>

    2. 查询受管集群的 AgentClusterInstall CR： 

      $ oc get agentclusterinstall -n $CLUSTER $CLUSTER -o jsonpath='{.status.conditions[?(@.type=="Completed")]}' | jq

    3. 获取集群的安装事件： 

      $ curl -sk $(oc get agentclusterinstall -n $CLUSTER $CLUSTER -o jsonpath='{.status.debugInfo.eventsURL}')  | jq '.[-2,-1]'

19.3.6. 通过验证安装 CR 对 GitOps ZTP 进行故障排除

ArgoCD 管道使用 SiteConfig 和 PolicyGenTemplate 自定义资源 (CR) 生成集群配置 CR 和 Red Hat Advanced Cluster Management (RHACM) 策略。使用以下步骤对此过程中可能出现的问题进行故障排除。

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 已以具有 cluster-admin 权限的用户身份登录到 hub 集群。

流程

  1. 您可以使用以下命令检查安装 CR 是否已创建： 

    $ oc get AgentClusterInstall -n <cluster_name>

    如果没有返回对象，请使用以下步骤对从 SiteConfig 文件到安装 CR 的 ArgoCD 管道流进行故障排除。

  2. 验证 ManagedCluster CR 是否使用 hub 集群上的 SiteConfig CR 生成： 

    $ oc get managedcluster

  3. 如果缺少 ManagedCluster，请检查 clusters 应用程序是否将 Git 存储库中的文件与 hub 集群同步： 

    $ oc describe -n openshift-gitops application clusters

    1. 检查 Status.Conditions 字段以查看受管集群的错误日志。例如，在 SiteConfig CR 中为 extraManifestPath: 设置无效的值会引发以下错误： 

      Status:
  Conditions:
    Last Transition Time:  2021-11-26T17:21:39Z
    Message:               rpc error: code = Unknown desc = `kustomize build /tmp/https___git.com/ran-sites/siteconfigs/ --enable-alpha-plugins` failed exit status 1: 2021/11/26 17:21:40 Error could not create extra-manifest ranSite1.extra-manifest3 stat extra-manifest3: no such file or directory 2021/11/26 17:21:40 Error: could not build the entire SiteConfig defined by /tmp/kust-plugin-config-913473579: stat extra-manifest3: no such file or directory Error: failure in plugin configured via /tmp/kust-plugin-config-913473579; exit status 1: exit status 1
    Type:  ComparisonError

    2. 检查 Status.Sync 字段。如果有日志错误，Status.Sync 字段可能会指示 Unknown 错误： 

      Status:
  Sync:
    Compared To:
      Destination:
        Namespace:  clusters-sub
        Server:     https://kubernetes.default.svc
      Source:
        Path:             sites-config
        Repo URL:         https://git.com/ran-sites/siteconfigs/.git
        Target Revision:  master
    Status:               Unknown

19.3.7. 从 ZTP 管道中删除受管集群站点

您可以从 ZTP 管道中删除受管站点以及关联的安装和配置策略 CR。

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 已以具有 cluster-admin 权限的用户身份登录到 hub 集群。

过程

  1. 通过从 kustomization.yaml 文件中删除关联的 SiteConfig 和 PolicyGenTemplate 文件来删除站点和相关 CR。

    当您再次运行 ZTP 管道时，生成的 CR 将被删除。

  2. 可选： 如果要永久删除站点，您还应从 Git 仓库中删除 SiteConfig 和特定站点的 PolicyGenTemplate 文件。
  3. 可选：如果要临时删除站点，例如在重新部署站点时，可以保留 Git 存储库中的 SiteConfig 和特定站点的 PolicyGenTemplate CR。
注意

从 Git 仓库中删除 SiteConfig 文件后，如果对应的集群一直处于 detach 过程中，请检查 hub 集群上的 Red Hat Advanced Cluster Management (RHACM)，以了解有关清理分离集群的信息。

其他资源

19.3.8. 从 ZTP 管道中删除过时的内容

如果对 PolicyGenTemplate 配置的更改会导致过时的策略，例如，如果您重命名策略，请使用以下步骤删除过时的策略。

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 已以具有 cluster-admin 权限的用户身份登录到 hub 集群。

流程

  1. 从 Git 存储库中删除受影响的 PolicyGenTemplate 文件，提交并推送到远程存储库。
  2. 等待更改通过应用程序同步，并将受影响的策略从 hub 集群中删除。

  3. 将更新的 PolicyGenTemplate 文件重新添加到 Git 存储库，然后提交并推送到远程存储库。

    注意

    从 Git 仓库中删除零接触置备 (ZTP) 策略，因此也会从 hub 集群中删除它们，不会影响受管集群的配置。由该策略管理的策略和 CR 保留在受管集群上。

  4. 可选：作为替代方案，在修改了导致过时策略的 PolicyGenTemplate CR 后，您可以手动从 hub 集群中删除这些策略。您可以使用 Governance 选项卡或运行以下命令来从 RHACM 控制台删除策略： 

    $ oc delete policy -n <namespace> <policy_name>

19.3.9. 弃用 ZTP 管道

您可以删除 ArgoCD 管道和所有生成的 ZTP 工件。

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 已以具有 cluster-admin 权限的用户身份登录到 hub 集群。

流程

  1. 从 hub 集群上的 Red Hat Advanced Cluster Management (RHACM)分离所有集群。

  2. 使用以下命令，删除 deployment 目录中的 kustomization.yaml 文件： 

    $ oc delete -k out/argocd/deployment
  3. 提交您的更改并推送到站点存储库。

19.4. 使用策略和 PolicyGenTemplate 资源配置受管集群

应用的策略自定义资源 (CR) 配置您置备的受管集群。您可以自定义 Red Hat Advanced Cluster Management (RHACM) 如何使用 PolicyGenTemplate CR 生成应用的策略 CR。

19.4.1. 关于 PolicyGenTemplate CRD

PolicyGenTemplate 自定义资源定义(CRD) 告知 PolicyGen 策略生成器在集群配置中包含哪些自定义资源 (CR)，如何将 CR 组合到生成的策略中，以及这些 CR 中的项目需要使用 overlay 内容更新。

以下示例显示了从 ztp-site-generate 引用容器中提取的 PolicyGenTemplate CR (common-du-ranGen.yaml)。common-du-ranGen.yaml 文件定义了两个 Red Hat Advanced Cluster Management (RHACM) 策略。策略管理配置 CR 集合，每个 CR 中的 policyName 值对应一个。common-du-ranGen.yaml 创建一个单个放置绑定和一个放置规则，根据 bindingRules 部分中列出的标签将策略绑定到集群。

Example PolicyGenTemplate CR - common-du-ranGen.yaml

---
apiVersion: ran.openshift.io/v1
kind: PolicyGenTemplate
metadata:
  name: "common"
  namespace: "ztp-common"
spec:
  bindingRules:
    common: "true" 1
  sourceFiles: 2
    - fileName: SriovSubscription.yaml
      policyName: "subscriptions-policy"
    - fileName: SriovSubscriptionNS.yaml
      policyName: "subscriptions-policy"
    - fileName: SriovSubscriptionOperGroup.yaml
      policyName: "subscriptions-policy"
    - fileName: SriovOperatorStatus.yaml
      policyName: "subscriptions-policy"
    - fileName: PtpSubscription.yaml
      policyName: "subscriptions-policy"
    - fileName: PtpSubscriptionNS.yaml
      policyName: "subscriptions-policy"
    - fileName: PtpSubscriptionOperGroup.yaml
      policyName: "subscriptions-policy"
    - fileName: PtpOperatorStatus.yaml
      policyName: "subscriptions-policy"
    - fileName: ClusterLogNS.yaml
      policyName: "subscriptions-policy"
    - fileName: ClusterLogOperGroup.yaml
      policyName: "subscriptions-policy"
    - fileName: ClusterLogSubscription.yaml
      policyName: "subscriptions-policy"
    - fileName: ClusterLogOperatorStatus.yaml
      policyName: "subscriptions-policy"
    - fileName: StorageNS.yaml
      policyName: "subscriptions-policy"
    - fileName: StorageOperGroup.yaml
      policyName: "subscriptions-policy"
    - fileName: StorageSubscription.yaml
      policyName: "subscriptions-policy"
    - fileName: StorageOperatorStatus.yaml
      policyName: "subscriptions-policy"
    - fileName: ReduceMonitoringFootprint.yaml
      policyName: "config-policy"
    - fileName: OperatorHub.yaml 3
      policyName: "config-policy"
    - fileName: DefaultCatsrc.yaml 4
      policyName: "config-policy" 5
      metadata:
        name: redhat-operators
      spec:
        displayName: disconnected-redhat-operators
        image: registry.example.com:5000/disconnected-redhat-operators/disconnected-redhat-operator-index:v4.9
    - fileName: DisconnectedICSP.yaml
      policyName: "config-policy"
      spec:
        repositoryDigestMirrors:
        - mirrors:
          - registry.example.com:5000
          source: registry.redhat.io

1
common: "true" 将策略应用到具有此标签的所有集群。
2
sourceFiles 下列出的文件为已安装的集群创建 Operator 策略。
3
OperatorHub.yaml 为断开连接的 registry 配置 OperatorHub。
4
DefaultCatsrc.yaml 配置断开连接的 registry 的目录源。
5
policyName: "config-policy" 配置 Operator 订阅。OperatorHub CR 禁用默认值，此 CR 将 redhat-operators 替换为指向断开连接的 registry 的 CatalogSource CR。

PolicyGenTemplate CR 可以使用任意数量的包含 CR 来构建。在 hub 集群中应用以下示例 CR 来生成包含单个 CR 的策略： 

apiVersion: ran.openshift.io/v1
kind: PolicyGenTemplate
metadata:
  name: "group-du-sno"
  namespace: "ztp-group"
spec:
  bindingRules:
    group-du-sno: ""
  mcp: "master"
  sourceFiles:
    - fileName: PtpConfigSlave.yaml
      policyName: "config-policy"
      metadata:
        name: "du-ptp-slave"
      spec:
        profile:
        - name: "slave"
          interface: "ens5f0"
          ptp4lOpts: "-2 -s --summary_interval -4"
          phc2sysOpts: "-a -r -n 24"

使用源文件 PtpConfigSlave.yaml 作为示例，文件会定义一个 PtpConfig CR。为 PtpConfigSlave 示例生成的策略名为 group-du-sno-config-policy。生成的 group-du-sno-config-policy 中定义的 PtpConfig CR 被命名为 du-ptp-slave。PtpConfigSlave.yaml 中定义的 spec 放置在 du-ptp-slave 下，以及与源文件中定义的其他 spec 项目一起放置。

以下示例显示了 group-du-sno-config-policy CR： 

apiVersion: policy.open-cluster-management.io/v1
kind: Policy
metadata:
  name: group-du-ptp-config-policy
  namespace: groups-sub
  annotations:
    policy.open-cluster-management.io/categories: CM Configuration Management
    policy.open-cluster-management.io/controls: CM-2 Baseline Configuration
    policy.open-cluster-management.io/standards: NIST SP 800-53
spec:
    remediationAction: inform
    disabled: false
    policy-templates:
        - objectDefinition:
            apiVersion: policy.open-cluster-management.io/v1
            kind: ConfigurationPolicy
            metadata:
                name: group-du-ptp-config-policy-config
            spec:
                remediationAction: inform
                severity: low
                namespaceselector:
                    exclude:
                        - kube-*
                    include:
                        - '*'
                object-templates:
                    - complianceType: musthave
                      objectDefinition:
                        apiVersion: ptp.openshift.io/v1
                        kind: PtpConfig
                        metadata:
                            name: du-ptp-slave
                            namespace: openshift-ptp
                        spec:
                            recommend:
                                - match:
                                - nodeLabel: node-role.kubernetes.io/worker-du
                                  priority: 4
                                  profile: slave
                            profile:
                                - interface: ens5f0
                                  name: slave
                                  phc2sysOpts: -a -r -n 24
                                  ptp4lConf: |
                                    [global]
                                    #
                                    # Default Data Set
                                    #
                                    twoStepFlag 1
                                    slaveOnly 0
                                    priority1 128
                                    priority2 128
                                    domainNumber 24
                                    .....

19.4.2. 在自定义 PolicyGenTemplate CR 时建议

在自定义站点配置 PolicyGenTemplate 自定义资源 (CR) 时，请考虑以下最佳实践：

  • 根据需要使用一些策略。使用较少的策略需要较少的资源。每个附加策略会为 hub 集群和部署的受管集群创建开销。CR 根据 PolicyGenTemplate CR 中的 policyName 字段合并到策略中。同一 PolicyGenTemplate 中的 CR，在单个策略下管理相同的 policyName 值。
  • 在断开连接的环境中，通过将 registry 配置为包含所有 Operator 的单个索引，为所有 Operator 使用单个目录源。受管集群中的每个额外 CatalogSource CR 会增加 CPU 用量。
  • MachineConfig CR 应包含在 siteConfig CR 中作为 extraManifests，以便在安装过程中应用它们。这可减少在集群就绪部署应用程序前所花费的总时间。
  • PolicyGenTemplates 应该覆盖 channel 字段以明确标识所需版本。这样可确保源 CR 在升级过程中的更改不会更新生成的订阅。

其他资源

注意

在 hub 集群中管理大量 spoke 集群时，请最小化策略数量来减少资源消耗。

将多个配置 CR 分组到单个或有限的策略中，一种方法是减少 hub 集群上的总体策略数量。在使用 common/group/site 层次结构来管理站点配置时，务必要将特定于站点的配置组合成单一策略。

19.4.3. RAN 部署的 PolicyGenTemplate CR

使用 PolicyGenTemplate (PGT) 自定义资源 (CR) 使用 GitOps 零接触置备 (ZTP) 管道自定义应用到集群的配置。PGT CR 允许您生成一个或多个策略来管理您的集群上的配置 CR 集合。PGT 标识一组受管 CR，将它们捆绑到策略中，构建与这些 CR 相关的策略，并使用标签绑定规则将策略与集群相关联。

从 GitOps ZTP 容器获取的参考配置旨在提供一组关键功能和节点调优设置，以确保集群可以支持字符串的性能和资源利用率限制，典型的 RAN 分布式单元(DU)应用程序。来自基准配置的更改或禁止可能会影响功能可用性、性能和资源利用率。使用 PolicyGenTemplate CR 作为参考来创建根据您的特定站点要求量身定制的配置文件的层次结构。

为 RAN DU 集群配置定义的基准 PolicyGenTemplate CR 可以从 GitOps ZTP ztp-site-generate 容器中提取。如需了解更多详细信息，请参阅"准备 GitOps ZTP 站点配置存储库"。

PolicyGenTemplate CR 可以在 ./out/argocd/example/policygentemplates 文件夹中找到。参考架构具有共同、组和特定站点的配置 CR。每个 PolicyGenTemplate CR 都引用可在 ./out/source-crs 文件夹中找到的其他 CR。

与 RAN 集群配置相关的 PolicyGenTemplate CR 如下所述。为组 PolicyGenTemplate CR 提供了变量，以考虑单节点、三节点紧凑和标准集群配置的不同。同样，为单节点集群和多节点（compact 或 standard）集群提供了特定于站点的配置变体。使用与部署相关的组和特定于站点的配置变体。

表 19.3. RAN 部署的 PolicyGenTemplate CR

PolicyGenTemplate CR描述

example-multinode-site.yaml

包含一组应用于多节点集群的 CR。这些 CR 配置 SR-IOV 功能，用于 RAN 安装。

example-sno-site.yaml

包含一组应用于单节点 OpenShift 集群的 CR。这些 CR 配置 SR-IOV 功能，用于 RAN 安装。

common-ranGen.yaml

包含一组应用于所有集群的通用 RAN CR。这些 CR 订阅一组 operator，提供典型的 RAN 和基准集群调整功能。

group-du-3node-ranGen.yaml

仅包含三节点集群的 RAN 策略。

group-du-sno-ranGen.yaml

仅包含单节点集群的 RAN 策略。

group-du-standard-ranGen.yaml

包含标准三个 control-plane 集群的 RAN 策略。

group-du-3node-validator-ranGen.yaml

PolicyGenTemplate CR 用于生成三节点集群所需的各种策略。

group-du-standard-validator-ranGen.yaml

PolicyGenTemplate CR 用于生成标准集群所需的各种策略。

group-du-sno-validator-ranGen.yaml

PolicyGenTemplate CR 用于生成单节点 OpenShift 集群所需的各种策略。

其他资源

19.4.4. 使用 PolicyGenTemplate CR 自定义受管集群

使用以下步骤自定义应用于使用零接触置备 (ZTP) 管道置备的受管集群的策略。

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 已以具有 cluster-admin 权限的用户身份登录到 hub 集群。
  • 配置了 hub 集群来生成所需的安装和策略 CR。
  • 您创建了 Git 存储库，用于管理自定义站点配置数据。该存储库必须可从 hub 集群访问，并定义为 Argo CD 应用程序的源仓库。

流程

  1. 为特定于站点的配置 CR 创建 PolicyGenTemplate CR。

    1. 从 out/argocd/example/policygentemplates 文件夹中选择适当的 CR 示例，例如 example-sno-site.yaml 或 example-multinode-site.yaml。

    2. 更改示例文件中的 bindingRules 字段，使其与 SiteConfig CR 中包含的特定于站点的标签匹配。在示例 SiteConfig 文件中，特定于站点的标签是 sites: example-sno。

      注意

      确保 PolicyGenTemplate bindingRules 字段中定义的标签对应于相关受管集群 SiteConfig CR 中定义的标签。

    3. 更改示例文件中的内容，使其与所需配置匹配。

  2. 可选：为应用到集群的任何通用配置 CR 创建一个 PolicyGenTemplate CR。

    1. 从 out/argocd/example/policygentemplates 文件夹中选择适合您的 CR 示例，例如 common-ranGen.yaml。
    2. 更改示例文件中的内容，使其与所需配置匹配。

  3. 可选：为应用到团队中特定集群组的任何组配置 CR 创建一个 PolicyGenTemplate CR。

    确保 overlaid spec 文件的内容与您的预期最终状态匹配。作为参考，out/source-crs 目录包含可用于包含并由您的 PolicyGenTemplate 模板提供的 source-crs 的完整列表。

    注意

    根据集群的特定要求，每个集群类型可能需要一个组策略，特别是考虑示例组策略各自有一个 PerformancePolicy.yaml 文件，如果这些集群是由相同的硬件配置，则只能在一组集群中共享。

    1. 从 out/argocd/example/policygentemplates 文件夹中选择适当的 CR 示例，例如 group-du-sno-ranGen.yaml。
    2. 更改示例文件中的内容，使其与所需配置匹配。
  4. 可选的。当 ZTP 安装和配置完成后，创建验证器通知策略 PolicyGenTemplate CR。如需更多信息，请参阅"创建验证器通知策略"。

  5. 在 YAML 文件中定义所有策略命名空间，类似于示例 out/argocd/example/policygentemplates/ns.yaml 文件。

    重要

    不要在带有 PolicyGenTemplate CR 的同一文件中包括 Namespace CR。

  6. 将 PolicyGenTemplate CR 和 Namespace CR 添加到 generators 部分中的 kustomization.yaml 文件中，类似于 out/argocd/example/policygentemplates/kustomization.yaml 所示的示例。

  7. 在 Git 存储库中提交 PolicyGenTemplate CR、Namespace CR 和关联的 kustomization.yaml 文件并推送更改。

    ArgoCD 管道检测到更改并开始受管集群部署。您可以同时将更改推送到 SiteConfig CR 和 PolicyGenTemplate CR。

其他资源

19.4.5. 监控受管集群策略部署进度

ArgoCD 管道使用 Git 中的 PolicyGenTemplate CR 生成 RHACM 策略，然后将其同步到 hub 集群。您可以在辅助服务在受管集群中安装 OpenShift Container Platform 后监控受管集群策略同步的进度。

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 已以具有 cluster-admin 权限的用户身份登录到 hub 集群。

流程

  1. Topology Aware Lifecycle Manager(TALM)应用绑定到集群的配置策略。

    集群安装完成后，集群变为 Ready，ClusterGroupUpgrade CR 对应于此集群，且由 run.openshift.io/ztp-deploy-wave annotations 定义的已排序策略列表由 TALM 自动创建。集群的策略按 ClusterGroupUpgrade CR 中列出的顺序应用。

    您可以使用以下命令监控配置策略协调的高级进度： 

    $ export CLUSTER=<clusterName>
    $ oc get clustergroupupgrades -n ztp-install $CLUSTER -o jsonpath='{.status.conditions[-1:]}' | jq

    输出示例

    {
  "lastTransitionTime": "2022-11-09T07:28:09Z",
  "message": "The ClusterGroupUpgrade CR has upgrade policies that are still non compliant",
  "reason": "UpgradeNotCompleted",
  "status": "False",
  "type": "Ready"
}

  2. 您可以使用 RHACM 仪表板或命令行监控详细的集群策略合规状态。

    1. 要使用 oc 检查策略合规性，请运行以下命令： 

      $ oc get policies -n $CLUSTER

      输出示例

      NAME                                                     REMEDIATION ACTION   COMPLIANCE STATE   AGE
ztp-common.common-config-policy                          inform               Compliant          3h42m
ztp-common.common-subscriptions-policy                   inform               NonCompliant       3h42m
ztp-group.group-du-sno-config-policy                     inform               NonCompliant       3h42m
ztp-group.group-du-sno-validator-du-policy               inform               NonCompliant       3h42m
ztp-install.example1-common-config-policy-pjz9s          enforce              Compliant          167m
ztp-install.example1-common-subscriptions-policy-zzd9k   enforce              NonCompliant       164m
ztp-site.example1-config-policy                          inform               NonCompliant       3h42m
ztp-site.example1-perf-policy                            inform               NonCompliant       3h42m

    2. 要从 RHACM Web 控制台检查策略状态，请执行以下操作：

      1. 点 Governance → Find policies。
      2. 点集群策略检查其状态。

当所有集群策略都合规时，集群的 ZTP 安装和配置已完成。ztp-done 标签添加到集群中。

在引用配置中，合规的最终策略是 *-du-validator-policy 策略中定义的。此策略当在一个集群中合规时，确保所有集群配置、Operator 安装和 Operator 配置已完成。

19.4.6. 验证配置策略 CR 的生成

策略自定义资源(CR)在与创建它们的 PolicyGenTemplate 相同的命名空间中生成。同样的故障排除流程适用于从 PolicyGenTemplate 生成的所有策略 CR，无论它们是 ztp-common、ztp-group，还是基于 ztp-site，请使用以下命令： 

$ export NS=<namespace>
$ oc get policy -n $NS

应该会显示预期的策略嵌套 CR 集合。

如果策略失败的同步，请使用以下故障排除步骤。

流程

  1. 要显示策略的详细信息，请运行以下命令： 

    $ oc describe -n openshift-gitops application policies

  2. 检查 Status: Conditions: 来显示错误日志。例如，设置无效的 sourceFile→fileName: 生成以下错误： 

    Status:
  Conditions:
    Last Transition Time:  2021-11-26T17:21:39Z
    Message:               rpc error: code = Unknown desc = `kustomize build /tmp/https___git.com/ran-sites/policies/ --enable-alpha-plugins` failed exit status 1: 2021/11/26 17:21:40 Error could not find test.yaml under source-crs/: no such file or directory Error: failure in plugin configured via /tmp/kust-plugin-config-52463179; exit status 1: exit status 1
    Type:  ComparisonError

  3. 检查 Status: Sync:。如果 Status: Conditions: 中存在日志错误，则 Status: Sync: 显示 Unknown 或 Error: 

    Status:
  Sync:
    Compared To:
      Destination:
        Namespace:  policies-sub
        Server:     https://kubernetes.default.svc
      Source:
        Path:             policies
        Repo URL:         https://git.com/ran-sites/policies/.git
        Target Revision:  master
    Status:               Error

  4. 当 Red Hat Advanced Cluster Management(RHACM)识别策略应用到 ManagedCluster 对象时，策略 CR 对象应用到集群命名空间。检查策略是否已复制到集群命名空间中： 

    $ oc get policy -n $CLUSTER

    输出示例：

    NAME                                         REMEDIATION ACTION   COMPLIANCE STATE   AGE
ztp-common.common-config-policy              inform               Compliant          13d
ztp-common.common-subscriptions-policy       inform               Compliant          13d
ztp-group.group-du-sno-config-policy         inform               Compliant          13d
Ztp-group.group-du-sno-validator-du-policy   inform               Compliant          13d
ztp-site.example-sno-config-policy           inform               Compliant          13d

    RHACM 将所有适用的策略复制到集群命名空间中。复制的策略名称使用以下格式：<policyGenTemplate.Namespace>.<policyGenTemplate.Name>-<policyName>。

  5. 检查放置规则中是否有没有复制到集群命名空间中的策略。这些策略的 PlacementRule 中的 matchSelector 应与 ManagedCluster 对象上的标签匹配： 

    $ oc get placementrule -n $NS

  6. 使用以下命令，注意适合缺少策略、通用、组或站点的 PlacementRule 名称： 

    $ oc get placementrule -n $NS <placementRuleName> -o yaml
    • status-decisions 应该包括集群名称。
    • spec 中 matchSelector 的键值对必须与受管集群上的标签匹配。

  7. 使用以下命令，检查 ManagedCluster 对象上的标签： 

    $ oc get ManagedCluster $CLUSTER -o jsonpath='{.metadata.labels}' | jq

  8. 使用以下命令查看合规策略： 

    $ oc get policy -n $CLUSTER

    如果 Namespace、OperatorGroup 和 Subscription 策略兼容，但 Operator 配置策略不兼容，则 Operator 可能不会在受管集群中安装。这会导致 Operator 配置策略无法应用，因为 CRD 还没有应用到 spoke。

19.4.7. 重启策略协调

当发生意外合规问题时，您可以重启策略协调，例如 ClusterGroupUpgrade 自定义资源 (CR) 超时时。

流程

  1. 在受管集群变为 Ready 后，Topology Aware Lifecycle Manager 在命名空间 ztp-install 中生成 ClusterGroupUpgrade CR： 

    $ export CLUSTER=<clusterName>
    $ oc get clustergroupupgrades -n ztp-install $CLUSTER

  2. 如果出现意外问题，且策略无法在配置超时（默认为 4 小时）内变为合规，ClusterGroupUpgrade CR 的状态会显示 UpgradeTimedOut ： 

    $ oc get clustergroupupgrades -n ztp-install $CLUSTER -o jsonpath='{.status.conditions[?(@.type=="Ready")]}'

  3. UpgradeTimedOut 状态的 ClusterGroupUpgrade CR 每小时自动重启其策略协调。如果更改了策略，可以通过删除现有 ClusterGroupUpgrade CR 来启动立即重试。这会触发自动创建新的 ClusterGroupUpgrade CR，以开始立即协调策略： 

    $ oc delete clustergroupupgrades -n ztp-install $CLUSTER

请注意，当 ClusterGroupUpgrade CR 完成，其状态为 UpgradeCompleted，且受管集群应用了 ztp-done 标签，您可以使用 PolicyGenTemplate 创建额外的配置更改。删除现有的 ClusterGroupUpgrade CR 将无法生成新的 CR。

此时，ZTP 完成了与集群的交互，任何进一步的交互都应被视为更新，并为补救策略创建新的 ClusterGroupUpgrade CR。

其他资源

  • 有关使用 Topology Aware Lifecycle Manager (TALM)来构建自己的 ClusterGroupUpgrade CR 的详情，请参考关于 ClusterGroupUpgrade CR。

19.4.8. 假定为 ZTP 安装

零接触置备 (ZTP) 简化了检查集群的 ZTP 安装状态的过程。ZTP 状态分为三个阶段：集群安装、集群配置和 ZTP。

集群安装阶段
集群安装阶段由 ManagedCluster CR 中的 ManagedClusterJoined 和 ManagedClusterAvailable 条件显示。如果 ManagedCluster CR 没有这些条件，或者条件设置为 False，集群仍然处于安装阶段。有关安装的更多信息，请参阅 AgentClusterInstall 和 ClusterDeployment CR。如需更多信息，请参阅"Troubleshooting GitOps ZTP"。
集群配置阶段
集群配置阶段由 ztp-running 标签显示，在集群中应用 ManagedCluster CR。
完成了 ZTP

集群安装和配置在 ZTP 完成。这可以通过删除 ztp-running 标签并在 ManagedCluster CR 中添加 ztp-done 标签来显示。ztp-done 标签显示应用了配置，基准 DU 配置已完成集群调整。

过渡到 ZTP 完成的状态是在 Red Hat Advanced Cluster Management (RHACM) 验证通知策略合规状态的条件。这个策略捕获了已完成的安装的现有条件，并确认只有在受管集群的 ZTP 置备完成后才会变为合规状态。

验证器通知策略可确保完全应用集群的配置，Operator 已完成初始化。策略验证以下内容：

  • 目标 MachineConfigPool 包含预期的条目，并已完成更新。所有节点都可用，且没有降级。
  • 至少有一个 SriovNetworkNodeState 带有 syncStatus: Succeeded 则代表 SR-IOV Operator 已完成初始化。
  • PTP Operator 守护进程集已存在。

19.5. 使用 ZTP 手动安装单节点 OpenShift 集群

您可以使用 Red Hat Advanced Cluster Management (RHACM) 和支持的服务部署受管单节点 OpenShift 集群。

注意

如果要创建多个受管集群，请参阅使用 ZTP 部署边缘站点中描述的 SiteConfig 方法。

重要

目标裸机主机必须满足 vDU 应用程序工作负载的推荐集群配置中列出的网络、固件和硬件要求。

19.5.1. 手动生成 ZTP 安装和配置 CR

使用 ztp-site-generate 容器的 generator 入口点，根据 SiteConfig 和 PolicyGenTemplate CR 为集群生成站点安装和配置自定义资源 (CR)。

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 已以具有 cluster-admin 权限的用户身份登录到 hub 集群。

流程

  1. 运行以下命令来创建输出文件夹： 

    $ mkdir -p ./out

  2. 从 ztp-site-generate 容器镜像导出 argocd 目录： 

    $ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.10 extract /home/ztp --tar | tar x -C ./out

    ./out 目录包含 out/argocd/example/ 文件夹中的参考 PolicyGenTemplate 和 SiteConfig CR。

    输出示例

    out
 └── argocd
      └── example
           ├── policygentemplates
           │     ├── common-ranGen.yaml
           │     ├── example-sno-site.yaml
           │     ├── group-du-sno-ranGen.yaml
           │     ├── group-du-sno-validator-ranGen.yaml
           │     ├── kustomization.yaml
           │     └── ns.yaml
           └── siteconfig
                  ├── example-sno.yaml
                  ├── KlusterletAddonConfigOverride.yaml
                  └── kustomization.yaml

  3. 为站点安装 CR 创建输出文件夹： 

    $ mkdir -p ./site-install

  4. 为您要安装的集群类型修改示例 SiteConfig CR。将 example-sno.yaml 复制到 site-1-sno.yaml，并修改 CR 以匹配您要安装的站点和裸机主机的详情，例如：

    单节点 OpenShift 集群 SiteConfig CR 示例

    apiVersion: ran.openshift.io/v1
kind: SiteConfig
metadata:
  name: "<site_name>"
  namespace: "<site_name>"
spec:
  baseDomain: "example.com"
  pullSecretRef:
    name: "assisted-deployment-pull-secret" 1
  clusterImageSetNameRef: "openshift-4.10" 2
  sshPublicKey: "ssh-rsa AAAA..." 3
  clusters:
  - clusterName: "<site_name>"
    networkType: "OVNKubernetes"
    clusterLabels: 4
      common: true
      group-du-sno: ""
      sites : "<site_name>"
    clusterNetwork:
      - cidr: 1001:1::/48
        hostPrefix: 64
    machineNetwork:
      - cidr: 1111:2222:3333:4444::/64
    serviceNetwork:
      - 1001:2::/112
    additionalNTPSources:
      - 1111:2222:3333:4444::2
    #crTemplates:
    #  KlusterletAddonConfig: "KlusterletAddonConfigOverride.yaml" 5
    nodes:
      - hostName: "example-node.example.com" 6
        role: "master"
        #biosConfigRef:
        #  filePath: "example-hw.profile" 7
        bmcAddress: idrac-virtualmedia://<out_of_band_ip>/<system_id>/ 8
        bmcCredentialsName:
          name: "bmh-secret" 9
        bootMACAddress: "AA:BB:CC:DD:EE:11"
        bootMode: "UEFI" 10
        rootDeviceHints:
          wwn: "0x11111000000asd123"
        cpuset: "0-1,52-53"
        nodeNetwork: 11
          interfaces:
            - name: eno1
              macAddress: "AA:BB:CC:DD:EE:11"
          config:
            interfaces:
              - name: eno1
                type: ethernet
                state: up
                ipv4:
                  enabled: false
                ipv6: 12
                  enabled: true
                  address:
                  - ip: 1111:2222:3333:4444::aaaa:1
                    prefix-length: 64
            dns-resolver:
              config:
                search:
                - example.com
                server:
                - 1111:2222:3333:4444::2
            routes:
              config:
              - destination: ::/0
                next-hop-interface: eno1
                next-hop-address: 1111:2222:3333:4444::1
                table-id: 254

    1
    使用与 SiteConfig CR 相同的命名空间创建 assisted-deployment-pull-secret CR。
    2
    clusterImageSetNameRef 定义 hub 集群中可用的镜像集。要查看 hub 集群上支持的版本列表，请运行 oc get clusterimagesets。
    3
    配置用于访问集群的 SSH 公钥。
    4
    集群标签必须与您定义的 PolicyGenTemplate CR 中的 bindingRules 字段对应。例如，policygentemplates/common-ranGen.yaml 应用到所有带有 common: true 设置的集群，policygentemplates/group-du-sno-ranGen.yaml 应用到所有带有 group-du-sno: "" 设置的所有集群。
    5
    可选的。KlusterletAddonConfig 下的 CR specifed 用于覆盖为集群创建的默认 KlusterletAddonConfig。
    6
    对于单节点部署，请定义一个主机。对于三节点部署，请定义三个主机。对于标准部署，使用 role: master 定义三个主机，使用 role: worker 定义两个或更多主机。
    7
    可选的。使用 biosConfigRef 为主机配置所需的固件。
    8
    适用于所有集群类型。指定 BMC 地址。
    9
    创建指定 BMC 凭证的 bmh-secret CR。使用与 SiteConfig CR 相同的命名空间。
    10
    使用 UEFISecureBoot 在主机上启用安全引导。
    11
    指定节点的网络设置。
    12
    配置主机的 IPv6 地址。对于带有静态 IP 地址的单节点 OpenShift 集群，特定于节点的 API 和 Ingress IP 应该相同。

  5. 运行以下命令，通过处理修改后的 SiteConfig CR site-1-sno.yaml 来生成 day-0 安装 CR： 

    $ podman run -it --rm -v `pwd`/out/argocd/example/siteconfig:/resources:Z -v `pwd`/site-install:/output:Z,U registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.10.1 generator install site-1-sno.yaml /output

    输出示例

    site-install
└── site-1-sno
    ├── site-1_agentclusterinstall_example-sno.yaml
    ├── site-1-sno_baremetalhost_example-node1.example.com.yaml
    ├── site-1-sno_clusterdeployment_example-sno.yaml
    ├── site-1-sno_configmap_example-sno.yaml
    ├── site-1-sno_infraenv_example-sno.yaml
    ├── site-1-sno_klusterletaddonconfig_example-sno.yaml
    ├── site-1-sno_machineconfig_02-master-workload-partitioning.yaml
    ├── site-1-sno_machineconfig_predefined-extra-manifests-master.yaml
    ├── site-1-sno_machineconfig_predefined-extra-manifests-worker.yaml
    ├── site-1-sno_managedcluster_example-sno.yaml
    ├── site-1-sno_namespace_example-sno.yaml
    └── site-1-sno_nmstateconfig_example-node1.example.com.yaml

  6. 可选：使用 -E 选项处理参考 SiteConfig CR，只为特定集群类型生成 day-0 MachineConfig 安装 CR。例如，运行以下命令：

    1. 为 MachineConfig CR 创建输出文件夹： 

      $ mkdir -p ./site-machineconfig

    2. 生成 MachineConfig 安装 CR： 

      $ podman run -it --rm -v `pwd`/out/argocd/example/siteconfig:/resources:Z -v `pwd`/site-machineconfig:/output:Z,U registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.10.1 generator install -E site-1-sno.yaml /output

      输出示例

      site-machineconfig
└── site-1-sno
    ├── site-1-sno_machineconfig_02-master-workload-partitioning.yaml
    ├── site-1-sno_machineconfig_predefined-extra-manifests-master.yaml
    └── site-1-sno_machineconfig_predefined-extra-manifests-worker.yaml

  7. 使用上一步中的参考 PolicyGenTemplate CR 生成并导出 day-2 配置 CR。运行以下命令：

    1. 为 day-2 CR 创建输出文件夹： 

      $ mkdir -p ./ref

    2. 生成并导出第 2 天配置 CR： 

      $ podman run -it --rm -v `pwd`/out/argocd/example/policygentemplates:/resources:Z -v `pwd`/ref:/output:Z,U registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.10.1 generator config -N . /output

      该命令在 ./ref 文件夹中为单节点 OpenShift、三节点集群和标准集群生成示例组和特定于站点的 PolicyGenTemplate CR。

      输出示例

      ref
 └── customResource
      ├── common
      ├── example-multinode-site
      ├── example-sno
      ├── group-du-3node
      ├── group-du-3node-validator
      │    └── Multiple-validatorCRs
      ├── group-du-sno
      ├── group-du-sno-validator
      ├── group-du-standard
      └── group-du-standard-validator
           └── Multiple-validatorCRs

  8. 使用生成的 CR 作为安装集群的 CR 的基础。您可以将安装 CR 应用到 hub 集群，如 "Installing a single managed cluster" 所述。配置 CR 可以在集群安装后应用到集群。

其他资源

19.5.2. 创建受管裸机主机 secret

将受管裸机主机所需的 Secret 自定义资源 (CR) 添加到 hub 集群。您需要 ZTP 管道的 secret 来访问 Baseboard Management Controller (BMC) 和支持的安装程序服务的 secret，以便从 registry 中拉取集群安装镜像。

注意

secret 按名称从 SiteConfig CR 引用。命名空间必须与 SiteConfig 命名空间匹配。

流程

  1. 创建一个 YAML secret 文件，其中包含主机 Baseboard Management Controller (BMC) 和安装 OpenShift 和所有附加组件集群 Operator 所需的凭证：

    1. 将以下 YAML 保存为文件 example-sno-secret.yaml ： 

      apiVersion: v1
kind: Secret
metadata:
  name: example-sno-bmc-secret
  namespace: example-sno 1
data: 2
  password: <base64_password>
  username: <base64_username>
type: Opaque
---
apiVersion: v1
kind: Secret
metadata:
  name: pull-secret
  namespace: example-sno  3
data:
  .dockerconfigjson: <pull_secret> 4
type: kubernetes.io/dockerconfigjson
      1
      必须与相关 SiteConfig CR 中配置的命名空间匹配
      2
      password 和 username 的 base64 编码值
      3
      必须与相关 SiteConfig CR 中配置的命名空间匹配
      4
      Base64 编码的 pull secret
  2. 将到 example-sno-secret.yaml 的相对路径添加用于安装集群的 kustomization.yaml 文件中。

19.5.3. 安装单个受管集群

您可以使用辅助服务和 Red Hat Advanced Cluster Management (RHACM) 手动部署单个受管集群。

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 已以具有 cluster-admin 权限的用户身份登录到 hub 集群。
  • 您已创建了基板管理控制器(BMC) Secret 和镜像 pull-secret Secret 自定义资源 (CR)。详情请参阅"创建受管裸机主机 secret"。
  • 您的目标裸机主机满足受管集群的网络和硬件要求。

流程

  1. 为要部署的每个特定集群版本创建一个 ClusterImageSet，如 clusterImageSet-4.10.yaml。ClusterImageSet 具有以下格式： 

    apiVersion: hive.openshift.io/v1
kind: ClusterImageSet
metadata:
  name: openshift-4.10.0-rc.0 1
spec:
   releaseImage: quay.io/openshift-release-dev/ocp-release:4.10.0-x86_64 2
    1
    要部署的描述性版本。
    2
    指定要部署并决定操作系统镜像的 releaseImage 版本。发现 ISO 基于由 releaseImage 设置的镜像版本，如果准确版本不可用，则为最新版本。

  2. 应用 clusterImageSet CR： 

    $ oc apply -f clusterImageSet-4.10.yaml

  3. 在 cluster-namespace.yaml 文件中创建 Namespace CR： 

    apiVersion: v1
kind: Namespace
metadata:
     name: <cluster_name> 1
     labels:
        name: <cluster_name> 2
    1 2
    要置备的受管集群的名称。

  4. 运行以下命令来应用 Namespace CR： 

    $ oc apply -f cluster-namespace.yaml

  5. 应用从 ztp-site-generate 容器中提取的生成的 day-0 CR，并自定义以满足您的要求： 

    $ oc apply -R ./site-install/site-sno-1

其他资源

19.5.4. 监控受管集群安装状态

通过检查集群状态，确保集群置备成功。

先决条件

  • 所有自定义资源都已配置并置备，在受管集群的 hub 上创建 Agent 自定义资源。

流程

  1. 检查受管集群的状态： 

    $ oc get managedcluster

    True 表示受管集群已就绪。

  2. 检查代理状态： 

    $ oc get agent -n <cluster_name>

  3. 使用 describe 命令，提供代理条件的深入描述。支持的状态包括 BackendError、InputError、ValidationsFailing、InFailed 和 AgentIsConnected。这些状态与 Agent 和 AgentClusterInstall 自定义资源相关。 

    $ oc describe agent -n <cluster_name>

  4. 检查集群置备状态： 

    $ oc get agentclusterinstall -n <cluster_name>

  5. 使用 describe 命令提供集群置备状态的深入描述： 

    $ oc describe agentclusterinstall -n <cluster_name>

  6. 检查受管集群的附加服务的状态： 

    $ oc get managedclusteraddon -n <cluster_name>

  7. 检索受管集群的 kubeconfig 文件的身份验证信息： 

    $ oc get secret -n <cluster_name> <cluster_name>-admin-kubeconfig -o jsonpath={.data.kubeconfig} | base64 -d > <directory>/<cluster_name>-kubeconfig

19.5.5. 受管集群故障排除

使用这个流程诊断受管集群中可能出现的任何安装问题。

流程

  1. 检查受管集群的状态： 

    $ oc get managedcluster

    输出示例

    NAME            HUB ACCEPTED   MANAGED CLUSTER URLS   JOINED   AVAILABLE   AGE
SNO-cluster     true                                   True     True      2d19h

    如果 AVAILABLE 列中的状态为 True，受管集群由 hub 管理。

    如果 AVAILABLE 列中的状态为 Unknown，则受管集群不会由 hub 管理。使用以下步骤继续检查 以了解更多信息。

  2. 检查 AgentClusterInstall 安装状态： 

    $ oc get clusterdeployment -n <cluster_name>

    输出示例

    NAME        PLATFORM            REGION   CLUSTERTYPE   INSTALLED    INFRAID    VERSION  POWERSTATE AGE
Sno0026    agent-baremetal                               false                          Initialized
2d14h

    如果 INSTALLED 列中的状态为 false，则安装会失败。

  3. 如果安装失败，请输入以下命令查看 AgentClusterInstall 资源的状态： 

    $ oc describe agentclusterinstall -n <cluster_name> <cluster_name>

  4. 解决错误并重置集群：

    1. 删除集群的受管集群资源： 

      $ oc delete managedcluster <cluster_name>

    2. 删除集群的命名空间： 

      $ oc delete namespace <cluster_name>

      这会删除为此集群创建的所有命名空间范围自定义资源。您必须等待 ManagedCluster CR 删除完成，然后才能继续。

    3. 为受管集群重新创建自定义资源。

19.5.6. RHACM 生成的集群安装 CR 参考

Red Hat Advanced Cluster Management (RHACM)支持在每个站点的 SiteConfig CR 上部署 OpenShift Container Platform，以及带有特定安装自定义资源 (CR) 的 OpenShift Container Platform。

注意

每个受管集群都有自己的命名空间，除 ManagedCluster 和 ClusterImageSet 以外的所有安装 CR 都位于该命名空间中。ManagedCluster 和 ClusterImageSet 是集群范围的，而不是命名空间范围的。命名空间和 CR 名称与集群名称匹配。

下表列出了在使用您配置的 SiteConfig CR 安装集群时 RHACM 辅助服务自动应用的安装 CR。

表 19.4. 由 RHACM 生成的集群安装 CR

CR描述使用方法

BareMetalHost

包含目标裸机主机 Baseboard Management Controller(BMC)的连接信息。

使用 Redfish 协议提供对 BMC 的访问在目标服务器上加载和引导发现镜像。

InfraEnv

包含在目标裸机主机上安装 OpenShift Container Platform 的信息。

与 ClusterDeployment 一起使用，为受管集群生成发现 ISO。

AgentClusterInstall

指定管理集群配置的详情，如网络和 control plane 节点的数量。安装完成后，显示集群 kubeconfig 和凭证。

指定受管集群配置信息，并在安装集群期间提供状态。

ClusterDeployment

引用要使用的 AgentClusterInstall CR。

与 InfraEnv 一起使用，为受管集群生成发现 ISO。

NMStateConfig

提供网络配置信息，如 MAC 地址到 IP 映射、DNS 服务器、默认路由和其他网络设置。如果使用 DHCP，则不需要此操作。

为受管集群的 Kube API 服务器设置静态 IP 地址。

Agent

包含有关目标裸机主机的硬件信息。

当目标机器的发现镜像引导时，在 hub 上自动创建。

ManagedCluster

当集群由 hub 管理时，必须导入并已知的集群。此 Kubernetes 对象提供该接口。

hub 使用这个资源来管理和显示受管集群的状态。

KlusterletAddonConfig

包含要部署到 ManagedCluster 资源的 hub 提供的服务列表。

告知 hub 部署到 ManagedCluster 资源的附加组件服务。

命名空间

hub 上已存在的 ManagedCluster 资源的逻辑空间。每个站点都是唯一的。

将资源传播到 ManagedCluster。

Secret

创建两个 CR：BMC Secret 和 Image Pull Secret。

  • BMC Secret 使用其用户名和密码向目标裸机主机进行身份验证。
  • Image Pull Secret 包含目标裸机主机中安装的 OpenShift Container Platform 镜像的身份验证信息。

ClusterImageSet

包含 OpenShift Container Platform 镜像信息，如存储库和镜像名称。

传递给资源以提供 OpenShift Container Platform 镜像。

19.6. 推荐的 vDU 应用程序工作负载的单节点 OpenShift 集群配置

使用以下引用信息，了解在集群中部署虚拟分布式单元 (vDU) 应用程序所需的单节点 OpenShift 配置。配置包括用于高性能工作负载的集群优化、启用工作负载分区以及最大程度减少安装后所需的重启数量。

其他资源

19.6.1. 在 OpenShift Container Platform 上运行低延迟应用程序

OpenShift Container Platform 通过使用几个技术和专用硬件设备，为在商业现成 (COTS) 硬件上运行的应用程序启用低延迟处理：

RHCOS 的实时内核
确保以高度的进程确定性处理工作负载。
CPU 隔离
避免 CPU 调度延迟并确保 CPU 容量一致可用。
NUMA 感知拓扑管理
将内存和巨页与 CPU 和 PCI 设备对齐，以将容器内存和巨页固定到非统一内存访问(NUMA)节点。所有服务质量 (QoS) 类的 Pod 资源保留在同一个 NUMA 节点上。这可降低延迟并提高节点的性能。
巨页内存管理
使用巨页大小可减少访问页表所需的系统资源量，从而提高系统性能。
使用 PTP 进行精确计时同步
允许以子微秒的准确性在网络中的节点之间进行同步。

19.6.2. vDU 应用程序工作负载的推荐集群主机要求

运行 vDU 应用程序工作负载需要一个具有足够资源的裸机主机来运行 OpenShift Container Platform 服务和生产工作负载。

表 19.5. 最低资源要求

profilevCPUmemoryStorage

最小值

4 到 8 个 vCPU 内核

32GB RAM

120GB

注意

当未启用并发多线程 (SMT) 或超线程时，一个 vCPU 相当于一个物理内核。启用后，使用以下公式来计算对应的比率：

  • （每个内核的线程数 x 内核数）x 插槽数 = vCPU
重要

使用虚拟介质引导时，服务器必须具有基板管理控制器(BMC)。

19.6.3. 为低延迟和高性能配置主机固件

裸机主机需要在置备主机前配置固件。固件配置取决于您的特定硬件和安装的具体要求。

流程

  1. 将 UEFI/BIOS Boot Mode 设置为 UEFI。
  2. 在主机引导顺序中，设置 Hard drive first。

  3. 为您的硬件应用特定的固件配置。下表描述了 Intel Xeon Skylake 或 Intel Cascade Lake 服务器的代表固件配置，它基于 Intel FlexRAN 4G 和 5G 基带 PHY 参考设计。

    重要

    确切的固件配置取决于您的特定硬件和网络要求。以下示例配置仅用于说明目的。

    表 19.6. Intel Xeon Skylake 或 Cascade Lake 服务器的固件配置示例

    固件设置Configuration

    CPU Power 和性能策略

    性能

    非核心频率扩展

    Disabled

    性能限制

    Disabled

    增强的 Intel SpeedStep ® Tech

    Enabled

    Intel 配置的 TDP

    Enabled

    可配置 TDP 级别

    2 级

    Intel® Turbo Boost Technology

    Enabled

    节能 Turbo

    Disabled

    硬件 P-State

    Disabled

    软件包 C-State

    C0/C1 状态

    C1E

    Disabled

    处理器 C6

    Disabled

注意

在主机的固件中启用全局 SR-IOV 和 VT-d 设置。这些设置与裸机环境相关。

19.6.4. 受管集群网络的连接先决条件

在安装并置备带有零接触置备 (ZTP) GitOps 管道的受管集群前，受管集群主机必须满足以下网络先决条件：

  • hub 集群中的 ZTP GitOps 容器和目标裸机主机的 Baseboard Management Controller (BMC) 之间必须有双向连接。

  • 受管集群必须能够解析和访问 hub 主机名和 *.apps 主机名的 API 主机名。以下是 hub 和 *.apps 主机名的 API 主机名示例：

    • api.hub-cluster.internal.domain.com
    • console-openshift-console.apps.hub-cluster.internal.domain.com

  • hub 集群必须能够解析并访问受管集群的 API 和 *.app 主机名。以下是受管集群的 API 主机名和 *.apps 主机名示例：

    • api.sno-managed-cluster-1.internal.domain.com
    • console-openshift-console.apps.sno-managed-cluster-1.internal.domain.com

19.6.5. 推荐的安装时集群配置

ZTP 管道在集群安装过程中应用以下自定义资源 (CR)。这些配置 CR 确保集群满足运行 vDU 应用程序所需的功能和性能要求。

注意

当将 ZTP GitOps 插件和 SiteConfig CR 用于集群部署时，默认包含以下 MachineConfig CR。

使用 SiteConfig extraManifests 过滤器更改默认包括的 CR。如需更多信息，请参阅使用 SiteConfig CR 的高级受管集群配置。

19.6.5.1. 工作负载分区

运行 DU 工作负载的单节点 OpenShift 集群需要工作负载分区。这限制了运行平台服务的内核数，从而最大程度提高应用程序有效负载的 CPU 内核。

注意

工作负载分区只能在集群安装过程中启用。您不能在安装后禁用工作负载分区。但是，您可以通过更新您在性能配置集中定义的 cpu 值以及相关的 MachineConfig 自定义资源 (CR) 来重新配置工作负载分区。

  • 启用工作负载分区的 base64 编码的 CR，它包含管理工作负载受限制的 CPU 集。为 base64 中的 crio.conf 和 kubelet.conf 对特定于主机的值进行编码。调整内容以匹配集群性能配置集中指定的 CPU 集。它必须与集群主机中的内核数匹配。

    推荐的工作负载分区配置

    apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: master
  name: 02-master-workload-partitioning
spec:
  config:
    ignition:
      version: 3.2.0
    storage:
      files:
      - contents:
          source: data:text/plain;charset=utf-8;base64,W2NyaW8ucnVudGltZS53b3JrbG9hZHMubWFuYWdlbWVudF0KYWN0aXZhdGlvbl9hbm5vdGF0aW9uID0gInRhcmdldC53b3JrbG9hZC5vcGVuc2hpZnQuaW8vbWFuYWdlbWVudCIKYW5ub3RhdGlvbl9wcmVmaXggPSAicmVzb3VyY2VzLndvcmtsb2FkLm9wZW5zaGlmdC5pbyIKcmVzb3VyY2VzID0geyAiY3B1c2hhcmVzIiA9IDAsICJjcHVzZXQiID0gIjAtMSw1Mi01MyIgfQo=
        mode: 420
        overwrite: true
        path: /etc/crio/crio.conf.d/01-workload-partitioning
        user:
          name: root
      - contents:
          source: data:text/plain;charset=utf-8;base64,ewogICJtYW5hZ2VtZW50IjogewogICAgImNwdXNldCI6ICIwLTEsNTItNTMiCiAgfQp9Cg==
        mode: 420
        overwrite: true
        path: /etc/kubernetes/openshift-workload-pinning
        user:
          name: root

  • 在集群主机上配置时，/etc/crio/crio.conf.d/01-workload-partitioning 的内容应该类似如下： 

    [crio.runtime.workloads.management]
activation_annotation = "target.workload.openshift.io/management"
annotation_prefix = "resources.workload.openshift.io"
resources = { "cpushares" = 0, "cpuset" = "0-1,52-53" } 1
    1
    CPU 值因安装而异。

    如果启用了超线程，请为每个内核指定两个线程。CPU 值必须与性能配置集中指定的保留 CPU 设置匹配。

  • 在集群中配置时，/etc/kubernetes/openshift-workload-pinning 的内容应如下所示： 

    {
  "management": {
    "cpuset": "0-1,52-53" 1
  }
}
    1
    cpuset 必须与 /etc/crio/crio.conf.d/01-workload-partitioning 中的 CPU 值匹配。

19.6.5.2. 减少平台管理占用空间

要减少平台的整体管理空间，需要一个 MachineConfig 自定义资源 (CR)，它将所有特定于 Kubernetes 的挂载点放在独立于主机操作系统的新命名空间中。以下 base64 编码的示例 MachineConfig CR 演示了此配置。

推荐的容器挂载命名空间配置

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: master
  name: container-mount-namespace-and-kubelet-conf-master
spec:
  config:
    ignition:
      version: 3.2.0
    storage:
      files:
      - contents:
          source: data:text/plain;charset=utf-8;base64,IyEvYmluL2Jhc2gKCmRlYnVnKCkgewogIGVjaG8gJEAgPiYyCn0KCnVzYWdlKCkgewogIGVjaG8gVXNhZ2U6ICQoYmFzZW5hbWUgJDApIFVOSVQgW2VudmZpbGUgW3Zhcm5hbWVdXQogIGVjaG8KICBlY2hvIEV4dHJhY3QgdGhlIGNvbnRlbnRzIG9mIHRoZSBmaXJzdCBFeGVjU3RhcnQgc3RhbnphIGZyb20gdGhlIGdpdmVuIHN5c3RlbWQgdW5pdCBhbmQgcmV0dXJuIGl0IHRvIHN0ZG91dAogIGVjaG8KICBlY2hvICJJZiAnZW52ZmlsZScgaXMgcHJvdmlkZWQsIHB1dCBpdCBpbiB0aGVyZSBpbnN0ZWFkLCBhcyBhbiBlbnZpcm9ubWVudCB2YXJpYWJsZSBuYW1lZCAndmFybmFtZSciCiAgZWNobyAiRGVmYXVsdCAndmFybmFtZScgaXMgRVhFQ1NUQVJUIGlmIG5vdCBzcGVjaWZpZWQiCiAgZXhpdCAxCn0KClVOSVQ9JDEKRU5WRklMRT0kMgpWQVJOQU1FPSQzCmlmIFtbIC16ICRVTklUIHx8ICRVTklUID09ICItLWhlbHAiIHx8ICRVTklUID09ICItaCIgXV07IHRoZW4KICB1c2FnZQpmaQpkZWJ1ZyAiRXh0cmFjdGluZyBFeGVjU3RhcnQgZnJvbSAkVU5JVCIKRklMRT0kKHN5c3RlbWN0bCBjYXQgJFVOSVQgfCBoZWFkIC1uIDEpCkZJTEU9JHtGSUxFI1wjIH0KaWYgW1sgISAtZiAkRklMRSBdXTsgdGhlbgogIGRlYnVnICJGYWlsZWQgdG8gZmluZCByb290IGZpbGUgZm9yIHVuaXQgJFVOSVQgKCRGSUxFKSIKICBleGl0CmZpCmRlYnVnICJTZXJ2aWNlIGRlZmluaXRpb24gaXMgaW4gJEZJTEUiCkVYRUNTVEFSVD0kKHNlZCAtbiAtZSAnL15FeGVjU3RhcnQ9LipcXCQvLC9bXlxcXSQvIHsgcy9eRXhlY1N0YXJ0PS8vOyBwIH0nIC1lICcvXkV4ZWNTdGFydD0uKlteXFxdJC8geyBzL15FeGVjU3RhcnQ9Ly87IHAgfScgJEZJTEUpCgppZiBbWyAkRU5WRklMRSBdXTsgdGhlbgogIFZBUk5BTUU9JHtWQVJOQU1FOi1FWEVDU1RBUlR9CiAgZWNobyAiJHtWQVJOQU1FfT0ke0VYRUNTVEFSVH0iID4gJEVOVkZJTEUKZWxzZQogIGVjaG8gJEVYRUNTVEFSVApmaQo=
        mode: 493
        path: /usr/local/bin/extractExecStart
      - contents:
          source: data:text/plain;charset=utf-8;base64,IyEvYmluL2Jhc2gKbnNlbnRlciAtLW1vdW50PS9ydW4vY29udGFpbmVyLW1vdW50LW5hbWVzcGFjZS9tbnQgIiRAIgo=
        mode: 493
        path: /usr/local/bin/nsenterCmns
    systemd:
      units:
      - contents: |
          [Unit]
          Description=Manages a mount namespace that both kubelet and crio can use to share their container-specific mounts

          [Service]
          Type=oneshot
          RemainAfterExit=yes
          RuntimeDirectory=container-mount-namespace
          Environment=RUNTIME_DIRECTORY=%t/container-mount-namespace
          Environment=BIND_POINT=%t/container-mount-namespace/mnt
          ExecStartPre=bash -c "findmnt ${RUNTIME_DIRECTORY} || mount --make-unbindable --bind ${RUNTIME_DIRECTORY} ${RUNTIME_DIRECTORY}"
          ExecStartPre=touch ${BIND_POINT}
          ExecStart=unshare --mount=${BIND_POINT} --propagation slave mount --make-rshared /
          ExecStop=umount -R ${RUNTIME_DIRECTORY}
        enabled: true
        name: container-mount-namespace.service
      - dropins:
        - contents: |
            [Unit]
            Wants=container-mount-namespace.service
            After=container-mount-namespace.service

            [Service]
            ExecStartPre=/usr/local/bin/extractExecStart %n /%t/%N-execstart.env ORIG_EXECSTART
            EnvironmentFile=-/%t/%N-execstart.env
            ExecStart=
            ExecStart=bash -c "nsenter --mount=%t/container-mount-namespace/mnt \
                ${ORIG_EXECSTART}"
          name: 90-container-mount-namespace.conf
        name: crio.service
      - dropins:
        - contents: |
            [Unit]
            Wants=container-mount-namespace.service
            After=container-mount-namespace.service

            [Service]
            ExecStartPre=/usr/local/bin/extractExecStart %n /%t/%N-execstart.env ORIG_EXECSTART
            EnvironmentFile=-/%t/%N-execstart.env
            ExecStart=
            ExecStart=bash -c "nsenter --mount=%t/container-mount-namespace/mnt \
                ${ORIG_EXECSTART} --housekeeping-interval=30s"
          name: 90-container-mount-namespace.conf
        - contents: |
            [Service]
            Environment="OPENSHIFT_MAX_HOUSEKEEPING_INTERVAL_DURATION=60s"
            Environment="OPENSHIFT_EVICTION_MONITORING_PERIOD_DURATION=30s"
          name: 30-kubelet-interval-tuning.conf
        name: kubelet.service

19.6.5.3. SCTP

流控制传输协议 (SCTP) 是在 RAN 应用程序中使用的密钥协议。此 MachineConfig 对象向节点添加 SCTP 内核模块以启用此协议。

推荐的 SCTP 配置

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: master
  name: load-sctp-module
spec:
  config:
    ignition:
      version: 2.2.0
    storage:
      files:
        - contents:
            source: data:,
            verification: {}
          filesystem: root
            mode: 420
            path: /etc/modprobe.d/sctp-blacklist.conf
        - contents:
            source: data:text/plain;charset=utf-8,sctp
          filesystem: root
            mode: 420
            path: /etc/modules-load.d/sctp-load.conf

19.6.5.4. 加速容器启动

以下 MachineConfig CR 配置 OpenShift 核心进程和容器，以便在系统启动和关闭过程中使用所有可用的 CPU 内核。这会加快初始引导过程和重启过程中的系统恢复。

推荐的容器启动配置

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: master
  name: 04-accelerated-container-startup-master
spec:
  config:
    ignition:
      version: 3.2.0
    storage:
      files:
      - contents:
          source: data:text/plain;charset=utf-8;base64,IyEvYmluL2Jhc2gKIwojIFRlbXBvcmFyaWx5IHJlc2V0IHRoZSBjb3JlIHN5c3RlbSBwcm9jZXNzZXMncyBDUFUgYWZmaW5pdHkgdG8gYmUgdW5yZXN0cmljdGVkIHRvIGFjY2VsZXJhdGUgc3RhcnR1cCBhbmQgc2h1dGRvd24KIwojIFRoZSBkZWZhdWx0cyBiZWxvdyBjYW4gYmUgb3ZlcnJpZGRlbiB2aWEgZW52aXJvbm1lbnQgdmFyaWFibGVzCiMKCiMgVGhlIGRlZmF1bHQgc2V0IG9mIGNyaXRpY2FsIHByb2Nlc3NlcyB3aG9zZSBhZmZpbml0eSBzaG91bGQgYmUgdGVtcG9yYXJpbHkgdW5ib3VuZDoKQ1JJVElDQUxfUFJPQ0VTU0VTPSR7Q1JJVElDQUxfUFJPQ0VTU0VTOi0ic3lzdGVtZCBvdnMgY3JpbyBrdWJlbGV0IE5ldHdvcmtNYW5hZ2VyIGNvbm1vbiBkYnVzIn0KCiMgRGVmYXVsdCB3YWl0IHRpbWUgaXMgNjAwcyA9IDEwbToKTUFYSU1VTV9XQUlUX1RJTUU9JHtNQVhJTVVNX1dBSVRfVElNRTotNjAwfQoKIyBEZWZhdWx0IHN0ZWFkeS1zdGF0ZSB0aHJlc2hvbGQgPSAyJQojIEFsbG93ZWQgdmFsdWVzOgojICA0ICAtIGFic29sdXRlIHBvZCBjb3VudCAoKy8tKQojICA0JSAtIHBlcmNlbnQgY2hhbmdlICgrLy0pCiMgIC0xIC0gZGlzYWJsZSB0aGUgc3RlYWR5LXN0YXRlIGNoZWNrClNURUFEWV9TVEFURV9USFJFU0hPTEQ9JHtTVEVBRFlfU1RBVEVfVEhSRVNIT0xEOi0yJX0KCiMgRGVmYXVsdCBzdGVhZHktc3RhdGUgd2luZG93ID0gNjBzCiMgSWYgdGhlIHJ1bm5pbmcgcG9kIGNvdW50IHN0YXlzIHdpdGhpbiB0aGUgZ2l2ZW4gdGhyZXNob2xkIGZvciB0aGlzIHRpbWUKIyBwZXJpb2QsIHJldHVybiBDUFUgdXRpbGl6YXRpb24gdG8gbm9ybWFsIGJlZm9yZSB0aGUgbWF4aW11bSB3YWl0IHRpbWUgaGFzCiMgZXhwaXJlcwpTVEVBRFlfU1RBVEVfV0lORE9XPSR7U1RFQURZX1NUQVRFX1dJTkRPVzotNjB9CgojIERlZmF1bHQgc3RlYWR5LXN0YXRlIGFsbG93cyBhbnkgcG9kIGNvdW50IHRvIGJlICJzdGVhZHkgc3RhdGUiCiMgSW5jcmVhc2luZyB0aGlzIHdpbGwgc2tpcCBhbnkgc3RlYWR5LXN0YXRlIGNoZWNrcyB1bnRpbCB0aGUgY291bnQgcmlzZXMgYWJvdmUKIyB0aGlzIG51bWJlciB0byBhdm9pZCBmYWxzZSBwb3NpdGl2ZXMgaWYgdGhlcmUgYXJlIHNvbWUgcGVyaW9kcyB3aGVyZSB0aGUKIyBjb3VudCBkb2Vzbid0IGluY3JlYXNlIGJ1dCB3ZSBrbm93IHdlIGNhbid0IGJlIGF0IHN0ZWFkeS1zdGF0ZSB5ZXQuClNURUFEWV9TVEFURV9NSU5JTVVNPSR7U1RFQURZX1NUQVRFX01JTklNVU06LTB9CgojIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjCgpLVUJFTEVUX0NQVV9TVEFURT0vdmFyL2xpYi9rdWJlbGV0L2NwdV9tYW5hZ2VyX3N0YXRlCkZVTExfQ1BVX1NUQVRFPS9zeXMvZnMvY2dyb3VwL2NwdXNldC9jcHVzZXQuY3B1cwp1bnJlc3RyaWN0ZWRDcHVzZXQoKSB7CiAgbG9jYWwgY3B1cwogIGlmIFtbIC1lICRLVUJFTEVUX0NQVV9TVEFURSBdXTsgdGhlbgogICAgICBjcHVzPSQoanEgLXIgJy5kZWZhdWx0Q3B1U2V0JyA8JEtVQkVMRVRfQ1BVX1NUQVRFKQogIGZpCiAgaWYgW1sgLXogJGNwdXMgXV07IHRoZW4KICAgICMgZmFsbCBiYWNrIHRvIHVzaW5nIGFsbCBjcHVzIGlmIHRoZSBrdWJlbGV0IHN0YXRlIGlzIG5vdCBjb25maWd1cmVkIHlldAogICAgW1sgLWUgJEZVTExfQ1BVX1NUQVRFIF1dIHx8IHJldHVybiAxCiAgICBjcHVzPSQoPCRGVUxMX0NQVV9TVEFURSkKICBmaQogIGVjaG8gJGNwdXMKfQoKcmVzdHJpY3RlZENwdXNldCgpIHsKICBmb3IgYXJnIGluICQoPC9wcm9jL2NtZGxpbmUpOyBkbwogICAgaWYgW1sgJGFyZyA9fiBec3lzdGVtZC5jcHVfYWZmaW5pdHk9IF1dOyB0aGVuCiAgICAgIGVjaG8gJHthcmcjKj19CiAgICAgIHJldHVybiAwCiAgICBmaQogIGRvbmUKICByZXR1cm4gMQp9CgpnZXRDUFVDb3VudCAoKSB7CiAgbG9jYWwgY3B1c2V0PSIkMSIKICBsb2NhbCBjcHVsaXN0PSgpCiAgbG9jYWwgY3B1cz0wCiAgbG9jYWwgbWluY3B1cz0yCgogIGlmIFtbIC16ICRjcHVzZXQgfHwgJGNwdXNldCA9fiBbXjAtOSwtXSBdXTsgdGhlbgogICAgZWNobyAkbWluY3B1cwogICAgcmV0dXJuIDEKICBmaQoKICBJRlM9JywnIHJlYWQgLXJhIGNwdWxpc3QgPDw8ICRjcHVzZXQKCiAgZm9yIGVsbSBpbiAiJHtjcHVsaXN0W0BdfSI7IGRvCiAgICBpZiBbWyAkZWxtID1+IF5bMC05XSskIF1dOyB0aGVuCiAgICAgICgoIGNwdXMrKyApKQogICAgZWxpZiBbWyAkZWxtID1+IF5bMC05XSstWzAtOV0rJCBdXTsgdGhlbgogICAgICBsb2NhbCBsb3c9MCBoaWdoPTAKICAgICAgSUZTPSctJyByZWFkIGxvdyBoaWdoIDw8PCAkZWxtCiAgICAgICgoIGNwdXMgKz0gaGlnaCAtIGxvdyArIDEgKSkKICAgIGVsc2UKICAgICAgZWNobyAkbWluY3B1cwogICAgICByZXR1cm4gMQogICAgZmkKICBkb25lCgogICMgUmV0dXJuIGEgbWluaW11bSBvZiAyIGNwdXMKICBlY2hvICQoKCBjcHVzID4gJG1pbmNwdXMgPyBjcHVzIDogJG1pbmNwdXMgKSkKICByZXR1cm4gMAp9CgpyZXNldE9WU3RocmVhZHMgKCkgewogIGxvY2FsIGNwdWNvdW50PSIkMSIKICBsb2NhbCBjdXJSZXZhbGlkYXRvcnM9MAogIGxvY2FsIGN1ckhhbmRsZXJzPTAKICBsb2NhbCBkZXNpcmVkUmV2YWxpZGF0b3JzPTAKICBsb2NhbCBkZXNpcmVkSGFuZGxlcnM9MAogIGxvY2FsIHJjPTAKCiAgY3VyUmV2YWxpZGF0b3JzPSQocHMgLVRlbyBwaWQsdGlkLGNvbW0sY21kIHwgZ3JlcCAtZSByZXZhbGlkYXRvciB8IGdyZXAgLWMgb3ZzLXZzd2l0Y2hkKQogIGN1ckhhbmRsZXJzPSQocHMgLVRlbyBwaWQsdGlkLGNvbW0sY21kIHwgZ3JlcCAtZSBoYW5kbGVyIHwgZ3JlcCAtYyBvdnMtdnN3aXRjaGQpCgogICMgQ2FsY3VsYXRlIHRoZSBkZXNpcmVkIG51bWJlciBvZiB0aHJlYWRzIHRoZSBzYW1lIHdheSBPVlMgZG9lcy4KICAjIE9WUyB3aWxsIHNldCB0aGVzZSB0aHJlYWQgY291bnQgYXMgYSBvbmUgc2hvdCBwcm9jZXNzIG9uIHN0YXJ0dXAsIHNvIHdlCiAgIyBoYXZlIHRvIGFkanVzdCB1cCBvciBkb3duIGR1cmluZyB0aGUgYm9vdCB1cCBwcm9jZXNzLiBUaGUgZGVzaXJlZCBvdXRjb21lIGlzCiAgIyB0byBub3QgcmVzdHJpY3QgdGhlIG51bWJlciBvZiB0aHJlYWQgYXQgc3RhcnR1cCB1bnRpbCB3ZSByZWFjaCBhIHN0ZWFkeQogICMgc3RhdGUuICBBdCB3aGljaCBwb2ludCB3ZSBuZWVkIHRvIHJlc2V0IHRoZXNlIGJhc2VkIG9uIG91ciByZXN0cmljdGVkICBzZXQKICAjIG9mIGNvcmVzLgogICMgU2VlIE9WUyBmdW5jdGlvbiB0aGF0IGNhbGN1bGF0ZXMgdGhlc2UgdGhyZWFkIGNvdW50czoKICAjIGh0dHBzOi8vZ2l0aHViLmNvbS9vcGVudnN3aXRjaC9vdnMvYmxvYi9tYXN0ZXIvb2Zwcm90by9vZnByb3RvLWRwaWYtdXBjYWxsLmMjTDYzNQogICgoIGRlc2lyZWRSZXZhbGlkYXRvcnM9JGNwdWNvdW50IC8gNCArIDEgKSkKICAoKCBkZXNpcmVkSGFuZGxlcnM9JGNwdWNvdW50IC0gJGRlc2lyZWRSZXZhbGlkYXRvcnMgKSkKCgogIGlmIFtbICRjdXJSZXZhbGlkYXRvcnMgLW5lICRkZXNpcmVkUmV2YWxpZGF0b3JzIHx8ICRjdXJIYW5kbGVycyAtbmUgJGRlc2lyZWRIYW5kbGVycyBdXTsgdGhlbgoKICAgIGxvZ2dlciAiUmVjb3Zlcnk6IFJlLXNldHRpbmcgT1ZTIHJldmFsaWRhdG9yIHRocmVhZHM6ICR7Y3VyUmV2YWxpZGF0b3JzfSAtPiAke2Rlc2lyZWRSZXZhbGlkYXRvcnN9IgogICAgbG9nZ2VyICJSZWNvdmVyeTogUmUtc2V0dGluZyBPVlMgaGFuZGxlciB0aHJlYWRzOiAke2N1ckhhbmRsZXJzfSAtPiAke2Rlc2lyZWRIYW5kbGVyc30iCgogICAgb3ZzLXZzY3RsIHNldCBcCiAgICAgIE9wZW5fdlN3aXRjaCAuIFwKICAgICAgb3RoZXItY29uZmlnOm4taGFuZGxlci10aHJlYWRzPSR7ZGVzaXJlZEhhbmRsZXJzfSBcCiAgICAgIG90aGVyLWNvbmZpZzpuLXJldmFsaWRhdG9yLXRocmVhZHM9JHtkZXNpcmVkUmV2YWxpZGF0b3JzfQogICAgcmM9JD8KICBmaQoKICByZXR1cm4gJHJjCn0KCnJlc2V0QWZmaW5pdHkoKSB7CiAgbG9jYWwgY3B1c2V0PSIkMSIKICBsb2NhbCBmYWlsY291bnQ9MAogIGxvY2FsIHN1Y2Nlc3Njb3VudD0wCiAgbG9nZ2VyICJSZWNvdmVyeTogU2V0dGluZyBDUFUgYWZmaW5pdHkgZm9yIGNyaXRpY2FsIHByb2Nlc3NlcyBcIiRDUklUSUNBTF9QUk9DRVNTRVNcIiB0byAkY3B1c2V0IgogIGZvciBwcm9jIGluICRDUklUSUNBTF9QUk9DRVNTRVM7IGRvCiAgICBsb2NhbCBwaWRzPSIkKHBncmVwICRwcm9jKSIKICAgIGZvciBwaWQgaW4gJHBpZHM7IGRvCiAgICAgIGxvY2FsIHRhc2tzZXRPdXRwdXQKICAgICAgdGFza3NldE91dHB1dD0iJCh0YXNrc2V0IC1hcGMgIiRjcHVzZXQiICRwaWQgMj4mMSkiCiAgICAgIGlmIFtbICQ/IC1uZSAwIF1dOyB0aGVuCiAgICAgICAgZWNobyAiRVJST1I6ICR0YXNrc2V0T3V0cHV0IgogICAgICAgICgoZmFpbGNvdW50KyspKQogICAgICBlbHNlCiAgICAgICAgKChzdWNjZXNzY291bnQrKykpCiAgICAgIGZpCiAgICBkb25lCiAgZG9uZQoKICByZXNldE9WU3RocmVhZHMgIiQoZ2V0Q1BVQ291bnQgJHtjcHVzZXR9KSIKICBpZiBbWyAkPyAtbmUgMCBdXTsgdGhlbgogICAgKChmYWlsY291bnQrKykpCiAgZWxzZQogICAgKChzdWNjZXNzY291bnQrKykpCiAgZmkKCiAgbG9nZ2VyICJSZWNvdmVyeTogUmUtYWZmaW5lZCAkc3VjY2Vzc2NvdW50IHBpZHMgc3VjY2Vzc2Z1bGx5IgogIGlmIFtbICRmYWlsY291bnQgLWd0IDAgXV07IHRoZW4KICAgIGxvZ2dlciAiUmVjb3Zlcnk6IEZhaWxlZCB0byByZS1hZmZpbmUgJGZhaWxjb3VudCBwcm9jZXNzZXMiCiAgICByZXR1cm4gMQogIGZpCn0KCnNldFVucmVzdHJpY3RlZCgpIHsKICBsb2dnZXIgIlJlY292ZXJ5OiBTZXR0aW5nIGNyaXRpY2FsIHN5c3RlbSBwcm9jZXNzZXMgdG8gaGF2ZSB1bnJlc3RyaWN0ZWQgQ1BVIGFjY2VzcyIKICByZXNldEFmZmluaXR5ICIkKHVucmVzdHJpY3RlZENwdXNldCkiCn0KCnNldFJlc3RyaWN0ZWQoKSB7CiAgbG9nZ2VyICJSZWNvdmVyeTogUmVzZXR0aW5nIGNyaXRpY2FsIHN5c3RlbSBwcm9jZXNzZXMgYmFjayB0byBub3JtYWxseSByZXN0cmljdGVkIGFjY2VzcyIKICByZXNldEFmZmluaXR5ICIkKHJlc3RyaWN0ZWRDcHVzZXQpIgp9CgpjdXJyZW50QWZmaW5pdHkoKSB7CiAgbG9jYWwgcGlkPSIkMSIKICB0YXNrc2V0IC1wYyAkcGlkIHwgYXdrIC1GJzogJyAne3ByaW50ICQyfScKfQoKd2l0aGluKCkgewogIGxvY2FsIGxhc3Q9JDEgY3VycmVudD0kMiB0aHJlc2hvbGQ9JDMKICBsb2NhbCBkZWx0YT0wIHBjaGFuZ2UKICBkZWx0YT0kKCggY3VycmVudCAtIGxhc3QgKSkKICBpZiBbWyAkY3VycmVudCAtZXEgJGxhc3QgXV07IHRoZW4KICAgIHBjaGFuZ2U9MAogIGVsaWYgW1sgJGxhc3QgLWVxIDAgXV07IHRoZW4KICAgIHBjaGFuZ2U9MTAwMDAwMAogIGVsc2UKICAgIHBjaGFuZ2U9JCgoICggJGRlbHRhICogMTAwKSAvIGxhc3QgKSkKICBmaQogIGVjaG8gLW4gImxhc3Q6JGxhc3QgY3VycmVudDokY3VycmVudCBkZWx0YTokZGVsdGEgcGNoYW5nZToke3BjaGFuZ2V9JTogIgogIGxvY2FsIGFic29sdXRlIGxpbWl0CiAgY2FzZSAkdGhyZXNob2xkIGluCiAgICAqJSkKICAgICAgYWJzb2x1dGU9JHtwY2hhbmdlIyMtfSAjIGFic29sdXRlIHZhbHVlCiAgICAgIGxpbWl0PSR7dGhyZXNob2xkJSUlfQogICAgICA7OwogICAgKikKICAgICAgYWJzb2x1dGU9JHtkZWx0YSMjLX0gIyBhYnNvbHV0ZSB2YWx1ZQogICAgICBsaW1pdD0kdGhyZXNob2xkCiAgICAgIDs7CiAgZXNhYwogIGlmIFtbICRhYnNvbHV0ZSAtbGUgJGxpbWl0IF1dOyB0aGVuCiAgICBlY2hvICJ3aXRoaW4gKCsvLSkkdGhyZXNob2xkIgogICAgcmV0dXJuIDAKICBlbHNlCiAgICBlY2hvICJvdXRzaWRlICgrLy0pJHRocmVzaG9sZCIKICAgIHJldHVybiAxCiAgZmkKfQoKc3RlYWR5c3RhdGUoKSB7CiAgbG9jYWwgbGFzdD0kMSBjdXJyZW50PSQyCiAgaWYgW1sgJGxhc3QgLWx0ICRTVEVBRFlfU1RBVEVfTUlOSU1VTSBdXTsgdGhlbgogICAgZWNobyAibGFzdDokbGFzdCBjdXJyZW50OiRjdXJyZW50IFdhaXRpbmcgdG8gcmVhY2ggJFNURUFEWV9TVEFURV9NSU5JTVVNIGJlZm9yZSBjaGVja2luZyBmb3Igc3RlYWR5LXN0YXRlIgogICAgcmV0dXJuIDEKICBmaQogIHdpdGhpbiAkbGFzdCAkY3VycmVudCAkU1RFQURZX1NUQVRFX1RIUkVTSE9MRAp9Cgp3YWl0Rm9yUmVhZHkoKSB7CiAgbG9nZ2VyICJSZWNvdmVyeTogV2FpdGluZyAke01BWElNVU1fV0FJVF9USU1FfXMgZm9yIHRoZSBpbml0aWFsaXphdGlvbiB0byBjb21wbGV0ZSIKICBsb2NhbCBsYXN0U3lzdGVtZENwdXNldD0iJChjdXJyZW50QWZmaW5pdHkgMSkiCiAgbG9jYWwgbGFzdERlc2lyZWRDcHVzZXQ9IiQodW5yZXN0cmljdGVkQ3B1c2V0KSIKICBsb2NhbCB0PTAgcz0xMAogIGxvY2FsIGxhc3RDY291bnQ9MCBjY291bnQ9MCBzdGVhZHlTdGF0ZVRpbWU9MAogIHdoaWxlIFtbICR0IC1sdCAkTUFYSU1VTV9XQUlUX1RJTUUgXV07IGRvCiAgICBzbGVlcCAkcwogICAgKCh0ICs9IHMpKQogICAgIyBSZS1jaGVjayB0aGUgY3VycmVudCBhZmZpbml0eSBvZiBzeXN0ZW1kLCBpbiBjYXNlIHNvbWUgb3RoZXIgcHJvY2VzcyBoYXMgY2hhbmdlZCBpdAogICAgbG9jYWwgc3lzdGVtZENwdXNldD0iJChjdXJyZW50QWZmaW5pdHkgMSkiCiAgICAjIFJlLWNoZWNrIHRoZSB1bnJlc3RyaWN0ZWQgQ3B1c2V0LCBhcyB0aGUgYWxsb3dlZCBzZXQgb2YgdW5yZXNlcnZlZCBjb3JlcyBtYXkgY2hhbmdlIGFzIHBvZHMgYXJlIGFzc2lnbmVkIHRvIGNvcmVzCiAgICBsb2NhbCBkZXNpcmVkQ3B1c2V0PSIkKHVucmVzdHJpY3RlZENwdXNldCkiCiAgICBpZiBbWyAkc3lzdGVtZENwdXNldCAhPSAkbGFzdFN5c3RlbWRDcHVzZXQgfHwgJGxhc3REZXNpcmVkQ3B1c2V0ICE9ICRkZXNpcmVkQ3B1c2V0IF1dOyB0aGVuCiAgICAgIHJlc2V0QWZmaW5pdHkgIiRkZXNpcmVkQ3B1c2V0IgogICAgICBsYXN0U3lzdGVtZENwdXNldD0iJChjdXJyZW50QWZmaW5pdHkgMSkiCiAgICAgIGxhc3REZXNpcmVkQ3B1c2V0PSIkZGVzaXJlZENwdXNldCIKICAgIGZpCgogICAgIyBEZXRlY3Qgc3RlYWR5LXN0YXRlIHBvZCBjb3VudAogICAgY2NvdW50PSQoY3JpY3RsIHBzIHwgd2MgLWwpCiAgICBpZiBzdGVhZHlzdGF0ZSAkbGFzdENjb3VudCAkY2NvdW50OyB0aGVuCiAgICAgICgoc3RlYWR5U3RhdGVUaW1lICs9IHMpKQogICAgICBlY2hvICJTdGVhZHktc3RhdGUgZm9yICR7c3RlYWR5U3RhdGVUaW1lfXMvJHtTVEVBRFlfU1RBVEVfV0lORE9XfXMiCiAgICAgIGlmIFtbICRzdGVhZHlTdGF0ZVRpbWUgLWdlICRTVEVBRFlfU1RBVEVfV0lORE9XIF1dOyB0aGVuCiAgICAgICAgbG9nZ2VyICJSZWNvdmVyeTogU3RlYWR5LXN0YXRlICgrLy0gJFNURUFEWV9TVEFURV9USFJFU0hPTEQpIGZvciAke1NURUFEWV9TVEFURV9XSU5ET1d9czogRG9uZSIKICAgICAgICByZXR1cm4gMAogICAgICBmaQogICAgZWxzZQogICAgICBpZiBbWyAkc3RlYWR5U3RhdGVUaW1lIC1ndCAwIF1dOyB0aGVuCiAgICAgICAgZWNobyAiUmVzZXR0aW5nIHN0ZWFkeS1zdGF0ZSB0aW1lciIKICAgICAgICBzdGVhZHlTdGF0ZVRpbWU9MAogICAgICBmaQogICAgZmkKICAgIGxhc3RDY291bnQ9JGNjb3VudAogIGRvbmUKICBsb2dnZXIgIlJlY292ZXJ5OiBSZWNvdmVyeSBDb21wbGV0ZSBUaW1lb3V0Igp9CgptYWluKCkgewogIGlmICEgdW5yZXN0cmljdGVkQ3B1c2V0ID4mL2Rldi9udWxsOyB0aGVuCiAgICBsb2dnZXIgIlJlY292ZXJ5OiBObyB1bnJlc3RyaWN0ZWQgQ3B1c2V0IGNvdWxkIGJlIGRldGVjdGVkIgogICAgcmV0dXJuIDEKICBmaQoKICBpZiAhIHJlc3RyaWN0ZWRDcHVzZXQgPiYvZGV2L251bGw7IHRoZW4KICAgIGxvZ2dlciAiUmVjb3Zlcnk6IE5vIHJlc3RyaWN0ZWQgQ3B1c2V0IGhhcyBiZWVuIGNvbmZpZ3VyZWQuICBXZSBhcmUgYWxyZWFkeSBydW5uaW5nIHVucmVzdHJpY3RlZC4iCiAgICByZXR1cm4gMAogIGZpCgogICMgRW5zdXJlIHdlIHJlc2V0IHRoZSBDUFUgYWZmaW5pdHkgd2hlbiB3ZSBleGl0IHRoaXMgc2NyaXB0IGZvciBhbnkgcmVhc29uCiAgIyBUaGlzIHdheSBlaXRoZXIgYWZ0ZXIgdGhlIHRpbWVyIGV4cGlyZXMgb3IgYWZ0ZXIgdGhlIHByb2Nlc3MgaXMgaW50ZXJydXB0ZWQKICAjIHZpYSBeQyBvciBTSUdURVJNLCB3ZSByZXR1cm4gdGhpbmdzIGJhY2sgdG8gdGhlIHdheSB0aGV5IHNob3VsZCBiZS4KICB0cmFwIHNldFJlc3RyaWN0ZWQgRVhJVAoKICBsb2dnZXIgIlJlY292ZXJ5OiBSZWNvdmVyeSBNb2RlIFN0YXJ0aW5nIgogIHNldFVucmVzdHJpY3RlZAogIHdhaXRGb3JSZWFkeQp9CgppZiBbWyAiJHtCQVNIX1NPVVJDRVswXX0iID0gIiR7MH0iIF1dOyB0aGVuCiAgbWFpbiAiJHtAfSIKICBleGl0ICQ/CmZpCg==
        mode: 493
        path: /usr/local/bin/accelerated-container-startup.sh
    systemd:
      units:
      - contents: |
          [Unit]
          Description=Unlocks more CPUs for critical system processes during container startup

          [Service]
          Type=simple
          ExecStart=/usr/local/bin/accelerated-container-startup.sh

          # Maximum wait time is 600s = 10m:
          Environment=MAXIMUM_WAIT_TIME=600

          # Steady-state threshold = 2%
          # Allowed values:
          #  4  - absolute pod count (+/-)
          #  4% - percent change (+/-)
          #  -1 - disable the steady-state check
          # Note: '%' must be escaped as '%%' in systemd unit files
          Environment=STEADY_STATE_THRESHOLD=2%%

          # Steady-state window = 120s
          # If the running pod count stays within the given threshold for this time
          # period, return CPU utilization to normal before the maximum wait time has
          # expires
          Environment=STEADY_STATE_WINDOW=120

          # Steady-state minimum = 40
          # Increasing this will skip any steady-state checks until the count rises above
          # this number to avoid false positives if there are some periods where the
          # count doesn't increase but we know we can't be at steady-state yet.
          Environment=STEADY_STATE_MINIMUM=40

          [Install]
          WantedBy=multi-user.target
        enabled: true
        name: accelerated-container-startup.service
      - contents: |
          [Unit]
          Description=Unlocks more CPUs for critical system processes during container shutdown
          DefaultDependencies=no

          [Service]
          Type=simple
          ExecStart=/usr/local/bin/accelerated-container-startup.sh

          # Maximum wait time is 600s = 10m:
          Environment=MAXIMUM_WAIT_TIME=600

          # Steady-state threshold
          # Allowed values:
          #  4  - absolute pod count (+/-)
          #  4% - percent change (+/-)
          #  -1 - disable the steady-state check
          # Note: '%' must be escaped as '%%' in systemd unit files
          Environment=STEADY_STATE_THRESHOLD=-1

          # Steady-state window = 60s
          # If the running pod count stays within the given threshold for this time
          # period, return CPU utilization to normal before the maximum wait time has
          # expires
          Environment=STEADY_STATE_WINDOW=60

          [Install]
          WantedBy=shutdown.target reboot.target halt.target
        enabled: true
        name: accelerated-container-shutdown.service

19.6.5.5. 使用 kdump 自动内核崩溃转储

kdump 是一个 Linux 内核功能，可在内核崩溃时创建内核崩溃转储。kdump 使用以下 MachineConfig CR 启用：

推荐的 kdump 配置

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: master
  name: 06-kdump-enable-master
spec:
  config:
    ignition:
      version: 3.2.0
    systemd:
      units:
      - enabled: true
        name: kdump.service
  kernelArguments:
    - crashkernel=512M

19.6.6. 推荐的安装后集群配置

当集群安装完成后，ZTP 管道会应用运行 DU 工作负载所需的以下自定义资源 (CR)。

注意

在 GitOps ZTP v4.10 及更早版本中，您可以使用 MachineConfig CR 配置 UEFI 安全引导。GitOps ZTP v4.11 及更新的版本中不再需要。在 v4.11 中，您可以使用 Performance 配置集 CR 为单节点 OpenShift 集群配置 UEFI 安全引导。如需更多信息，请参阅性能配置集。

19.6.6.1. Operator 命名空间和 Operator 组

运行 DU 工作负载的单节点 OpenShift 集群需要以下 OperatorGroup 和 Namespace 自定义资源 (CR)：

  • Local Storage Operator
  • Logging Operator
  • PTP Operator
  • Cluster Network Operator

以下 YAML 总结了这些 CR：

推荐的 Operator 命名空间和 OperatorGroup 配置

apiVersion: v1
kind: Namespace
metadata:
  annotations:
    workload.openshift.io/allowed: management
  name: openshift-local-storage
---
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: openshift-local-storage
  namespace: openshift-local-storage
spec:
  targetNamespaces:
    - openshift-local-storage
---
apiVersion: v1
kind: Namespace
metadata:
  annotations:
    workload.openshift.io/allowed: management
  name: openshift-logging
---
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: cluster-logging
  namespace: openshift-logging
spec:
  targetNamespaces:
    - openshift-logging
---
apiVersion: v1
kind: Namespace
metadata:
  annotations:
    workload.openshift.io/allowed: management
  labels:
    openshift.io/cluster-monitoring: "true"
  name: openshift-ptp
---
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: ptp-operators
  namespace: openshift-ptp
spec:
  targetNamespaces:
    - openshift-ptp
---
apiVersion: v1
kind: Namespace
metadata:
  annotations:
    workload.openshift.io/allowed: management
    name: openshift-sriov-network-operator
---
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: sriov-network-operators
  namespace: openshift-sriov-network-operator
spec:
  targetNamespaces:
    - openshift-sriov-network-operator

19.6.6.2. Operator 订阅

运行 DU 工作负载的单节点 OpenShift 集群需要以下 Subscription CR。订阅提供下载以下 Operator 的位置：

  • Local Storage Operator
  • Logging Operator
  • PTP Operator
  • Cluster Network Operator

推荐的 Operator 订阅

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: cluster-logging
  namespace: openshift-logging
spec:
  channel: "stable" 1
  name: cluster-logging
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  installPlanApproval: Manual 2
---
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: local-storage-operator
  namespace: openshift-local-storage
spec:
  channel: "stable"
  installPlanApproval: Automatic
  name: local-storage-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  installPlanApproval: Manual
---
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
    name: ptp-operator-subscription
    namespace: openshift-ptp
spec:
  channel: "stable"
  name: ptp-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  installPlanApproval: Manual
---
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: sriov-network-operator-subscription
  namespace: openshift-sriov-network-operator
spec:
  channel: "stable"
  name: sriov-network-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  installPlanApproval: Manual

1
指定要从中获取 Operator 的频道。stable 是推荐的频道。
2
指定 Manual 或 Automatic。在 Automatic 模式中，Operator 会在 registry 中可用时自动更新到频道中最新版本。在 Manual 模式中，只有在被明确批准后，才会安装新的 Operator 版本。

19.6.6.3. 集群日志记录和日志转发

运行 DU 工作负载的单节点 OpenShift 集群需要日志记录和日志转发以进行调试。以下示例 YAML 演示了所需的 ClusterLogging 和 ClusterLogForwarder CR。

推荐的集群日志记录和日志转发配置

apiVersion: logging.openshift.io/v1
kind: ClusterLogging 1
metadata:
  name: instance
  namespace: openshift-logging
spec:
  collection:
    logs:
      fluentd: {}
      type: fluentd
  curation:
    type: "curator"
    curator:
      schedule: "30 3 * * *"
  managementState: Managed
---
apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder 2
metadata:
  name: instance
  namespace: openshift-logging
spec:
  inputs:
    - infrastructure: {}
      name: infra-logs
  outputs:
    - name: kafka-open
      type: kafka
      url: tcp://10.46.55.190:9092/test    3
  pipelines:
    - inputRefs:
      - audit
      name: audit-logs
      outputRefs:
      - kafka-open
    - inputRefs:
      - infrastructure
      name: infrastructure-logs
      outputRefs:
      - kafka-open

1
更新现有的 ClusterLogging 实例，如果实例不存在，则创建该实例。
2
更新现有的 ClusterLogForwarder 实例，如果实例不存在，则创建该实例。
3
指定日志转发到的 Kafka 服务器的 URL。

19.6.6.4. 性能配置集

运行 DU 工作负载的单节点 OpenShift 集群需要 Node Tuning Operator 性能配置集才能使用实时主机功能和服务。

注意

在早期版本的 OpenShift Container Platform 中，Performance Addon Operator 用来实现自动性能优化，以便为 OpenShift 应用程序实现低延迟性能。在 OpenShift Container Platform 4.11 中，这些功能是 Node Tuning Operator 的一部分。

以下示例 PerformanceProfile CR 演示了所需的集群配置。

推荐的性能配置集配置

apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
  name: openshift-node-performance-profile 1
spec:
  additionalKernelArgs:
    - rcupdate.rcu_normal_after_boot=0
    - "efi=runtime" 2
  cpu:
    isolated: 2-51,54-103 3
    reserved: 0-1,52-53   4
  hugepages:
    defaultHugepagesSize: 1G
    pages:
      - count: 32 5
        size: 1G  6
        node: 1 7
  machineConfigPoolSelector:
    pools.operator.machineconfiguration.openshift.io/master: ""
  nodeSelector:
    node-role.kubernetes.io/master: ""
  numa:
    topologyPolicy: "restricted"
  realTimeKernel:
    enabled: true    8

1
确保 name 的值与 Tuned PerformancePatch.yaml 的 spec.profile.data 字段中指定的值和 validatorCR/informDuValidator.yaml 的 status.configuration.source.name 字段匹配。
2 3
为集群主机配置 UEFI 安全引导。
4
设置隔离的 CPU。确保所有 Hyper-Threading 对都匹配。
5
设置保留的 CPU。启用工作负载分区时，系统进程、内核线程和系统容器线程仅限于这些 CPU。所有不是隔离的 CPU 都应保留。
6
设置巨页数量。
7
设置巨页大小。
8
将 enabled 设置为 true 以安装实时 Linux 内核。

19.6.6.5. PTP

单节点 OpenShift 集群使用 Precision Time Protocol (PTP) 进行网络时间同步。以下示例 PtpConfig CR 演示了所需的 PTP slave 配置。

推荐的 PTP 配置

apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: du-ptp-slave
  namespace: openshift-ptp
spec:
  profile:
    - interface: ens5f0     1
      name: slave
      phc2sysOpts: -a -r -n 24
      ptp4lConf: |
        [global]
        #
        # Default Data Set
        #
        twoStepFlag 1
        slaveOnly 0
        priority1 128
        priority2 128
        domainNumber 24
        #utc_offset 37
        clockClass 248
        clockAccuracy 0xFE
        offsetScaledLogVariance 0xFFFF
        free_running 0
        freq_est_interval 1
        dscp_event 0
        dscp_general 0
        dataset_comparison ieee1588
        G.8275.defaultDS.localPriority 128
        #
        # Port Data Set
        #
        logAnnounceInterval -3
        logSyncInterval -4
        logMinDelayReqInterval -4
        logMinPdelayReqInterval -4
        announceReceiptTimeout 3
        syncReceiptTimeout 0
        delayAsymmetry 0
        fault_reset_interval 4
        neighborPropDelayThresh 20000000
        masterOnly 0
        G.8275.portDS.localPriority 128
        #
        # Run time options
        #
        assume_two_step 0
        logging_level 6
        path_trace_enabled 0
        follow_up_info 0
        hybrid_e2e 0
        inhibit_multicast_service 0
        net_sync_monitor 0
        tc_spanning_tree 0
        tx_timestamp_timeout 1
        unicast_listen 0
        unicast_master_table 0
        unicast_req_duration 3600
        use_syslog 1
        verbose 0
        summary_interval 0
        kernel_leap 1
        check_fup_sync 0
        #
        # Servo Options
        #
        pi_proportional_const 0.0
        pi_integral_const 0.0
        pi_proportional_scale 0.0
        pi_proportional_exponent -0.3
        pi_proportional_norm_max 0.7
        pi_integral_scale 0.0
        pi_integral_exponent 0.4
        pi_integral_norm_max 0.3
        step_threshold 2.0
        first_step_threshold 0.00002
        max_frequency 900000000
        clock_servo pi
        sanity_freq_limit 200000000
        ntpshm_segment 0
        #
        # Transport options
        #
        transportSpecific 0x0
        ptp_dst_mac 01:1B:19:00:00:00
        p2p_dst_mac 01:80:C2:00:00:0E
        udp_ttl 1
        udp6_scope 0x0E
        uds_address /var/run/ptp4l
        #
        # Default interface options
        #
        clock_type OC
        network_transport L2
        delay_mechanism E2E
        time_stamping hardware
        tsproc_mode filter
        delay_filter moving_median
        delay_filter_length 10
        egressLatency 0
        ingressLatency 0
        boundary_clock_jbod 0
        #
        # Clock description
        #
        productDescription ;;
        revisionData ;;
        manufacturerIdentity 00:00:00
        userDescription ;
        timeSource 0xA0
      ptp4lOpts: -2 -s --summary_interval -4
recommend:
  - match:
      - nodeLabel: node-role.kubernetes.io/master
    priority: 4
    profile: slave

1
设置用于接收 PTP 时钟信号的接口。

19.6.6.6. 扩展的 Tuned 配置集

运行 DU 工作负载的单节点 OpenShift 集群需要额外的高性能工作负载所需的性能调优配置。以下 Tuned CR 示例扩展了 Tuned 配置集：

推荐的扩展 Tuned 配置集配置

apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: performance-patch
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
    - data: |
        [main]
        summary=Configuration changes profile inherited from performance created tuned
        include=openshift-node-performance-openshift-node-performance-profile
        [bootloader]
        cmdline_crash=nohz_full=2-51,54-103
        [sysctl]
        kernel.timer_migration=1
        [scheduler]
        group.ice-ptp=0:f:10:*:ice-ptp.*
        [service]
        service.stalld=start,enable
        service.chronyd=stop,disable
      name: performance-patch
  recommend:
    - machineConfigLabels:
        machineconfiguration.openshift.io/role: master
      priority: 19
      profile: performance-patch

19.6.6.7. SR-IOV

单根 I/O 虚拟化 (SR-IOV) 通常用于启用前端和中间网络。以下 YAML 示例为单节点 OpenShift 集群配置 SR-IOV。

推荐的 SR-IOV 配置

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovOperatorConfig
metadata:
  name: default
  namespace: openshift-sriov-network-operator
spec:
  configDaemonNodeSelector:
    node-role.kubernetes.io/master: ""
  disableDrain: true
  enableInjector: true
  enableOperatorWebhook: true
---
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: sriov-nw-du-mh
  namespace: openshift-sriov-network-operator
spec:
  networkNamespace: openshift-sriov-network-operator
  resourceName: du_mh
  vlan: 150 1
---
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: sriov-nnp-du-mh
  namespace: openshift-sriov-network-operator
spec:
  deviceType: vfio-pci 2
  isRdma: false
  nicSelector:
    pfNames:
      - ens7f0 3
  nodeSelector:
    node-role.kubernetes.io/master: ""
  numVfs: 8 4
  priority: 10
  resourceName: du_mh
---
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: sriov-nw-du-fh
  namespace: openshift-sriov-network-operator
spec:
  networkNamespace: openshift-sriov-network-operator
  resourceName: du_fh
  vlan: 140 5
---
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: sriov-nnp-du-fh
  namespace: openshift-sriov-network-operator
spec:
  deviceType: netdevice 6
  isRdma: true
  nicSelector:
    pfNames:
      - ens5f0 7
  nodeSelector:
    node-role.kubernetes.io/master: ""
  numVfs: 8 8
  priority: 10
  resourceName: du_fh

1
指定 midhaul 网络的 VLAN。
2
根据需要选择 vfio-pci 或 netdevice。
3
指定连接到中间网络的接口。
4
指定 midhaul 网络的 VF 数量。
5
前端网络的 VLAN。
6
根据需要选择 vfio-pci 或 netdevice。
7
指定连接到前端网络的接口。
8
指定前端网络的 VF 数量。

19.6.6.8. Console Operator

console-operator 在集群中安装并维护 web 控制台。当节点被集中管理时，不需要 Operator，并为应用程序工作负载腾出空间。以下 Console 自定义资源 (CR) 示例禁用控制台。

推荐的控制台配置

apiVersion: operator.openshift.io/v1
kind: Console
metadata:
  annotations:
    include.release.openshift.io/ibm-cloud-managed: "false"
    include.release.openshift.io/self-managed-high-availability: "false"
    include.release.openshift.io/single-node-developer: "false"
    release.openshift.io/create-only: "true"
  name: cluster
spec:
  logLevel: Normal
  managementState: Removed
  operatorLogLevel: Normal

19.6.6.9. Grafana 和 Alertmanager

运行 DU 工作负载的单节点 OpenShift 集群需要减少 OpenShift Container Platform 监控组件所消耗的 CPU 资源。以下 ConfigMap 自定义资源 (CR) 禁用 Grafana 和 Alertmanager。

推荐的集群监控配置

apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-monitoring-config
  namespace: openshift-monitoring
data:
  config.yaml: |
    grafana:
      enabled: false
    alertmanagerMain:
      enabled: false
    prometheusK8s:
       retention: 24h

19.6.6.10. 网络诊断

运行 DU 工作负载的单节点 OpenShift 集群需要较少的 pod 网络连接检查，以减少这些 pod 创建的额外负载。以下自定义资源 (CR) 禁用这些检查。

推荐的网络诊断配置

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  disableNetworkDiagnostics: true

其他资源

19.7. 为 vDU 应用程序工作负载验证单节点 OpenShift 集群调整

在部署虚拟分布式单元 (vDU) 应用程序前，您需要调整并配置集群主机固件和各种其他集群配置设置。使用以下信息来验证集群配置以支持 vDU 工作负载。

其他资源

19.7.1. vDU 集群主机的建议固件配置

使用下表为在 OpenShift Container Platform 4.10 上运行的 vDU 应用程序配置集群主机固件的基础。

注意

下表是 vDU 集群主机固件配置的一般建议。具体固件设置将取决于您的要求和特定的硬件平台。固件的自动设置不会被零接触置备管道处理。

表 19.7. 推荐的集群主机固件设置

固件设置Configuration描述

HyperTransport (HT)

Enabled

HyperTransport (HT) 总线是由 AMD 开发的总线技术。HT 提供主机内存中组件与其他系统外围之间的高速链接。

UEFI

Enabled

为 vDU 主机启用从 UEFI 引导。

CPU Power 和性能策略

性能

设置 CPU 电源和性能策略，以优化系统以提高能源效率。

非核心频率扩展

Disabled

禁用 Uncore Frequency 扩展，以防止单独设置 CPU 的非内核部分和频率。

Uncore Frequency

最大值

将 CPU 的非内核部分（如缓存和内存控制器）设置为操作最多可能的频率。

性能限制

Disabled

禁用性能 P-limit 以防止处理器的 Uncore 频率协调。

增强的 Intel® SpeedStep Tech

Enabled

启用增强的 Intel SpeedStep，以便系统动态调整处理器消耗和降低主机中功耗和 heat 生产的核心频率。

Intel® Turbo Boost Technology

Enabled

为基于 Intel 的 CPU 启用 Turbo Boost Technology，允许处理器内核比底层操作频率更快运行（如果它们低于 power、current 和 temperature 规格限制）。

Intel 配置的 TDP

Enabled

为 CPU 启用 Thermal Design Power (TDP)

可配置 TDP 级别

2 级

TDP 级别设置特定性能评级所需的 CPU 功耗。TDP 级别 2 以功耗为代价以实现最稳定的性能水平。

节能 Turbo

Disabled

禁用 Energy Efficient Turbo，以防止处理器使用基于能源效率的策略。

硬件 P-State

Disabled

禁用 P-states （性能状态）以优化操作系统和 CPU 以提高功耗。

软件包 C-State

C0/C1 状态

使用 C0 或 C1 状态将处理器设置为完全活动状态 (C0) 或停止在软件中运行的 CPU 内部时钟 (C1)。

C1E

Disabled

CPU Enhanced Halt (C1E) 是 Intel 芯片中的节能功能。禁用 C1E 可防止操作系统在不活跃时向 CPU 发送 halt 命令。

处理器 C6

Disabled

C6 节能程序是 CPU 功能，可自动禁用空闲 CPU 内核和缓存。禁用 C6 可提高系统性能。

子 NUMA 集群

Disabled

子 NUMA 集群将处理器内核、缓存和内存划分为多个 NUMA 域。禁用这个选项可以提高对延迟敏感工作负载的性能。

注意

在主机的固件中启用全局 SR-IOV 和 VT-d 设置。这些设置与裸机环境相关。

19.7.2. 推荐的集群配置来运行 vDU 应用程序

运行虚拟化分布式单元 (vDU) 应用程序的集群需要高度调整和优化的配置。以下信息描述了在 OpenShift Container Platform 4.10 集群中支持 vDU 工作负载时所需的各种元素。

19.7.2.1. 推荐的集群 MachineConfig CR

以下 MachineConfig CR 配置集群主机：

表 19.8. 推荐的 MachineConfig CR

CR 文件名描述

02-workload-partitioning.yaml

配置集群的工作负载分区。安装集群时应用此 MachineConfig CR。

MachineConfigSctp.yaml

加载 SCTP 内核模块。此 MachineConfig CR 是可选的，如果您不需要这个内核模块，可以忽略。

MachineConfigContainerMountNS.yaml

配置容器挂载命名空间和 kubelet conf。

MachineConfigAcceleratedStartup.yaml

配置集群的加速启动。

06-kdump-master.yaml, 06-kdump-worker.yaml

为集群配置 kdump。

19.7.2.2. 推荐的集群 Operator

运行 vDU 应用程序的集群需要以下 Operator，它是基准参考配置的一部分：

  • Node Tuning Operator (NTO).与 Performance Addon Operator 一起提供的 NTO 软件包功能，现在是 NTO 的一部分。
  • PTP Operator
  • Cluster Network Operator
  • Red Hat OpenShift Logging Operator
  • Local Storage Operator

19.7.2.4. 检查实时内核版本

在 OpenShift Container Platform 集群中，始终使用最新版本的 realtime 内核。如果您不确定集群中正在使用的内核版本，您可以将当前的 realtime 内核版本与发行版本进行比较。

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 以具有 cluster-admin 权限的用户身份登录。
  • 已安装 podman。

流程

  1. 运行以下命令来获取集群版本： 

    $ OCP_VERSION=$(oc get clusterversion version -o jsonpath='{.status.desired.version}{"\n"}')

  2. 获取发行镜像 SHA 号： 

    $ DTK_IMAGE=$(oc adm release info --image-for=driver-toolkit quay.io/openshift-release-dev/ocp-release:$OCP_VERSION-x86_64)

  3. 运行发行镜像容器，并提取与集群当前发行版本一起打包的内核版本： 

    $ podman run --rm $DTK_IMAGE rpm -qa | grep 'kernel-rt-core-' | sed 's#kernel-rt-core-##'

    输出示例

    4.18.0-305.49.1.rt7.121.el8_4.x86_64

    这是版本附带的默认 realtime 内核版本。

    注意

    realtime 内核由内核版本中的字符串 .rt 表示。

验证

检查为集群当前发行版本列出的内核版本是否与集群中运行的实际实时内核匹配。运行以下命令检查运行的 realtime 内核版本：

  1. 打开到集群节点的远程 shell 连接： 

    $ oc debug node/<node_name>

  2. 检查 realtime 内核版本： 

    sh-4.4# uname -r

    输出示例

    4.18.0-305.49.1.rt7.121.el8_4.x86_64

19.7.3. 检查是否应用推荐的集群配置

您可以检查集群是否正在运行正确的配置。以下流程描述了如何检查在 OpenShift Container Platform 4.10 集群中部署 DU 应用程序所需的各种配置。

先决条件

  • 您已部署了集群，并根据 vDU 工作负载对其进行调整。
  • 已安装 OpenShift CLI(oc)。
  • 您已以具有 cluster-admin 权限的用户身份登录。

流程

  1. 检查默认 Operator Hub 源是否已禁用。运行以下命令: 

    $ oc get operatorhub cluster -o yaml

    输出示例

    spec:
    disableAllDefaultSources: true

  2. 运行以下命令，检查所有所需的 CatalogSource 资源是否标注了工作负载分区 (PreferredDuringScheduling)： 

    $ oc get catalogsource -A -o jsonpath='{range .items[*]}{.metadata.name}{" -- "}{.metadata.annotations.target\.workload\.openshift\.io/management}{"\n"}{end}'

    输出示例

    certified-operators -- {"effect": "PreferredDuringScheduling"}
community-operators -- {"effect": "PreferredDuringScheduling"}
ran-operators 1
redhat-marketplace -- {"effect": "PreferredDuringScheduling"}
redhat-operators -- {"effect": "PreferredDuringScheduling"}

    1
    未注解的 CatalogSource 资源也会返回。在本例中，ran-operators CatalogSource 资源没有被注解，它没有 PreferredDuringScheduling 注解。
    注意

    在正确配置的 vDU 集群中，只会列出注解的一个目录源。

  3. 检查是否为工作负载分区注解了所有适用的 OpenShift Container Platform Operator 命名空间。这包括 OpenShift Container Platform 核心安装的所有 Operator，以及参考 DU 调整配置中包含的附加 Operator 集合。运行以下命令: 

    $ oc get namespaces -A -o jsonpath='{range .items[*]}{.metadata.name}{" -- "}{.metadata.annotations.workload\.openshift\.io/allowed}{"\n"}{end}'

    输出示例

    default --
openshift-apiserver -- management
openshift-apiserver-operator -- management
openshift-authentication -- management
openshift-authentication-operator -- management

    重要

    对于工作负载分区，不得为其他 Operator 进行注解。在上一命令的输出中，应列出其他 Operator（不包括 -- 分隔符右侧的值）。

  4. 检查 ClusterLogging 配置是否正确。运行以下命令：

    1. 验证是否配置了适当的输入和输出日志： 

      $ oc get -n openshift-logging ClusterLogForwarder instance -o yaml

      输出示例

      apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  creationTimestamp: "2022-07-19T21:51:41Z"
  generation: 1
  name: instance
  namespace: openshift-logging
  resourceVersion: "1030342"
  uid: 8c1a842d-80c5-447a-9150-40350bdf40f0
spec:
  inputs:
  - infrastructure: {}
    name: infra-logs
  outputs:
  - name: kafka-open
    type: kafka
    url: tcp://10.46.55.190:9092/test
  pipelines:
  - inputRefs:
    - audit
    name: audit-logs
    outputRefs:
    - kafka-open
  - inputRefs:
    - infrastructure
    name: infrastructure-logs
    outputRefs:
    - kafka-open
...

    2. 检查策展调度是否适合您的应用程序： 

      $ oc get -n openshift-logging clusterloggings.logging.openshift.io instance -o yaml

      输出示例

      apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  creationTimestamp: "2022-07-07T18:22:56Z"
  generation: 1
  name: instance
  namespace: openshift-logging
  resourceVersion: "235796"
  uid: ef67b9b8-0e65-4a10-88ff-ec06922ea796
spec:
  collection:
    logs:
      fluentd: {}
      type: fluentd
  curation:
    curator:
      schedule: 30 3 * * *
    type: curator
  managementState: Managed
...

  5. 运行以下命令，检查 Web 控制台是否已禁用 (managementState: Removed)： 

    $ oc get consoles.operator.openshift.io cluster -o jsonpath="{ .spec.managementState }"

    输出示例

    Removed

  6. 运行以下命令，检查集群节点中禁用了 chronyd ： 

    $ oc debug node/<node_name>

    检查节点上的 chronyd 状态： 

    sh-4.4# chroot /host
    sh-4.4# systemctl status chronyd

    输出示例

    ● chronyd.service - NTP client/server
    Loaded: loaded (/usr/lib/systemd/system/chronyd.service; disabled; vendor preset: enabled)
    Active: inactive (dead)
      Docs: man:chronyd(8)
            man:chrony.conf(5)

  7. 使用连接到 linuxptp-daemon 容器和 PTP Management Client (pmc) 工具，检查 PTP 接口是否已成功同步到主时钟：

    1. 运行以下命令，使用 linuxptp-daemon pod 的名称设置 $PTP_POD_NAME 变量： 

      $ PTP_POD_NAME=$(oc get pods -n openshift-ptp -l app=linuxptp-daemon -o name)

    2. 运行以下命令来检查 PTP 设备的同步状态： 

      $ oc -n openshift-ptp rsh -c linuxptp-daemon-container ${PTP_POD_NAME} pmc -u -f /var/run/ptp4l.0.config -b 0 'GET PORT_DATA_SET'

      输出示例

      sending: GET PORT_DATA_SET
  3cecef.fffe.7a7020-1 seq 0 RESPONSE MANAGEMENT PORT_DATA_SET
    portIdentity            3cecef.fffe.7a7020-1
    portState               SLAVE
    logMinDelayReqInterval  -4
    peerMeanPathDelay       0
    logAnnounceInterval     1
    announceReceiptTimeout  3
    logSyncInterval         0
    delayMechanism          1
    logMinPdelayReqInterval 0
    versionNumber           2
  3cecef.fffe.7a7020-2 seq 0 RESPONSE MANAGEMENT PORT_DATA_SET
    portIdentity            3cecef.fffe.7a7020-2
    portState               LISTENING
    logMinDelayReqInterval  0
    peerMeanPathDelay       0
    logAnnounceInterval     1
    announceReceiptTimeout  3
    logSyncInterval         0
    delayMechanism          1
    logMinPdelayReqInterval 0
    versionNumber           2

    3. 运行以下 pmc 命令来检查 PTP 时钟状态： 

      $ oc -n openshift-ptp rsh -c linuxptp-daemon-container ${PTP_POD_NAME} pmc -u -f /var/run/ptp4l.0.config -b 0 'GET TIME_STATUS_NP'

      输出示例

      sending: GET TIME_STATUS_NP
  3cecef.fffe.7a7020-0 seq 0 RESPONSE MANAGEMENT TIME_STATUS_NP
    master_offset              10 1
    ingress_time               1657275432697400530
    cumulativeScaledRateOffset +0.000000000
    scaledLastGmPhaseChange    0
    gmTimeBaseIndicator        0
    lastGmPhaseChange          0x0000'0000000000000000.0000
    gmPresent                  true 2
    gmIdentity                 3c2c30.ffff.670e00

      1
      master_offset 应该介于 -100 到 100 ns 之间。
      2
      这表示 PTP 时钟被同步到 master，本地时钟不是 grandmaster 时钟。

    4. 检查在 linuxptp-daemon-container 日志中有与 /var/run/ptp4l.0.config 中的值对应的 master offset ： 

      $ oc logs $PTP_POD_NAME -n openshift-ptp -c linuxptp-daemon-container

      输出示例

      phc2sys[56020.341]: [ptp4l.1.config] CLOCK_REALTIME phc offset  -1731092 s2 freq -1546242 delay    497
ptp4l[56020.390]: [ptp4l.1.config] master offset         -2 s2 freq   -5863 path delay       541
ptp4l[56020.390]: [ptp4l.0.config] master offset         -8 s2 freq  -10699 path delay       533

  8. 运行以下命令检查 SR-IOV 配置是否正确：

    1. 检查 SriovOperatorConfig 资源中的 disableDrain 值是否已设置为 true ： 

      $ oc get sriovoperatorconfig -n openshift-sriov-network-operator default -o jsonpath="{.spec.disableDrain}{'\n'}"

      输出示例

      true

    2. 运行以下命令，检查 SriovNetworkNodeState 同步状态是否为 Succeeded ： 

      $ oc get SriovNetworkNodeStates -n openshift-sriov-network-operator -o jsonpath="{.items[*].status.syncStatus}{'\n'}"

      输出示例

      Succeeded

    3. 验证为 SR-IOV 配置的每个接口下的虚拟功能（Vfs）预期数量和配置是否存在，并在 .status.interfaces 字段中是正确的。例如： 

      $ oc get SriovNetworkNodeStates -n openshift-sriov-network-operator -o yaml

      输出示例

      apiVersion: v1
items:
- apiVersion: sriovnetwork.openshift.io/v1
  kind: SriovNetworkNodeState
...
  status:
    interfaces:
    ...
    - Vfs:
      - deviceID: 154c
        driver: vfio-pci
        pciAddress: 0000:3b:0a.0
        vendor: "8086"
        vfID: 0
      - deviceID: 154c
        driver: vfio-pci
        pciAddress: 0000:3b:0a.1
        vendor: "8086"
        vfID: 1
      - deviceID: 154c
        driver: vfio-pci
        pciAddress: 0000:3b:0a.2
        vendor: "8086"
        vfID: 2
      - deviceID: 154c
        driver: vfio-pci
        pciAddress: 0000:3b:0a.3
        vendor: "8086"
        vfID: 3
      - deviceID: 154c
        driver: vfio-pci
        pciAddress: 0000:3b:0a.4
        vendor: "8086"
        vfID: 4
      - deviceID: 154c
        driver: vfio-pci
        pciAddress: 0000:3b:0a.5
        vendor: "8086"
        vfID: 5
      - deviceID: 154c
        driver: vfio-pci
        pciAddress: 0000:3b:0a.6
        vendor: "8086"
        vfID: 6
      - deviceID: 154c
        driver: vfio-pci
        pciAddress: 0000:3b:0a.7
        vendor: "8086"
        vfID: 7

  9. 检查集群性能配置集是否正确。cpu 和 hugepages 部分将根据您的硬件配置而有所不同。运行以下命令: 

    $ oc get PerformanceProfile openshift-node-performance-profile -o yaml

    输出示例

    apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
  creationTimestamp: "2022-07-19T21:51:31Z"
  finalizers:
  - foreground-deletion
  generation: 1
  name: openshift-node-performance-profile
  resourceVersion: "33558"
  uid: 217958c0-9122-4c62-9d4d-fdc27c31118c
spec:
  additionalKernelArgs:
  - idle=poll
  - rcupdate.rcu_normal_after_boot=0
  - efi=runtime
  cpu:
    isolated: 2-51,54-103
    reserved: 0-1,52-53
  hugepages:
    defaultHugepagesSize: 1G
    pages:
    - count: 32
      size: 1G
  machineConfigPoolSelector:
    pools.operator.machineconfiguration.openshift.io/master: ""
  net:
    userLevelNetworking: true
  nodeSelector:
    node-role.kubernetes.io/master: ""
  numa:
    topologyPolicy: restricted
  realTimeKernel:
    enabled: true
status:
  conditions:
  - lastHeartbeatTime: "2022-07-19T21:51:31Z"
    lastTransitionTime: "2022-07-19T21:51:31Z"
    status: "True"
    type: Available
  - lastHeartbeatTime: "2022-07-19T21:51:31Z"
    lastTransitionTime: "2022-07-19T21:51:31Z"
    status: "True"
    type: Upgradeable
  - lastHeartbeatTime: "2022-07-19T21:51:31Z"
    lastTransitionTime: "2022-07-19T21:51:31Z"
    status: "False"
    type: Progressing
  - lastHeartbeatTime: "2022-07-19T21:51:31Z"
    lastTransitionTime: "2022-07-19T21:51:31Z"
    status: "False"
    type: Degraded
  runtimeClass: performance-openshift-node-performance-profile
  tuned: openshift-cluster-node-tuning-operator/openshift-node-performance-openshift-node-performance-profile

    注意

    CPU 设置取决于服务器上可用的内核数，应当与工作负载分区设置保持一致。巨页配置取决于服务器和应用程序。

  10. 运行以下命令，检查 PerformanceProfile 是否已成功应用到集群： 

    $ oc get performanceprofile openshift-node-performance-profile -o jsonpath="{range .status.conditions[*]}{ @.type }{' -- '}{@.status}{'\n'}{end}"

    输出示例

    Available -- True
Upgradeable -- True
Progressing -- False
Degraded -- False

  11. 运行以下命令检查 Tuned 性能补丁设置： 

    $ oc get tuneds.tuned.openshift.io -n openshift-cluster-node-tuning-operator performance-patch -o yaml

    输出示例

    apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  creationTimestamp: "2022-07-18T10:33:52Z"
  generation: 1
  name: performance-patch
  namespace: openshift-cluster-node-tuning-operator
  resourceVersion: "34024"
  uid: f9799811-f744-4179-bf00-32d4436c08fd
spec:
  profile:
  - data: |
      [main]
      summary=Configuration changes profile inherited from performance created tuned
      include=openshift-node-performance-openshift-node-performance-profile
      [bootloader]
      cmdline_crash=nohz_full=2-23,26-47 1
      [sysctl]
      kernel.timer_migration=1
      [scheduler]
      group.ice-ptp=0:f:10:*:ice-ptp.*
      [service]
      service.stalld=start,enable
      service.chronyd=stop,disable
    name: performance-patch
  recommend:
  - machineConfigLabels:
      machineconfiguration.openshift.io/role: master
    priority: 19
    profile: performance-patch

    1
    cmdline=nohz_full= 中的 cpu 列表将根据您的硬件配置而有所不同。

  12. 运行以下命令，检查是否禁用了集群网络诊断： 

    $ oc get networks.operator.openshift.io cluster -o jsonpath='{.spec.disableNetworkDiagnostics}'

    输出示例

    true

  13. 检查 Kubelet housekeeping 间隔是否调整为较慢的速度。这是在 containerMountNS 机器配置中设置的。运行以下命令: 

    $ oc describe machineconfig container-mount-namespace-and-kubelet-conf-master | grep OPENSHIFT_MAX_HOUSEKEEPING_INTERVAL_DURATION

    输出示例

    Environment="OPENSHIFT_MAX_HOUSEKEEPING_INTERVAL_DURATION=60s"

  14. 运行以下命令，检查 Grafana 和 alertManagerMain 是否已禁用，Prometheus 保留周期是否已设置为 24h： 

    $ oc get configmap cluster-monitoring-config -n openshift-monitoring -o jsonpath="{ .data.config\.yaml }"

    输出示例

    grafana:
  enabled: false
alertmanagerMain:
  enabled: false
prometheusK8s:
   retention: 24h

    1. 使用以下命令验证集群中没有找到 Grafana 和 alertManagerMain 路由： 

      $ oc get route -n openshift-monitoring alertmanager-main
      $ oc get route -n openshift-monitoring grafana

      这两个查询都应返回 Error from server(NotFound) 消息。

  15. 运行以下命令，检查是否已为每个 PerformanceProfile、Tuned 性能补丁、工作负载分区和内核命令行参数分配至少 4 个保留 CPU： 

    $ oc get performanceprofile -o jsonpath="{ .items[0].spec.cpu.reserved }"

    输出示例

    0-1,52-53

    注意

    根据您的工作负载要求，您可能需要分配额外的保留 CPU。

19.8. 带有 SiteConfig 资源的高级受管集群配置

您可以使用 SiteConfig 自定义资源 (CR) 在安装时在受管集群中部署自定义功能和配置。

19.8.1. 在 ZTP GitOps 管道中自定义额外的安装清单

您可以定义一组额外的清单，以包含在零接触置备(ZTP) GitOps 管道的安装阶段。这些清单链接到 siteConfig 自定义资源(CR)，并在安装过程中应用到集群。在安装时包括 MachineConfig CR 可提高安装过程的效率。

先决条件

  • 创建一个 Git 存储库，在其中管理自定义站点配置数据。该存储库必须可从 hub 集群访问，并定义为 Argo CD 应用程序的源仓库。

流程

  1. 创建 ZTP 管道用于自定义集群安装的一组额外清单 CR。

  2. 在自定义 /siteconfig 目录中，为您的额外清单创建一个 /extra-manifest 文件夹。以下示例演示了一个 /siteconfig 示例，带有 /extra-manifest 文件夹： 

    siteconfig
├── site1-sno-du.yaml
├── site2-standard-du.yaml
└── extra-manifest
    └── 01-example-machine-config.yaml
  3. 将自定义额外清单 CR 添加到 siteconfig/extra-manifest 目录。

  4. 在 SiteConfig CR 的 extraManifestPath 字段中输入目录名称，例如： 

    clusters:
- clusterName: "example-sno"
  networkType: "OVNKubernetes"
  extraManifestPath: extra-manifest
  5. 保存 SiteConfig CR 和 /extra-manifest CR，并将它们推送到站点配置存储库。

ZTP 管道在集群置备过程中将 /extra-manifest 目录中的 CR 附加到默认额外清单集合中。

19.8.2. 使用 siteConfig 过滤器过滤自定义资源

通过使用过滤器，您可以轻松地自定义 SiteConfig 自定义资源 (CR) 来包含或排除其他 CR，以便在零 touch 置备 (ZTP) GitOps 管道的安装阶段使用。

您可以为 SiteConfig CR 指定一个 inclusionDefault 值（include 或 exclude），以及您要包含或排除的特定 extraManifest RAN CR 列表。将 inclusionDefault 设置为 include 可使 ZTP 管道在安装过程中应用 /source-crs/extra-manifest 中的所有文件。将 includeDefault 设置为 exclude 的作用相反。

您可以从 /source-crs/extra-manifest 文件夹中排除默认会被包括的 CR。以下示例配置了自定义单节点 OpenShift SiteConfig CR，以在安装时排除 /source-crs/extra-manifest/03-sctp-machine-config-worker.yaml CR。

另外还介绍了一些额外的可选过滤场景。

先决条件

  • 配置了 hub 集群来生成所需的安装和策略 CR。
  • 您创建了 Git 存储库，用于管理自定义站点配置数据。该存储库必须可从 hub 集群访问，并定义为 Argo CD 应用程序的源仓库。

流程

  1. 要防止 ZTP 管道应用 03-sctp-machine-config-worker.yaml CR 文件，在 SiteConfig CR 中应用以下 YAML： 

    apiVersion: ran.openshift.io/v1
kind: SiteConfig
metadata:
  name: "site1-sno-du"
  namespace: "site1-sno-du"
spec:
  baseDomain: "example.com"
  pullSecretRef:
    name: "assisted-deployment-pull-secret"
  clusterImageSetNameRef: "openshift-4.10"
  sshPublicKey: "<ssh_public_key>"
  clusters:
- clusterName: "site1-sno-du"
  extraManifests:
    filter:
      exclude:
        - 03-sctp-machine-config-worker.yaml

    ZTP 管道在安装过程中跳过 03-sctp-machine-config-worker.yaml CR。应用 /source-crs/extra-manifest 中的所有其他 CR。

  2. 保存 SiteConfig CR，并将更改推送到站点配置存储库。

    ZTP 管道会监控和调整它根据 SiteConfig 过滤器指令所应用的 CR。

  3. 可选： 要防止 ZTP 管道在集群中应用所有 /source-crs/extra-manifest CR，请在 SiteConfig CR 中应用以下 YAML： 

    - clusterName: "site1-sno-du"
  extraManifests:
    filter:
      inclusionDefault: exclude

  4. 可选： 要排除所有 /source-crs/extra-manifest RAN CR，并在安装过程中包括自定义 CR 文件，编辑自定义 SiteConfig CR 来设置自定义清单文件夹和 include 文件，例如： 

    clusters:
- clusterName: "site1-sno-du"
  extraManifestPath: "<custom_manifest_folder>" 1
  extraManifests:
    filter:
      inclusionDefault: exclude  2
      include:
        - custom-sctp-machine-config-worker.yaml
    1
    将 <custom_manifest_folder> 替换为包含自定义安装 CR 的文件夹名称，如 user-custom-manifest/。
    2
    将 inclusionDefault 设置为 exclude 以防止 ZTP 管道在安装过程中应用 /source-crs/extra-manifest 中的文件。

    以下示例演示了自定义文件夹结构： 

    siteconfig
  ├── site1-sno-du.yaml
  └── user-custom-manifest
        └── custom-sctp-machine-config-worker.yaml

19.9. 使用 PolicyGenTemplate 资源进行高级受管集群配置

您可以使用 PolicyGenTemplate CR 在受管集群中部署自定义功能。

19.9.1. 为集群部署额外的更改

如果需要在基本 GitOps ZTP 管道配置之外更改集群配置，则有三个选项：

在 ZTP 管道完成后应用附加配置
当 GitOps ZTP 管道部署完成后，部署的集群就可以用于应用程序工作负载。此时，您可以安装其他 Operator 并应用具体具体要求的配置。确保额外的配置不会影响平台或分配的 CPU 预算的性能。
在 ZTP 库中添加内容
使用 GitOps ZTP 管道部署的基本源自定义资源 (CR) 可以根据需要使用自定义内容增强。
为集群安装创建额外的清单
在安装过程中应用额外的清单，并使安装过程更高效。
重要

提供额外的源 CR 或修改现有源 CR 可能会影响 OpenShift Container Platform 的性能或 CPU 配置集。

其他资源

19.9.2. 使用 PolicyGenTemplate CR 覆盖源 CR 内容

PolicyGenTemplate 自定义资源 (CR) 允许您覆盖与 ztp-site-generate 容器中提供的 GitOps 插件提供的基本源 CR 之上的额外配置详情。您可以将 PolicyGenTemplate CR 视为基础 CR 的逻辑合并或补丁。使用 PolicyGenTemplate CR 更新基本 CR 的单个字段，或覆盖基本 CR 的整个内容。您可以更新不在基本 CR 中的值和插入字段。

以下示例步骤描述了如何根据 group-du-sno-ranGen.yaml 文件中的 PolicyGenTemplate CR 为参考配置更新生成的 PerformanceProfile CR 中的字段。根据要求，使用流程修改 PolicyGenTemplate 的其他部分。

先决条件

  • 创建一个 Git 存储库，在其中管理自定义站点配置数据。存储库必须可从 hub 集群访问，并定义为 Argo CD 的源存储库。

流程

  1. 查看基准源 CR 以查找现有内容。您可以通过从零接触置备(ZTP)容器提取，来查看参考 PolicyGenTemplate CR 中列出的源 CR。

    1. 创建 /out 文件夹： 

      $ mkdir -p ./out

    2. 提取源 CR： 

      $ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v{product-version}.1 extract /home/ztp --tar | tar x -C ./out

  2. 查看 ./out/source-crs/PerformanceProfile.yaml 中的基线 PerformanceProfile CR： 

    apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
  name: $name
  annotations:
    ran.openshift.io/ztp-deploy-wave: "10"
spec:
  additionalKernelArgs:
  - "idle=poll"
  - "rcupdate.rcu_normal_after_boot=0"
  cpu:
    isolated: $isolated
    reserved: $reserved
  hugepages:
    defaultHugepagesSize: $defaultHugepagesSize
    pages:
      - size: $size
        count: $count
        node: $node
  machineConfigPoolSelector:
    pools.operator.machineconfiguration.openshift.io/$mcp: ""
  net:
    userLevelNetworking: true
  nodeSelector:
    node-role.kubernetes.io/$mcp: ''
  numa:
    topologyPolicy: "restricted"
  realTimeKernel:
    enabled: true
    注意

    如果 PolicyGenTemplate CR 中未提供，则包含 $…​ 的任何字段都会从生成的 CR 中删除。

  3. 在 group-du-sno-ranGen.yaml 参考文件中为 PerformanceProfile 更新 PolicyGenTemplate 条目。以下示例 PolicyGenTemplate CR 小节提供了适当的 CPU 规格，设置 hugepages 配置，并添加一个新的字段，将 globallyDisableIrqLoadBalancing 设置为 false。 

    - fileName: PerformanceProfile.yaml
  policyName: "config-policy"
  metadata:
    name: openshift-node-performance-profile
  spec:
    cpu:
      # These must be tailored for the specific hardware platform
      isolated: "2-19,22-39"
      reserved: "0-1,20-21"
    hugepages:
      defaultHugepagesSize: 1G
      pages:
        - size: 1G
          count: 10
    globallyDisableIrqLoadBalancing: false
  4. 提交 Git 中的 PolicyGenTemplate 更改，然后推送到由 GitOps ZTP argo CD 应用程序监控的 Git 存储库。

输出示例

ZTP 应用程序生成包含生成的 PerformanceProfile CR 的 RHACM 策略。该 CR 的内容通过将 PolicyGenTemplate 中的 PerformanceProfile 条目的 metadata 和 spec 内容合并到源 CR 中。生成的 CR 包含以下内容： 

---
apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
    name: openshift-node-performance-profile
spec:
    additionalKernelArgs:
        - idle=poll
        - rcupdate.rcu_normal_after_boot=0
    cpu:
        isolated: 2-19,22-39
        reserved: 0-1,20-21
    globallyDisableIrqLoadBalancing: false
    hugepages:
        defaultHugepagesSize: 1G
        pages:
            - count: 10
              size: 1G
    machineConfigPoolSelector:
        pools.operator.machineconfiguration.openshift.io/master: ""
    net:
        userLevelNetworking: true
    nodeSelector:
        node-role.kubernetes.io/master: ""
    numa:
        topologyPolicy: restricted
    realTimeKernel:
        enabled: true
注意

在从 ztp-site-generate 容器中提取的 /source-crs 文件夹中，$ 语法用于模板替换。相反，如果 policyGen 工具看到字符串的 $ 前缀，并且您不会在相关 PolicyGenTemplate CR 中为该字段指定值，则会完全从输出 CR 省略该字段。

一个例外是 /source-crs YAML 文件中的 $mcp 变量，该文件被替换为来自 PolicyGenTemplate CR 的 mcp 的指定的值。例如，在 example/policygentemplates/group-du-standard-ranGen.yaml 中，mcp 的值为 worker ： 

spec:
  bindingRules:
    group-du-standard: ""
  mcp: "worker"

policyGen 工具将输出 CR 中的 $mcp 实例替换为 worker。

19.9.3. 在 GitOps ZTP 管道中添加新内容

GitOps ZTP 站点生成器容器中的源 CR 提供一组 RAN 分布式单元(DU)应用程序的重要功能和节点调整设置。它们应用到您使用 ZTP 部署的集群。要在 ztp-site-generate 容器中添加或修改现有的源 CR，重建 ztp-site-generate 容器，并使其可用于 hub 集群，通常是与 hub 集群关联的断开连接的 registry。可以添加任何有效的 OpenShift Container Platform CR。

执行以下步骤在 ZTP 管道中添加新内容。

流程

  1. 创建包含 Containerfile 和您要包含在更新的 ztp-site-generate 容器中的源 CR YAML 文件的目录，例如： 

    ztp-update/
├── example-cr1.yaml
├── example-cr2.yaml
└── ztp-update.in

  2. 在 ztp-update.in Containerfile 中添加以下内容： 

    FROM registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.10

ADD example-cr2.yaml /kustomize/plugin/ran.openshift.io/v1/policygentemplate/source-crs/
ADD example-cr1.yaml /kustomize/plugin/ran.openshift.io/v1/policygentemplate/source-crs/

  3. 在 ztp-update/ 文件夹打开终端窗口并重建容器： 

    $ podman build -t ztp-site-generate-rhel8-custom:v4.10-custom-1

  4. 将构建的镜像推送到断开连接的 registry 中，例如： 

    $ podman push localhost/ztp-site-generate-rhel8-custom:v4.10-custom-1 registry.example.com:5000/ztp-site-generate-rhel8-custom:v4.10-custom-1

  5. 对 hub 集群中的 Argo CD 实例进行补丁，以指向新构建的容器镜像： 

    $ oc patch -n openshift-gitops argocd openshift-gitops --type=json -p '[{"op": "replace", "path":"/spec/repo/initContainers/0/image", "value": "registry.example.com:5000/ztp-site-generate-rhel8-custom:v4.10-custom-1"} ]'

    当 Argo CD 实例修补时，openshift-gitops-repo-server pod 会自动重启。

验证

  1. 验证新的 openshift-gitops-repo-server pod 是否已完成初始化，并且前面的 repo pod 是否已终止： 

    $ oc get pods -n openshift-gitops | grep openshift-gitops-repo-server

    输出示例

    openshift-gitops-server-7df86f9774-db682          1/1     Running   	     1          28s

    您必须等到新的 openshift-gitops-repo-server pod 完成初始化，并在新添加的容器镜像内容可用前终止之前的 pod。

其他资源

  • 另外，您可以在应用补丁文件前，对 ArgoCD 进行补丁，如 Configuring the hub cluster with ArgoCD 所述，使用一个更新的 initContainer 镜像来修改 argocd-openshift-gitops-patch.json。

19.9.4. 使用验证器通知策略信号 ZTP 集群部署完成

创建一个验证器通知策略，在零接触置备(ZTP)安装和配置完成部署集群时信号。此策略可用于部署单节点 OpenShift 集群、三节点集群和标准集群。

流程

  1. 创建包含源文件 validatorCR/informDuValidator.yaml 的独立 PolicyGenTemplate 自定义资源 (CR)。每个集群类型只需要一个独立 PolicyGenTemplate CR。例如，此 CR 为单节点 OpenShift 集群应用验证器通知策略：

    Example single-node cluster validator inform policy CR (group-du-sno-validator-ranGen.yaml)

    apiVersion: ran.openshift.io/v1
kind: PolicyGenTemplate
metadata:
  name: "group-du-sno-validator" 1
  namespace: "ztp-group" 2
spec:
  bindingRules:
    group-du-sno: "" 3
  bindingExcludedRules:
    ztp-done: "" 4
  mcp: "master" 5
  sourceFiles:
    - fileName: validatorCRs/informDuValidator.yaml
      remediationAction: inform 6
      policyName: "du-policy" 7

    1
    PolicyGenTemplates 对象的名称。此名称也用作在请求的 namespace 中创建的 placementBinding、placementRule 和 policy 的一部分。
    2
    这个值应该与组 PolicyGenTemplates 中使用的命名空间匹配。
    3
    bindingRules 中定义的 group-du-* 标签必须存在于 SiteConfig 文件中。
    4
    bindingExcludedRules 中定义的标签必须是'ztp-done:'。ztp-done 标签用于与 Topology Aware Lifecycle Manager 协调。
    5
    mcp 定义在源文件 validatorCR/informDuValidator.yaml 中使用的 MachineConfigPool 对象。它应该是单一节点的 master，以及用于标准集群部署的三节点集群部署和 worker。
    6
    可选的。默认值是 inform。
    7
    这个值被用作生成的 RHACM 策略的名称的一部分。单一节点示例生成的验证器策略是 group-du-sno-validator-du-policy。
  2. 在 Git 存储库中提交 PolicyGenTemplate CR 文件并推送更改。

其他资源

19.9.5. 使用 PolicyGenTemplate CR 配置 PTP 快速事件

您可以为使用 GitOps Zero Touch Provisioning(ZTP)管道部署的 vRAN 集群配置 PTP fast 事件。使用 PolicyGenTemplate 自定义 CR 作为基础来创建根据您的特定站点要求量身定制的配置文件的层次结构。

先决条件

  • 创建一个 Git 存储库，在其中管理自定义站点配置数据。

流程

  1. 将以下 YAML 添加到 common-ranGen.yaml 文件中的 .spec.sourceFiles 中，以配置 AMQP Operator： 

    #AMQ interconnect operator for fast events
- fileName: AmqSubscriptionNS.yaml
  policyName: "subscriptions-policy"
- fileName: AmqSubscriptionOperGroup.yaml
  policyName: "subscriptions-policy"
- fileName: AmqSubscription.yaml
  policyName: "subscriptions-policy"

  2. 根据您的具体要求，将以下 PolicyGenTemplate 应用到 group-du-3node-ranGen.yaml、group-du-sno-ranGen.yaml 或 group-du-standard-ranGen.yaml 文件：

    1. 在 .sourceFiles 中，添加 PtpOperatorConfig CR 文件，该文件将 AMQ 传输主机配置为 config-policy ： 

      - fileName: PtpOperatorConfigForEvent.yaml
  policyName: "config-policy"

    2. 为 PTP 时钟类型和接口配置 linuxptp 和 phc2sys。例如，将以下小节添加到 .sourceFiles 中： 

      - fileName: PtpConfigSlave.yaml 1
  policyName: "config-policy"
  metadata:
    name: "du-ptp-slave"
  spec:
    profile:
    - name: "slave"
      interface: "ens5f1" 2
      ptp4lOpts: "-2 -s --summary_interval -4" 3
      phc2sysOpts: "-a -r -m -n 24 -N 8 -R 16" 4
    ptpClockThreshold: 5
      holdOverTimeout: 30 #secs
      maxOffsetThreshold: 100  #nano secs
      minOffsetThreshold: -100 #nano secs
      1
      可以是 PtpConfigMaster.yaml、PtpConfigSlave.yaml 或 PtpConfigSlaveCvl.yaml，具体取决于您的要求。PtpConfigSlaveCvl.yaml 为 Intel E810 Columbiaville NIC 配置 linuxptp 服务。对于基于 group-du-sno-ranGen.yaml 或 group-du-3node-ranGen.yaml 的配置，请使用 PtpConfigSlave.yaml。
      2
      特定于设备的接口名称。
      3
      您必须将 --summary_interval -4 值附加到 .spec.sourceFiles.spec.profile 中的 ptp4lOpts 中，以启用 PTP fast 事件。
      4
      所需的 phc2sysOpts 值。-m 将消息输出到 stdout。linuxptp-daemon DaemonSet 解析日志并生成 Prometheus 指标。
      5
      可选的。如果 ptpClockThreshold 小节不存在，则默认值用于 ptpClockThreshold 字段。小节显示默认的 ptpClockThreshold 值。ptpClockThreshold 值配置 PTP master 时钟在触发 PTP 事件前的时长。holdOverTimeout 是在 PTP master clock 断开连接时，PTP 时钟事件状态更改为 FREERUN 前的时间值（以秒为单位）。maxOffsetThreshold 和 minOffsetThreshold 设置以纳秒为单位，它们与 CLOCK_REALTIME (phc2sys) 或 master 偏移 (ptp4l) 的值进行比较。当 ptp4l 或 phc2sys 偏移值超出这个范围时，PTP 时钟状态被设置为 FREERUN。当偏移值在这个范围内时，PTP 时钟状态被设置为 LOCKED。

  3. 将以下 PolicyGenTemplate 更改应用到您的特定站点 YAML 文件，如 example-sno-site.yaml ：

    1. 在 .sourceFiles 中，添加 Interconnect CR 文件，该文件将 AMQ 路由器配置为 config-policy ： 

      - fileName: AmqInstance.yaml
  policyName: "config-policy"
  4. 将任何其他必要的更改和文件与自定义站点存储库合并。
  5. 将更改推送到站点配置存储库，以使用 GitOps ZTP 将 PTP 快速事件部署到新站点。

其他资源

19.9.6. 使用 PolicyGenTemplate CR 配置裸机事件监控

您可以使用 GitOps Zero Touch Provisioning (ZTP) 管道为 vRAN 集群配置裸机硬件事件。

先决条件

  • 安装 OpenShift CLI（oc）。
  • 以具有 cluster-admin 特权的用户身份登录。
  • 创建一个 Git 存储库，在其中管理自定义站点配置数据。

流程

  1. 要配置 AMQ Interconnect Operator 和 Bare Metal Event Relay Operator，请将以下 YAML 添加到 common-ranGen.yaml 文件中的 spec.sourceFiles 中： 

    # AMQ interconnect operator for fast events
- fileName: AmqSubscriptionNS.yaml
  policyName: "subscriptions-policy"
- fileName: AmqSubscriptionOperGroup.yaml
  policyName: "subscriptions-policy"
- fileName: AmqSubscription.yaml
  policyName: "subscriptions-policy"
# Bare Metal Event Rely operator
- fileName: BareMetalEventRelaySubscriptionNS.yaml
  policyName: "subscriptions-policy"
- fileName: BareMetalEventRelaySubscriptionOperGroup.yaml
  policyName: "subscriptions-policy"
- fileName: BareMetalEventRelaySubscription.yaml
  policyName: "subscriptions-policy"

  2. 将 Interconnect CR 添加到站点配置文件中的 .spec.sourceFiles 中，例如 example-sno-site.yaml 文件： 

    - fileName: AmqInstance.yaml
  policyName: "config-policy"

  3. 将 HardwareEvent CR 添加到特定组配置文件中的 spec.sourceFiles，例如在 group-du-sno-ranGen.yaml 文件中： 

    - fileName: HardwareEvent.yaml
  policyName: "config-policy"
  spec:
    nodeSelector: {}
    transportHost: "amqp://<amq_interconnect_name>.<amq_interconnect_namespace>.svc.cluster.local" 1
    logLevel: "info"
    1
    transportHost URL 由现有的 AMQ Interconnect CR 名称和命名空间组成。例如，在 transportHost: "amq-router.amq-router.svc.cluster.local" 中，AMQ Interconnect name 和 namespace 都被设置为 amq-router。
    注意

    每个基板管理控制器 (BMC) 仅需要一个 HardwareEvent 资源。

  4. 在 Git 中提交 PolicyGenTemplate 更改，然后将更改推送到您的站点配置存储库，以使用 GitOps ZTP 将裸机事件监控部署到新站点。

  5. 运行以下命令来创建 Redfish Secret： 

    $ oc -n openshift-bare-metal-events create secret generic redfish-basic-auth \
--from-literal=username=<bmc_username> --from-literal=password=<bmc_password> \
--from-literal=hostaddr="<bmc_host_ip_addr>"

其他资源

其他资源

19.10. 使用 Topology Aware Lifecycle Manager 更新受管集群

您可以使用 Topology Aware Lifecycle Manager (TALM) 来管理 OpenShift Container Platform 受管集群的软件生命周期。TALM 使用 Red Hat Advanced Cluster Management(RHACM)策略在目标集群中进行更改。

重要

Topology Aware Lifecycle Manager 只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议（SLA）支持，且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能，并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的更多信息，请参阅技术预览功能支持范围。

其他资源

19.10.1. 在断开连接的环境中更新集群

您可以使用 GitOps ZTP 和 Topology Aware Lifecycle Manager (TALM) 为您部署的受管集群升级受管集群和 Operator。

19.10.1.1. 设置环境

TALM 可以同时执行平台和 Operator 更新。

您必须在镜像 registry 中镜像您要升级到的平台镜像和 Operator 镜像，然后才能使用 TALM 更新断开连接的集群。完成以下步骤以镜像镜像：

  • 对于平台更新，您必须执行以下步骤：

    1. 镜像所需的 OpenShift Container Platform 镜像存储库。根据"镜像 OpenShift Container Platform 镜像存储库"流程在附加资源中链接，确保所需的平台镜像已被镜像。在 imageContentSources.yaml 文件中保存 imageContentSources 部分的内容：

      输出示例

      imageContentSources:
 - mirrors:
   - mirror-ocp-registry.ibmcloud.io.cpak:5000/openshift-release-dev/openshift4
   source: quay.io/openshift-release-dev/ocp-release
 - mirrors:
   - mirror-ocp-registry.ibmcloud.io.cpak:5000/openshift-release-dev/openshift4
   source: quay.io/openshift-release-dev/ocp-v4.0-art-dev

    2. 保存已镜像的所需平台镜像的镜像签名。对于平台更新，您必须将镜像签名添加到 PolicyGenTemplate CR 中。要获取镜像签名，请执行以下步骤：

      1. 运行以下命令指定所需的 OpenShift Container Platform 标签： 

        $ OCP_RELEASE_NUMBER=<release_version>

      2. 运行以下命令指定服务器的构架： 

        $ ARCHITECTURE=<server_architecture>

      3. 运行以下命令，从 Quay 获取发行版本镜像摘要 

        $ DIGEST="$(oc adm release info quay.io/openshift-release-dev/ocp-release:${OCP_RELEASE_NUMBER}-${ARCHITECTURE} | sed -n 's/Pull From: .*@//p')"

      4. 运行以下命令来设置摘要算法： 

        $ DIGEST_ALGO="${DIGEST%%:*}"

      5. 运行以下命令来设置摘要签名： 

        $ DIGEST_ENCODED="${DIGEST#*:}"

      6. 运行以下命令，从 mirror.openshift.com 网站获取镜像签名： 

        $ SIGNATURE_BASE64=$(curl -s "https://mirror.openshift.com/pub/openshift-v4/signatures/openshift/release/${DIGEST_ALGO}=${DIGEST_ENCODED}/signature-1" | base64 -w0 && echo)

      7. 运行以下命令，将镜像签名保存到 checksum-<OCP_RELEASE_NUMBER>.yaml 文件中： 

        $ cat >checksum-${OCP_RELEASE_NUMBER}.yaml <<EOF
${DIGEST_ALGO}-${DIGEST_ENCODED}: ${SIGNATURE_BASE64}
EOF

    3. 准备更新图表。您可以通过两个选项来准备更新图形：

      1. 使用 OpenShift Update Service。

        有关如何在 hub 集群上设置图形的更多信息，请参阅为 OpenShift Update Service 部署 Operator 并构建图形数据 init 容器。

      2. 生成上游图形的本地副本。在可访问受管集群的断开连接的环境中的 http 或 https 服务器上托管更新图表。要下载更新图表，请使用以下命令： 

        $ curl -s https://api.openshift.com/api/upgrades_info/v1/graph?channel=stable-4.10 -o ~/upgrade-graph_stable-4.10

  • 对于 Operator 更新，您必须执行以下任务：

    • 镜像 Operator 目录。确保所需的 Operator 镜像按照"Mirroring Operator 目录以用于断开连接的集群"部分中的步骤进行镜像。

其他资源

19.10.1.2. 执行平台更新

您可以使用 TALM 执行平台更新。

先决条件

  • 安装 Topology Aware Lifecycle Manager(TALM)。
  • 将 ZTP 更新至最新版本。
  • 使用 ZTP 置备一个或多个受管集群。
  • 镜像所需的镜像存储库。
  • 以具有 cluster-admin 特权的用户身份登录。
  • 在 hub 集群中创建 RHACM 策略。

流程

  1. 为平台更新创建 PolicyGenTemplate CR：

    1. 将 PolicyGenTemplate CR 的以下内容保存到 du-upgrade.yaml 文件中。

      平台更新的 PolicyGenTemplate 示例

      apiVersion: ran.openshift.io/v1
kind: PolicyGenTemplate
metadata:
  name: "du-upgrade"
  namespace: "ztp-group-du-sno"
spec:
  bindingRules:
    group-du-sno: ""
  mcp: "master"
  remediationAction: inform
  sourceFiles:
    - fileName: ImageSignature.yaml 1
      policyName: "platform-upgrade-prep"
      binaryData:
        ${DIGEST_ALGO}-${DIGEST_ENCODED}: ${SIGNATURE_BASE64} 2
    - fileName: DisconnectedICSP.yaml
      policyName: "platform-upgrade-prep"
      metadata:
        name: disconnected-internal-icsp-for-ocp
      spec:
        repositoryDigestMirrors: 3
          - mirrors:
            - quay-intern.example.com/ocp4/openshift-release-dev
            source: quay.io/openshift-release-dev/ocp-release
          - mirrors:
            - quay-intern.example.com/ocp4/openshift-release-dev
            source: quay.io/openshift-release-dev/ocp-v4.0-art-dev
    - fileName: ClusterVersion.yaml 4
      policyName: "platform-upgrade-prep"
      metadata:
        name: version
        annotations:
          ran.openshift.io/ztp-deploy-wave: "1"
      spec:
        channel: "stable-4.10"
        upstream: http://upgrade.example.com/images/upgrade-graph_stable-4.10
    - fileName: ClusterVersion.yaml 5
      policyName: "platform-upgrade"
      metadata:
        name: version
      spec:
        channel: "stable-4.10"
        upstream: http://upgrade.example.com/images/upgrade-graph_stable-4.10
        desiredUpdate:
          version: 4.10.4
      status:
        history:
          - version: 4.10.4
            state: "Completed"

      1
      ConfigMap CR 包含要更新到的所需发行镜像的签名。
      2
      显示所需 OpenShift Container Platform 发行版本的镜像签名。根据"设置环境"部分中的步骤，从您保存的 checksum-${OCP_RELASE_NUMBER}.yaml 文件获取签名。
      3
      显示包含所需 OpenShift Container Platform 镜像的镜像存储库。获取在"设置 environment"部分中的步骤时所保存的 imageContentSources.yaml 文件中的镜像。
      4
      显示要更新上游的 ClusterVersion CR。
      5
      显示触发更新的 ClusterVersion CR。对于预缓存，channel, upstream, 和 desiredVersion 项都是必需的。

      PolicyGenTemplate CR 会生成两个策略：

      • du-upgrade-platform-upgrade-prep 策略为平台更新做准备。它为所需的发行版本镜像签名创建 ConfigMap CR，创建镜像的发行镜像存储库的镜像内容源，并使用所需的更新频道更新集群版本，以及在断开连接的环境中由 spoke 集群访问的更新图。
      • du-upgrade-platform-upgrade 策略用于执行平台升级。

    2. 对于 PolicyGenTemplate CR，将 du-upgrade.yaml 文件内容添加到 kustomization.yaml 文件（在 ZTP Git 存储库中），并将更改推送到 Git 存储库。

      ArgoCD 从 Git 存储库拉取更改并在 hub 集群上生成策略。

    3. 运行以下命令检查创建的策略： 

      $ oc get policies -A | grep platform-upgrade

  2. 在使用 TALM 启动平台更新前应用所需的更新资源。

    1. 将带有 du-upgrade-platform-upgrade-prep 的 platform-upgrade-prep ClusterUpgradeGroup CR 的内容，以及目标受管集群保存为 cgu-platform-upgrade-prep.yml 文件，如以下示例所示： 

      apiVersion: ran.openshift.io/v1alpha1
kind: ClusterGroupUpgrade
metadata:
  name: cgu-platform-upgrade-prep
  namespace: default
spec:
  managedPolicies:
  - du-upgrade-platform-upgrade-prep
  clusters:
  - spoke1
  remediationStrategy:
    maxConcurrency: 1
  enable: true

    2. 运行以下命令，将策略应用到 hub 集群： 

      $ oc apply -f cgu-platform-upgrade-prep.yml

    3. 监控更新过程。在完成后，运行以下命令来确保策略兼容： 

      $ oc get policies --all-namespaces

  3. 为平台更新创建 ClusterGroupUpdate CR，将 spec.enable 项设置为 false。

    1. 使用 du-upgrade-platform-upgrade 策略将平台更新 ClusterGroupUpdate CR 的内容保存到 cgu-platform-upgrade.yml 文件中，如下例所示： 

      apiVersion: ran.openshift.io/v1alpha1
kind: ClusterGroupUpgrade
metadata:
  name: cgu-platform-upgrade
  namespace: default
spec:
  managedPolicies:
  - du-upgrade-platform-upgrade
  preCaching: false
  clusters:
  - spoke1
  remediationStrategy:
    maxConcurrency: 1
  enable: false

    2. 运行以下命令，将 ClusterGroupUpdate CR 应用到 hub 集群： 

      $ oc apply -f cgu-platform-upgrade.yml

  4. 可选：缓存平台更新的镜像。

    1. 运行以下命令，在 ClusterGroupUpdate CR 中启用预缓存： 

      $ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-platform-upgrade \
--patch '{"spec":{"preCaching": true}}' --type=merge

    2. 监控更新过程，并等待预缓存完成。在 hub 集群中运行以下命令来检查预缓存的状态： 

      $ oc get cgu cgu-platform-upgrade -o jsonpath='{.status.precaching.status}'

  5. 启动平台更新：

    1. 运行以下命令启用 cgu-platform-upgrade 策略并禁用预缓存： 

      $ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-platform-upgrade \
--patch '{"spec":{"enable":true, "preCaching": false}}' --type=merge

    2. 监控进程。在完成后，运行以下命令来确保策略兼容： 

      $ oc get policies --all-namespaces

其他资源

19.10.1.3. 执行 Operator 更新

您可以使用 TALM 执行 Operator 更新。

先决条件

  • 安装 Topology Aware Lifecycle Manager(TALM)。
  • 将 ZTP 更新至最新版本。
  • 使用 ZTP 置备一个或多个受管集群。
  • 镜像捆绑包镜像、捆绑包镜像以及捆绑包镜像中引用的所有 Operator 镜像。
  • 以具有 cluster-admin 特权的用户身份登录。
  • 在 hub 集群中创建 RHACM 策略。

流程

  1. 为 Operator 更新更新 PolicyGenTemplate CR。

    1. 使用 du-upgrade.yaml 文件中的以下额外内容更新 du-upgrade PolicyGenTemplate CR： 

      apiVersion: ran.openshift.io/v1
kind: PolicyGenTemplate
metadata:
  name: "du-upgrade"
  namespace: "ztp-group-du-sno"
spec:
  bindingRules:
    group-du-sno: ""
  mcp: "master"
  remediationAction: inform
  sourceFiles:
    - fileName: DefaultCatsrc.yaml
      remediationAction: inform
      policyName: "operator-catsrc-policy"
      metadata:
        name: redhat-operators
      spec:
        displayName: Red Hat Operators Catalog
        image: registry.example.com:5000/olm/redhat-operators:v4.10 1
        updateStrategy: 2
          registryPoll:
            interval: 1h
      1
      索引镜像 URL 包含所需的 Operator 镜像。如果索引镜像始终推送到相同的镜像名称和标签，则不需要此更改。
      2
      使用 registryPoll.interval 字段设置 Operator Lifecycle Manager(OLM)轮询新 Operator 版本的索引镜像。如果为 y-stream 和 z-stream Operator 更新而总是推送新的索引镜像标签，则不需要此更改。registryPoll.interval 字段可以设置为较短的间隔，以加快更新，但较短的间隔会增大计算负载。要影响这个问题，您可以在更新完成后将 registryPoll.interval 恢复到默认值。

    2. 在这个版本中，生成一个策略 du-upgrade-operator-catsrc-policy，以使用包含所需 Operator 镜像的新索引镜像更新 redhat-operators 目录源。

      注意

      如果要使用 Operator 预缓存，并且有来自 redhat-operators 以外的其他目录源的 Operator，您必须执行以下任务：

      • 使用新的索引镜像或 registry 轮询间隔更新准备单独的目录源策略。
      • 为来自不同目录源的所需 Operator 准备单独的订阅策略。

      例如，所需的 SRIOV-FEC Operator 在 certified-operators 目录源中提供。要更新目录源和 Operator 订阅，请添加以下内容来生成两个策略： du-upgrade-fec-catsrc-policy 和 du-upgrade-subscriptions-fec-policy ： 

      apiVersion: ran.openshift.io/v1
kind: PolicyGenTemplate
metadata:
  name: "du-upgrade"
  namespace: "ztp-group-du-sno"
spec:
  bindingRules:
    group-du-sno: ""
  mcp: "master"
  remediationAction: inform
  sourceFiles:
       …
    - fileName: DefaultCatsrc.yaml
      remediationAction: inform
      policyName: "fec-catsrc-policy"
      metadata:
        name: certified-operators
      spec:
        displayName: Intel SRIOV-FEC Operator
        image: registry.example.com:5000/olm/far-edge-sriov-fec:v4.10
        updateStrategy:
          registryPoll:
            interval: 10m
    - fileName: AcceleratorsSubscription.yaml
      policyName: "subscriptions-fec-policy"
      spec:
        channel: "stable"
        source: certified-operators

    3. 如果存在，在常规 PolicyGenTemplate CR 中删除指定的订阅频道。ZTP 镜像的默认订阅频道用于更新。

      注意

      通过 ZTP 4.10 应用的 Operator 的默认频道是 stable，但 performance-addon-operator 除外。PAO 的默认频道是 4.10。您还可以在常规 PolicyGenTemplate CR 中指定默认频道。

    4. 将 PolicyGenTemplate CR 更新推送到 ZTP Git 存储库。

      ArgoCD 从 Git 存储库拉取更改并在 hub 集群上生成策略。

    5. 运行以下命令检查创建的策略： 

      $ oc get policies -A | grep -E "catsrc-policy|subscription"

  2. 在启动 Operator 更新前，应用所需的目录源更新。

    1. 使用目录源策略将名为 operator-upgrade-prep 的 ClusterGroupUpgrade CR 的内容保存到 cgu-operator-upgrade-prep.yml 文件中： 

      apiVersion: ran.openshift.io/v1alpha1
kind: ClusterGroupUpgrade
metadata:
  name: cgu-operator-upgrade-prep
  namespace: default
spec:
  clusters:
  - spoke1
  enable: true
  managedPolicies:
  - du-upgrade-operator-catsrc-policy
  remediationStrategy:
    maxConcurrency: 1

    2. 运行以下命令，将策略应用到 hub 集群： 

      $ oc apply -f cgu-operator-upgrade-prep.yml

    3. 监控更新过程。在完成后，运行以下命令来确保策略兼容： 

      $ oc get policies -A | grep -E "catsrc-policy"

  3. 为 Operator 更新创建 ClusterGroupUpgrade CR，并将 spec.enable 字段设置为 false。

    1. 使用 du-upgrade-operator-catsrc-policy 策略和从常规 PolicyGenTemplate 创建的订阅策略，将 Operator 更新 ClusterGroupUpgrade CR 的内容保存到 cgu-operator-upgrade.yml 文件，如下例所示： 

      apiVersion: ran.openshift.io/v1alpha1
kind: ClusterGroupUpgrade
metadata:
  name: cgu-operator-upgrade
  namespace: default
spec:
  managedPolicies:
  - du-upgrade-operator-catsrc-policy 1
  - common-subscriptions-policy 2
  preCaching: false
  clusters:
  - spoke1
  remediationStrategy:
    maxConcurrency: 1
  enable: false
      1
      镜像预缓存功能需要该策略，以便从目录源检索 Operator 镜像。
      2
      策略包含 Operator 订阅。如果您根据 "ZTP 从 4.9 升级到 4.10" 将 ZTP 从 4.9 升级到 4.10，则所有 Operator 订阅都会分组到 common-subscriptions-policy 策略中。
      注意

      一个 ClusterGroupUpgrade CR 只能从 ClusterGroupUpgrade CR 中包含的一个目录源中预缓存订阅策略中定义的 Operator 镜像。如果所需的 Operator 来自不同目录源，如 SRIOV-FEC Operator 示例，则必须使用 du-upgrade-fec-catsrc-policy 和 du-upgrade-subscriptions-fec-policy 镜像（pre-FEC Operator 镜像）创建另一个 ClusterGroupUpgrade CR。

    2. 运行以下命令，将 ClusterGroupUpgrade CR 应用到 hub 集群： 

      $ oc apply -f cgu-operator-upgrade.yml

  4. 可选：缓存 Operator 更新的镜像。

    1. 在启动镜像预缓存前，运行以下命令验证订阅策略在此时是否是 NonCompliant ： 

      $ oc get policy common-subscriptions-policy -n <policy_namespace>

      输出示例

      NAME                          REMEDIATION ACTION   COMPLIANCE STATE     AGE
common-subscriptions-policy   inform               NonCompliant         27d

    2. 运行以下命令，在 ClusterGroupUpgrade CR 中启用预缓存： 

      $ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-operator-upgrade \
--patch '{"spec":{"preCaching": true}}' --type=merge

    3. 监控进程并等待预缓存完成。在受管集群中运行以下命令来检查预缓存的状态： 

      $ oc get cgu cgu-operator-upgrade -o jsonpath='{.status.precaching.status}'

    4. 运行以下命令，检查预缓存是否在启动更新前完成： 

      $ oc get cgu -n default cgu-operator-upgrade -ojsonpath='{.status.conditions}' | jq

      输出示例

      [
    {
      "lastTransitionTime": "2022-03-08T20:49:08.000Z",
      "message": "The ClusterGroupUpgrade CR is not enabled",
      "reason": "UpgradeNotStarted",
      "status": "False",
      "type": "Ready"
    },
    {
      "lastTransitionTime": "2022-03-08T20:55:30.000Z",
      "message": "Precaching is completed",
      "reason": "PrecachingCompleted",
      "status": "True",
      "type": "PrecachingDone"
    }
]

  5. 启动 Operator 更新。

    1. 运行以下命令，启用 cgu-operator-upgrade ClusterGroupUpgrade CR，并禁用预缓存来启动 Operator 更新： 

      $ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-operator-upgrade \
--patch '{"spec":{"enable":true, "preCaching": false}}' --type=merge

    2. 监控进程。在完成后，运行以下命令来确保策略兼容： 

      $ oc get policies --all-namespaces

其他资源

19.10.1.4. 一起执行平台和 Operator 更新

您可以同时执行平台和 Operator 更新。

先决条件

  • 安装 Topology Aware Lifecycle Manager(TALM)。
  • 将 ZTP 更新至最新版本。
  • 使用 ZTP 置备一个或多个受管集群。
  • 以具有 cluster-admin 特权的用户身份登录。
  • 在 hub 集群中创建 RHACM 策略。

流程

  1. 按照 "forming a platform update" 和 "Performing an Operator update" 部分所述的步骤为更新创建 PolicyGenTemplate CR。

  2. 为平台和 Operator 更新应用准备工作。

    1. 使用平台更新准备工作、目录源更新和目标集群的 ClusterGroupUpgrade CR 将内容保存到 cgu-platform-operator-upgrade-prep.yml 文件中，例如： 

      apiVersion: ran.openshift.io/v1alpha1
kind: ClusterGroupUpgrade
metadata:
  name: cgu-platform-operator-upgrade-prep
  namespace: default
spec:
  managedPolicies:
  - du-upgrade-platform-upgrade-prep
  - du-upgrade-operator-catsrc-policy
  clusterSelector:
  - group-du-sno
  remediationStrategy:
    maxConcurrency: 10
  enable: true

    2. 运行以下命令，将 cgu-platform-operator-upgrade-prep.yml 文件应用到 hub 集群： 

      $ oc apply -f cgu-platform-operator-upgrade-prep.yml

    3. 监控进程。在完成后，运行以下命令来确保策略兼容： 

      $ oc get policies --all-namespaces

  3. 为平台创建 ClusterGroupUpdate CR，并将 spec.enable 字段设置为 false 的 Operator 更新。

    1. 将平台的内容和带有策略和目标集群的 Operator 更新 ClusterGroupUpdate CR 保存为 cgu-platform-operator-upgrade.yml 文件，如下例所示： 

      apiVersion: ran.openshift.io/v1alpha1
kind: ClusterGroupUpgrade
metadata:
  name: cgu-du-upgrade
  namespace: default
spec:
  managedPolicies:
  - du-upgrade-platform-upgrade 1
  - du-upgrade-operator-catsrc-policy 2
  - common-subscriptions-policy 3
  preCaching: true
  clusterSelector:
  - group-du-sno
  remediationStrategy:
    maxConcurrency: 1
  enable: false
      1
      这是平台更新策略。
      2
      这是包含要更新 Operator 的目录源信息的策略。预缓存功能需要它来确定要下载至受管集群的 Operator 镜像。
      3
      这是更新 Operator 的策略。

    2. 运行以下命令，将 cgu-platform-operator-upgrade.yml 文件应用到 hub 集群： 

      $ oc apply -f cgu-platform-operator-upgrade.yml

  4. 可选：为平台和 Operator 更新缓存镜像。

    1. 运行以下命令，在 ClusterGroupUpgrade CR 中启用预缓存： 

      $ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-du-upgrade \
--patch '{"spec":{"preCaching": true}}' --type=merge

    2. 监控更新过程，并等待预缓存完成。在受管集群中运行以下命令来检查预缓存的状态： 

      $ oc get jobs,pods -n openshift-talm-pre-cache

    3. 运行以下命令，检查预缓存是否在启动更新前完成： 

      $ oc get cgu cgu-du-upgrade -ojsonpath='{.status.conditions}'

  5. 启动平台和 Operator 更新。

    1. 运行以下命令，启用 cgu-du-upgrade ClusterGroupUpgrade CR 来启动平台和 Operator 更新： 

      $ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-du-upgrade \
--patch '{"spec":{"enable":true, "preCaching": false}}' --type=merge

    2. 监控进程。在完成后，运行以下命令来确保策略兼容： 

      $ oc get policies --all-namespaces
      注意

      可通过将设置配置为 spec.enable: true，从开始创建平台和 Operator 更新 CR。在这种情况下，更新会在预缓存完成后立即启动，且不需要手动启用 CR。

      预缓存和更新都创建额外的资源，如策略、放置规则、放置规则、受管集群操作和受管集群视图，以帮助完成这个过程。将 afterCompletion.deleteObjects 字段设置为 true 在更新完成后删除所有这些资源。

19.10.1.5. 从部署的集群中删除 Performance Addon Operator 订阅

在早期版本的 OpenShift Container Platform 中，Performance Addon Operator 为应用程序提供了自动、低延迟的性能调整。在 OpenShift Container Platform 4.11 或更高版本中，这些功能是 Node Tuning Operator 的一部分。

不要在运行 OpenShift Container Platform 4.11 或更高版本的集群中安装 Performance Addon Operator。如果您升级到 OpenShift Container Platform 4.11 或更高版本，Node Tuning Operator 会自动删除 Performance Addon Operator。

注意

您需要删除创建 Performance Addon Operator 订阅的任何策略，以防止重新安装 Operator。

参考 DU 配置集在 PolicyGenTemplate CR common-ranGen.yaml 中包含 Performance Addon Operator。要从部署的受管集群中删除订阅，您必须更新 common-ranGen.yaml。

注意

如果在 OpenShift Container Platform 4.11 或更高版本上安装 Performance Addon Operator 4.10.3-5 或更高版本，Performance Addon Operator 会检测到集群版本并自动休眠，以避免与 Node Tuning Operator 正常工作。但是，为了确保获得最佳性能，请从 OpenShift Container Platform 4.11 集群中删除 Performance Addon Operator。

先决条件

  • 创建一个 Git 存储库，在其中管理自定义站点配置数据。存储库必须可从 hub 集群访问，并定义为 Argo CD 的源存储库。
  • 更新至 OpenShift Container Platform 4.11 或更高版本。
  • 以具有 cluster-admin 特权的用户身份登录。

流程

  1. 在 common-ranGen.yaml 文件中，为 Performance Addon Operator 命名空间、Operator 组和订阅的 complianceType 更改为 mustnothave。 

     -  fileName: PaoSubscriptionNS.yaml
    policyName: "subscriptions-policy"
    complianceType: mustnothave
 -  fileName: PaoSubscriptionOperGroup.yaml
    policyName: "subscriptions-policy"
    complianceType: mustnothave
 -  fileName: PaoSubscription.yaml
    policyName: "subscriptions-policy"
    complianceType: mustnothave
  2. 将更改与自定义站点存储库合并，并等待 ArgoCD 应用程序对 hub 集群同步更改。common-subscriptions-policy 策略的状态更改为 Non-Compliant。
  3. 使用 Topology Aware Lifecycle Manager 将更改应用到您的目标集群。有关滚动配置更改的更多信息，请参阅“附加资源”部分。

  4. 监控进程。当目标集群的 common-subscriptions-policy 策略的状态为 Compliant 时，Performance Addon Operator 已从集群中移除。运行以下命令，获取 common-subscriptions-policy 的状态： 

    $ oc get policy -n ztp-common common-subscriptions-policy
  5. 从 common-ranGen.yaml 文件中的 .spec.sourceFiles 中删除 Performance Addon Operator 命名空间、Operator 组和订阅 CR。
  6. 将更改与自定义站点存储库合并，并等待 ArgoCD 应用程序对 hub 集群同步更改。策略保持合规。

19.10.2. 关于为 ZTP 自动创建的 ClusterGroupUpgrade CR

TALM 有一个名为 ManagedClusterForCGU 的控制器，它监控 hub 集群上的 ManagedCluster CR 的 Ready 状态，并为 ZTP 创建 ClusterGroupUpgrade CR（零接触置备）。

对于没有应用 "ztp-done" 标签的 Ready 状态中的任何受管集群，ManagedClusterForCGU 控制器会在 ztp-install 命名空间中创建一个带有在 ZTP 进程中创建的关联 RHACM 策略的 ClusterGroupUpgrade CR。然后，TALM 会修复自动创建 ClusterGroupUpgrade CR 中列出的一组配置策略，将配置 CR 推送到受管集群。

注意

如果集群在集群变为 Ready 时没有绑定策略，则不会创建 ClusterGroupUpgrade CR。

ZTP 自动创建的 ClusterGroupUpgrade CR 示例

apiVersion: ran.openshift.io/v1alpha1
kind: ClusterGroupUpgrade
metadata:
  generation: 1
  name: spoke1
  namespace: ztp-install
  ownerReferences:
  - apiVersion: cluster.open-cluster-management.io/v1
    blockOwnerDeletion: true
    controller: true
    kind: ManagedCluster
    name: spoke1
    uid: 98fdb9b2-51ee-4ee7-8f57-a84f7f35b9d5
  resourceVersion: "46666836"
  uid: b8be9cd2-764f-4a62-87d6-6b767852c7da
spec:
  actions:
    afterCompletion:
      addClusterLabels:
        ztp-done: "" 1
      deleteClusterLabels:
        ztp-running: ""
      deleteObjects: true
    beforeEnable:
      addClusterLabels:
        ztp-running: "" 2
  clusters:
  - spoke1
  enable: true
  managedPolicies:
  - common-spoke1-config-policy
  - common-spoke1-subscriptions-policy
  - group-spoke1-config-policy
  - spoke1-config-policy
  - group-spoke1-validator-du-policy
  preCaching: false
  remediationStrategy:
    maxConcurrency: 1
    timeout: 240

1
当 TALM 完成集群配置时，应用到受管集群。
2
当 TALM 开始部署配置策略时，应用到受管集群。

19.11. 更新 GitOps ZTP

您可以独立于 hub 集群、Red Hat Advanced Cluster Management (RHACM) 和受管 OpenShift Container Platform 集群更新 Gitops 零接触置备 (ZTP) 基础架构。

注意

当新版本可用时，您可以更新 Red Hat OpenShift GitOps Operator。更新 GitOps ZTP 插件时，请查看参考配置中的更新文件，并确保更改满足您的要求。

19.11.1. GitOps ZTP 更新过程概述

您可以为运行较早版本的 GitOps ZTP 集群更新 GitOps 零接触置备 (ZTP)。更新过程可避免对受管集群的影响。

注意

对策略设置的任何更改（包括添加推荐内容）都会生成要应用到受管集群并协调的更新策略。

在高级别上，更新 GitOps ZTP 基础架构的策略如下：

  1. 使用 ztp-done 标签标记所有现有集群。
  2. 停止 ArgoCD 应用程序。
  3. 安装新的 GitOps ZTP 工具。
  4. 更新 Git 存储库中的所需内容和可选更改。
  5. 更新并重启应用程序配置。

19.11.2. 准备升级

使用以下步骤为 GitOps 零接触置备(ZTP)升级准备您的站点。

流程

  1. 获取具有用于配置 Red Hat OpenShift GitOps 的自定义资源 (CR) 的 GitOps ZTP 容器的最新版本，以用于 GitOps ZTP。

  2. 使用以下命令提取 argocd/deployment 目录： 

    $ mkdir -p ./update
    $ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v{product-version} extract /home/ztp --tar | tar x -C ./update

    /update 目录包含以下子目录：

    • update/extra-manifest: 包含 SiteConfig CR 用来生成额外清单 configMap 的源 CR 文件。
    • update/source-crs ：包含 PolicyGenTemplate CR 用于生成 Red Hat Advanced Cluster Management(RHACM)策略的源 CR 文件。
    • update/argocd/deployment: 包含要在 hub 集群上应用的补丁和 YAML 文件，以便在此过程的下一步中使用。
    • update/argocd/example 包含代表推荐的配置的 siteConfig 和 PolicyGenTemplate 文件的示例。

  3. 更新 cluster-app.yaml 和 policies-app.yaml 文件，以反映应用程序的名称以及 Git 仓库的 URL、分支和路径。

    如果升级包含导致过时的策略的更改，则应该在执行升级前删除过时的策略。

  4. 在 /update 文件夹和 Git 仓库（您管理团队站点 CR）中的配置和部署源 CR 之间的更改进行 diff 操作。应用所需的更改并将其推送到您的站点存储库。

    重要

    当您将 GitOps ZTP 更新至最新版本时，您必须将 update/argocd/deployment 目录中的更改应用到您的站点存储库。不要使用旧版本的 argocd/deployment/ 文件。

19.11.3. 标记现有集群

为确保现有集群由工具更新保持不变，请使用 ztp-done 标签标记所有现有的受管集群。

注意

此流程仅在更新没有使用 Topology Aware Lifecycle Manager (TALM) 置备的集群时应用。使用 TALM 置备的集群会使用 ztp-done 自动标记。

流程

  1. 找到列出使用零接触置备(ZTP)部署的受管集群的标签选择器，如 local-cluster!=true ： 

    $ oc get managedcluster -l 'local-cluster!=true'

  2. 确保生成的列表中包含使用 ZTP 部署的所有受管集群，然后使用该选择器添加 ztp-done 标签： 

    $ oc label managedcluster -l 'local-cluster!=true' ztp-done=

19.11.4. 停止现有的 GitOps ZTP 应用程序

删除现有的应用程序可确保在有新版本工具可用前，不会推出对 Git 存储库中现有内容的任何更改。

使用 deployment 目录中的应用文件。如果您为应用程序使用自定义名称，则首先更新这些文件中的名称。

流程

  1. 在 clusters 应用程序上执行非级联删除以保留所有生成的资源： 

    $ oc delete -f update/argocd/deployment/clusters-app.yaml

  2. 在 policies 应用程序上执行级联删除以删除所有之前的策略： 

    $ oc patch -f policies-app.yaml -p '{"metadata": {"finalizers": ["resources-finalizer.argocd.argoproj.io"]}}' --type merge
    $ oc delete -f update/argocd/deployment/policies-app.yaml

19.11.5. 对 Git 存储库进行所需的更改

当将 ztp-site-generate 容器从较早版本的 GitOps ZTP 升级到 v4.10 或更高版本时，Git 仓库的内容需要额外的要求。存储库中的现有内容必须更新，以反映这些更改。

  • 对 PolicyGenTemplate 文件进行必要的更改：

    所有 PolicyGenTemplate 文件都必须在带有 ztp 前缀的命名空间中创建。这样可确保 GitOps 零接触置备(ZTP)应用程序可以管理由 GitOps ZTP 生成的策略 CR，而不与 Red Hat Advanced Cluster Management(RHACM)在内部管理策略冲突。

  • 将 kustomization.yaml 文件添加到存储库中：

    所有 siteConfig 和 PolicyGenTemplate CR 必须包含在其各自目录树下的 kustomization.yaml 文件中。例如： 

    ├── policygentemplates
│   ├── site1-ns.yaml
│   ├── site1.yaml
│   ├── site2-ns.yaml
│   ├── site2.yaml
│   ├── common-ns.yaml
│   ├── common-ranGen.yaml
│   ├── group-du-sno-ranGen-ns.yaml
│   ├── group-du-sno-ranGen.yaml
│   └── kustomization.yaml
└── siteconfig
    ├── site1.yaml
    ├── site2.yaml
    └── kustomization.yaml
    注意

    generator 部分中列出的文件只能包含 site Config 或 PolicyGenTemplate CR。如果现有 YAML 文件包含其他 CR，如 Namespace，则这些其他 CR 必须拉取到单独的文件中，并在 resources 部分列出。

    PolicyGenTemplate kustomization 文件必须包括 generator 部分中的所有 PolicyGenTemplate YAML 文件，以及 resources 部分中的 Namespace CR。例如： 

    apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

generators:
- common-ranGen.yaml
- group-du-sno-ranGen.yaml
- site1.yaml
- site2.yaml

resources:
- common-ns.yaml
- group-du-sno-ranGen-ns.yaml
- site1-ns.yaml
- site2-ns.yaml

    SiteConfig kustomization 文件必须包括 generator 部分中的所有 SiteConfig YAML 文件，以及资源中的任何其他 CR： 

    apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

generators:
- site1.yaml
- site2.yaml

  • 删除 pre-sync.yaml 和 post-sync.yaml 文件。

    在 OpenShift Container Platform 4.10 及更新的版本中，不再需要 pre-sync.yaml 和 post-sync.yaml 文件。update/deployment/kustomization.yaml CR 管理 hub 集群上的策略部署。

    注意

    在 SiteConfig 和 PolicyGenTemplate 树下都有一组 pre-sync.yaml 和 post-sync.yaml 文件。

  • 检查并纳入推荐的更改

    每个发行版本可能会包括对应用到已部署集群的配置进行额外的推荐更改。通常，这些更改由 OpenShift 平台、额外功能或改进对平台的调整带来较低的 CPU 使用。

    查看适用于您网络中的集群类型的参考 SiteConfig 和 PolicyGenTemplate CR。这些示例可在从 GitOps ZTP 容器中提取的 argocd/example 目录中找到。

19.11.6. 安装新的 GitOps ZTP 应用程序

使用提取的 argocd/deployment 目录，并在确保应用程序指向 Git 存储库后应用部署目录的所有内容。应用目录的内容可确保正确配置应用程序的所有必要资源。

流程

  1. 要使用之前提取到 update/argocd/deployment/ 目录中的补丁文件来修补 hub 集群中的 ArgoCD 实例，请输入以下命令： 

    $ oc patch argocd openshift-gitops \
-n openshift-gitops --type=merge \
--patch-file update/argocd/deployment/argocd-openshift-gitops-patch.json

  2. 要应用 argocd/deployment 目录的内容，请输入以下命令： 

    $ oc apply -k update/argocd/deployment

19.11.7. 推出 GitOps ZTP 配置更改

如果因为实现推荐的更改而在升级过程中包括任何配置更改，升级过程会在 hub 集群上生成 Non-Compliant 状态的一组策略 CR。使用 ZTP GitOps v4.10 及之后的版本 ztp-site-generate 容器，这些策略被设置为 inform 模式，且不会为用户在没有额外步骤的情况下推送到受管集群。这样可保证在进行更改时可以管理对集群的破坏性更改，例如在维护窗口期间以及同时更新多少个集群。

要推出更改，请创建一个或多个 ClusterGroupUpgrade CR，如 TALM 文档所述。CR 必须包含您要推送到受管集群的 Non-Compliant 策略列表，以及应包含在更新中的集群的列表或选择器。

其他资源

法律通告

Copyright © 2023 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.