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


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

19.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-slavePtpConfigSlave.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
                                    .....

19.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 在升级过程中的更改不会更新生成的订阅。

其他资源

注意

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

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

19.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)集群提供了特定于站点的配置变体。使用与部署相关的组和特定于站点的配置变体。

表 19.6. RAN 部署的 PolicyGenTemplate CR
PolicyGenTemplate CR描述

example-multinode-site.yaml

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

example-sno-site.yaml

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

common-ranGen.yaml

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

group-du-3node-ranGen.yaml

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

group-du-sno-ranGen.yaml

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

group-du-standard-ranGen.yaml

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

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

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

group-du-standard-validator-ranGen.yaml

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

group-du-sno-validator-ranGen.yaml

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

19.4.4. 使用 PolicyGenTemplate CR 自定义受管集群

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

先决条件

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

流程

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

    1. out/argocd/example/policygentemplates 文件夹中选择适当的 CR 示例,例如 example-sno-site.yamlexample-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. 可选。当 GitOps 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。

19.4.5. 监控受管集群策略部署进度

ArgoCD 管道使用 Git 中的 PolicyGenTemplate CR 生成 RHACM 策略,然后将其同步到 hub 集群。您可以在辅助服务在受管集群中安装 OpenShift Container Platform 后监控受管集群策略同步的进度。

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 已以具有 cluster-admin 权限的用户身份登录到 hub 集群。

流程

  1. Topology Aware Lifecycle Manager(TALM)应用绑定到集群的配置策略。

    集群安装完成后,集群变为 ReadyClusterGroupUpgrade 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 配置已完成。

19.4.6. 验证配置策略 CR 的生成

策略自定义资源(CR)在与创建它们的 PolicyGenTemplate 相同的命名空间中生成。同样的故障排除流程适用于从 PolicyGenTemplate 生成的所有策略 CR,无论它们是 ztp-commonztp-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: 显示 UnknownError:

    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

    如果 NamespaceOperatorGroupSubscription 策略兼容,但 Operator 配置策略不兼容,则 Operator 可能不会在受管集群中安装。这会导致 Operator 配置策略无法应用,因为 CRD 还没有应用到 spoke。

19.4.7. 重启策略协调

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

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

其他资源

  • 有关使用 Topology Aware Lifecycle Manager (TALM)来构建自己的 ClusterGroupUpgrade CR 的详情,请参考关于 ClusterGroupUpgrade CR

19.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。

流程

  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 STATECompliant 时,这意味着已更新 CR,并删除不需要的内容。

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

    $ oc get <kind> <changed_cr_name>

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

19.4.9. 假定为 GitOps ZTP 安装

GitOps Zero Touch Provisioning (ZTP) 简化了检查集群的 GitOps ZTP 安装状态的过程。GitOps ZTP 状态分为三个阶段:集群安装、集群配置和 GitOps ZTP。

集群安装阶段
集群安装阶段由 ManagedCluster CR 中的 ManagedClusterJoinedManagedClusterAvailable 条件显示。如果 ManagedCluster CR 没有这些条件,或者条件设置为 False,集群仍然处于安装阶段。有关安装的更多信息,请参阅 AgentClusterInstallClusterDeployment 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 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

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

© 2024 Red Hat, Inc.