搜索

10.3. 使用 PolicyGenTemplate 资源和 TALM 在断开连接的环境中更新受管集群

download PDF

您可以使用 Topology Aware Lifecycle Manager (TALM)来管理您使用 GitOps Zero Touch Provisioning (ZTP)和 Topology Aware Lifecycle Manager (TALM)部署的受管集群的软件生命周期。TALM 使用 Red Hat Advanced Cluster Management (RHACM) PolicyGenTemplate 策略来管理和控制应用到目标集群的更改。

重要

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

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

10.3.1. 设置断开连接的环境

TALM 可以同时执行平台和 Operator 更新。

您必须在镜像 registry 中镜像您要升级到的平台镜像和 Operator 镜像,然后才能使用 TALM 更新断开连接的集群。完成以下步骤以镜像镜像:

  • 对于平台更新,您必须执行以下步骤:

    1. 镜像所需的 OpenShift Container Platform 镜像存储库。根据"镜像 OpenShift Container Platform 镜像存储库"流程在附加资源中链接,确保所需的平台镜像已被镜像。在 imageContentSources.yaml 文件中保存 imageContentSources 部分的内容:

      输出示例

      imageContentSources:
       - mirrors:
         - mirror-ocp-registry.ibmcloud.io.cpak:5000/openshift-release-dev/openshift4
         source: quay.io/openshift-release-dev/ocp-release
       - mirrors:
         - mirror-ocp-registry.ibmcloud.io.cpak:5000/openshift-release-dev/openshift4
         source: quay.io/openshift-release-dev/ocp-v4.0-art-dev

    2. 保存已镜像的所需平台镜像的镜像签名。对于平台更新,您必须将镜像签名添加到 PolicyGenTemplate CR 中。要获取镜像签名,请执行以下步骤:

      1. 运行以下命令指定所需的 OpenShift Container Platform 标签:

        $ OCP_RELEASE_NUMBER=<release_version>
      2. 运行以下命令指定集群的构架:

        $ ARCHITECTURE=<cluster_architecture> 1
        1
        指定集群的构架,如 x86_64, aarch64, s390x, 获 ppc64le
      3. 运行以下命令,从 Quay 获取发行版本镜像摘要

        $ DIGEST="$(oc adm release info quay.io/openshift-release-dev/ocp-release:${OCP_RELEASE_NUMBER}-${ARCHITECTURE} | sed -n 's/Pull From: .*@//p')"
      4. 运行以下命令来设置摘要算法:

        $ DIGEST_ALGO="${DIGEST%%:*}"
      5. 运行以下命令来设置摘要签名:

        $ DIGEST_ENCODED="${DIGEST#*:}"
      6. 运行以下命令,从 mirror.openshift.com 网站获取镜像签名:

        $ SIGNATURE_BASE64=$(curl -s "https://mirror.openshift.com/pub/openshift-v4/signatures/openshift/release/${DIGEST_ALGO}=${DIGEST_ENCODED}/signature-1" | base64 -w0 && echo)
      7. 运行以下命令,将镜像签名保存到 checksum-<OCP_RELEASE_NUMBER>.yaml 文件中:

        $ cat >checksum-${OCP_RELEASE_NUMBER}.yaml <<EOF
        ${DIGEST_ALGO}-${DIGEST_ENCODED}: ${SIGNATURE_BASE64}
        EOF
    3. 准备更新图表。您可以通过两个选项来准备更新图形:

      1. 使用 OpenShift Update Service。

        有关如何在 hub 集群上设置图形的更多信息,请参阅为 OpenShift Update Service 部署 Operator 并构建图形数据 init 容器

      2. 生成上游图形的本地副本。在可访问受管集群的断开连接的环境中的 httphttps 服务器上托管更新图表。要下载更新图表,请使用以下命令:

        $ curl -s https://api.openshift.com/api/upgrades_info/v1/graph?channel=stable-4.16 -o ~/upgrade-graph_stable-4.16
  • 对于 Operator 更新,您必须执行以下任务:

    • 镜像 Operator 目录。确保所需的 Operator 镜像按照"Mirroring Operator 目录以用于断开连接的集群"部分中的步骤进行镜像。

10.3.2. 使用 PolicyGenTemplate CR 执行平台更新

您可以使用 TALM 执行平台更新。

先决条件

  • 安装 Topology Aware Lifecycle Manager(TALM)。
  • 将 GitOps Zero Touch Provisioning (ZTP) 更新至最新版本。
  • 使用 GitOps ZTP 置备一个或多个受管集群。
  • 镜像所需的镜像存储库。
  • 以具有 cluster-admin 特权的用户身份登录。
  • 在 hub 集群中创建 RHACM 策略。

流程

  1. 为平台更新创建 PolicyGenTemplate CR:

    1. 将以下 PolicyGenTemplate CR 保存到 du-upgrade.yaml 文件中:

      平台更新的 PolicyGenTemplate 示例

      apiVersion: ran.openshift.io/v1
      kind: PolicyGenTemplate
      metadata:
        name: "du-upgrade"
        namespace: "ztp-group-du-sno"
      spec:
        bindingRules:
          group-du-sno: ""
        mcp: "master"
        remediationAction: inform
        sourceFiles:
          - fileName: ImageSignature.yaml 1
            policyName: "platform-upgrade-prep"
            binaryData:
              ${DIGEST_ALGO}-${DIGEST_ENCODED}: ${SIGNATURE_BASE64} 2
          - fileName: DisconnectedICSP.yaml
            policyName: "platform-upgrade-prep"
            metadata:
              name: disconnected-internal-icsp-for-ocp
            spec:
              repositoryDigestMirrors: 3
                - mirrors:
                  - quay-intern.example.com/ocp4/openshift-release-dev
                  source: quay.io/openshift-release-dev/ocp-release
                - mirrors:
                  - quay-intern.example.com/ocp4/openshift-release-dev
                  source: quay.io/openshift-release-dev/ocp-v4.0-art-dev
          - fileName: ClusterVersion.yaml 4
            policyName: "platform-upgrade"
            metadata:
              name: version
            spec:
              channel: "stable-4.16"
              upstream: http://upgrade.example.com/images/upgrade-graph_stable-4.16
              desiredUpdate:
                version: 4.16.4
            status:
              history:
                - version: 4.16.4
                  state: "Completed"

      1
      ConfigMap CR 包含要更新到的所需发行镜像的签名。
      2
      显示所需 OpenShift Container Platform 发行版本的镜像签名。按照"设置环境"部分中的步骤,从您保存的 checksum-${OCP_RELEASE_NUMBER}.yaml 文件中获取签名。
      3
      显示包含所需 OpenShift Container Platform 镜像的镜像存储库。获取在"设置 environment"部分中的步骤时所保存的 imageContentSources.yaml 文件中的镜像。
      4
      显示触发更新的 ClusterVersion CR。对于预缓存,channel, upstream, 和 desiredVersion 项都是必需的。

      PolicyGenTemplate CR 会生成两个策略:

      • du-upgrade-platform-upgrade-prep 策略为平台更新做准备。它为所需的发行版本镜像签名创建 ConfigMap CR,创建镜像的发行镜像存储库的镜像内容源,并使用所需的更新频道更新集群版本,以及在断开连接的环境中由 spoke 集群访问的更新图。
      • du-upgrade-platform-upgrade 策略用于执行平台升级。
    2. du-upgrade.yaml 文件内容添加到 PolicyGenTemplate CR 的 GitOps ZTP Git 存储库中的 kustomization.yaml 文件中,并将更改推送到 Git 存储库。

      ArgoCD 从 Git 存储库拉取更改并在 hub 集群上生成策略。

    3. 运行以下命令检查创建的策略:

      $ oc get policies -A | grep platform-upgrade
  2. 为平台更新创建 ClusterGroupUpdate CR,将 spec.enable 项设置为 false

    1. 将平台更新 ClusterGroupUpdate CR 的内容,带有 du-upgrade-platform-upgrade-prepdu-upgrade-platform-upgrade 策略,以及目标集群保存到 cgu-platform-upgrade.yml 文件,如以下示例所述:

      apiVersion: ran.openshift.io/v1alpha1
      kind: ClusterGroupUpgrade
      metadata:
        name: cgu-platform-upgrade
        namespace: default
      spec:
        managedPolicies:
        - du-upgrade-platform-upgrade-prep
        - du-upgrade-platform-upgrade
        preCaching: false
        clusters:
        - spoke1
        remediationStrategy:
          maxConcurrency: 1
        enable: false
    2. 运行以下命令,将 ClusterGroupUpdate CR 应用到 hub 集群:

      $ oc apply -f cgu-platform-upgrade.yml
  3. 可选:缓存平台更新的镜像。

    1. 运行以下命令,在 ClusterGroupUpdate CR 中启用预缓存:

      $ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-platform-upgrade \
      --patch '{"spec":{"preCaching": true}}' --type=merge
    2. 监控更新过程,并等待预缓存完成。在 hub 集群中运行以下命令来检查预缓存的状态:

      $ oc get cgu cgu-platform-upgrade -o jsonpath='{.status.precaching.status}'
  4. 启动平台更新:

    1. 运行以下命令启用 cgu-platform-upgrade 策略并禁用预缓存:

      $ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-platform-upgrade \
      --patch '{"spec":{"enable":true, "preCaching": false}}' --type=merge
    2. 监控进程。在完成后,运行以下命令来确保策略兼容:

      $ oc get policies --all-namespaces

10.3.3. 使用 PolicyGenTemplate CR 执行 Operator 更新

您可以使用 TALM 执行 Operator 更新。

先决条件

  • 安装 Topology Aware Lifecycle Manager(TALM)。
  • 将 GitOps Zero Touch Provisioning (ZTP) 更新至最新版本。
  • 使用 GitOps ZTP 置备一个或多个受管集群。
  • 镜像捆绑包镜像、捆绑包镜像以及捆绑包镜像中引用的所有 Operator 镜像。
  • 以具有 cluster-admin 特权的用户身份登录。
  • 在 hub 集群中创建 RHACM 策略。

流程

  1. 为 Operator 更新更新 PolicyGenTemplate CR。

    1. 使用 du-upgrade.yaml 文件中的以下额外内容更新 du-upgrade PolicyGenTemplate CR:

      apiVersion: ran.openshift.io/v1
      kind: PolicyGenTemplate
      metadata:
        name: "du-upgrade"
        namespace: "ztp-group-du-sno"
      spec:
        bindingRules:
          group-du-sno: ""
        mcp: "master"
        remediationAction: inform
        sourceFiles:
          - fileName: DefaultCatsrc.yaml
            remediationAction: inform
            policyName: "operator-catsrc-policy"
            metadata:
              name: redhat-operators
            spec:
              displayName: Red Hat Operators Catalog
              image: registry.example.com:5000/olm/redhat-operators:v4.16 1
              updateStrategy: 2
                registryPoll:
                  interval: 1h
            status:
              connectionState:
                  lastObservedState: READY 3
      1
      索引镜像 URL 包含所需的 Operator 镜像。如果索引镜像始终推送到相同的镜像名称和标签,则不需要此更改。
      2
      使用 registryPoll.interval 字段设置 Operator Lifecycle Manager(OLM)轮询新 Operator 版本的索引镜像。如果为 y-stream 和 z-stream Operator 更新而总是推送新的索引镜像标签,则不需要此更改。registryPoll.interval 字段可以设置为较短的间隔,以加快更新,但较短的间隔会增大计算负载。要影响此行为,您可以在更新完成后将 registryPoll.interval 恢复到默认值。
      3
      目录连接的最后观察到状态。READY 值确保 CatalogSource 策略已就绪,表示索引 Pod 已拉取并在运行。这样,TALM 根据最新的策略合规性状态升级 Operator。
    2. 在这个版本中,生成一个策略 du-upgrade-operator-catsrc-policy,以使用包含所需 Operator 镜像的新索引镜像更新 redhat-operators 目录源。

      注意

      如果要使用 Operator 预缓存,并且有来自 redhat-operators 以外的其他目录源的 Operator,您必须执行以下任务:

      • 使用新的索引镜像或 registry 轮询间隔更新准备单独的目录源策略。
      • 为来自不同目录源的所需 Operator 准备单独的订阅策略。

      例如,所需的 SRIOV-FEC Operator 在 certified-operators 目录源中提供。要更新目录源和 Operator 订阅,请添加以下内容来生成两个策略: du-upgrade-fec-catsrc-policydu-upgrade-subscriptions-fec-policy

      apiVersion: ran.openshift.io/v1
      kind: PolicyGenTemplate
      metadata:
        name: "du-upgrade"
        namespace: "ztp-group-du-sno"
      spec:
        bindingRules:
          group-du-sno: ""
        mcp: "master"
        remediationAction: inform
        sourceFiles:
            # ...
          - fileName: DefaultCatsrc.yaml
            remediationAction: inform
            policyName: "fec-catsrc-policy"
            metadata:
              name: certified-operators
            spec:
              displayName: Intel SRIOV-FEC Operator
              image: registry.example.com:5000/olm/far-edge-sriov-fec:v4.10
              updateStrategy:
                registryPoll:
                  interval: 10m
          - fileName: AcceleratorsSubscription.yaml
            policyName: "subscriptions-fec-policy"
            spec:
              channel: "stable"
              source: certified-operators
    3. 如果存在,在常规 PolicyGenTemplate CR 中删除指定的订阅频道。GitOps ZTP 镜像的默认订阅频道用于更新。

      注意

      通过 GitOps ZTP 4.16 应用的 Operator 的默认频道是 stable,但 performance-addon-operator 除外。从 OpenShift Container Platform 4.11 开始,performance-addon-operator 功能被移到 node-tuning-operator 中。对于 4.10 发行版本,PAO 的默认频道是 v4.10。您还可以在常规 PolicyGenTemplate CR 中指定默认频道。

    4. PolicyGenTemplate CR 更新推送到 GitOps ZTP Git 存储库。

      ArgoCD 从 Git 存储库拉取更改并在 hub 集群上生成策略。

    5. 运行以下命令检查创建的策略:

      $ oc get policies -A | grep -E "catsrc-policy|subscription"
  2. 在启动 Operator 更新前,应用所需的目录源更新。

    1. 使用目录源策略将名为 operator-upgrade-prepClusterGroupUpgrade CR 的内容保存到 cgu-operator-upgrade-prep.yml 文件中:

      apiVersion: ran.openshift.io/v1alpha1
      kind: ClusterGroupUpgrade
      metadata:
        name: cgu-operator-upgrade-prep
        namespace: default
      spec:
        clusters:
        - spoke1
        enable: true
        managedPolicies:
        - du-upgrade-operator-catsrc-policy
        remediationStrategy:
          maxConcurrency: 1
    2. 运行以下命令,将策略应用到 hub 集群:

      $ oc apply -f cgu-operator-upgrade-prep.yml
    3. 监控更新过程。在完成后,运行以下命令来确保策略兼容:

      $ oc get policies -A | grep -E "catsrc-policy"
  3. 为 Operator 更新创建 ClusterGroupUpgrade CR,并将 spec.enable 字段设置为 false

    1. 使用 du-upgrade-operator-catsrc-policy 策略和从常规 PolicyGenTemplate 创建的订阅策略,将 Operator 更新 ClusterGroupUpgrade CR 的内容保存到 cgu-operator-upgrade.yml 文件,如下例所示:

      apiVersion: ran.openshift.io/v1alpha1
      kind: ClusterGroupUpgrade
      metadata:
        name: cgu-operator-upgrade
        namespace: default
      spec:
        managedPolicies:
        - du-upgrade-operator-catsrc-policy 1
        - common-subscriptions-policy 2
        preCaching: false
        clusters:
        - spoke1
        remediationStrategy:
          maxConcurrency: 1
        enable: false
      1
      镜像预缓存功能需要该策略,以便从目录源检索 Operator 镜像。
      2
      策略包含 Operator 订阅。如果您遵循了参考 PolicyGenTemplates 的结构和内容,则所有 Operator 订阅都分组到 common-subscriptions-policy 策略中。
      注意

      一个 ClusterGroupUpgrade CR 只能从 ClusterGroupUpgrade CR 中包含的一个目录源中预缓存订阅策略中定义的 Operator 镜像。如果所需的 Operator 来自不同目录源,如 SRIOV-FEC Operator 示例,则必须使用 du-upgrade-fec-catsrc-policydu-upgrade-subscriptions-fec-policy 镜像(pre-FEC Operator 镜像)创建另一个 ClusterGroupUpgrade CR。

    2. 运行以下命令,将 ClusterGroupUpgrade CR 应用到 hub 集群:

      $ oc apply -f cgu-operator-upgrade.yml
  4. 可选:缓存 Operator 更新的镜像。

    1. 在启动镜像预缓存前,运行以下命令验证订阅策略在此时是否是 NonCompliant

      $ oc get policy common-subscriptions-policy -n <policy_namespace>

      输出示例

      NAME                          REMEDIATION ACTION   COMPLIANCE STATE     AGE
      common-subscriptions-policy   inform               NonCompliant         27d

    2. 运行以下命令,在 ClusterGroupUpgrade CR 中启用预缓存:

      $ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-operator-upgrade \
      --patch '{"spec":{"preCaching": true}}' --type=merge
    3. 监控进程并等待预缓存完成。在受管集群中运行以下命令来检查预缓存的状态:

      $ oc get cgu cgu-operator-upgrade -o jsonpath='{.status.precaching.status}'
    4. 运行以下命令,检查预缓存是否在启动更新前完成:

      $ oc get cgu -n default cgu-operator-upgrade -ojsonpath='{.status.conditions}' | jq

      输出示例

      [
          {
            "lastTransitionTime": "2022-03-08T20:49:08.000Z",
            "message": "The ClusterGroupUpgrade CR is not enabled",
            "reason": "UpgradeNotStarted",
            "status": "False",
            "type": "Ready"
          },
          {
            "lastTransitionTime": "2022-03-08T20:55:30.000Z",
            "message": "Precaching is completed",
            "reason": "PrecachingCompleted",
            "status": "True",
            "type": "PrecachingDone"
          }
      ]

  5. 启动 Operator 更新。

    1. 运行以下命令,启用 cgu-operator-upgrade ClusterGroupUpgrade CR,并禁用预缓存来启动 Operator 更新:

      $ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-operator-upgrade \
      --patch '{"spec":{"enable":true, "preCaching": false}}' --type=merge
    2. 监控进程。在完成后,运行以下命令来确保策略兼容:

      $ oc get policies --all-namespaces

其他资源

10.3.4. 使用 PolicyGenTemplate CR 对丢失的 Operator 更新进行故障排除

在某些情况下,Topology Aware Lifecycle Manager (TALM)可能会因为过时的策略合规状态而丢失 Operator 更新。

在目录源更新后,Operator Lifecycle Manager (OLM)需要时间来更新订阅状态。当 TALM 决定是否需要补救时,订阅策略的状态可能会继续显示为合规。因此,订阅策略中指定的 Operator 不会升级。

要避免这种情况,请在 PolicyGenTemplate 中添加另一个目录源配置,并为需要更新的任何 Operator 在订阅中指定此配置。

流程

  1. PolicyGenTemplate 资源中添加目录源配置:

    - fileName: DefaultCatsrc.yaml
          remediationAction: inform
          policyName: "operator-catsrc-policy"
          metadata:
            name: redhat-operators
          spec:
            displayName: Red Hat Operators Catalog
            image: registry.example.com:5000/olm/redhat-operators:v{product-version}
            updateStrategy:
              registryPoll:
                interval: 1h
          status:
            connectionState:
                lastObservedState: READY
    - fileName: DefaultCatsrc.yaml
          remediationAction: inform
          policyName: "operator-catsrc-policy"
          metadata:
            name: redhat-operators-v2 1
          spec:
            displayName: Red Hat Operators Catalog v2 2
            image: registry.example.com:5000/olredhat-operators:<version> 3
            updateStrategy:
              registryPoll:
                interval: 1h
          status:
            connectionState:
                lastObservedState: READY
    1
    更新新配置的名称。
    2
    更新新配置的显示名称。
    3
    更新索引镜像 URL。此 fileName.spec.image 字段覆盖 DefaultCatsrc.yaml 文件中的任何配置。
  2. 更新 Subscription 资源,以指向需要更新的 Operator 的新配置:

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: operator-subscription
      namespace: operator-namspace
    # ...
    spec:
      source: redhat-operators-v2 1
    # ...
    1
    输入您在 PolicyGenTemplate 资源中定义的额外目录源配置的名称。

10.3.5. 一起执行平台和 Operator 更新

您可以同时执行平台和 Operator 更新。

先决条件

  • 安装 Topology Aware Lifecycle Manager(TALM)。
  • 将 GitOps Zero Touch Provisioning (ZTP) 更新至最新版本。
  • 使用 GitOps ZTP 置备一个或多个受管集群。
  • 以具有 cluster-admin 特权的用户身份登录。
  • 在 hub 集群中创建 RHACM 策略。

流程

  1. 按照 "forming a platform update" 和 "Performing an Operator update" 部分所述的步骤为更新创建 PolicyGenTemplate CR。
  2. 为平台和 Operator 更新应用准备工作。

    1. 使用平台更新准备工作、目录源更新和目标集群的 ClusterGroupUpgrade CR 将内容保存到 cgu-platform-operator-upgrade-prep.yml 文件中,例如:

      apiVersion: ran.openshift.io/v1alpha1
      kind: ClusterGroupUpgrade
      metadata:
        name: cgu-platform-operator-upgrade-prep
        namespace: default
      spec:
        managedPolicies:
        - du-upgrade-platform-upgrade-prep
        - du-upgrade-operator-catsrc-policy
        clusterSelector:
        - group-du-sno
        remediationStrategy:
          maxConcurrency: 10
        enable: true
    2. 运行以下命令,将 cgu-platform-operator-upgrade-prep.yml 文件应用到 hub 集群:

      $ oc apply -f cgu-platform-operator-upgrade-prep.yml
    3. 监控进程。在完成后,运行以下命令来确保策略兼容:

      $ oc get policies --all-namespaces
  3. 为平台创建 ClusterGroupUpdate CR,并将 spec.enable 字段设置为 false 的 Operator 更新。

    1. 将平台的内容和带有策略和目标集群的 Operator 更新 ClusterGroupUpdate CR 保存为 cgu-platform-operator-upgrade.yml 文件,如下例所示:

      apiVersion: ran.openshift.io/v1alpha1
      kind: ClusterGroupUpgrade
      metadata:
        name: cgu-du-upgrade
        namespace: default
      spec:
        managedPolicies:
        - du-upgrade-platform-upgrade 1
        - du-upgrade-operator-catsrc-policy 2
        - common-subscriptions-policy 3
        preCaching: true
        clusterSelector:
        - group-du-sno
        remediationStrategy:
          maxConcurrency: 1
        enable: false
      1
      这是平台更新策略。
      2
      这是包含要更新 Operator 的目录源信息的策略。预缓存功能需要它来确定要下载至受管集群的 Operator 镜像。
      3
      这是更新 Operator 的策略。
    2. 运行以下命令,将 cgu-platform-operator-upgrade.yml 文件应用到 hub 集群:

      $ oc apply -f cgu-platform-operator-upgrade.yml
  4. 可选:为平台和 Operator 更新缓存镜像。

    1. 运行以下命令,在 ClusterGroupUpgrade CR 中启用预缓存:

      $ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-du-upgrade \
      --patch '{"spec":{"preCaching": true}}' --type=merge
    2. 监控更新过程,并等待预缓存完成。在受管集群中运行以下命令来检查预缓存的状态:

      $ oc get jobs,pods -n openshift-talm-pre-cache
    3. 运行以下命令,检查预缓存是否在启动更新前完成:

      $ oc get cgu cgu-du-upgrade -ojsonpath='{.status.conditions}'
  5. 启动平台和 Operator 更新。

    1. 运行以下命令,启用 cgu-du-upgrade ClusterGroupUpgrade CR 来启动平台和 Operator 更新:

      $ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-du-upgrade \
      --patch '{"spec":{"enable":true, "preCaching": false}}' --type=merge
    2. 监控进程。在完成后,运行以下命令来确保策略兼容:

      $ oc get policies --all-namespaces
      注意

      可通过将设置配置为 spec.enable: true,从开始创建平台和 Operator 更新 CR。在这种情况下,更新会在预缓存完成后立即启动,且不需要手动启用 CR。

      预缓存和更新都创建额外的资源,如策略、放置规则、放置规则、受管集群操作和受管集群视图,以帮助完成这个过程。将 afterCompletion.deleteObjects 字段设置为 true 在更新完成后删除所有这些资源。

10.3.6. 使用 PolicyGenTemplate CR 从部署的集群中删除 Performance Addon Operator 订阅

在早期版本的 OpenShift Container Platform 中,Performance Addon Operator 为应用程序提供了自动、低延迟的性能调整。在 OpenShift Container Platform 4.11 或更高版本中,这些功能是 Node Tuning Operator 的一部分。

不要在运行 OpenShift Container Platform 4.11 或更高版本的集群中安装 Performance Addon Operator。如果您升级到 OpenShift Container Platform 4.11 或更高版本,Node Tuning Operator 会自动删除 Performance Addon Operator。

注意

您需要删除创建 Performance Addon Operator 订阅的任何策略,以防止重新安装 Operator。

参考 DU 配置集在 PolicyGenTemplate CR common-ranGen.yaml 中包含 Performance Addon Operator。要从部署的受管集群中删除订阅,您必须更新 common-ranGen.yaml

注意

如果在 OpenShift Container Platform 4.11 或更高版本上安装 Performance Addon Operator 4.10.3-5 或更高版本,Performance Addon Operator 会检测到集群版本并自动休眠,以避免与 Node Tuning Operator 正常工作。但是,为了确保获得最佳性能,请从 OpenShift Container Platform 4.11 集群中删除 Performance Addon Operator。

先决条件

  • 创建一个 Git 存储库,在其中管理自定义站点配置数据。存储库必须可从 hub 集群访问,并定义为 Argo CD 的源存储库。
  • 更新至 OpenShift Container Platform 4.11 或更高版本。
  • 以具有 cluster-admin 特权的用户身份登录。

流程

  1. common-ranGen.yaml 文件中,为 Performance Addon Operator 命名空间、Operator 组和订阅的 complianceType 更改为 mustnothave

    - fileName: PaoSubscriptionNS.yaml
      policyName: "subscriptions-policy"
      complianceType: mustnothave
    - fileName: PaoSubscriptionOperGroup.yaml
      policyName: "subscriptions-policy"
      complianceType: mustnothave
    - fileName: PaoSubscription.yaml
      policyName: "subscriptions-policy"
      complianceType: mustnothave
  2. 将更改与自定义站点存储库合并,并等待 ArgoCD 应用程序对 hub 集群同步更改。common-subscriptions-policy 策略的状态更改为 Non-Compliant
  3. 使用 Topology Aware Lifecycle Manager 将更改应用到您的目标集群。有关滚动配置更改的更多信息,请参阅“附加资源”部分。
  4. 监控进程。当目标集群的 common-subscriptions-policy 策略的状态为 Compliant 时,Performance Addon Operator 已从集群中移除。运行以下命令,获取 common-subscriptions-policy 的状态:

    $ oc get policy -n ztp-common common-subscriptions-policy
  5. common-ranGen.yaml 文件中的 spec.sourceFiles 中删除 Performance Addon Operator 命名空间、Operator 组和订阅 CR。
  6. 将更改与自定义站点存储库合并,并等待 ArgoCD 应用程序对 hub 集群同步更改。策略保持合规。

10.3.7. 在单节点 OpenShift 集群中使用 TALM 预缓存用户指定的镜像

在升级应用程序前,您可以在单节点 OpenShift 集群上预缓存应用程序相关的工作负载镜像。

您可以使用以下自定义资源(CR)指定预缓存作业的配置选项:

  • PreCachingConfig CR
  • ClusterGroupUpgrade CR
注意

PreCachingConfig CR 中的所有字段都是可选的。

PreCachingConfig CR 示例

apiVersion: ran.openshift.io/v1alpha1
kind: PreCachingConfig
metadata:
  name: exampleconfig
  namespace: exampleconfig-ns
spec:
  overrides: 1
    platformImage: quay.io/openshift-release-dev/ocp-release@sha256:3d5800990dee7cd4727d3fe238a97e2d2976d3808fc925ada29c559a47e2e1ef
    operatorsIndexes:
      - registry.example.com:5000/custom-redhat-operators:1.0.0
    operatorsPackagesAndChannels:
      - local-storage-operator: stable
      - ptp-operator: stable
      - sriov-network-operator: stable
  spaceRequired: 30 Gi 2
  excludePrecachePatterns: 3
    - aws
    - vsphere
  additionalImages: 4
    - quay.io/exampleconfig/application1@sha256:3d5800990dee7cd4727d3fe238a97e2d2976d3808fc925ada29c559a47e2e1ef
    - quay.io/exampleconfig/application2@sha256:3d5800123dee7cd4727d3fe238a97e2d2976d3808fc925ada29c559a47adfaef
    - quay.io/exampleconfig/applicationN@sha256:4fe1334adfafadsf987123adfffdaf1243340adfafdedga0991234afdadfsa09

1
默认情况下,TALM 会自动填充 platformImageoperatorIndexes 和受管集群策略中的 operatorsPackagesAndChannels 字段。您可以指定值来覆盖这些字段的默认 TALM-derived 值。
2
指定集群上的最低磁盘空间。如果未指定,TALM 为 OpenShift Container Platform 镜像定义一个默认值。磁盘空间字段必须包含整数值和存储单元。例如:40 GiB200 MB1 TiB
3
根据镜像名称匹配,指定要从预缓存中排除的镜像。
4
指定要预缓存的额外镜像列表。

带有 PreCachingConfig CR 引用的 ClusterGroupUpgrade CR 示例

apiVersion: ran.openshift.io/v1alpha1
kind: ClusterGroupUpgrade
metadata:
  name: cgu
spec:
  preCaching: true 1
  preCachingConfigRef:
    name: exampleconfig 2
    namespace: exampleconfig-ns 3

1
preCaching 字段设置为 true 可启用预缓存作业。
2
preCachingConfigRef.name 字段指定您要使用的 PreCachingConfig CR。
3
preCachingConfigRef.namespace 指定您要使用的 PreCachingConfig CR 的命名空间。

10.3.7.1. 为预缓存创建自定义资源

您必须在 ClusterGroupUpgrade CR 之前或同时创建 PreCachingConfig CR。

  1. 使用您要预缓存的额外镜像列表创建 PreCachingConfig CR。

    apiVersion: ran.openshift.io/v1alpha1
    kind: PreCachingConfig
    metadata:
      name: exampleconfig
      namespace: default 1
    spec:
    [...]
      spaceRequired: 30Gi 2
      additionalImages:
        - quay.io/exampleconfig/application1@sha256:3d5800990dee7cd4727d3fe238a97e2d2976d3808fc925ada29c559a47e2e1ef
        - quay.io/exampleconfig/application2@sha256:3d5800123dee7cd4727d3fe238a97e2d2976d3808fc925ada29c559a47adfaef
        - quay.io/exampleconfig/applicationN@sha256:4fe1334adfafadsf987123adfffdaf1243340adfafdedga0991234afdadfsa09
    1
    namespace 必须可以被 hub 集群访问。
    2
    建议设置最小磁盘空间所需字段,以确保预缓存镜像有足够的存储空间。
  2. 创建一个 ClusterGroupUpgrade CR,并将 preCaching 字段设置为 true 并指定上一步中创建的 PreCachingConfig CR:

    apiVersion: ran.openshift.io/v1alpha1
    kind: ClusterGroupUpgrade
    metadata:
      name: cgu
      namespace: default
    spec:
      clusters:
      - sno1
      - sno2
      preCaching: true
      preCachingConfigRef:
      - name: exampleconfig
        namespace: default
      managedPolicies:
        - du-upgrade-platform-upgrade
        - du-upgrade-operator-catsrc-policy
        - common-subscriptions-policy
      remediationStrategy:
        timeout: 240
    警告

    在集群上安装镜像后,您无法更改或删除它们。

  3. 当您要启动预缓存镜像时,请运行以下命令应用 ClusterGroupUpgrade CR:

    $ oc apply -f cgu.yaml

TALM 验证 ClusterGroupUpgrade CR。

此时,您可以继续 TALM 预缓存工作流。

注意

所有站点都同时预缓存。

验证

  1. 运行以下命令,检查应用 ClusterUpgradeGroup CR 的 hub 集群上的预缓存状态:

    $ oc get cgu <cgu_name> -n <cgu_namespace> -oyaml

    输出示例

      precaching:
        spec:
          platformImage: quay.io/openshift-release-dev/ocp-release@sha256:3d5800990dee7cd4727d3fe238a97e2d2976d3808fc925ada29c559a47e2e1ef
          operatorsIndexes:
            - registry.example.com:5000/custom-redhat-operators:1.0.0
          operatorsPackagesAndChannels:
            - local-storage-operator: stable
            - ptp-operator: stable
            - sriov-network-operator: stable
          excludePrecachePatterns:
            - aws
            - vsphere
          additionalImages:
            - quay.io/exampleconfig/application1@sha256:3d5800990dee7cd4727d3fe238a97e2d2976d3808fc925ada29c559a47e2e1ef
            - quay.io/exampleconfig/application2@sha256:3d5800123dee7cd4727d3fe238a97e2d2976d3808fc925ada29c559a47adfaef
            - quay.io/exampleconfig/applicationN@sha256:4fe1334adfafadsf987123adfffdaf1243340adfafdedga0991234afdadfsa09
          spaceRequired: "30"
        status:
          sno1: Starting
          sno2: Starting

    通过检查受管策略是否存在预缓存配置来验证预缓存配置。ClusterGroupUpgradePreCachingConfig CR 的有效配置会导致以下状态:

    有效 CR 的输出示例

    - lastTransitionTime: "2023-01-01T00:00:01Z"
      message: All selected clusters are valid
      reason: ClusterSelectionCompleted
      status: "True"
      type: ClusterSelected
    - lastTransitionTime: "2023-01-01T00:00:02Z"
      message: Completed validation
      reason: ValidationCompleted
      status: "True"
      type: Validated
    - lastTransitionTime: "2023-01-01T00:00:03Z"
      message: Precaching spec is valid and consistent
      reason: PrecacheSpecIsWellFormed
      status: "True"
      type: PrecacheSpecValid
    - lastTransitionTime: "2023-01-01T00:00:04Z"
      message: Precaching in progress for 1 clusters
      reason: InProgress
      status: "False"
      type: PrecachingSucceeded

    无效的 PreCachingConfig CR 示例

    Type:    "PrecacheSpecValid"
    Status:  False,
    Reason:  "PrecacheSpecIncomplete"
    Message: "Precaching spec is incomplete: failed to get PreCachingConfig resource due to PreCachingConfig.ran.openshift.io "<pre-caching_cr_name>" not found"

  2. 您可以在受管集群中运行以下命令来查找预缓存作业:

    $ oc get jobs -n openshift-talo-pre-cache

    预缓存作业正在进行的示例

    NAME        COMPLETIONS       DURATION      AGE
    pre-cache   0/1               1s            1s

  3. 您可以运行以下命令来检查为预缓存作业创建的 pod 状态:

    $ oc describe pod pre-cache -n openshift-talo-pre-cache

    预缓存作业正在进行的示例

    Type        Reason              Age    From              Message
    Normal      SuccesfulCreate     19s    job-controller    Created pod: pre-cache-abcd1

  4. 您可以运行以下命令来获取作业状态的实时更新:

    $ oc logs -f pre-cache-abcd1 -n openshift-talo-pre-cache
  5. 要验证预缓存作业是否已成功完成,请运行以下命令:

    $ oc describe pod pre-cache -n openshift-talo-pre-cache

    完成的预缓存作业示例

    Type        Reason              Age    From              Message
    Normal      SuccesfulCreate     5m19s  job-controller    Created pod: pre-cache-abcd1
    Normal      Completed           19s    job-controller    Job completed

  6. 要验证镜像是否在单节点 OpenShift 上成功预缓存,请执行以下操作:

    1. 以 debug 模式进入节点:

      $ oc debug node/cnfdf00.example.lab
    2. 将 root 更改为 host

      $ chroot /host/
    3. 搜索所需的镜像:

      $ sudo podman images | grep <operator_name>

10.3.8. 关于为 GitOps ZTP 自动创建的 ClusterGroupUpgrade CR

TALM 有一个名为 ManagedClusterForCGU 的控制器,它监控 hub 集群上的 ManagedCluster CR 的 Ready 状态,并为 GitOps Zero Touch Provisioning (ZTP) 创建 ClusterGroupUpgrade CR。

对于没有应用 ztp-done 标签的 Ready 状态中的任何受管集群,ManagedClusterForCGU 控制器会在 ztp-install 命名空间中创建一个带有在 GitOps ZTP 进程中创建的关联 RHACM 策略的 ClusterGroupUpgrade CR。然后,TALM 会修复自动创建 ClusterGroupUpgrade CR 中列出的一组配置策略,将配置 CR 推送到受管集群。

如果集群变为 Ready 时,没有用于受管集群的策略,则会创建一个没有策略的 ClusterGroupUpgrade CR。完成 ClusterGroupUpgrade 受管集群后,受管集群被标记为 ztp-done。如果要对该受管集群应用策略,请手动创建一个 ClusterGroupUpgrade 作为第 2 天操作。

GitOps ZTP 自动创建的 ClusterGroupUpgrade CR 示例

apiVersion: ran.openshift.io/v1alpha1
kind: ClusterGroupUpgrade
metadata:
  generation: 1
  name: spoke1
  namespace: ztp-install
  ownerReferences:
  - apiVersion: cluster.open-cluster-management.io/v1
    blockOwnerDeletion: true
    controller: true
    kind: ManagedCluster
    name: spoke1
    uid: 98fdb9b2-51ee-4ee7-8f57-a84f7f35b9d5
  resourceVersion: "46666836"
  uid: b8be9cd2-764f-4a62-87d6-6b767852c7da
spec:
  actions:
    afterCompletion:
      addClusterLabels:
        ztp-done: "" 1
      deleteClusterLabels:
        ztp-running: ""
      deleteObjects: true
    beforeEnable:
      addClusterLabels:
        ztp-running: "" 2
  clusters:
  - spoke1
  enable: true
  managedPolicies:
  - common-spoke1-config-policy
  - common-spoke1-subscriptions-policy
  - group-spoke1-config-policy
  - spoke1-config-policy
  - group-spoke1-validator-du-policy
  preCaching: false
  remediationStrategy:
    maxConcurrency: 1
    timeout: 240

1
当 TALM 完成集群配置时,应用到受管集群。
2
当 TALM 开始部署配置策略时,应用到受管集群。
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.