17.9. 使用 PolicyGenTemplate 资源进行高级受管集群配置
您可以使用 PolicyGenTemplate
CR 在受管集群中部署自定义功能。
17.9.1. 为集群部署额外的更改
如果需要在基本 GitOps ZTP 管道配置之外更改集群配置,则有三个选项:
- 在 ZTP 管道完成后应用附加配置
- 当 GitOps ZTP 管道部署完成后,部署的集群就可以用于应用程序工作负载。此时,您可以安装其他 Operator 并应用具体具体要求的配置。确保额外的配置不会影响平台或分配的 CPU 预算的性能。
- 在 ZTP 库中添加内容
- 使用 GitOps ZTP 管道部署的基本源自定义资源 (CR) 可以根据需要使用自定义内容增强。
- 为集群安装创建额外的清单
- 在安装过程中应用额外的清单,并使安装过程更高效。
提供额外的源 CR 或修改现有源 CR 可能会影响 OpenShift Container Platform 的性能或 CPU 配置集。
17.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 的源存储库。
流程
查看基准源 CR 以查找现有内容。您可以通过从零接触置备(ZTP)容器提取,来查看参考
PolicyGenTemplate
CR 中列出的源 CR。创建
/out
文件夹:$ mkdir -p ./out
提取源 CR:
$ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.12.1 extract /home/ztp --tar | tar x -C ./out
查看
./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 中删除。在
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
-
提交 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
。
17.9.3. 在 GitOps ZTP 管道中添加自定义内容
执行以下步骤在 ZTP 管道中添加新内容。
流程
-
在目录中创建一个名为
source-crs
的子目录,其中包含PolicyGenTemplate
自定义资源(CR)的kustomization.yaml
文件。 将自定义 CR 添加到
source-crs
子目录中,如下例所示:example └── policygentemplates ├── dev.yaml ├── kustomization.yaml ├── mec-edge-sno1.yaml ├── sno.yaml └── source-crs 1 ├── PaoCatalogSource.yaml ├── PaoSubscription.yaml ├── custom-crs | ├── apiserver-config.yaml | └── disable-nic-lldp.yaml └── elasticsearch ├── ElasticsearchNS.yaml └── ElasticsearchOperatorGroup.yaml
- 1
source-crs
子目录必须与kustomization.yaml
文件位于同一个目录中。
重要要使用您自己的资源,请确保自定义 CR 名称与 ZTP 容器中提供的默认源 CR 不同。
更新所需的
PolicyGenTemplate
CR,使其包含对source-crs/custom-crs
和source-crs/elasticsearch
目录中添加的内容的引用。例如:apiVersion: ran.openshift.io/v1 kind: PolicyGenTemplate metadata: name: "group-dev" namespace: "ztp-clusters" spec: bindingRules: dev: "true" mcp: "master" sourceFiles: # These policies/CRs come from the internal container Image #Cluster Logging - fileName: ClusterLogNS.yaml remediationAction: inform policyName: "group-dev-cluster-log-ns" - fileName: ClusterLogOperGroup.yaml remediationAction: inform policyName: "group-dev-cluster-log-operator-group" - fileName: ClusterLogSubscription.yaml remediationAction: inform policyName: "group-dev-cluster-log-sub" #Local Storage Operator - fileName: StorageNS.yaml remediationAction: inform policyName: "group-dev-lso-ns" - fileName: StorageOperGroup.yaml remediationAction: inform policyName: "group-dev-lso-operator-group" - fileName: StorageSubscription.yaml remediationAction: inform policyName: "group-dev-lso-sub" #These are custom local polices that come from the source-crs directory in the git repo # Performance Addon Operator - fileName: PaoSubscriptionNS.yaml remediationAction: inform policyName: "group-dev-pao-ns" - fileName: PaoSubscriptionCatalogSource.yaml remediationAction: inform policyName: "group-dev-pao-cat-source" spec: image: <image_URL_here> - fileName: PaoSubscription.yaml remediationAction: inform policyName: "group-dev-pao-sub" #Elasticsearch Operator - fileName: elasticsearch/ElasticsearchNS.yaml 1 remediationAction: inform policyName: "group-dev-elasticsearch-ns" - fileName: elasticsearch/ElasticsearchOperatorGroup.yaml remediationAction: inform policyName: "group-dev-elasticsearch-operator-group" #Custom Resources - fileName: custom-crs/apiserver-config.yaml 2 remediationAction: inform policyName: "group-dev-apiserver-config" - fileName: custom-crs/disable-nic-lldp.yaml remediationAction: inform policyName: "group-dev-disable-nic-lldp"
-
提交 Git 中的
PolicyGenTemplate
更改,然后推送到由 GitOps ZTP Argo CD 策略应用程序监控的 Git 存储库。 更新
ClusterGroupUpgrade
CR,使其包含更改的PolicyGenTemplate
,并将它保存为cgu-test.yaml
。以下示例显示了生成的cgu-test.yaml
文件。apiVersion: ran.openshift.io/v1alpha1 kind: ClusterGroupUpgrade metadata: name: custom-source-cr namespace: ztp-clusters spec: managedPolicies: - group-dev-config-policy enable: true clusters: - cluster1 remediationStrategy: maxConcurrency: 2 timeout: 240
运行以下命令来应用更新的
ClusterGroupUpgrade
CR:$ oc apply -f cgu-test.yaml
验证
运行以下命令检查更新是否成功:
$ oc get cgu -A
输出示例
NAMESPACE NAME AGE STATE DETAILS ztp-clusters custom-source-cr 6s InProgress Remediating non-compliant policies ztp-install cluster1 19h Completed All clusters are compliant with all the managed policies
17.9.4. 为 PolicyGenTemplate CR 配置策略合规性评估超时
使用在 hub 集群上安装的 Red Hat Advanced Cluster Management (RHACM) 来监控和报告您的受管集群是否合规。RHACM 使用策略模板来应用预定义的策略控制器和策略。策略控制器是 Kubernetes 自定义资源定义(CRD)实例。
您可以使用 PolicyGenTemplate
自定义资源 (CR) 覆盖默认策略评估间隔。您可以配置持续时间设置,以定义 ConfigurationPolicy
CR 在 RHACM 重新评估集群策略前处于策略合规或不合规的时长。
零接触置备 (ZTP) 策略生成器使用预定义的策略评估间隔生成 ConfigurationPolicy
CR 策略。noncompliant
状态的默认值为 10 秒。compliant
状态的默认值为 10 分钟。要禁用评估间隔,将值设为 never
。
先决条件
-
已安装 OpenShift CLI(
oc
)。 -
已以具有
cluster-admin
权限的用户身份登录到 hub 集群。 - 您已创建了管理自定义站点配置数据的 Git 存储库。
流程
要为
PolicyGenTemplate
CR 中的所有策略配置评估间隔,请将evaluationInterval
添加到spec
字段中,然后设置适当的compliant
和noncompliant
的值。例如:spec: evaluationInterval: compliant: 30m noncompliant: 20s
要在
PolicyGenTemplate
CR 中为spec.sourceFiles
对象配置评估间隔,请将evaluationInterval
添加到sourceFiles
字段中,例如:spec: sourceFiles: - fileName: SriovSubscription.yaml policyName: "sriov-sub-policy" evaluationInterval: compliant: never noncompliant: 10s
-
在 Git 存储库中提交
PolicyGenTemplate
CR 文件并推送您的更改。
验证
检查管理的 spoke 集群策略是否以预期间隔监控。
-
在受管集群中以具有
cluster-admin
权限的用户身份登录。 获取在
open-cluster-management-agent-addon
命名空间中运行的 pod。运行以下命令:$ oc get pods -n open-cluster-management-agent-addon
输出示例
NAME READY STATUS RESTARTS AGE config-policy-controller-858b894c68-v4xdb 1/1 Running 22 (5d8h ago) 10d
检查应用的策略是以
config-policy-controller
pod 的日志中预期间隔评估:$ oc logs -n open-cluster-management-agent-addon config-policy-controller-858b894c68-v4xdb
输出示例
2022-05-10T15:10:25.280Z info configuration-policy-controller controllers/configurationpolicy_controller.go:166 Skipping the policy evaluation due to the policy not reaching the evaluation interval {"policy": "compute-1-config-policy-config"} 2022-05-10T15:10:25.280Z info configuration-policy-controller controllers/configurationpolicy_controller.go:166 Skipping the policy evaluation due to the policy not reaching the evaluation interval {"policy": "compute-1-common-compute-1-catalog-policy-config"}
17.9.5. 使用验证器通知策略信号 ZTP 集群部署完成
创建一个验证器通知策略,在零接触置备(ZTP)安装和配置完成部署集群时信号。此策略可用于部署单节点 OpenShift 集群、三节点集群和标准集群。
流程
创建包含源文件
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
。
-
在 Git 存储库中提交
PolicyGenTemplate
CR 文件并推送更改。
17.9.6. 使用 PolicyGenTemplate CR 配置 PTP 事件
您可以使用 GitOps ZTP 管道来配置使用 HTTP 或 AMQP 传输的 PTP 事件。
HTTP 传输是 PTP 和裸机事件的默认传输。在可能的情况下,使用 HTTP 传输而不是 AMQP 用于 PTP 和裸机事件。AMQ Interconnect 于 2024 年 6 月 30 日结束生命周期(EOL)。AMQ Interconnect 的延长生命周期支持 (ELS) 于 2029 年 11 月 29 日结束。如需更多信息,请参阅 Red Hat AMQ Interconnect 支持状态。
17.9.6.1. 配置使用 HTTP 传输的 PTP 事件
您可以配置使用 GitOps Zero Touch Provisioning (ZTP)管道部署的受管集群中使用 HTTP 传输的 PTP 事件。
先决条件
-
已安装 OpenShift CLI(
oc
)。 -
您已以具有
cluster-admin
权限的用户身份登录。 - 您已创建了管理自定义站点配置数据的 Git 存储库。
流程
根据您的具体要求,将以下
PolicyGenTemplate
应用到group-du-3node-ranGen.yaml
、group-du-sno-ranGen.yaml
或group-du-standard-ranGen.yaml
文件:在
.sourceFiles
中,添加PtpOperatorConfig
CR 文件来配置传输主机:- fileName: PtpOperatorConfigForEvent.yaml policyName: "config-policy" spec: daemonNodeSelector: {} ptpEventConfig: enableEventPublisher: true transportHost: http://ptp-event-publisher-service-NODE_NAME.openshift-ptp.svc.cluster.local:9043
注意在 OpenShift Container Platform 4.12 或更高版本中,在使用带有 PTP 事件的 HTTP 传输时,您不需要在
PtpOperatorConfig
资源中设置transportHost
字段。为 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
。
- 将任何其他必要的更改和文件与自定义站点存储库合并。
- 将更改推送到站点配置存储库,以使用 GitOps ZTP 将 PTP 快速事件部署到新站点。
17.9.6.2. 配置使用 AMQP 传输的 PTP 事件
您可以在使用 GitOps Zero Touch Provisioning (ZTP) 管道部署的受管集群中配置使用 AMQP 传输的 PTP 事件。
HTTP 传输是 PTP 和裸机事件的默认传输。在可能的情况下,使用 HTTP 传输而不是 AMQP 用于 PTP 和裸机事件。AMQ Interconnect 于 2024 年 6 月 30 日结束生命周期(EOL)。AMQ Interconnect 的延长生命周期支持 (ELS) 于 2029 年 11 月 29 日结束。如需更多信息,请参阅 Red Hat AMQ Interconnect 支持状态。
先决条件
-
已安装 OpenShift CLI(
oc
)。 -
您已以具有
cluster-admin
权限的用户身份登录。 - 您已创建了管理自定义站点配置数据的 Git 存储库。
流程
将以下 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"
根据您的具体要求,将以下
PolicyGenTemplate
应用到group-du-3node-ranGen.yaml
、group-du-sno-ranGen.yaml
或group-du-standard-ranGen.yaml
文件:在
.sourceFiles
中,添加PtpOperatorConfig
CR 文件,该文件将 AMQ 传输主机配置为config-policy
:- fileName: PtpOperatorConfigForEvent.yaml policyName: "config-policy" spec: daemonNodeSelector: {} ptpEventConfig: enableEventPublisher: true transportHost: "amqp://amq-router.amq-router.svc.cluster.local"
为 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
。
将以下
PolicyGenTemplate
更改应用到您的特定站点 YAML 文件,如example-sno-site.yaml
:在
.sourceFiles
中,添加Interconnect
CR 文件,该文件将 AMQ 路由器配置为config-policy
:- fileName: AmqInstance.yaml policyName: "config-policy"
- 将任何其他必要的更改和文件与自定义站点存储库合并。
- 将更改推送到站点配置存储库,以使用 GitOps ZTP 将 PTP 快速事件部署到新站点。
其他资源
17.9.7. 使用 PolicyGenTemplate CR 配置裸机事件
您可以使用 GitOps ZTP 管道来配置使用 HTTP 或 AMQP 传输的裸机事件。
HTTP 传输是 PTP 和裸机事件的默认传输。在可能的情况下,使用 HTTP 传输而不是 AMQP 用于 PTP 和裸机事件。AMQ Interconnect 于 2024 年 6 月 30 日结束生命周期(EOL)。AMQ Interconnect 的延长生命周期支持 (ELS) 于 2029 年 11 月 29 日结束。如需更多信息,请参阅 Red Hat AMQ Interconnect 支持状态。
17.9.7.1. 配置使用 HTTP 传输的裸机事件
您可以配置使用 GitOps Zero Touch Provisioning (ZTP)管道部署的受管集群中使用 HTTP 传输的裸机事件。
先决条件
-
已安装 OpenShift CLI(
oc
)。 -
您已以具有
cluster-admin
权限的用户身份登录。 - 您已创建了管理自定义站点配置数据的 Git 存储库。
流程
通过在
common-ranGen.yaml
文件中的spec.sourceFiles
中添加以下 YAML 来配置 Bare Metal Event Relay Operator:# Bare Metal Event Relay operator - fileName: BareMetalEventRelaySubscriptionNS.yaml policyName: "subscriptions-policy" - fileName: BareMetalEventRelaySubscriptionOperGroup.yaml policyName: "subscriptions-policy" - fileName: BareMetalEventRelaySubscription.yaml policyName: "subscriptions-policy"
将
HardwareEvent
CR 添加到特定组配置文件中的spec.sourceFiles
,例如在group-du-sno-ranGen.yaml
文件中:- fileName: HardwareEvent.yaml 1 policyName: "config-policy" spec: nodeSelector: {} transportHost: "http://hw-event-publisher-service.openshift-bare-metal-events.svc.cluster.local:9043" logLevel: "info"
- 1
- 每个基板管理控制器 (BMC) 只需要一个
HardwareEvent
CR。
注意在 OpenShift Container Platform 4.12 或更高版本中,当将 HTTP 传输用于裸机事件时,您不需要在
HardwareEvent
自定义资源 (CR) 中设置transportHost
字段。- 将任何其他必要的更改和文件与自定义站点存储库合并。
- 将更改推送到站点配置存储库,以使用 GitOps ZTP 将裸机事件部署到新站点。
运行以下命令来创建 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>"
17.9.7.2. 配置使用 AMQP 传输的裸机事件
您可以在使用 GitOps Zero Touch Provisioning (ZTP) 管道部署的受管集群中配置使用 AMQP 传输的裸机事件。
HTTP 传输是 PTP 和裸机事件的默认传输。在可能的情况下,使用 HTTP 传输而不是 AMQP 用于 PTP 和裸机事件。AMQ Interconnect 于 2024 年 6 月 30 日结束生命周期(EOL)。AMQ Interconnect 的延长生命周期支持 (ELS) 于 2029 年 11 月 29 日结束。如需更多信息,请参阅 Red Hat AMQ Interconnect 支持状态。
先决条件
-
已安装 OpenShift CLI(
oc
)。 -
您已以具有
cluster-admin
权限的用户身份登录。 - 您已创建了管理自定义站点配置数据的 Git 存储库。
流程
要配置 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"
将
Interconnect
CR 添加到站点配置文件中的.spec.sourceFiles
中,例如example-sno-site.yaml
文件:- fileName: AmqInstance.yaml policyName: "config-policy"
将
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 Interconnectname
和namespace
都被设置为amq-router
。
注意每个基板管理控制器 (BMC) 仅需要一个
HardwareEvent
资源。-
在 Git 中提交
PolicyGenTemplate
更改,然后将更改推送到您的站点配置存储库,以使用 GitOps ZTP 将裸机事件监控部署到新站点。 运行以下命令来创建 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>"
17.9.8. 配置 Image Registry Operator 以进行镜像的本地缓存
OpenShift Container Platform 使用本地 registry 管理镜像缓存。在边缘计算用例中,集群通常会受到带宽限制,与集中式镜像 registry 通信时,这可能会导致长时间镜像下载时间。
在初始部署期间,长时间下载时间不可避免。随着时间的推移,CRI-O 会在出现意外关闭时擦除 /var/lib/containers/storage
目录的风险。要解决长镜像下载时间,您可以使用 GitOps ZTP 在远程受管集群上创建本地镜像 registry。当集群部署在网络边缘时,这非常有用。
在使用 GitOps ZTP 设置本地镜像 registry 前,您需要在用于安装远程受管集群的 SiteConfig
CR 中配置磁盘分区。安装后,您可以使用 PolicyGenTemplate
CR 配置本地镜像 registry。然后,ZTP 管道创建持久性卷 (PV) 和持久性卷声明 (PVC) CR,并修补 imageregistry
配置。
本地镜像 registry 只能用于用户应用程序镜像,不能用于 OpenShift Container Platform 或 Operator Lifecycle Manager operator 镜像。
17.9.8.1. 使用 SiteConfig 配置磁盘分区
使用 SiteConfig
CR 和 GitOps ZTP 为受管集群配置磁盘分区。SiteConfig
CR 中的磁盘分区详情必须与底层磁盘匹配。
对设备使用持久性命名以避免每次重启时切换 /dev/sda
和 /dev/sdb
等设备名称。您可以使用 rootDeviceHints
选择可引导设备,然后使用同一设备进行进一步分区。
先决条件
-
已安装 OpenShift CLI(
oc
)。 -
已以具有
cluster-admin
权限的用户身份登录到 hub 集群。 - 您已创建了 Git 存储库,在其中管理自定义站点配置数据以用于 GitOps Zero Touch Provisioning (ZTP)。
流程
将以下 YAML 添加至用于安装受管集群的
SiteConfig
CR 中描述主机磁盘分区:nodes: rootDeviceHints: wwn: "0x62cea7f05c98c2002708a0a22ff480ea" diskPartition: - device: /dev/disk/by-id/wwn-0x62cea7f05c98c2002708a0a22ff480ea 1 partitions: - mount_point: /var/imageregistry size: 102500 2 start: 344844 3
-
保存
SiteConfig
CR 并将其推送到站点配置存储库。
ZTP 管道使用 SiteConfig
CR 置备集群并配置磁盘分区。
17.9.8.2. 使用 PolicyGenTemplate CR 配置镜像 registry
使用 PolicyGenTemplate
(PGT) CR 应用配置镜像 registry 所需的 CR 并对 imageregistry
配置进行补丁。
先决条件
- 您已在受管集群中配置了磁盘分区。
-
已安装 OpenShift CLI(
oc
)。 -
已以具有
cluster-admin
权限的用户身份登录到 hub 集群。 - 您已创建了 Git 存储库,在其中管理自定义站点配置数据以用于 GitOps Zero Touch Provisioning (ZTP)。
流程
在适当的
PolicyGenTemplate
CR 中配置存储类、持久性卷声明、持久性卷和镜像 registry 配置。例如,要配置单个站点,请将以下 YAML 添加到文件example-sno-site.yaml
中:sourceFiles: # storage class - fileName: StorageClass.yaml policyName: "sc-for-image-registry" metadata: name: image-registry-sc annotations: ran.openshift.io/ztp-deploy-wave: "100" 1 # persistent volume claim - fileName: StoragePVC.yaml policyName: "pvc-for-image-registry" metadata: name: image-registry-pvc namespace: openshift-image-registry annotations: ran.openshift.io/ztp-deploy-wave: "100" spec: accessModes: - ReadWriteMany resources: requests: storage: 100Gi storageClassName: image-registry-sc volumeMode: Filesystem # persistent volume - fileName: ImageRegistryPV.yaml 2 policyName: "pv-for-image-registry" metadata: annotations: ran.openshift.io/ztp-deploy-wave: "100" - fileName: ImageRegistryConfig.yaml policyName: "config-for-image-registry" complianceType: musthave metadata: annotations: ran.openshift.io/ztp-deploy-wave: "100" spec: storage: pvc: claim: "image-registry-pvc"
重要不要为
- fileName: ImageRegistryConfig.yaml
配置设置complianceType: mustonlyhave
。这可能导致 registry pod 部署失败。-
提交 Git 中的
PolicyGenTemplate
更改,然后推送到由 GitOps ZTP Argo CD 应用程序监控的 Git 存储库。
验证
使用以下步骤排除受管集群中本地镜像 registry 的错误:
在登录到受管集群时,验证是否成功登录到 registry。运行以下命令:
导出受管集群名称:
$ cluster=<managed_cluster_name>
获取受管集群
kubeconfig
详情:$ oc get secret -n $cluster $cluster-admin-password -o jsonpath='{.data.password}' | base64 -d > kubeadmin-password-$cluster
下载并导出集群
kubeconfig
:$ oc get secret -n $cluster $cluster-admin-kubeconfig -o jsonpath='{.data.kubeconfig}' | base64 -d > kubeconfig-$cluster && export KUBECONFIG=./kubeconfig-$cluster
- 验证从受管集群访问镜像 registry。请参阅"访问 registry"。
检查
imageregistry.operator.openshift.io
组实例的Config
CRD 是否没有报告错误。登录到受管集群时运行以下命令:$ oc get image.config.openshift.io cluster -o yaml
输出示例
apiVersion: config.openshift.io/v1 kind: Image metadata: annotations: include.release.openshift.io/ibm-cloud-managed: "true" include.release.openshift.io/self-managed-high-availability: "true" include.release.openshift.io/single-node-developer: "true" release.openshift.io/create-only: "true" creationTimestamp: "2021-10-08T19:02:39Z" generation: 5 name: cluster resourceVersion: "688678648" uid: 0406521b-39c0-4cda-ba75-873697da75a4 spec: additionalTrustedCA: name: acm-ice
检查受管集群上的
PersistentVolumeClaim
是否填充了数据。登录到受管集群时运行以下命令:$ oc get pv image-registry-sc
检查
registry*
pod 是否正在运行,并位于openshift-image-registry
命名空间下。$ oc get pods -n openshift-image-registry | grep registry*
输出示例
cluster-image-registry-operator-68f5c9c589-42cfg 1/1 Running 0 8d image-registry-5f8987879-6nx6h 1/1 Running 0 8d
检查受管集群中的磁盘分区是否正确:
为受管集群打开默认 shell:
$ oc debug node/sno-1.example.com
运行
lsblk
以检查主机磁盘分区:sh-4.4# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 446.6G 0 disk |-sda1 8:1 0 1M 0 part |-sda2 8:2 0 127M 0 part |-sda3 8:3 0 384M 0 part /boot |-sda4 8:4 0 336.3G 0 part /sysroot `-sda5 8:5 0 100.1G 0 part /var/imageregistry 1 sdb 8:16 0 446.6G 0 disk sr0 11:0 1 104M 0 rom
- 1
/var/imageregistry
表示磁盘已被正确分区。
其他资源
17.9.9. 在 PolicyGenTemplate CR 中使用 hub 模板
Topology Aware Lifecycle Manager 支持在 GitOps ZTP 的配置策略中支持部分 Red Hat Advanced Cluster Management (RHACM) hub 集群模板功能。
hub-side 集群模板允许您定义可动态自定义到目标集群的配置策略。这可减少为具有辅助配置但具有不同值的很多集群创建单独的策略的需求。
策略模板仅限于与定义策略的命名空间相同的命名空间。这意味着,您必须在创建策略的同一命名空间中创建 hub 模板中引用的对象。
以下支持的 hub 模板功能可用于 TALM 的 GitOps ZTP:
fromConfigmap
返回命名的ConfigMap
资源中提供的 data 键的值。注意ConfigMap
CR 有一个 1 MiB 大小限制。ConfigMap
CR 的有效大小被last-applied-configuration
注解进一步限制。要避免last-applied-configuration
限制,请在模板ConfigMap
中添加以下注解:argocd.argoproj.io/sync-options: Replace=true
-
base64enc
返回输入字符串的 base64 编码值 -
base64dec
返回 base64 编码的输入字符串的解码值 -
indent
返回输入字符串,并带有添加的缩进空格 -
autoindent
返回输入字符串,并根据父模板中使用的空间添加空格 -
toInt
casts 并返回输入值的整数值 -
toBool
将输入字符串转换为布尔值,并返回布尔值
各种 开源社区功能 也可用于 GitOps ZTP。
17.9.9.1. hub 模板示例
以下代码示例是有效的 hub 模板。每个模板都会从 default
命名空间的 ConfigMap
CR 返回的其名称为 test-config
的值。
使用键
common-key
返回值:{{hub fromConfigMap "default" "test-config" "common-key" hub}}
使用
.ManagedClusterName
字段的串联值和字符串-name
返回一个字符串:{{hub fromConfigMap "default" "test-config" (printf "%s-name" .ManagedClusterName) hub}}
casts 并从
.ManagedClusterName
字段的串联值和字符串-name
返回布尔值:{{hub fromConfigMap "default" "test-config" (printf "%s-name" .ManagedClusterName) | toBool hub}}
casts 并从
.ManagedClusterName
字段的串联值和字符串-name
返回整数值:{{hub (printf "%s-name" .ManagedClusterName) | fromConfigMap "default" "test-config" | toInt hub}}
17.9.9.2. 使用 hub 集群模板在站点 PolicyGenTemplate CR 中指定主机 NIC
您可以在单个 ConfigMap
CR 中管理主机 NIC,并使用 hub 集群模板在应用到集群主机的生成的策略中填充自定义 NIC 值。在站点 PolicyGenTemplate
(PGT) CR 中使用 hub 集群模板意味着您不需要为每个站点创建多个站点 PGT CR。
以下示例演示了如何使用单个 ConfigMap
CR 管理集群主机 NIC,并使用单个 PolicyGenTemplate
站点 CR 作为策略应用到集群。
当您使用 fromConfigmap
功能时,printf
变量仅适用于模板资源 data
键字段。您不能将其与 name
和 namespace
字段一起使用。
先决条件
-
已安装 OpenShift CLI(
oc
)。 -
已以具有
cluster-admin
权限的用户身份登录到 hub 集群。 - 您已创建了管理自定义站点配置数据的 Git 存储库。存储库必须可从 hub 集群访问,并定义为 GitOps ZTP ArgoCD 应用程序的源存储库。
流程
创建描述一组主机的 NIC 的
ConfigMap
资源。例如:apiVersion: v1 kind: ConfigMap metadata: name: sriovdata namespace: ztp-site annotations: argocd.argoproj.io/sync-options: Replace=true 1 data: example-sno-du_fh-numVfs: "8" example-sno-du_fh-pf: ens1f0 example-sno-du_fh-priority: "10" example-sno-du_fh-vlan: "140" example-sno-du_mh-numVfs: "8" example-sno-du_mh-pf: ens3f0 example-sno-du_mh-priority: "10" example-sno-du_mh-vlan: "150"
- 1
- 只有在
ConfigMap
大于 1 MiB 时,才需要argocd.argoproj.io/sync-options
注解。
注意ConfigMap
必须位于同一命名空间中,其策略带有 hub 模板替换的策略。-
在 Git 中提交
ConfigMap
CR,然后推送到由 Argo CD 应用程序监控的 Git 存储库。 创建一个使用模板从
ConfigMap
对象拉取所需数据的 site PGT CR。例如:apiVersion: ran.openshift.io/v1 kind: PolicyGenTemplate metadata: name: "site" namespace: "ztp-site" spec: remediationAction: inform bindingRules: group-du-sno: "" mcp: "master" sourceFiles: - fileName: SriovNetwork.yaml policyName: "config-policy" metadata: name: "sriov-nw-du-fh" spec: resourceName: du_fh vlan: '{{hub fromConfigMap "ztp-site" "sriovdata" (printf "%s-du_fh-vlan" .ManagedClusterName) | toInt hub}}' - fileName: SriovNetworkNodePolicy.yaml policyName: "config-policy" metadata: name: "sriov-nnp-du-fh" spec: deviceType: netdevice isRdma: true nicSelector: pfNames: - '{{hub fromConfigMap "ztp-site" "sriovdata" (printf "%s-du_fh-pf" .ManagedClusterName) | autoindent hub}}' numVfs: '{{hub fromConfigMap "ztp-site" "sriovdata" (printf "%s-du_fh-numVfs" .ManagedClusterName) | toInt hub}}' priority: '{{hub fromConfigMap "ztp-site" "sriovdata" (printf "%s-du_fh-priority" .ManagedClusterName) | toInt hub}}' resourceName: du_fh - fileName: SriovNetwork.yaml policyName: "config-policy" metadata: name: "sriov-nw-du-mh" spec: resourceName: du_mh vlan: '{{hub fromConfigMap "ztp-site" "sriovdata" (printf "%s-du_mh-vlan" .ManagedClusterName) | toInt hub}}' - fileName: SriovNetworkNodePolicy.yaml policyName: "config-policy" metadata: name: "sriov-nnp-du-mh" spec: deviceType: vfio-pci isRdma: false nicSelector: pfNames: - '{{hub fromConfigMap "ztp-site" "sriovdata" (printf "%s-du_mh-pf" .ManagedClusterName) hub}}' numVfs: '{{hub fromConfigMap "ztp-site" "sriovdata" (printf "%s-du_mh-numVfs" .ManagedClusterName) | toInt hub}}' priority: '{{hub fromConfigMap "ztp-site" "sriovdata" (printf "%s-du_mh-priority" .ManagedClusterName) | toInt hub}}' resourceName: du_mh
在 Git 中提交站点
PolicyGenTemplate
CR,并推送到由 ArgoCD 应用程序监控的 Git 存储库。注意对引用的
ConfigMap
CR 的后续更改不会自动同步到应用的策略。您需要手动同步新的ConfigMap
更改来更新现有的 PolicyGenTemplate CR。请参阅 "Syncing new ConfigMap changes to existing PolicyGenTemplate CR"。
17.9.9.3. 使用 hub 集群模板在组 PolicyGenTemplate CR 中指定 VLAN ID
您可以在单个 ConfigMap
CR 中为受管集群管理 VLAN ID,并使用 hub 集群模板在应用到集群的生成的策略中填充 VLAN ID。
以下示例演示了如何在单个 ConfigMap
CR 中管理 VLAN ID,并使用单个 PolicyGenTemplate
组 CR 在单个集群策略中应用它们。
使用 fromConfigmap
功能时,printf
变量仅适用于模板资源 data
键字段。您不能将其与 name
和 namespace
字段一起使用。
先决条件
-
已安装 OpenShift CLI(
oc
)。 -
已以具有
cluster-admin
权限的用户身份登录到 hub 集群。 - 您已创建了管理自定义站点配置数据的 Git 存储库。该存储库必须可从 hub 集群访问,并定义为 Argo CD 应用程序的源仓库。
流程
创建描述一组集群主机的 VLAN ID 的
ConfigMap
CR。例如:apiVersion: v1 kind: ConfigMap metadata: name: site-data namespace: ztp-group annotations: argocd.argoproj.io/sync-options: Replace=true 1 data: site-1-vlan: "101" site-2-vlan: "234"
- 1
- 只有在
ConfigMap
大于 1 MiB 时,才需要argocd.argoproj.io/sync-options
注解。
注意ConfigMap
必须位于同一命名空间中,其策略带有 hub 模板替换的策略。-
在 Git 中提交
ConfigMap
CR,然后推送到由 Argo CD 应用程序监控的 Git 存储库。 创建一个组 PGT CR,它使用 hub 模板从
ConfigMap
对象拉取所需的 VLAN ID。例如,将以下 YAML 片断添加到组 PGT CR 中:- fileName: SriovNetwork.yaml policyName: "config-policy" metadata: name: "sriov-nw-du-mh" annotations: ran.openshift.io/ztp-deploy-wave: "10" spec: resourceName: du_mh vlan: '{{hub fromConfigMap "" "site-data" (printf "%s-vlan" .ManagedClusterName) | toInt hub}}'
在 Git 中提交组
PolicyGenTemplate
CR,然后推送到由 Argo CD 应用程序监控的 Git 存储库。注意对引用的
ConfigMap
CR 的后续更改不会自动同步到应用的策略。您需要手动同步新的ConfigMap
更改来更新现有的 PolicyGenTemplate CR。请参阅 "Syncing new ConfigMap changes to existing PolicyGenTemplate CR"。
17.9.9.4. 将新 ConfigMap 更改同步到现有的 PolicyGenTemplate CR
先决条件
-
已安装 OpenShift CLI(
oc
)。 -
已以具有
cluster-admin
权限的用户身份登录到 hub 集群。 -
您已创建了
PolicyGenTemplate
CR,它使用 hub 集群模板从ConfigMap
CR 中拉取信息。
流程
-
更新
ConfigMap
CR 的内容,并应用 hub 集群中的更改。 要将更新的
ConfigMap
CR 的内容同步到部署的策略中,请执行以下操作之一:选项 1:删除现有策略。ArgoCD 使用
PolicyGenTemplate
CR 立即重新创建已删除的策略。例如,运行以下命令:$ oc delete policy <policy_name> -n <policy_namespace>
选项 2:在每次更新 ConfigMap 时,每次更新
ConfigMap
时,将特殊注解policy.open-cluster-management.io/trigger-update
应用到策略。例如:$ oc annotate policy <policy_name> -n <policy_namespace> policy.open-cluster-management.io/trigger-update="1"
注意您必须应用更新的策略才能使更改生效。如需更多信息,请参阅重新处理的特殊注解。
可选:如果存在,删除包含策略的
ClusterGroupUpdate
CR。例如:$ oc delete clustergroupupgrade <cgu_name> -n <cgu_namespace>
创建新的
ClusterGroupUpdate
CR,其中包含要应用更新的ConfigMap
更改的策略。例如,将以下 YAML 添加到文件cgr-example.yaml
中:apiVersion: ran.openshift.io/v1alpha1 kind: ClusterGroupUpgrade metadata: name: <cgr_name> namespace: <policy_namespace> spec: managedPolicies: - <managed_policy> enable: true clusters: - <managed_cluster_1> - <managed_cluster_2> remediationStrategy: maxConcurrency: 2 timeout: 240
应用更新的策略:
$ oc apply -f cgr-example.yaml