×

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

在即将发布的 OpenShift Container Platform 版本中,将弃用使用PolicyGenTemplate CR 来管理和部署策略到托管集群的功能。可以使用 Red Hat Advanced Cluster Management (RHACM) 和PolicyGenerator CR 来实现等效且改进的功能。

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

设置断开连接的环境

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

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

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

    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. 保存所需的已镜像平台镜像的镜像签名。必须将镜像签名添加到平台更新的PolicyGenTemplate CR 中。要获取镜像签名,请执行以下步骤

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

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

        $ ARCHITECTURE=<cluster_architecture> (1)
        1 指定集群的架构,例如x86_64aarch64s390xppc64le
      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构建图数据初始化容器

      2. 制作上游图的本地副本。在断开连接的环境中托管一个具有访问托管集群权限的httphttps服务器上的更新图。要下载更新图,请使用以下命令

        $ 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 镜像。

使用 PolicyGenTemplate CR 执行平台更新

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

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

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

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

  • 镜像所需的镜像仓库。

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

  • 在中心集群中创建 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.17"
              upstream: http://upgrade.example.com/images/upgrade-graph_stable-4.17
              desiredUpdate:
                version: 4.17.4
            status:
              history:
                - version: 4.17.4
                  state: "Completed"
      1 ConfigMap CR 包含要更新到的所需发行版镜像的签名。
      2 显示所需 OpenShift Container Platform 发行版的镜像签名。从在“设置环境”部分中按照步骤保存的checksum-${OCP_RELEASE_NUMBER}.yaml文件中获取签名。
      3 显示包含所需 OpenShift Container Platform 镜像的镜像仓库。从在“设置环境”部分中按照步骤保存的imageContentSources.yaml文件中获取镜像。
      4 显示用于触发更新的ClusterVersion CR。对于镜像预缓存,channelupstreamdesiredVersion字段都是必需的。

      PolicyGenTemplate CR 生成两个策略

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

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

    2. du-upgrade.yaml文件的内容添加到 GitOps ZTP Git 仓库中PolicyGenTemplate 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

使用 PolicyGenTemplate CR 执行 Operator 更新

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

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

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

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

  • 镜像所需的索引镜像、bundle 镜像以及 bundle 镜像中引用的所有 Operator 镜像。

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

  • 在中心集群中创建 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-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 索引镜像 URL 包含所需的 Operator 镜像。如果索引镜像始终推送到相同的镜像名称和标签,则不需要此更改。
      2 使用registryPoll.interval字段设置 Operator 生命周期管理器 (OLM) 轮询索引镜像以查找新 Operator 版本的频率。如果始终为 y 流和 z 流 Operator 更新推送新的索引镜像标签,则不需要此更改。可以将registryPoll.interval字段设置为较短的间隔以加快更新速度,但是较短的间隔会增加计算负载。为了抵消这种行为,您可以在更新完成后将registryPoll.interval恢复为默认值。
      3 目录连接的最后观察到的状态。READY值确保CatalogSource策略已准备好,表明索引 pod 已被拉取并正在运行。这样,TALM 就可以根据最新的策略合规性状态升级 Operator。
    2. 此更新生成一个策略du-upgrade-operator-catsrc-policy,以使用包含所需 Operator 镜像的新索引镜像更新redhat-operators-disconnected目录源。

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

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

      • 为来自不同目录源的所需 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.17 应用的 Operator 的默认通道为stableperformance-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 仓库拉取更改,并在中心集群上生成策略。

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

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

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

    1. 将Operator更新ClusterGroupUpgrade CR的内容,以及由公共PolicyGenTemplate和目标集群创建的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 镜像预缓存功能需要此策略才能从目录源检索Operator镜像。
      2 该策略包含Operator订阅。如果您遵循参考PolicyGenTemplate的结构和内容,所有Operator订阅都将分组到common-subscriptions-policy策略中。

      一个ClusterGroupUpgrade CR只能预缓存ClusterGroupUpgrade CR中包含的一个目录源中定义的所需Operator的镜像。如果所需Operator来自不同的目录源(例如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
其他资源

使用PolicyGenTemplate CR排查遗漏的Operator更新

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

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

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

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

    - fileName: DefaultCatsrc.yaml
          remediationAction: inform
          policyName: "operator-catsrc-policy"
          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
    - fileName: DefaultCatsrc.yaml
          remediationAction: inform
          policyName: "operator-catsrc-policy"
          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。此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-disconnected-v2 (1)
    # ...
    1 输入您在PolicyGenTemplate资源中定义的附加目录源配置的名称。

同时执行平台和Operator更新

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

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

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

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

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

  • 在中心集群中创建 RHACM 策略。

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

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

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

    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文件应用于中心集群。

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

使用PolicyGenTemplate 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配置文件在PolicyGenTemplate CR common-ranGen.yaml中包含性能附加组件Operator。要从已部署的托管集群中删除订阅,您必须更新common-ranGen.yaml

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

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

  • 更新到 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策略的状态将更改为不符合

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

  4. 监控流程。当目标集群的 common-subscriptions-policy 策略状态为 符合 时,表示 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 集群。策略保持符合。

在单节点 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 命名空间必须可被 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. 以调试模式进入节点

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

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

      $ sudo podman images | grep <operator_name>

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

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

对于任何未应用 ztp-done 标签的处于 Ready 状态的托管集群,ManagedClusterForCGU 控制器会在 ztp-install 命名空间中自动创建一个 ClusterGroupUpgrade CR,以及在 GitOps ZTP 过程中创建的关联 RHACM 策略。然后,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 开始部署配置策略时,应用于托管集群。