17.4. 使用策略和 PolicyGenTemplate 资源配置受管集群
应用的策略自定义资源 (CR) 配置您置备的受管集群。您可以自定义 Red Hat Advanced Cluster Management (RHACM) 如何使用 PolicyGenTemplate
CR 生成应用的策略 CR。
17.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
部分中列出的标签将策略绑定到集群。
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 .....
17.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 在升级过程中的更改不会更新生成的订阅。
其他资源
- 有关使用 RHACM 扩展集群的建议,请参阅性能和可扩展性。
在 hub 集群中管理大量 spoke 集群时,请最小化策略数量来减少资源消耗。
将多个配置 CR 分组到单个或有限的策略中,一种方法是减少 hub 集群上的总体策略数量。在使用 common/group/site 层次结构来管理站点配置时,务必要将特定于站点的配置组合成单一策略。
17.4.3. RAN 部署的 PolicyGenTemplate CR
使用 PolicyGenTemplate
(PGT) 自定义资源 (CR) 使用 GitOps Zero Touch Provisioning (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)集群提供了特定于站点的配置变体。使用与部署相关的组和特定于站点的配置变体。
PolicyGenTemplate CR | 描述 |
---|---|
| 包含一组应用于多节点集群的 CR。这些 CR 配置 SR-IOV 功能,用于 RAN 安装。 |
| 包含一组应用于单节点 OpenShift 集群的 CR。这些 CR 配置 SR-IOV 功能,用于 RAN 安装。 |
| 包含一组应用于所有集群的通用 RAN CR。这些 CR 订阅一组 operator,提供典型的 RAN 和基准集群调整功能。 |
| 仅包含三节点集群的 RAN 策略。 |
| 仅包含单节点集群的 RAN 策略。 |
| 包含标准三个 control-plane 集群的 RAN 策略。 |
|
|
|
|
|
|
17.4.4. 使用 PolicyGenTemplate CR 自定义受管集群
使用以下步骤自定义应用于使用 GitOps Zero Touch Provisioning (ZTP) 管道置备的受管集群的策略。
先决条件
-
已安装 OpenShift CLI(
oc
)。 -
已以具有
cluster-admin
权限的用户身份登录到 hub 集群。 - 配置了 hub 集群来生成所需的安装和策略 CR。
- 您创建了 Git 存储库,用于管理自定义站点配置数据。该存储库必须可从 hub 集群访问,并定义为 Argo CD 应用程序的源仓库。
流程
为特定于站点的配置 CR 创建
PolicyGenTemplate
CR。-
从
out/argocd/example/policygentemplates
文件夹中选择适当的 CR 示例,例如example-sno-site.yaml
或example-multinode-site.yaml
。 更改示例文件中的
bindingRules
字段,使其与SiteConfig
CR 中包含的特定于站点的标签匹配。在示例SiteConfig
文件中,特定于站点的标签是sites: example-sno
。注意确保
PolicyGenTemplate
bindingRules
字段中定义的标签对应于相关受管集群SiteConfig
CR 中定义的标签。- 更改示例文件中的内容,使其与所需配置匹配。
-
从
可选:为应用到集群的任何通用配置 CR 创建一个
PolicyGenTemplate
CR。-
从
out/argocd/example/policygentemplates
文件夹中选择适合您的 CR 示例,例如common-ranGen.yaml
。 - 更改示例文件中的内容,使其与所需配置匹配。
-
从
可选:为应用到团队中特定集群组的任何组配置 CR 创建一个
PolicyGenTemplate
CR。确保 overlaid spec 文件的内容与您的预期最终状态匹配。作为参考,out/source-crs 目录包含可用于包含并由您的 PolicyGenTemplate 模板提供的 source-crs 的完整列表。
注意根据集群的特定要求,每个集群类型可能需要一个组策略,特别是考虑示例组策略各自有一个 PerformancePolicy.yaml 文件,如果这些集群是由相同的硬件配置,则只能在一组集群中共享。
-
从
out/argocd/example/policygentemplates
文件夹中选择适当的 CR 示例,例如group-du-sno-ranGen.yaml
。 - 更改示例文件中的内容,使其与所需配置匹配。
-
从
-
可选。当 GitOps ZTP 安装和配置完成后,创建验证器通知策略
PolicyGenTemplate
CR。如需更多信息,请参阅"创建验证器通知策略"。 在 YAML 文件中定义所有策略命名空间,类似于示例
out/argocd/example/policygentemplates/ns.yaml
文件。重要不要在带有
PolicyGenTemplate
CR 的同一文件中包括Namespace
CR。-
将
PolicyGenTemplate
CR 和Namespace
CR 添加到 generators 部分中的kustomization.yaml
文件中,类似于out/argocd/example/policygentemplates/kustomization.yaml
所示的示例。 在 Git 存储库中提交
PolicyGenTemplate
CR、Namespace
CR 和关联的kustomization.yaml
文件并推送更改。ArgoCD 管道检测到更改并开始受管集群部署。您可以同时将更改推送到
SiteConfig
CR 和PolicyGenTemplate
CR。
17.4.5. 监控受管集群策略部署进度
ArgoCD 管道使用 Git 中的 PolicyGenTemplate
CR 生成 RHACM 策略,然后将其同步到 hub 集群。您可以在辅助服务在受管集群中安装 OpenShift Container Platform 后监控受管集群策略同步的进度。
先决条件
-
已安装 OpenShift CLI(
oc
)。 -
已以具有
cluster-admin
权限的用户身份登录到 hub 集群。
流程
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": "Remediating non-compliant policies", "reason": "InProgress", "status": "True", "type": "Progressing" }
您可以使用 RHACM 仪表板或命令行监控详细的集群策略合规状态。
要使用
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
要从 RHACM Web 控制台检查策略状态,请执行以下操作:
-
点 Governance
Find policies。 - 点集群策略检查其状态。
-
点 Governance
当所有集群策略都合规时,集群的 GitOps ZTP 安装和配置已完成。ztp-done
标签添加到集群中。
在引用配置中,合规的最终策略是 *-du-validator-policy
策略中定义的。此策略当在一个集群中合规时,确保所有集群配置、Operator 安装和 Operator 配置已完成。
17.4.6. 验证配置策略 CR 的生成
策略自定义资源(CR)在与创建它们的 PolicyGenTemplate
相同的命名空间中生成。同样的故障排除流程适用于从 PolicyGenTemplate
生成的所有策略 CR,无论它们是 ztp-common
、ztp-group
,还是基于 ztp-site
,请使用以下命令:
$ export NS=<namespace>
$ oc get policy -n $NS
应该会显示预期的策略嵌套 CR 集合。
如果策略失败的同步,请使用以下故障排除步骤。
流程
要显示策略的详细信息,请运行以下命令:
$ oc describe -n openshift-gitops application policies
检查
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
检查
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
当 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>
。检查放置规则中是否有没有复制到集群命名空间中的策略。这些策略的
PlacementRule
中的matchSelector
应与ManagedCluster
对象上的标签匹配:$ oc get placementrule -n $NS
使用以下命令,注意适合缺少策略、通用、组或站点的
PlacementRule
名称:$ oc get placementrule -n $NS <placementRuleName> -o yaml
- status-decisions 应该包括集群名称。
-
spec 中
matchSelector
的键值对必须与受管集群上的标签匹配。
使用以下命令,检查
ManagedCluster
对象上的标签:$ oc get ManagedCluster $CLUSTER -o jsonpath='{.metadata.labels}' | jq
使用以下命令查看合规策略:
$ oc get policy -n $CLUSTER
如果
Namespace
、OperatorGroup
和Subscription
策略兼容,但 Operator 配置策略不兼容,则 Operator 可能不会在受管集群中安装。这会导致 Operator 配置策略无法应用,因为 CRD 还没有应用到 spoke。
17.4.7. 重启策略协调
当发生意外合规问题时,您可以重启策略协调,例如 ClusterGroupUpgrade
自定义资源 (CR) 超时时。
流程
在受管集群变为
Ready
后,Topology Aware Lifecycle Manager 在命名空间ztp-install
中生成ClusterGroupUpgrade
CR:$ export CLUSTER=<clusterName>
$ oc get clustergroupupgrades -n ztp-install $CLUSTER
如果出现意外问题,且策略无法在配置超时(默认为 4 小时)内变为合规,
ClusterGroupUpgrade
CR 的状态会显示UpgradeTimedOut
:$ oc get clustergroupupgrades -n ztp-install $CLUSTER -o jsonpath='{.status.conditions[?(@.type=="Ready")]}'
UpgradeTimedOut
状态的ClusterGroupUpgrade
CR 每小时自动重启其策略协调。如果更改了策略,可以通过删除现有ClusterGroupUpgrade
CR 来启动立即重试。这会触发自动创建新的ClusterGroupUpgrade
CR,以开始立即协调策略:$ oc delete clustergroupupgrades -n ztp-install $CLUSTER
请注意,当 ClusterGroupUpgrade
CR 完成,其状态为 UpgradeCompleted
,且受管集群应用了 ztp-done
标签,您可以使用 PolicyGenTemplate
创建额外的配置更改。删除现有的 ClusterGroupUpgrade
CR 将无法生成新的 CR。
此时,GitOps ZTP 完成了与集群的交互,任何进一步的交互都应被视为更新,并为补救策略创建新的 ClusterGroupUpgrade
CR。
其他资源
-
有关使用 Topology Aware Lifecycle Manager (TALM)来构建自己的
ClusterGroupUpgrade
CR 的详情,请参考关于 ClusterGroupUpgrade CR。
17.4.8. 使用策略更改应用的受管集群 CR
您可以通过策略从受管集群中部署的自定义资源(CR)中删除内容。
默认情况下,从 PolicyGenTemplate
CR 创建的所有 Policy
CR 将 complianceType
字段设置为 musthave
。没有删除内容的 musthave
策略仍然合规,因为受管集群上的 CR 具有所有指定的内容。使用这个配置,当从 CR 中删除内容时,TALM 从策略中删除内容,但不会从受管集群的 CR 中删除内容。
当 complianceType
字段为 mustonlyhave
时,策略可确保集群中的 CR 与策略中指定的内容完全匹配。
先决条件
-
已安装 OpenShift CLI(
oc
)。 -
已以具有
cluster-admin
权限的用户身份登录到 hub 集群。 - 您已从运行 RHACM 的 hub 集群部署了受管集群。
- 您已在 hub 集群中安装了 Topology Aware Lifecycle Manager。
流程
从受影响的 CR 中删除您不再需要的内容。在本例中,
disableDrain: false
行已从SriovOperatorConfig
CR 中删除。CR 示例
apiVersion: sriovnetwork.openshift.io/v1 kind: SriovOperatorConfig metadata: name: default namespace: openshift-sriov-network-operator spec: configDaemonNodeSelector: "node-role.kubernetes.io/$mcp": "" disableDrain: true enableInjector: true enableOperatorWebhook: true
在
group-du-sno-ranGen.yaml
文件中,将受影响的策略的complianceType
更改为mustonlyhave
。YAML 示例
# ... - fileName: SriovOperatorConfig.yaml policyName: "config-policy" complianceType: mustonlyhave # ...
创建
ClusterGroupUpdates
CR,并指定必须接收 CR 更改的集群:ClusterGroupUpdates CR 示例
apiVersion: ran.openshift.io/v1alpha1 kind: ClusterGroupUpgrade metadata: name: cgu-remove namespace: default spec: managedPolicies: - ztp-group.group-du-sno-config-policy enable: false clusters: - spoke1 - spoke2 remediationStrategy: maxConcurrency: 2 timeout: 240 batchTimeoutAction:
运行以下命令来创建
ClusterGroupUpgrade
CR:$ oc create -f cgu-remove.yaml
当您准备好应用更改时,例如在适当的维护窗口中,运行以下命令将
spec.enable
字段的值改为true
:$ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-remove \ --patch '{"spec":{"enable":true}}' --type=merge
验证
运行以下命令,检查策略的状态:
$ oc get <kind> <changed_cr_name>
输出示例
NAMESPACE NAME REMEDIATION ACTION COMPLIANCE STATE AGE default cgu-ztp-group.group-du-sno-config-policy enforce 17m default ztp-group.group-du-sno-config-policy inform NonCompliant 15h
当策略的
COMPLIANCE STATE
为Compliant
时,这意味着已更新 CR,并删除不需要的内容。在受管集群中运行以下命令来检查策略是否已从目标集群中移除:
$ oc get <kind> <changed_cr_name>
如果没有结果,则会从受管集群中删除 CR。
17.4.9. 假定为 GitOps ZTP 安装
GitOps Zero Touch Provisioning (ZTP) 简化了检查集群的 GitOps ZTP 安装状态的过程。GitOps ZTP 状态分为三个阶段:集群安装、集群配置和 GitOps ZTP。
- 集群安装阶段
-
集群安装阶段由
ManagedCluster
CR 中的ManagedClusterJoined
和ManagedClusterAvailable
条件显示。如果ManagedCluster
CR 没有这些条件,或者条件设置为False
,集群仍然处于安装阶段。有关安装的更多信息,请参阅AgentClusterInstall
和ClusterDeployment
CR。如需更多信息,请参阅"Troubleshooting GitOps ZTP"。 - 集群配置阶段
-
集群配置阶段由
ztp-running
标签显示,在集群中应用ManagedCluster
CR。 - 完成 GitOps ZTP
集群安装和配置在 GitOps ZTP 完成。这可以通过删除
ztp-running
标签并在ManagedCluster
CR 中添加ztp-done
标签来显示。ztp-done
标签显示应用了配置,基准 DU 配置已完成集群调整。过渡到 GitOps ZTP 完成的状态是在 Red Hat Advanced Cluster Management (RHACM) 验证通知策略合规状态的条件。这个策略捕获了已完成的安装的现有条件,并确认只有在受管集群的 GitOps ZTP 置备完成后才会变为合规状态。
验证器通知策略可确保完全应用集群的配置,Operator 已完成初始化。策略验证以下内容:
-
目标
MachineConfigPool
包含预期的条目,并已完成更新。所有节点都可用,且没有降级。 -
至少有一个
SriovNetworkNodeState
带有syncStatus: Succeeded
则代表 SR-IOV Operator 已完成初始化。 - PTP Operator 守护进程集已存在。
-
目标