×

您可以使用拓扑感知生命周期管理器 (TALM) 来管理您使用 GitOps 零接触配置 (ZTP) 和拓扑感知生命周期管理器 (TALM) 部署的托管集群的软件生命周期。TALM 使用 Red Hat 高级集群管理 (RHACM) PolicyGenerator 策略来管理和控制应用于目标集群的更改。

仅将 PolicyGenerator 资源与 GitOps ZTP 一起使用属于技术预览功能。技术预览功能不受 Red Hat 生产服务级别协议 (SLA) 支持,并且功能可能不完整。Red Hat 不建议在生产环境中使用它们。这些功能可让您抢先体验即将推出的产品功能,从而能够在开发过程中测试功能并提供反馈。

有关 Red Hat 技术预览功能的支持范围的更多信息,请参见 技术预览功能支持范围

其他资源

设置断开连接的环境

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

您必须先将要更新的平台镜像和 Operator 镜像镜像到您的镜像注册表中,然后才能使用 TALM 更新您的断开连接的集群。请完成以下步骤以镜像镜像

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

    1. 镜像所需的 OpenShift Container Platform 镜像存储库。请确保按照“镜像 OpenShift Container Platform 镜像存储库”过程中链接的步骤镜像所需的平台镜像。将 `imageContentSources` 部分的内容保存在 `imageContentSources.yaml` 文件中

      示例输出
      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. 保存已镜像的所需平台镜像的镜像签名。您必须将镜像签名添加到平台更新的 `PolicyGenerator` 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 更新服务。

        有关如何在集线器集群上设置图的更多信息,请参见 为 OpenShift 更新服务部署 Operator构建图数据 init 容器

      2. 创建上游图的本地副本。在断开连接的环境中托管具有访问托管集群权限的 `http` 或 `https` 服务器上的更新图。要下载更新图,请使用以下命令

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

    • 镜像 Operator 目录。请确保按照“将 Operator 目录镜像到与断开连接的集群一起使用”部分中的步骤镜像所需的 Operator 镜像。

其他资源

使用 PolicyGenerator CR 执行平台更新

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

先决条件
  • 安装拓扑感知生命周期管理器 (TALM)。

  • 将 GitOps 零接触配置 (ZTP) 更新到最新版本。

  • 使用 GitOps ZTP 配置一个或多个托管集群。

  • 镜像所需的镜像存储库。

  • 以具有 `cluster-admin` 权限的用户身份登录。

  • 在集线器集群中创建 RHACM 策略。

步骤
  1. 为平台更新创建 `PolicyGenerator` CR

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

      平台更新的PolicyGenerator 示例
      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-platform-upgrade
            policyAnnotations:
              ran.openshift.io/ztp-deploy-wave: "100"
            manifests:
              - path: source-crs/ClusterVersion.yaml (1)
                patches:
                  - metadata:
                      name: version
                    spec:
                      channel: stable-4.17
                      desiredUpdate:
                          version: 4.17.4
                      upstream: http://upgrade.example.com/images/upgrade-graph_stable-4.17
                    status:
                      history:
                          - state: Completed
                            version: 4.17.4
          - name: du-upgrade-platform-upgrade-prep
            policyAnnotations:
              ran.openshift.io/ztp-deploy-wave: "1"
            manifests:
              - path: source-crs/ImageSignature.yaml (2)
              - path: source-crs/DisconnectedICSP.yaml
                patches:
                  - 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
      1 显示用于触发更新的ClusterVersion CR。为了进行镜像预缓存,channelupstreamdesiredVersion 字段都是必需的。
      2 ImageSignature.yaml 包含所需发行版镜像的镜像签名。镜像签名用于在应用平台更新之前验证镜像。
      3 显示包含所需 OpenShift Container Platform 镜像的镜像仓库。从“设置环境”部分的步骤中保存的imageContentSources.yaml 文件中获取镜像。

      PolicyGenerator CR 生成两个策略

      • du-upgrade-platform-upgrade-prep 策略执行平台更新的准备工作。它创建所需发行版镜像签名的ConfigMap CR,创建镜像仓库的镜像内容源,并使用所需的更新通道和断开连接的环境中托管集群可访问的更新图来更新集群版本。

      • du-upgrade-platform-upgrade 策略用于执行平台升级。

    2. du-upgrade.yaml 文件的内容添加到 GitOps ZTP Git 仓库中位于PolicyGenerator CR 的kustomization.yaml 文件中,并将更改推送到 Git 仓库。

      ArgoCD 从 Git 仓库拉取更改并在中心集群上生成策略。

    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 应用到中心集群

      $ 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. 监控更新过程并等待预缓存完成。在中心集群上运行以下命令检查预缓存的状态

      $ 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
其他资源

使用 PolicyGenerator CR 执行操作符更新

您可以使用 TALM 执行操作符更新。

先决条件
  • 安装拓扑感知生命周期管理器 (TALM)。

  • 将 GitOps 零接触配置 (ZTP) 更新到最新版本。

  • 使用 GitOps ZTP 配置一个或多个托管集群。

  • 镜像所需的索引镜像、捆绑镜像以及捆绑镜像中引用的所有操作符镜像。

  • 以具有 `cluster-admin` 权限的用户身份登录。

  • 在集线器集群中创建 RHACM 策略。

步骤
  1. 更新操作符更新的PolicyGenerator CR。

    1. du-upgrade.yaml 文件中,使用以下附加内容更新du-upgrade PolicyGenerator 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-disconnected
                    spec:
                      displayName: Red Hat Operators Catalog
                      image: registry.example.com:5000/olm/redhat-operators-disconnected:v4.17 (1)
                      updateStrategy: (2)
                          registryPoll:
                              interval: 1h
                    status:
                      connectionState:
                          lastObservedState: READY (3)
      1 包含所需的操作符镜像。如果索引镜像始终推送到相同的镜像名称和标签,则不需要此更改。
      2 使用registryPoll.interval 字段设置操作符生命周期管理器 (OLM) 轮询索引镜像以查找新操作符版本的频率。如果始终为 y 流和 z 流操作符更新推送新的索引镜像标签,则不需要此更改。可以将registryPoll.interval 字段设置为较短的间隔以加快更新速度,但是较短的间隔会增加计算负载。为了抵消这种情况,可以在更新完成后将registryPoll.interval恢复为默认值。
      3 显示目录连接的观察状态。READY 值确保CatalogSource 策略已准备好,表明索引 pod 已被拉取并正在运行。通过这种方式,TALM 基于最新的策略符合性状态升级操作符。
    2. 此更新生成一个策略du-upgrade-operator-catsrc-policy,以使用包含所需操作符镜像的新索引镜像更新redhat-operators-disconnected 目录源。

      如果您想对操作符使用镜像预缓存,并且存在来自redhat-operators-disconnected以外的不同目录源的操作符,则必须执行以下任务

      • 为不同的目录源准备一个单独的目录源策略,其中包含新的索引镜像或注册表轮询间隔更新。

      • 为来自不同目录源的所需操作符准备一个单独的订阅策略。

      例如,所需的 SRIOV-FEC 操作符可在certified-operators 目录源中使用。要更新目录源和操作符订阅,请添加以下内容以生成两个策略du-upgrade-fec-catsrc-policydu-upgrade-subscriptions-fec-policy

      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-fec-catsrc-policy
            policyAnnotations:
              ran.openshift.io/ztp-deploy-wave: "1"
            manifests:
              - path: source-crs/DefaultCatsrc.yaml
                patches:
                  - 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
          - name: du-upgrade-subscriptions-fec-policy
            policyAnnotations:
              ran.openshift.io/ztp-deploy-wave: "2"
            manifests:
              - path: source-crs/AcceleratorsSubscription.yaml
                patches:
                  - spec:
                      channel: stable
                      source: certified-operators
    3. 如果存在,请删除通用PolicyGenerator CR 中指定的订阅通道。更新使用 GitOps ZTP 镜像中的默认订阅通道。

      通过 GitOps ZTP 4.17 应用的操作符的默认通道为stableperformance-addon-operator 除外。从 OpenShift Container Platform 4.11 开始,performance-addon-operator 功能已移至node-tuning-operator。对于 4.10 版本,PAO 的默认通道为v4.10。您也可以在通用PolicyGenerator CR 中指定默认通道。

    4. PolicyGenerator CR 更新推送到 GitOps ZTP Git 仓库。

      ArgoCD 从 Git 仓库拉取更改并在中心集群上生成策略。

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

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

    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. 运行以下命令将策略应用到中心集群

      $ oc apply -f cgu-operator-upgrade-prep.yml
    3. 监控更新过程。完成后,运行以下命令确保策略符合要求

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

    1. 将操作符更新ClusterGroupUpdate CR 的内容(包括从通用PolicyGenerator 创建的du-upgrade-operator-catsrc-policy 策略和订阅策略以及目标集群)保存到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 镜像预缓存功能需要此策略才能从目录源检索操作符镜像。
      2 该策略包含操作符订阅。如果您遵循了参考PolicyGenTemplates 的结构和内容,所有操作符订阅都将分组到common-subscriptions-policy 策略中。

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

    2. 通过运行以下命令将ClusterGroupUpgrade CR 应用于中心集群

      $ 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
其他资源

排查 PolicyGenerator CR 中遗漏的 Operator 更新

在某些情况下,由于策略合规性状态过期,拓扑感知生命周期管理器 (TALM) 可能会错过 Operator 更新。

目录源更新后,Operator 生命周期管理器 (OLM) 需要一段时间才能更新订阅状态。订阅策略的状态可能会继续显示为符合要求,而 TALM 决定是否需要补救。结果,订阅策略中指定的 Operator 不会升级。

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

步骤
  1. PolicyGenerator资源中添加目录源配置

    manifests:
    - path: source-crs/DefaultCatsrc.yaml
      patches:
        - metadata:
            name: redhat-operators-disconnected
          spec:
            displayName: Red Hat Operators Catalog
            image: registry.example.com:5000/olm/redhat-operators-disconnected:v{product-version}
            updateStrategy:
                registryPoll:
                    interval: 1h
          status:
            connectionState:
                lastObservedState: READY
    - path: source-crs/DefaultCatsrc.yaml
      patches:
        - metadata:
            name: redhat-operators-disconnected-v2 (1)
          spec:
            displayName: Red Hat Operators Catalog v2 (2)
            image: registry.example.com:5000/olm/redhat-operators-disconnected:<version> (3)
            updateStrategy:
                registryPoll:
                    interval: 1h
          status:
            connectionState:
                lastObservedState: READY
    1 更新新配置的名称。
    2 更新新配置的显示名称。
    3 更新索引镜像 URL。此policies.manifests.patches.spec.image字段会覆盖DefaultCatsrc.yaml文件中任何配置。
  2. 更新Subscription资源以指向为需要更新的 Operators 定义的新配置

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

同时执行平台和 Operator 更新

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

先决条件
  • 安装拓扑感知生命周期管理器 (TALM)。

  • 将 GitOps 零接触配置 (ZTP) 更新到最新版本。

  • 使用 GitOps ZTP 配置一个或多个托管集群。

  • 以具有 `cluster-admin` 权限的用户身份登录。

  • 在集线器集群中创建 RHACM 策略。

步骤
  1. 按照“执行平台更新”和“执行 Operator 更新”部分中描述的步骤创建更新的PolicyGenerator 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文件应用于中心集群

      $ oc apply -f cgu-platform-operator-upgrade-prep.yml
    3. 监控该过程。完成后,运行以下命令确保策略符合要求

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

    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 此策略包含要更新的 Operators 的目录源信息。预缓存功能需要此信息来确定要下载到托管集群的哪些 Operator 镜像。
      3 这是更新 Operators 的策略。
    2. 通过运行以下命令将cgu-platform-operator-upgrade.yml文件应用于中心集群

      $ 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会在更新完成后删除所有这些资源。

使用 PolicyGenerator CR 从已部署集群中删除性能附加组件 Operator 订阅

在早期版本的 OpenShift Container Platform 中,性能附加组件 Operator 为应用程序提供自动的低延迟性能调整。在 OpenShift Container Platform 4.11 或更高版本中,这些功能是节点调优 Operator 的一部分。

不要在运行 OpenShift Container Platform 4.11 或更高版本的集群上安装性能附加组件 Operator。如果您升级到 OpenShift Container Platform 4.11 或更高版本,节点调优 Operator 会自动删除性能附加组件 Operator。

您需要删除创建性能附加组件 Operator 订阅的任何策略,以防止重新安装 Operator。

参考 DU 配置文件在PolicyGenerator CR acm-common-ranGen.yaml中包含性能附加组件 Operator。要从已部署的托管集群中删除订阅,您必须更新acm-common-ranGen.yaml

如果您在 OpenShift Container Platform 4.11 或更高版本上安装性能附加组件 Operator 4.10.3-5 或更高版本,则性能附加组件 Operator 会检测集群版本并自动休眠,以避免干扰节点调优 Operator 功能。但是,为了确保最佳性能,请从您的 OpenShift Container Platform 4.11 集群中删除性能附加组件 Operator。

先决条件
  • 创建一个 Git 仓库来管理您的自定义站点配置数据。该仓库必须可从中心集群访问,并被定义为 ArgoCD 的源仓库。

  • 更新到 OpenShift Container Platform 4.11 或更高版本。

  • 以具有 `cluster-admin` 权限的用户身份登录。

步骤
  1. acm-common-ranGen.yaml文件中,将性能附加组件 Operator 命名空间、Operator 组和订阅的complianceType更改为mustnothave

    - name: group-du-sno-pg-subscriptions-policy
      policyAnnotations:
        ran.openshift.io/ztp-deploy-wave: "2"
      manifests:
        - path: source-crs/PaoSubscriptionNS.yaml
        - path: source-crs/PaoSubscriptionOperGroup.yaml
        - path: source-crs/PaoSubscription.yaml
  2. 将更改与您的自定义站点存储库合并,然后等待 ArgoCD 应用程序将更改同步到中心集群。common-subscriptions-policy策略的状态将更改为不符合

  3. 使用拓扑感知生命周期管理器将更改应用于您的目标集群。有关推出配置更改的更多信息,请参阅“附加资源”部分。

  4. 监控该过程。当目标集群的common-subscriptions-policy策略状态为符合时,性能附加组件操作符已从集群中删除。运行以下命令获取common-subscriptions-policy的状态

    $ oc get policy -n ztp-common common-subscriptions-policy
  5. acm-common-ranGen.yaml文件中的policies.manifests中删除性能附加组件操作符命名空间、操作符组和订阅 CR。

  6. 将更改与您的自定义站点存储库合并,然后等待 ArgoCD 应用程序将更改同步到中心集群。策略保持符合。

在单节点 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 会自动填充platformImageoperatorsIndexesoperatorsPackagesAndChannels字段,这些字段来自托管集群的策略。您可以指定值来覆盖这些字段的默认 TALM 派生值。
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 的命名空间。

创建用于预缓存的自定义资源

您必须在创建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 命名空间必须对中心集群可见。
    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 的中心集群上的预缓存状态:

    $ 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. 以调试模式进入节点

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

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

      $ sudo podman images | grep <operator_name>
其他资源

关于 GitOps ZTP 的自动创建的 ClusterGroupUpgrade CR

TALM 具有一个名为ManagedClusterForCGU的控制器,它监控中心集群上ManagedCluster CR 的就绪状态,并为 GitOps 零接触配置 (ZTP) 创建ClusterGroupUpgrade CR。

对于任何处于就绪状态且未应用ztp-done标签的托管集群,ManagedClusterForCGU控制器都会在ztp-install命名空间中自动创建一个ClusterGroupUpgrade CR,以及在 GitOps ZTP 过程中创建的关联 RHACM 策略。然后,TALM 将修复自动创建的ClusterGroupUpgrade CR 中列出的配置策略集,以将配置 CR 推送到托管集群。

如果集群变为就绪时没有托管集群的策略,则会创建一个没有策略的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 开始部署配置策略时应用于托管集群。