17.4. 使用策略和 PolicyGenTemplate 资源配置受管集群

流程

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。

流程

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": "Remediating non-compliant policies",
     "reason": "InProgress",
     "status": "True",
     "type": "Progressing"
   }

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. 点集群策略检查其状态。

流程

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。

流程

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

流程

1. 从受影响的 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

2. 在 group-du-sno-ranGen.yaml 文件中，将受影响的策略的 complianceType 更改为 mustonlyhave。

   YAML 示例

   # ...
   - fileName: SriovOperatorConfig.yaml
     policyName: "config-policy"
     complianceType: mustonlyhave
   # ...

3. 创建 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:

4. 运行以下命令来创建 ClusterGroupUpgrade CR：

   $ oc create -f cgu-remove.yaml

5. 当您准备好应用更改时，例如在适当的维护窗口中，运行以下命令将 spec.enable 字段的值改为 true ：

   $ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-remove \
   --patch '{"spec":{"enable":true}}' --type=merge

验证

1. 运行以下命令，检查策略的状态：

   $ 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，并删除不需要的内容。

2. 在受管集群中运行以下命令来检查策略是否已从目标集群中移除：

   $ oc get <kind> <changed_cr_name>

   如果没有结果，则会从受管集群中删除 CR。