Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

第 9 章 使用 PolicyGenerator 资源管理集群策略

9.1. 使用 PolicyGenerator 资源配置受管集群策略
复制链接

应用的 Policy 自定义资源 (CR) 配置您置备的受管集群。您可以自定义 Red Hat Advanced Cluster Management (RHACM) 如何使用 PolicyGenerator CR 生成应用的 Policy CR。

重要

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

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

注意

有关 PolicyGenerator 资源的更多信息，请参阅 RHACM 策略生成器 文档。

在 GitOps ZTP 中可以使用 PolicyGenerator 自定义资源 (CR) 和 PolicyGenTemplate CR 为受管集群生成 RHACM 策略。

当涉及到使用 GitOps ZTP 修补 OpenShift Container Platform 资源时，使用 PolicyGenerator CR 而不是 PolicyGenTemplate CR 有优点。使用 RHACM PolicyGenerator API 提供了一种通用方法来修补资源，这些资源无法使用 PolicyGenTemplate 资源。

PolicyGenerator API 是 Open Cluster Management 标准的一部分，而 PolicyGenTemplate API 不是。下表描述了 PolicyGenerator 和 PolicyGenTemplate 资源补丁和放置策略的比较。

重要

使用 PolicyGenTemplate CR 管理和监控对受管集群的策略将在即将发布的 OpenShift Container Platform 发行版本中弃用。使用 Red Hat Advanced Cluster Management (RHACM) 和 PolicyGenerator CR 提供了等效的和改进的功能。

有关 PolicyGenerator 资源的更多信息，请参阅 RHACM 策略生成器 文档。

Expand
表 9.1. RHACM PolicyGenerator 和 PolicyGenTemplate 补丁的比较
PolicyGenerator 补丁PolicyGenTemplate 补丁

使用 Kustomize 战略性合并来合并资源。如需更多信息，请参阅使用 Kustomize 管理 Kubernetes 对象。

将变量替换为补丁所定义的值。与 Kustomize 合并策略相比，这不太灵活。

支持 ManagedClusterSet 和 Binding 资源。

不支持 ManagedClusterSet 和 Binding 资源。

依赖于补丁，不需要替换嵌入的变量。

覆盖补丁中定义的变量值。

不支持合并补丁中的合并列表。支持替换合并补丁中的列表。

合并和替换列表会有限，您只能在列表中合并一个对象。

目前不支持资源补丁的 OpenAPI 规格。这意味着补丁中需要额外的指令来合并不遵循模式的内容，如 PtpConfig 资源。

将字段和值替换为补丁所定义的值。

需要额外的指令，例如，补丁中的 $patch: replace 来合并没有遵循模式的内容。

将源 CR 中定义的字段和值替换为补丁中定义的值，如 $name。

可以修补引用源 CR 中定义的 Name 和 Namespace 字段，但只有当 CR 文件只有一个对象时。

可以修补引用源 CR 中定义的 Name 和 Namespace 字段。

9.1.2. 关于 PolicyGenerator CRD
复制链接

PolicyGenerator 自定义资源定义(CRD) 告知 PolicyGen 策略生成器在集群配置中包含哪些自定义资源 (CR)，如何将 CR 组合到生成的策略中，以及这些 CR 中的项目需要使用 overlay 内容更新。

以下示例显示了从 ztp-site-generate 引用容器中提取的 PolicyGenerator CR (acm-common-du-ranGen.yaml)。acm-common-du-ranGen.yaml 文件定义了两个 Red Hat Advanced Cluster Management (RHACM) 策略。策略管理配置 CR 集合，每个 CR 中的 policyName 值对应一个。acm-common-du-ranGen.yaml 创建一个单个放置绑定和一个放置规则，根据 policyDefaults.placement.labelSelector 部分中列出的标签将策略绑定到集群。

示例 PolicyGenerator CR - acm-common-ranGen.yaml

apiVersion: policy.open-cluster-management.io/v1
kind: PolicyGenerator
metadata:
    name: common-latest
placementBindingDefaults:
    name: common-latest-placement-binding
1 

policyDefaults:
    namespace: ztp-common
    placement:
        labelSelector:
            matchExpressions:
                - key: common
                  operator: In
                  values:
                    - "true"
                - key: du-profile
                  operator: In
                  values:
                    - latest
    remediationAction: inform
    severity: low
    namespaceSelector:
        exclude:
            - kube-*
        include:
            - '*'
    evaluationInterval:
        compliant: 10m
        noncompliant: 10s
policies:
    - name: common-latest-config-policy
      policyAnnotations:
        ran.openshift.io/ztp-deploy-wave: "1"
      manifests:
        - path: source-crs/ReduceMonitoringFootprint.yaml
        - path: source-crs/DefaultCatsrc.yaml
2 

          patches:
            - metadata:
                name: redhat-operators-disconnected
              spec:
                displayName: disconnected-redhat-operators
                image: registry.example.com:5000/disconnected-redhat-operators/disconnected-redhat-operator-index:v4.9
        - path: source-crs/DisconnectedICSP.yaml
          patches:
            - spec:
                repositoryDigestMirrors:
                    - mirrors:
                        - registry.example.com:5000
                      source: registry.redhat.io
    - name: common-latest-subscriptions-policy
      policyAnnotations:
        ran.openshift.io/ztp-deploy-wave: "2"
      manifests:
3 

        - path: source-crs/SriovSubscriptionNS.yaml
        - path: source-crs/SriovSubscriptionOperGroup.yaml
        - path: source-crs/SriovSubscription.yaml
        - path: source-crs/SriovOperatorStatus.yaml
        - path: source-crs/PtpSubscriptionNS.yaml
        - path: source-crs/PtpSubscriptionOperGroup.yaml
        - path: source-crs/PtpSubscription.yaml
        - path: source-crs/PtpOperatorStatus.yaml
        - path: source-crs/ClusterLogNS.yaml
        - path: source-crs/ClusterLogOperGroup.yaml
        - path: source-crs/ClusterLogSubscription.yaml
        - path: source-crs/ClusterLogOperatorStatus.yaml
        - path: source-crs/StorageNS.yaml
        - path: source-crs/StorageOperGroup.yaml
        - path: source-crs/StorageSubscription.yaml
        - path: source-crs/StorageOperatorStatus.yaml

1
将策略应用到具有此标签的所有集群。
2
DefaultCatsrc.yaml 文件包含断开连接的 registry 和相关 registry 配置详情的目录源。
3
policies.manifests 下列出的文件为已安装的集群创建 Operator 策略。

PolicyGenerator CR 可以使用任意数量的包含 CR 来构建。在 hub 集群中应用以下示例 CR 来生成包含单个 CR 的策略： 

apiVersion: policy.open-cluster-management.io/v1
kind: PolicyGenerator
metadata:
  name: group-du-sno
placementBindingDefaults:
  name: group-du-sno-placement-binding
policyDefaults:
  namespace: ztp-group
  placement:
    labelSelector:
      matchExpressions:
        - key: group-du-sno
          operator: Exists
  remediationAction: inform
  severity: low
  namespaceSelector:
    exclude:
      - kube-*
    include:
      - '*'
  evaluationInterval:
    compliant: 10m
    noncompliant: 10s
policies:
  - name: group-du-sno-config-policy
    policyAnnotations:
      ran.openshift.io/ztp-deploy-wave: '10'
    manifests:
      - path: source-crs/PtpConfigSlave-MCP-master.yaml
        patches:
          - metadata: null
            name: du-ptp-slave
            namespace: openshift-ptp
            annotations:
              ran.openshift.io/ztp-deploy-wave: '10'
            spec:
              profile:
                - name: slave
                  interface: $interface
                  ptp4lOpts: '-2 -s'
                  phc2sysOpts: '-a -r -n 24'
                  ptpSchedulingPolicy: SCHED_FIFO
                  ptpSchedulingPriority: 10
                  ptpSettings:
                    logReduce: 'true'
                  ptp4lConf: |
                    [global]
                    #
                    # Default Data Set
                    #
                    twoStepFlag 1
                    slaveOnly 1
                    priority1 128
                    priority2 128
                    domainNumber 24
                    #utc_offset 37
                    clockClass 255
                    clockAccuracy 0xFE
                    offsetScaledLogVariance 0xFFFF
                    free_running 0
                    freq_est_interval 1
                    dscp_event 0
                    dscp_general 0
                    dataset_comparison G.8275.x
                    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 50
                    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
                    clock_class_threshold 7
                    #
                    # 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
              recommend:
                - profile: slave
                  priority: 4
                  match:
                    - nodeLabel: node-role.kubernetes.io/master

使用源文件 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: PolicyGenerator
metadata:
    name: du-upgrade
placementBindingDefaults:
    name: du-upgrade-placement-binding
policyDefaults:
    namespace: ztp-group-du-sno
    placement:
        labelSelector:
            matchExpressions:
                - key: group-du-sno
                  operator: Exists
    remediationAction: inform
    severity: low
    namespaceSelector:
        exclude:
            - kube-*
        include:
            - '*'
    evaluationInterval:
        compliant: 10m
        noncompliant: 10s
policies:
    - name: du-upgrade-operator-catsrc-policy
      policyAnnotations:
        ran.openshift.io/ztp-deploy-wave: "1"
      manifests:
        - path: source-crs/DefaultCatsrc.yaml
          patches:
            - metadata:
                name: redhat-operators
              spec:
                displayName: Red Hat Operators Catalog
                image: registry.example.com:5000/olm/redhat-operators:v4.14
                updateStrategy:
                    registryPoll:
                        interval: 1h
              status:
                connectionState:
                    lastObservedState: READY

9.1.3. 自定义 PolicyGenerator CR 时的建议
复制链接

在自定义站点配置 PolicyGenerator 自定义资源 (CR) 时请考虑以下最佳实践：

  • 根据需要使用一些策略。使用较少的策略需要较少的资源。每个附加策略会为 hub 集群和部署的受管集群创建 CPU 负载增加。CR 根据 PolicyGenerator CR 中的 policyName 字段合并到策略中。同一 PolicyGenerator 中的 CR，在单个策略下管理相同的 policyName 值。
  • 在断开连接的环境中，通过将 registry 配置为包含所有 Operator 的单个索引，为所有 Operator 使用单个目录源。受管集群中的每个额外 CatalogSource CR 会增加 CPU 用量。
  • MachineConfig CR 应包含在 siteConfig CR 中作为 extraManifests，以便在安装过程中应用它们。这可减少在集群就绪部署应用程序前所花费的总时间。
  • PolicyGenerator CR 应该覆盖 channel 字段来明确识别所需的版本。这样可确保源 CR 在升级过程中的更改不会更新生成的订阅。
注意

在 hub 集群中管理大量 spoke 集群时，请最小化策略数量来减少资源消耗。

将多个配置 CR 分组到单个或有限的策略中，一种方法是减少 hub 集群上的总体策略数量。在使用 common/group/site 层次结构来管理站点配置时，务必要将特定于站点的配置组合成单一策略。

9.1.4. RAN 部署的 PolicyGenerator CR
复制链接

使用 PolicyGenerator 自定义资源 (CR) 使用 GitOps Zero Touch Provisioning (ZTP) 管道自定义应用到集群的配置。PolicyGenerator CR 允许您生成一个或多个策略来管理集群中的配置 CR 集合。PolicyGenerator CR 标识一组受管 CR，将它们捆绑到策略中，构建与这些 CR 相关的策略，并使用标签绑定规则将策略与集群相关联。

从 GitOps ZTP 容器获取的参考配置旨在提供一组关键功能和节点调优设置，以确保集群可以支持字符串的性能和资源利用率限制，典型的 RAN 分布式单元(DU)应用程序。来自基准配置的更改或禁止可能会影响功能可用性、性能和资源利用率。使用引用 PolicyGenerator CR 作为基础来创建根据您的特定站点要求量身定制的配置文件的层次结构。

为 RAN DU 集群配置定义的基准 PolicyGenerator CR 可以从 GitOps ZTP ztp-site-generate 容器中提取。如需了解更多详细信息，请参阅"准备 GitOps ZTP 站点配置存储库"。

PolicyGenerator CR 可以在 ./out/argocd/example/acmpolicygenerator/ 文件夹中找到。参考架构具有共同、组和特定站点的配置 CR。每个 PolicyGenerator CR 都引用可在 ./out/source-crs 文件夹中找到的其他 CR。

与 RAN 集群配置相关的 PolicyGenerator CR 如下所述。为组 PolicyGenerator CR 提供变体，以考虑单节点、三节点紧凑和标准集群配置中的差别。同样，为单节点集群和多节点（compact 或 standard）集群提供了特定于站点的配置变体。使用与部署相关的组和特定于站点的配置变体。

Expand
表 9.2. RAN 部署的 PolicyGenerator CR
PolicyGenerator CR描述

acm-example-multinode-site.yaml

包含一组应用于多节点集群的 CR。这些 CR 配置 SR-IOV 功能，用于 RAN 安装。

acm-example-sno-site.yaml

包含一组应用于单节点 OpenShift 集群的 CR。这些 CR 配置 SR-IOV 功能，用于 RAN 安装。

acm-common-mno-ranGen.yaml

包含一组应用于多节点集群的通用 RAN 策略配置。

acm-common-ranGen.yaml

包含一组应用于所有集群的通用 RAN CR。这些 CR 订阅一组 operator，提供典型的 RAN 和基准集群调整功能。

acm-group-du-3node-ranGen.yaml

仅包含三节点集群的 RAN 策略。

acm-group-du-sno-ranGen.yaml

仅包含单节点集群的 RAN 策略。

acm-group-du-standard-ranGen.yaml

包含标准三个 control-plane 集群的 RAN 策略。

acm-group-du-3node-validator-ranGen.yaml

用于生成三节点集群所需的各种策略的 PolicyGenerator CR。

acm-group-du-standard-validator-ranGen.yaml

用于生成标准集群所需的各种策略的 PolicyGenerator CR。

acm-group-du-sno-validator-ranGen.yaml

用于生成单节点 OpenShift 集群所需的各种策略的 PolicyGenerator CR。

9.1.5. 使用 PolicyGenerator CR 自定义受管集群
复制链接

使用以下步骤自定义应用于使用 GitOps Zero Touch Provisioning (ZTP) 管道置备的受管集群的策略。

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 已以具有 cluster-admin 权限的用户身份登录到 hub 集群。
  • 配置了 hub 集群来生成所需的安装和策略 CR。
  • 您创建了 Git 存储库，用于管理自定义站点配置数据。该存储库必须可从 hub 集群访问，并定义为 Argo CD 应用程序的源仓库。

流程

  1. 为特定于站点的配置 CR 创建 PolicyGenerator CR。

    1. 从 out/argocd/example/acmpolicygenerator/ 文件夹中选择适当的 CR 示例，例如 acm-example-sno-site.yaml 或 acm-example-multinode-site.yaml。

    2. 更改示例文件中的 policyDefaults.placement.labelSelector 字段，以匹配 SiteConfig CR 中包含的特定于站点的标签匹配。在示例 SiteConfig 文件中，特定于站点的标签是 sites: example-sno。

      注意

      确保 PolicyGenerator policyDefaults.placement.labelSelector 字段中定义的标签与相关受管集群 SiteConfig CR 中定义的标签对应。

    3. 更改示例文件中的内容，使其与所需配置匹配。

  2. 可选：为应用到整个集群的任何通用配置 CR 创建一个 PolicyGenerator CR。

    1. 从 out/argocd/example/acmpolicygenerator/ 文件夹中选择适当的 CR 示例，例如 acm-common-ranGen.yaml。
    2. 更改示例文件中的内容，使其与所需配置匹配。

  3. 可选：为应用到团队中特定集群组的任何组配置 CR 创建一个 PolicyGenerator CR。

    确保 overlaid spec 文件的内容与您的所需最终状态匹配。作为参考，out/source-crs 目录包含可用于包含和由 PolicyGenerator 模板提供的 source-crs 的完整列表。

    注意

    根据集群的特定要求，每个集群类型可能需要一个组策略，特别是考虑示例组策略各自有一个 PerformancePolicy.yaml 文件，如果这些集群是由相同的硬件配置，则只能在一组集群中共享。

    1. 从 out/argocd/example/acmpolicygenerator/ 文件夹中选择适当的 CR 示例，例如 acm-group-du-sno-ranGen.yaml。
    2. 更改示例文件中的内容，使其与所需配置匹配。
  4. 可选。当 GitOps ZTP 安装和配置完成后，创建一个验证器通知策略 PolicyGenerator CR。如需更多信息，请参阅"创建验证器通知策略"。

  5. 在 YAML 文件中定义所有策略命名空间，类似于示例 out/argocd/example/acmpolicygenerator//ns.yaml 文件。

    重要

    不要在带有 PolicyGenerator CR 的同一文件中包括 Namespace CR。

  6. 将 PolicyGenerator CR 和 Namespace CR 添加到 generators 部分中的 kustomization.yaml 文件中，类似于 out/argocd/example/acmpolicygenerator/kustomization.yaml 所示的示例。

  7. 在 Git 存储库中提交 PolicyGenerator CR、Namespace CR 和关联的 kustomization.yaml 文件并推送更改。

    ArgoCD 管道检测到更改并开始受管集群部署。您可以同时将更改推送到 SiteConfig CR 和 PolicyGenerator CR。

9.1.6. 监控受管集群策略部署进度
复制链接

ArgoCD 管道使用 Git 中的 PolicyGenerator 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": "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. 点集群策略检查其状态。

当所有集群策略都合规时，集群的 GitOps ZTP 安装和配置已完成。ztp-done 标签添加到集群中。

在引用配置中，合规的最终策略是 *-du-validator-policy 策略中定义的。此策略当在一个集群中合规时，确保所有集群配置、Operator 安装和 Operator 配置已完成。

9.1.7. 验证配置策略 CR 的生成
复制链接

Policy 自定义资源 (CR) 在与创建它们的 PolicyGenerator 相同的命名空间中生成。相同的故障排除流程适用于从 PolicyGenerator 生成的所有策略 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 将所有适用的策略复制到集群命名空间中。复制的策略名称的格式为：<PolicyGenerator.Namespace>.<PolicyGenerator.Name>-<policyName>。

  5. 检查放置规则中是否有没有复制到集群命名空间中的策略。这些策略的 Placement 中的 matchSelector 应与 ManagedCluster 对象上的标签匹配： 

    $ oc get Placement -n $NS

  6. 使用以下命令，注意适合缺少策略、通用、组或站点的 Placement 名称： 

    $ oc get Placement -n $NS <placement_rule_name> -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。

9.1.8. 重启策略协调
复制链接

当发生意外合规问题时，您可以重启策略协调，例如 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 标签，您可以使用 PolicyGenerator 创建额外的配置更改。删除现有的 ClusterGroupUpgrade CR 将无法生成新的 CR。

此时，GitOps ZTP 完成了与集群的交互，任何进一步的交互都应被视为更新，并为补救策略创建新的 ClusterGroupUpgrade CR。

9.1.9. 使用策略更改应用的受管集群 CR
复制链接

您可以通过策略从受管集群中部署的自定义资源(CR)中删除内容。

默认情况下，从 PolicyGenerator 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。

流程

  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. 在 acm-group-du-sno-ranGen.yaml 文件中将受影响策略的 complianceType 更改为 mustonlyhave。

    YAML 示例

    # ...
policyDefaults:
  complianceType: "mustonlyhave"
# ...
policies:
  - name: config-policy
    policyAnnotations:
      ran.openshift.io/ztp-deploy-wave: ""
    manifests:
      - path: source-crs/SriovOperatorConfig.yaml

  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。

9.1.10. 假定为 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 守护进程集已存在。
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

Theme

© 2026 Red Hat返回顶部