19.13. 使用 GitOps ZTP 扩展单节点 OpenShift 集群

流程

1. 在其中一个 spoke 集群中检查 PTP Operator 的守护进程节点选择器设置：

   $ oc get ptpoperatorconfig/default -n openshift-ptp -ojsonpath='{.spec}' | jq

   PTP Operator 的输出示例

   {"daemonNodeSelector":{"node-role.kubernetes.io/master":""}} 1

   1

   如果节点选择器设置为 master，则 spoke 会使用需要更改的 GitOps ZTP 插件的版本进行部署。

2. 在其中一个 spoke 集群中检查 SR-IOV Operator 的守护进程节点选择器设置：

   $  oc get sriovoperatorconfig/default -n \
   openshift-sriov-network-operator -ojsonpath='{.spec}' | jq

   SR-IOV Operator 的输出示例

   {"configDaemonNodeSelector":{"node-role.kubernetes.io/worker":""},"disableDrain":false,"enableInjector":true,"enableOperatorWebhook":true} 1

   1

   如果节点选择器设置为 master，则 spoke 会使用需要更改的 GitOps ZTP 插件的版本进行部署。

3. 在组策略中，添加以下 complianceType 和 spec 条目：

   spec:
       - fileName: PtpOperatorConfig.yaml
         policyName: "config-policy"
         complianceType: mustonlyhave
         spec:
           daemonNodeSelector:
             node-role.kubernetes.io/worker: ""
       - fileName: SriovOperatorConfig.yaml
         policyName: "config-policy"
         complianceType: mustonlyhave
         spec:
           configDaemonNodeSelector:
             node-role.kubernetes.io/worker: ""

   重要

   更改 daemonNodeSelector 字段会导致临时 PTP 同步丢失和 SR-IOV 连接丢失。

4. 提交 Git 中的更改，然后推送到由 GitOps ZTP ArgoCD 应用程序监控的 Git 存储库。

流程

1. 创建以下策略模板：

   apiVersion: ran.openshift.io/v1
   kind: PolicyGenTemplate
   metadata:
     name: "example-sno-workers"
     namespace: "example-sno"
   spec:
     bindingRules:
       sites: "example-sno" 1
     mcp: "worker" 2
     sourceFiles:
       - fileName: MachineConfigGeneric.yaml 3
         policyName: "config-policy"
         metadata:
           labels:
             machineconfiguration.openshift.io/role: worker
           name: enable-workload-partitioning
         spec:
           config:
             storage:
               files:
               - contents:
                   source: data:text/plain;charset=utf-8;base64,W2NyaW8ucnVudGltZS53b3JrbG9hZHMubWFuYWdlbWVudF0KYWN0aXZhdGlvbl9hbm5vdGF0aW9uID0gInRhcmdldC53b3JrbG9hZC5vcGVuc2hpZnQuaW8vbWFuYWdlbWVudCIKYW5ub3RhdGlvbl9wcmVmaXggPSAicmVzb3VyY2VzLndvcmtsb2FkLm9wZW5zaGlmdC5pbyIKcmVzb3VyY2VzID0geyAiY3B1c2hhcmVzIiA9IDAsICJjcHVzZXQiID0gIjAtMyIgfQo=
                 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,ewogICJtYW5hZ2VtZW50IjogewogICAgImNwdXNldCI6ICIwLTMiCiAgfQp9Cg==
                 mode: 420
                 overwrite: true
                 path: /etc/kubernetes/openshift-workload-pinning
                 user:
                   name: root
       - fileName: PerformanceProfile.yaml
         policyName: "config-policy"
         metadata:
           name: openshift-worker-node-performance-profile
         spec:
           cpu: 4
             isolated: "4-47"
             reserved: "0-3"
           hugepages:
             defaultHugepagesSize: 1G
             pages:
               - size: 1G
                 count: 32
           realTimeKernel:
             enabled: true
       - fileName: TunedPerformancePatch.yaml
         policyName: "config-policy"
         metadata:
           name: performance-patch-worker
         spec:
           profile:
             - name: performance-patch-worker
               data: |
                 [main]
                 summary=Configuration changes profile inherited from performance created tuned
                 include=openshift-node-performance-openshift-worker-node-performance-profile
                 [bootloader]
                 cmdline_crash=nohz_full=4-47 5
                 [sysctl]
                 kernel.timer_migration=1
                 [scheduler]
                 group.ice-ptp=0:f:10:*:ice-ptp.*
                 [service]
                 service.stalld=start,enable
                 service.chronyd=stop,disable
           recommend:
           - profile: performance-patch-worker

   1

   该策略应用于带有此标签的所有集群。

   2

   MCP 字段必须设置为 worker。

   3

   此通用 MachineConfig CR 用于在 worker 节点上配置工作负载分区。

   4

   必须为每个特定的硬件平台配置 cpu.isolated 和 cpu.reserved 字段。

   5

   cmdline_crash CPU 集必须与 PerformanceProfile 部分中设置的 cpu.isolated 匹配。

   通用 MachineConfig CR 用于在 worker 节点上配置工作负载分区。您可以生成 crio 和 kubelet 配置文件的内容。

2. 将创建的策略模板添加到由 ArgoCD policies 应用程序监控的 Git 存储库中。
3. 在 kustomization.yaml 文件中添加策略。
4. 提交 Git 中的更改，然后推送到由 GitOps ZTP ArgoCD 应用程序监控的 Git 存储库。

5. 要将新策略修复到 spoke 集群，请创建一个 TALM 自定义资源：

   $ cat <<EOF | oc apply -f -
   apiVersion: ran.openshift.io/v1alpha1
   kind: ClusterGroupUpgrade
   metadata:
     name: example-sno-worker-policies
     namespace: default
   spec:
     backup: false
     clusters:
     - example-sno
     enable: true
     managedPolicies:
     - group-du-sno-config-policy
     - example-sno-workers-config-policy
     - example-sno-config-policy
     preCaching: false
     remediationStrategy:
       maxConcurrency: 1
   EOF

流程

1. 如果您使用 example-sno.yaml SiteConfig 清单部署集群，请将新的 worker 节点添加到 spec.clusters['example-sno'].nodes 列表中：

   nodes:
   - hostName: "example-node2.example.com"
     role: "worker"
     bmcAddress: "idrac-virtualmedia+https://[1111:2222:3333:4444::bbbb:1]/redfish/v1/Systems/System.Embedded.1"
     bmcCredentialsName:
       name: "example-node2-bmh-secret"
     bootMACAddress: "AA:BB:CC:DD:EE:11"
     bootMode: "UEFI"
     nodeNetwork:
       interfaces:
         - name: eno1
           macAddress: "AA:BB:CC:DD:EE:11"
       config:
         interfaces:
           - name: eno1
             type: ethernet
             state: up
             macAddress: "AA:BB:CC:DD:EE:11"
             ipv4:
               enabled: false
             ipv6:
               enabled: true
               address:
               - ip: 1111:2222:3333:4444::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

2. 为新主机创建一个 BMC 身份验证 secret，如 SiteConfig 文件的 spec.nodes 部分中的 bmcCredentialsName 字段引用：

   apiVersion: v1
   data:
     password: "password"
     username: "username"
   kind: Secret
   metadata:
     name: "example-node2-bmh-secret"
     namespace: example-sno
   type: Opaque

3. 提交 Git 中的更改，然后推送到由 GitOps ZTP ArgoCD 应用程序监控的 Git 存储库。

   当 ArgoCD cluster 应用程序同步时，由 GitOps ZTP 插件生成的 hub 集群中会出现两个新清单：

   • BareMetalHost

   • NMStateConfig

     重要

     不应为 worker 节点配置 cpuset 字段。worker 节点的工作负载分区会在节点安装完成后通过管理策略添加。