支持控制台（Console）开发人员开始试用联系人

19.10. 使用 Topology Aware Lifecycle Manager 更新受管集群

您可以使用 Topology Aware Lifecycle Manager (TALM) 来管理 OpenShift Container Platform 受管集群的软件生命周期。TALM 使用 Red Hat Advanced Cluster Management(RHACM)策略在目标集群中进行更改。

重要

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

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

其他资源

19.10.1. 在断开连接的环境中更新集群

您可以使用 GitOps ZTP 和 Topology Aware Lifecycle Manager (TALM) 为您部署的受管集群升级受管集群和 Operator。

19.10.1.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=<server_architecture>

      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. 生成上游图形的本地副本。在可访问受管集群的断开连接的环境中的 http 或 https 服务器上托管更新图表。要下载更新图表，请使用以下命令： 

        $ curl -s https://api.openshift.com/api/upgrades_info/v1/graph?channel=stable-4.10 -o ~/upgrade-graph_stable-4.10

  • 对于 Operator 更新，您必须执行以下任务：

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

其他资源

19.10.1.2. 执行平台更新

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

先决条件

  • 安装 Topology Aware Lifecycle Manager(TALM)。
  • 将 ZTP 更新至最新版本。
  • 使用 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-prep"
      metadata:
        name: version
        annotations:
          ran.openshift.io/ztp-deploy-wave: "1"
      spec:
        channel: "stable-4.10"
        upstream: http://upgrade.example.com/images/upgrade-graph_stable-4.10
    - fileName: ClusterVersion.yaml 5
      policyName: "platform-upgrade"
      metadata:
        name: version
      spec:
        channel: "stable-4.10"
        upstream: http://upgrade.example.com/images/upgrade-graph_stable-4.10
        desiredUpdate:
          version: 4.10.4
      status:
        history:
          - version: 4.10.4
            state: "Completed"

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

      PolicyGenTemplate CR 会生成两个策略：

      • du-upgrade-platform-upgrade-prep 策略为平台更新做准备。它为所需的发行版本镜像签名创建 ConfigMap CR，创建镜像的发行镜像存储库的镜像内容源，并使用所需的更新频道更新集群版本，以及在断开连接的环境中由 spoke 集群访问的更新图。
      • du-upgrade-platform-upgrade 策略用于执行平台升级。

    2. 对于 PolicyGenTemplate CR，将 du-upgrade.yaml 文件内容添加到 kustomization.yaml 文件（在 ZTP Git 存储库中），并将更改推送到 Git 存储库。

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

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

      $ oc get policies -A | grep platform-upgrade

  2. 在使用 TALM 启动平台更新前应用所需的更新资源。

    1. 将带有 du-upgrade-platform-upgrade-prep 的 platform-upgrade-prep ClusterUpgradeGroup CR 的内容，以及目标受管集群保存为 cgu-platform-upgrade-prep.yml 文件，如以下示例所示： 

      apiVersion: ran.openshift.io/v1alpha1
kind: ClusterGroupUpgrade
metadata:
  name: cgu-platform-upgrade-prep
  namespace: default
spec:
  managedPolicies:
  - du-upgrade-platform-upgrade-prep
  clusters:
  - spoke1
  remediationStrategy:
    maxConcurrency: 1
  enable: true

    2. 运行以下命令，将策略应用到 hub 集群： 

      $ oc apply -f cgu-platform-upgrade-prep.yml

    3. 监控更新过程。在完成后，运行以下命令来确保策略兼容： 

      $ oc get policies --all-namespaces

  3. 为平台更新创建 ClusterGroupUpdate CR，将 spec.enable 项设置为 false。

    1. 使用 du-upgrade-platform-upgrade 策略将平台更新 ClusterGroupUpdate CR 的内容保存到 cgu-platform-upgrade.yml 文件中，如下例所示： 

      apiVersion: ran.openshift.io/v1alpha1
kind: ClusterGroupUpgrade
metadata:
  name: cgu-platform-upgrade
  namespace: default
spec:
  managedPolicies:
  - du-upgrade-platform-upgrade
  preCaching: false
  clusters:
  - spoke1
  remediationStrategy:
    maxConcurrency: 1
  enable: false

    2. 运行以下命令，将 ClusterGroupUpdate CR 应用到 hub 集群： 

      $ oc apply -f cgu-platform-upgrade.yml

  4. 可选：缓存平台更新的镜像。

    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}'

  5. 启动平台更新：

    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

其他资源

19.10.1.3. 执行 Operator 更新

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

先决条件

  • 安装 Topology Aware Lifecycle Manager(TALM)。
  • 将 ZTP 更新至最新版本。
  • 使用 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.10 1
        updateStrategy: 2
          registryPoll:
            interval: 1h
      1
      索引镜像 URL 包含所需的 Operator 镜像。如果索引镜像始终推送到相同的镜像名称和标签，则不需要此更改。
      2
      使用 registryPoll.interval 字段设置 Operator Lifecycle Manager(OLM)轮询新 Operator 版本的索引镜像。如果为 y-stream 和 z-stream Operator 更新而总是推送新的索引镜像标签，则不需要此更改。registryPoll.interval 字段可以设置为较短的间隔，以加快更新，但较短的间隔会增大计算负载。要影响这个问题，您可以在更新完成后将 registryPoll.interval 恢复到默认值。

    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-policy 和 du-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 中删除指定的订阅频道。ZTP 镜像的默认订阅频道用于更新。

      注意

      通过 ZTP 4.10 应用的 Operator 的默认频道是 stable，但 performance-addon-operator 除外。PAO 的默认频道是 4.10。您还可以在常规 PolicyGenTemplate CR 中指定默认频道。

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

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

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

      $ oc get policies -A | grep -E "catsrc-policy|subscription"

  2. 在启动 Operator 更新前，应用所需的目录源更新。

    1. 使用目录源策略将名为 operator-upgrade-prep 的 ClusterGroupUpgrade 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 订阅。如果您根据 "ZTP 从 4.9 升级到 4.10" 将 ZTP 从 4.9 升级到 4.10，则所有 Operator 订阅都会分组到 common-subscriptions-policy 策略中。
      注意

      一个 ClusterGroupUpgrade CR 只能从 ClusterGroupUpgrade CR 中包含的一个目录源中预缓存订阅策略中定义的 Operator 镜像。如果所需的 Operator 来自不同目录源，如 SRIOV-FEC Operator 示例，则必须使用 du-upgrade-fec-catsrc-policy 和 du-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

其他资源

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

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

先决条件

  • 安装 Topology Aware Lifecycle Manager(TALM)。
  • 将 ZTP 更新至最新版本。
  • 使用 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 在更新完成后删除所有这些资源。

19.10.1.5. 从部署的集群中删除 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 集群同步更改。策略保持合规。

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

TALM 有一个名为 ManagedClusterForCGU 的控制器，它监控 hub 集群上的 ManagedCluster CR 的 Ready 状态，并为 ZTP 创建 ClusterGroupUpgrade CR（零接触置备）。

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

注意

如果集群在集群变为 Ready 时没有绑定策略，则不会创建 ClusterGroupUpgrade CR。

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.