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

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

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

19.10.1. 关于 Topology Aware Lifecycle Manager 配置

Topology Aware Lifecycle Manager(TALM)管理一个或多个 OpenShift Container Platform 集群的部署 Red Hat Advanced Cluster Management(RHACM)策略。通过在大型集群网络中使用 TALM，可以使用有限制的批处理，在集群中逐步实施相关的策略。这有助于最大程度降低更新时可能造成的服务中断。使用 TALM，您可以控制以下操作：

  • 更新的时间
  • RHACM 管理的集群数量
  • 将策略应用到的受管集群的子集
  • 集群的更新顺序
  • 在集群中修复的一组策略
  • 在集群中修复的策略顺序
  • Canary 集群的分配

对于单节点 OpenShift，Topology Aware Lifecycle Manager (TALM) 提供以下功能：

  • 在升级前创建部署的备份
  • 有限带宽的集群预缓存镜像

TALM 支持编排 OpenShift Container Platform y-stream 和 z-stream 更新，以及 y-streams 和 z-streams 上的 day-two 操作。

19.10.2. 关于用于 Topology Aware Lifecycle Manager 的受管策略

Topology Aware Lifecycle Manager(TALM)使用 RHACM 策略进行集群更新。

TALM 可以用来管理任何策略 CR 的推出，其中 remediationAction 字段被设置为 inform。支持的用例包括：

  • 手动创建用户策略 CR
  • 从 PolicyGenTemplate 自定义资源定义 (CRD) 自动生成的策略

对于使用手动批准更新 Operator 订阅的策略，TALM 提供了额外的功能来批准更新的 Operator 的安装。

有关受管策略的更多信息，请参阅 RHACM 文档中的策略概述。

如需有关 PolicyGenTemplate CRD 的更多信息，请参阅"使用策略和 PolicyGenTemplate 资源配置受管集群"中的"About the PolicyGenTemplate CRD"部分。

19.10.3. 使用 Web 控制台安装 Topology Aware Lifecycle Manager

您可以使用 OpenShift Container Platform Web 控制台安装 Topology Aware Lifecycle Manager。

先决条件

  • 安装最新版本的 RHACM Operator。
  • 使用断开连接的 regitry 设置 hub 集群。
  • 以具有 cluster-admin 特权的用户身份登录。

流程

  1. 在 OpenShift Container Platform Web 控制台中导航至 Operators OperatorHub。
  2. 从可用的 Operator 列表中选择 Topology Aware Lifecycle Manager，然后点 Install。
  3. 保持默认的选择 Installation mode ["All namespaces on the cluster (default)"] 和 Installed Namespace ("openshift-operators") 以确保 Operator 已正确安装。
  4. 点 Install。

验证

确认安装成功：

  1. 进入到 Operators Installed Operators 页面。
  2. 检查 Operator 是否在 All Namespaces 命名空间中，其状态为 Succeeded。

如果 Operator 没有成功安装：

  1. 导航到 Operators Installed Operators 页面，并检查 Status 列中是否有任何错误或故障。
  2. 进入到 Workloads Pods 页面，检查 cluster-group-upgrades-controller-manager pod 中报告问题的容器日志。

19.10.4. 使用 CLI 安装 Topology Aware Lifecycle Manager

您可以使用 OpenShift CLI(oc)安装 Topology Aware Lifecycle Manager(TALM)。

先决条件

  • 安装 OpenShift CLI (oc) 。
  • 安装最新版本的 RHACM Operator。
  • 使用断开连接的 registry 设置 hub 集群。
  • 以具有 cluster-admin 特权的用户身份登录。

流程

  1. 创建一个 Subscription CR：

    1. 定义 Subscription CR 并保存 YAML 文件，如 talm-subscription.yaml ： 

      apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: openshift-topology-aware-lifecycle-manager-subscription
  namespace: openshift-operators
spec:
  channel: "stable"
  name: topology-aware-lifecycle-manager
  source: redhat-operators
  sourceNamespace: openshift-marketplace

    2. 运行以下命令来创建 Subscription CR： 

      $ oc create -f talm-subscription.yaml

验证

  1. 检查 CSV 资源来验证安装是否成功： 

    $ oc get csv -n openshift-operators

    输出示例

    NAME                                                   DISPLAY                            VERSION               REPLACES                           PHASE
topology-aware-lifecycle-manager.4.13.x   Topology Aware Lifecycle Manager   4.13.x                                      Succeeded

  2. 验证 TALM 是否正在运行： 

    $ oc get deploy -n openshift-operators

    输出示例

    NAMESPACE                                          NAME                                             READY   UP-TO-DATE   AVAILABLE   AGE
openshift-operators                                cluster-group-upgrades-controller-manager        1/1     1            1           14s

19.10.5. 关于 ClusterGroupUpgrade CR

Topology Aware Lifecycle Manager(TALM)为一组集群从 ClusterGroupUpgrade CR 构建补救计划。您可以在 ClusterGroupUpgrade CR 中定义以下规格：

  • 组中的集群
  • 阻塞 ClusterGroupUpgrade CR
  • 适用的受管策略列表
  • 并发更新数
  • 适用的 Canary 更新
  • 更新前和更新之后执行的操作
  • 更新数据

您可以使用 ClusterGroupUpgrade CR 中的 enable 字段控制更新的开始时间。例如，如果您调度的维护窗口为 4 小时，您可以准备 ClusterGroupUpgrade CR，并将 enable 字段设置为 false。

您可以通过配置 spec.remediationStrategy.timeout 设置来设置超时，如下所示： 

spec
  remediationStrategy:
          maxConcurrency: 1
          timeout: 240

您可以使用 batchTimeoutAction 来确定更新是否有集群发生的情况。您可以指定 continue 跳过失败的集群，并继续升级其他集群，或 abort 以停止所有集群的策略补救。超时后，TALM 删除所有 enforce 策略，以确保对集群不进行进一步的更新。

要应用更改，您可以将 enabled 字段设置为 true。

如需更多信息，请参阅"将更新策略应用到受管集群"部分。

当 TALM 通过对指定集群进行补救时，ClusterGroupUpgrade CR 可以为多个条件报告 true 或 false 状态。

注意

当 TALM 完成集群更新后，集群不会在同一 ClusterGroupUpgrade CR 控制下再次更新。在以下情况下，必须创建新的 ClusterGroupUpgrade CR：

  • 当您需要再次更新集群时
  • 当集群在更新后变为与 inform 策略不符合时

19.10.5.1. 选择集群

TALM 构建补救计划并根据以下字段选择集群：

  • clusterLabelSelector 字段指定您要更新的集群标签。这由来自 k8s.io/apimachinery/pkg/apis/meta/v1 的标准标签选择器的列表组成。列表中的每个选择器都使用标签值对或标签表达式。来自每个选择器的匹配会添加到集群的最终列表中，以及来自 clusterSelector 字段和 cluster 字段的匹配项。
  • clusters 字段指定要更新的集群列表。
  • canaries 字段指定集群进行 Canary 更新。
  • maxConcurrency 字段指定批处理中要更新的集群数量。
  • actions 字段指定 TALM 在启动更新过程时执行的 beforeEnable 操作，以及 TALM 在完成每个集群策略补救时执行的 afterCompletion 操作。

您可以使用 clusters、clusterLabelSelector 和 clusterSelector 字段来创建组合的集群列表。

补救计划从 canaries 字段中列出的集群开始。每个 canary 集群组成一个集群批处理。

Sample ClusterGroupUpgrade CR，带有 the enabled field 设置为 false

apiVersion: ran.openshift.io/v1alpha1
kind: ClusterGroupUpgrade
metadata:
  creationTimestamp: '2022-11-18T16:27:15Z'
  finalizers:
    - ran.openshift.io/cleanup-finalizer
  generation: 1
  name: talm-cgu
  namespace: talm-namespace
  resourceVersion: '40451823'
  uid: cca245a5-4bca-45fa-89c0-aa6af81a596c
Spec:
  actions:
    afterCompletion: 1
      addClusterLabels:
        upgrade-done: ""
      deleteClusterLabels:
        upgrade-running: ""
      deleteObjects: true
    beforeEnable: 2
      addClusterLabels:
        upgrade-running: ""
  backup: false
  clusters: 3
    - spoke1
  enable: false 4
  managedPolicies: 5
    - talm-policy
  preCaching: false
  remediationStrategy: 6
    canaries: 7
        - spoke1
    maxConcurrency: 2 8
    timeout: 240
  clusterLabelSelectors: 9
    - matchExpressions:
      - key: label1
      operator: In
      values:
        - value1a
        - value1b
  batchTimeoutAction: 10
status: 11
    computedMaxConcurrency: 2
    conditions:
      - lastTransitionTime: '2022-11-18T16:27:15Z'
        message: All selected clusters are valid
        reason: ClusterSelectionCompleted
        status: 'True'
        type: ClustersSelected 12
      - lastTransitionTime: '2022-11-18T16:27:15Z'
        message: Completed validation
        reason: ValidationCompleted
        status: 'True'
        type: Validated 13
      - lastTransitionTime: '2022-11-18T16:37:16Z'
        message: Not enabled
        reason: NotEnabled
        status: 'False'
        type: Progressing
    managedPoliciesForUpgrade:
      - name: talm-policy
        namespace: talm-namespace
    managedPoliciesNs:
      talm-policy: talm-namespace
    remediationPlan:
      - - spoke1
      - - spoke2
        - spoke3
    status:

1
指定 TALM 完成每个集群的策略补救时执行的操作。
2
指定 TALM 在开始更新过程时执行的操作。
3
定义要更新的集群列表。
4
enable 字段设置为 false。
5
列出要修复的用户定义的策略集合。
6
定义集群更新的具体信息。
7
定义可用于 canary 更新的集群。
8
定义批处理中的最大并发更新数。补救批处理数量是 canary 集群的数量，加上除 Canary 集群外的集群数量除以 maxConcurrency 值。已兼容所有受管策略的集群不包括在补救计划中。
9
显示选择集群的参数。
10
控制批处理超时时会发生什么。可能的值有 abort 或 continue。如果未指定，则默认为 continue。
11
显示更新状态的信息。
12
ClustersSelected 条件显示所有选择的集群有效。
13
Validated 条件显示所有选择的集群都已验证。
注意

在更新 canary 集群的过程中任何错误都会停止更新过程。

当成功创建补救计划时，您可以将 enable 字段设置为 true，TALM 会开始使用指定的受管策略更新不合规的集群。

注意

只有 ClusterGroupUpgrade CR 的 enable 字段设置为 false 时，才能更改 spec 字段。

19.10.5.2. 验证

TALM 检查所有指定的受管策略是否可用并正确，并使用 Validated 条件来报告状态和原因：

  • true

    验证已完成。

  • false

    策略缺失或无效，或者指定了无效的平台镜像。

19.10.5.3. 预缓存

集群可能具有有限的带宽来访问容器镜像 registry，这可能会在更新完成前造成超时。在单节点 OpenShift 集群中，您可以使用预缓存来避免这种情况。当创建 ClusterGroupUpgrade CR 时，容器镜像预缓存会启动，并将 preCaching 字段设置为 true。TALM 将可用磁盘空间与预计 OpenShift Container Platform 镜像大小进行比较，以确保有足够的空间。如果集群没有足够的空间，TALM 会取消该集群的预缓存，且不会修复其上的策略。

TALM 使用 PrecacheSpecValid 条件来报告状态信息，如下所示：

  • true

    预缓存规格有效且一致。

  • false

    预缓存规格不完整。

TALM 使用 PrecachingSucceeded 条件来报告状态信息，如下所示：

  • true

    TALM 已完成预缓存过程。如果任何集群的预缓存失败，则该集群的更新会失败，但会继续执行所有其他集群。如果任何集群预缓存失败，您会接收到一个通知信息。

  • false

    预缓存仍在为一个或多个集群处理，或者所有集群都失败。

如需更多信息，请参阅"使用容器镜像预缓存功能"部分。

19.10.5.4. 创建备份

对于单节点 OpenShift，TALM 可以在更新前创建部署的备份。如果更新失败，您可以恢复之前的版本并将集群恢复到工作状态，而无需重新置备应用程序。要使用备份功能，您首先创建一个 ClusterGroupUpgrade CR，并将 backup 字段设置为 true。为确保备份内容为最新版本，在 ClusterGroupUpgrade CR 中的 enable 字段设置为 true 之前，不会进行备份。

TALM 使用 BackupSucceeded 条件来报告状态，如下所示：

  • true

    备份对于所有集群都完成，或备份运行已完成但对一个或多个集群失败。如果任何集群的备份失败，则该集群的更新会失败，但会继续执行所有其他集群。

  • false

    备份仍在为一个或多个集群处理，或者所有集群都失败。

如需更多信息，请参阅"在升级前创建集群资源备份"部分。

19.10.5.5. 更新集群

TALM 按照补救计划强制实施策略。在当前批处理的所有集群与所有受管策略兼容后，对后续批处理的策略强制启动。如果批处理超时，TALM 会进入下一个批处理。批处理的超时值是 spec.timeout 字段除以补救计划中的批处理数量。

TALM 使用 Progressing 条件来报告状态以及如下原因：

  • true

    TALM 是补救不合规的策略。

  • false

    更新没有进行。可能的原因包括：

    • 所有集群都符合所有受管策略。
    • 当策略补救用时过长时，更新会超时。
    • 阻塞系统中丢失或尚未完成的 CR。
    • ClusterGroupUpgrade CR 不会被启用。
    • 备份仍在进行中。
注意

受管策略会按照 ClusterGroupUpgrade CR 中的 managedPolicies 字段中列出的顺序进行应用。一个受管策略被应用于指定的集群。当集群符合当前策略时，会应用下一个受管策略。

处于 Progressing 状态的 ClusterGroupUpgrade CR 示例

apiVersion: ran.openshift.io/v1alpha1
kind: ClusterGroupUpgrade
metadata:
  creationTimestamp: '2022-11-18T16:27:15Z'
  finalizers:
    - ran.openshift.io/cleanup-finalizer
  generation: 1
  name: talm-cgu
  namespace: talm-namespace
  resourceVersion: '40451823'
  uid: cca245a5-4bca-45fa-89c0-aa6af81a596c
Spec:
  actions:
    afterCompletion:
      deleteObjects: true
    beforeEnable: {}
  backup: false
  clusters:
    - spoke1
  enable: true
  managedPolicies:
    - talm-policy
  preCaching: true
  remediationStrategy:
    canaries:
        - spoke1
    maxConcurrency: 2
    timeout: 240
  clusterLabelSelectors:
    - matchExpressions:
      - key: label1
      operator: In
      values:
        - value1a
        - value1b
  batchTimeoutAction:
status:
    clusters:
      - name: spoke1
        state: complete
    computedMaxConcurrency: 2
    conditions:
      - lastTransitionTime: '2022-11-18T16:27:15Z'
        message: All selected clusters are valid
        reason: ClusterSelectionCompleted
        status: 'True'
        type: ClustersSelected
      - lastTransitionTime: '2022-11-18T16:27:15Z'
        message: Completed validation
        reason: ValidationCompleted
        status: 'True'
        type: Validated
      - lastTransitionTime: '2022-11-18T16:37:16Z'
        message: Remediating non-compliant policies
        reason: InProgress
        status: 'True'
        type: Progressing 1
    managedPoliciesForUpgrade:
      - name: talm-policy
        namespace: talm-namespace
    managedPoliciesNs:
      talm-policy: talm-namespace
    remediationPlan:
      - - spoke1
      - - spoke2
        - spoke3
    status:
      currentBatch: 2
      currentBatchRemediationProgress:
        spoke2:
          state: Completed
        spoke3:
          policyIndex: 0
          state: InProgress
      currentBatchStartedAt: '2022-11-18T16:27:16Z'
      startedAt: '2022-11-18T16:27:15Z'

1
Progressing 字段显示 TALM 处于补救策略的过程。

19.10.5.6. 更新状态

TALM 使用 Succeeded 条件来报告状态和如下原因：

  • true

    所有集群都符合指定的受管策略。

  • false

    因为没有集群可用于补救，策略补救会失败，或者因为以下原因之一策略补救用时过长：

    • 在当前批处理包含 Canary 更新时，批处理中的集群不会遵循批处理超时中的所有受管策略。
    • 集群不符合 remediationStrategy 字段中指定的 timeout 值的受管策略。

处于 Succeeded 状态的 ClusterGroupUpgrade CR 示例

    apiVersion: ran.openshift.io/v1alpha1
    kind: ClusterGroupUpgrade
    metadata:
      name: cgu-upgrade-complete
      namespace: default
    spec:
      clusters:
      - spoke1
      - spoke4
      enable: true
      managedPolicies:
      - policy1-common-cluster-version-policy
      - policy2-common-pao-sub-policy
      remediationStrategy:
        maxConcurrency: 1
        timeout: 240
    status: 1
      clusters:
        - name: spoke1
          state: complete
        - name: spoke4
          state: complete
      conditions:
      - message: All selected clusters are valid
        reason: ClusterSelectionCompleted
        status: "True"
        type: ClustersSelected
      - message: Completed validation
        reason: ValidationCompleted
        status: "True"
        type: Validated
      - message: All clusters are compliant with all the managed policies
        reason: Completed
        status: "False"
        type: Progressing 2
      - message: All clusters are compliant with all the managed policies
        reason: Completed
        status: "True"
        type: Succeeded 3
      managedPoliciesForUpgrade:
      - name: policy1-common-cluster-version-policy
        namespace: default
      - name: policy2-common-pao-sub-policy
        namespace: default
      remediationPlan:
      - - spoke1
      - - spoke4
      status:
        completedAt: '2022-11-18T16:27:16Z'
        startedAt: '2022-11-18T16:27:15Z'

2
在 Progressing 字段中，更新完成时状态为 false ；集群与所有受管策略兼容。
3
Succeeded 字段显示验证成功完成。
1
status 字段包含集群列表及其状态。集群的状态可以是 complete 或 timedout。

timedout 状态的 Sample ClusterGroupUpgrade CR

apiVersion: ran.openshift.io/v1alpha1
kind: ClusterGroupUpgrade
metadata:
  creationTimestamp: '2022-11-18T16:27:15Z'
  finalizers:
    - ran.openshift.io/cleanup-finalizer
  generation: 1
  name: talm-cgu
  namespace: talm-namespace
  resourceVersion: '40451823'
  uid: cca245a5-4bca-45fa-89c0-aa6af81a596c
spec:
  actions:
    afterCompletion:
      deleteObjects: true
    beforeEnable: {}
  backup: false
  clusters:
    - spoke1
    - spoke2
  enable: true
  managedPolicies:
    - talm-policy
  preCaching: false
  remediationStrategy:
    maxConcurrency: 2
    timeout: 240
status:
  clusters:
    - name: spoke1
      state: complete
    - currentPolicy: 1
        name: talm-policy
        status: NonCompliant
      name: spoke2
      state: timedout
  computedMaxConcurrency: 2
  conditions:
    - lastTransitionTime: '2022-11-18T16:27:15Z'
      message: All selected clusters are valid
      reason: ClusterSelectionCompleted
      status: 'True'
      type: ClustersSelected
    - lastTransitionTime: '2022-11-18T16:27:15Z'
      message: Completed validation
      reason: ValidationCompleted
      status: 'True'
      type: Validated
    - lastTransitionTime: '2022-11-18T16:37:16Z'
      message: Policy remediation took too long
      reason: TimedOut
      status: 'False'
      type: Progressing
    - lastTransitionTime: '2022-11-18T16:37:16Z'
      message: Policy remediation took too long
      reason: TimedOut
      status: 'False'
      type: Succeeded 2
  managedPoliciesForUpgrade:
    - name: talm-policy
      namespace: talm-namespace
  managedPoliciesNs:
    talm-policy: talm-namespace
  remediationPlan:
    - - spoke1
      - spoke2
  status:
        startedAt: '2022-11-18T16:27:15Z'
        completedAt: '2022-11-18T20:27:15Z'

1
如果集群的状态是 timedout，currentPolicy 字段会显示策略名称和策略状态。
2
succeeded 的状态为 false，这个消息代表策略补救用时过长。

19.10.5.7. 阻塞 ClusterGroupUpgrade CR

您可以创建多个 ClusterGroupUpgrade CR，并控制应用程序的顺序。

例如，如果您创建了 ClusterGroupUpgrade CR C，它会阻塞 ClusterGroupUpgrade CR A 的启动，那么 ClusterGroupUpgrade CR A 将无法启动，直到 ClusterGroupUpgrade CR C 变为 UpgradeComplete 状态。

一个 ClusterGroupUpgrade CR 可以有多个阻塞 CR。在这种情况下，所有块 CR 都必须在升级当前 CR 升级前完成。

先决条件

  • 安装 Topology Aware Lifecycle Manager(TALM)。
  • 置备一个或多个受管集群。
  • 以具有 cluster-admin 特权的用户身份登录。
  • 在 hub 集群中创建 RHACM 策略。

流程

  1. 将 ClusterGroupUpgrade CR 的内容保存到 cgu-a.yaml、cgu-b.yaml 和 cgu-c.yaml 文件中。 

    apiVersion: ran.openshift.io/v1alpha1
kind: ClusterGroupUpgrade
metadata:
  name: cgu-a
  namespace: default
spec:
  blockingCRs: 1
  - name: cgu-c
    namespace: default
  clusters:
  - spoke1
  - spoke2
  - spoke3
  enable: false
  managedPolicies:
  - policy1-common-cluster-version-policy
  - policy2-common-pao-sub-policy
  - policy3-common-ptp-sub-policy
  remediationStrategy:
    canaries:
    - spoke1
    maxConcurrency: 2
    timeout: 240
status:
  conditions:
  - message: The ClusterGroupUpgrade CR is not enabled
    reason: UpgradeNotStarted
    status: "False"
    type: Ready
  copiedPolicies:
  - cgu-a-policy1-common-cluster-version-policy
  - cgu-a-policy2-common-pao-sub-policy
  - cgu-a-policy3-common-ptp-sub-policy
  managedPoliciesForUpgrade:
  - name: policy1-common-cluster-version-policy
    namespace: default
  - name: policy2-common-pao-sub-policy
    namespace: default
  - name: policy3-common-ptp-sub-policy
    namespace: default
  placementBindings:
  - cgu-a-policy1-common-cluster-version-policy
  - cgu-a-policy2-common-pao-sub-policy
  - cgu-a-policy3-common-ptp-sub-policy
  placementRules:
  - cgu-a-policy1-common-cluster-version-policy
  - cgu-a-policy2-common-pao-sub-policy
  - cgu-a-policy3-common-ptp-sub-policy
  remediationPlan:
  - - spoke1
  - - spoke2
    1
    定义阻塞 CR。cgu-a 更新无法启动，直到 cgu-c 完成后。 
    apiVersion: ran.openshift.io/v1alpha1
kind: ClusterGroupUpgrade
metadata:
  name: cgu-b
  namespace: default
spec:
  blockingCRs: 1
  - name: cgu-a
    namespace: default
  clusters:
  - spoke4
  - spoke5
  enable: false
  managedPolicies:
  - policy1-common-cluster-version-policy
  - policy2-common-pao-sub-policy
  - policy3-common-ptp-sub-policy
  - policy4-common-sriov-sub-policy
  remediationStrategy:
    maxConcurrency: 1
    timeout: 240
status:
  conditions:
  - message: The ClusterGroupUpgrade CR is not enabled
    reason: UpgradeNotStarted
    status: "False"
    type: Ready
  copiedPolicies:
  - cgu-b-policy1-common-cluster-version-policy
  - cgu-b-policy2-common-pao-sub-policy
  - cgu-b-policy3-common-ptp-sub-policy
  - cgu-b-policy4-common-sriov-sub-policy
  managedPoliciesForUpgrade:
  - name: policy1-common-cluster-version-policy
    namespace: default
  - name: policy2-common-pao-sub-policy
    namespace: default
  - name: policy3-common-ptp-sub-policy
    namespace: default
  - name: policy4-common-sriov-sub-policy
    namespace: default
  placementBindings:
  - cgu-b-policy1-common-cluster-version-policy
  - cgu-b-policy2-common-pao-sub-policy
  - cgu-b-policy3-common-ptp-sub-policy
  - cgu-b-policy4-common-sriov-sub-policy
  placementRules:
  - cgu-b-policy1-common-cluster-version-policy
  - cgu-b-policy2-common-pao-sub-policy
  - cgu-b-policy3-common-ptp-sub-policy
  - cgu-b-policy4-common-sriov-sub-policy
  remediationPlan:
  - - spoke4
  - - spoke5
  status: {}
    1
    cgu-b 更新无法启动，直到 cgu-a 完成后。 
    apiVersion: ran.openshift.io/v1alpha1
kind: ClusterGroupUpgrade
metadata:
  name: cgu-c
  namespace: default
spec: 1
  clusters:
  - spoke6
  enable: false
  managedPolicies:
  - policy1-common-cluster-version-policy
  - policy2-common-pao-sub-policy
  - policy3-common-ptp-sub-policy
  - policy4-common-sriov-sub-policy
  remediationStrategy:
    maxConcurrency: 1
    timeout: 240
status:
  conditions:
  - message: The ClusterGroupUpgrade CR is not enabled
    reason: UpgradeNotStarted
    status: "False"
    type: Ready
  copiedPolicies:
  - cgu-c-policy1-common-cluster-version-policy
  - cgu-c-policy4-common-sriov-sub-policy
  managedPoliciesCompliantBeforeUpgrade:
  - policy2-common-pao-sub-policy
  - policy3-common-ptp-sub-policy
  managedPoliciesForUpgrade:
  - name: policy1-common-cluster-version-policy
    namespace: default
  - name: policy4-common-sriov-sub-policy
    namespace: default
  placementBindings:
  - cgu-c-policy1-common-cluster-version-policy
  - cgu-c-policy4-common-sriov-sub-policy
  placementRules:
  - cgu-c-policy1-common-cluster-version-policy
  - cgu-c-policy4-common-sriov-sub-policy
  remediationPlan:
  - - spoke6
  status: {}
    1
    cgu-c 更新没有任何阻塞 CR。当 enable 字段设为 true 时，TALM 会启动 cgu-c 更新。

  2. 通过为每个相关 CR 运行以下命令创建 ClusterGroupUpgrade CR： 

    $ oc apply -f <name>.yaml

  3. 通过为每个相关 CR 运行以下命令启动更新过程： 

    $ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/<name> \
--type merge -p '{"spec":{"enable":true}}'

    以下示例显示 enable 字段设为 true 的 ClusterGroupUpgrade CR：

    带有阻塞 CR 的 cgu-a 示例

    apiVersion: ran.openshift.io/v1alpha1
kind: ClusterGroupUpgrade
metadata:
  name: cgu-a
  namespace: default
spec:
  blockingCRs:
  - name: cgu-c
    namespace: default
  clusters:
  - spoke1
  - spoke2
  - spoke3
  enable: true
  managedPolicies:
  - policy1-common-cluster-version-policy
  - policy2-common-pao-sub-policy
  - policy3-common-ptp-sub-policy
  remediationStrategy:
    canaries:
    - spoke1
    maxConcurrency: 2
    timeout: 240
status:
  conditions:
  - message: 'The ClusterGroupUpgrade CR is blocked by other CRs that have not yet
      completed: [cgu-c]' 1
    reason: UpgradeCannotStart
    status: "False"
    type: Ready
  copiedPolicies:
  - cgu-a-policy1-common-cluster-version-policy
  - cgu-a-policy2-common-pao-sub-policy
  - cgu-a-policy3-common-ptp-sub-policy
  managedPoliciesForUpgrade:
  - name: policy1-common-cluster-version-policy
    namespace: default
  - name: policy2-common-pao-sub-policy
    namespace: default
  - name: policy3-common-ptp-sub-policy
    namespace: default
  placementBindings:
  - cgu-a-policy1-common-cluster-version-policy
  - cgu-a-policy2-common-pao-sub-policy
  - cgu-a-policy3-common-ptp-sub-policy
  placementRules:
  - cgu-a-policy1-common-cluster-version-policy
  - cgu-a-policy2-common-pao-sub-policy
  - cgu-a-policy3-common-ptp-sub-policy
  remediationPlan:
  - - spoke1
  - - spoke2
  status: {}

    1
    显示阻塞 CR 的列表。

    带有阻塞 CR 的 cgu-b 示例

    apiVersion: ran.openshift.io/v1alpha1
kind: ClusterGroupUpgrade
metadata:
  name: cgu-b
  namespace: default
spec:
  blockingCRs:
  - name: cgu-a
    namespace: default
  clusters:
  - spoke4
  - spoke5
  enable: true
  managedPolicies:
  - policy1-common-cluster-version-policy
  - policy2-common-pao-sub-policy
  - policy3-common-ptp-sub-policy
  - policy4-common-sriov-sub-policy
  remediationStrategy:
    maxConcurrency: 1
    timeout: 240
status:
  conditions:
  - message: 'The ClusterGroupUpgrade CR is blocked by other CRs that have not yet
      completed: [cgu-a]' 1
    reason: UpgradeCannotStart
    status: "False"
    type: Ready
  copiedPolicies:
  - cgu-b-policy1-common-cluster-version-policy
  - cgu-b-policy2-common-pao-sub-policy
  - cgu-b-policy3-common-ptp-sub-policy
  - cgu-b-policy4-common-sriov-sub-policy
  managedPoliciesForUpgrade:
  - name: policy1-common-cluster-version-policy
    namespace: default
  - name: policy2-common-pao-sub-policy
    namespace: default
  - name: policy3-common-ptp-sub-policy
    namespace: default
  - name: policy4-common-sriov-sub-policy
    namespace: default
  placementBindings:
  - cgu-b-policy1-common-cluster-version-policy
  - cgu-b-policy2-common-pao-sub-policy
  - cgu-b-policy3-common-ptp-sub-policy
  - cgu-b-policy4-common-sriov-sub-policy
  placementRules:
  - cgu-b-policy1-common-cluster-version-policy
  - cgu-b-policy2-common-pao-sub-policy
  - cgu-b-policy3-common-ptp-sub-policy
  - cgu-b-policy4-common-sriov-sub-policy
  remediationPlan:
  - - spoke4
  - - spoke5
  status: {}

    1
    显示阻塞 CR 的列表。

    带有阻塞 CR 的 cgu-c 示例

    apiVersion: ran.openshift.io/v1alpha1
kind: ClusterGroupUpgrade
metadata:
  name: cgu-c
  namespace: default
spec:
  clusters:
  - spoke6
  enable: true
  managedPolicies:
  - policy1-common-cluster-version-policy
  - policy2-common-pao-sub-policy
  - policy3-common-ptp-sub-policy
  - policy4-common-sriov-sub-policy
  remediationStrategy:
    maxConcurrency: 1
    timeout: 240
status:
  conditions:
  - message: The ClusterGroupUpgrade CR has upgrade policies that are still non compliant 1
    reason: UpgradeNotCompleted
    status: "False"
    type: Ready
  copiedPolicies:
  - cgu-c-policy1-common-cluster-version-policy
  - cgu-c-policy4-common-sriov-sub-policy
  managedPoliciesCompliantBeforeUpgrade:
  - policy2-common-pao-sub-policy
  - policy3-common-ptp-sub-policy
  managedPoliciesForUpgrade:
  - name: policy1-common-cluster-version-policy
    namespace: default
  - name: policy4-common-sriov-sub-policy
    namespace: default
  placementBindings:
  - cgu-c-policy1-common-cluster-version-policy
  - cgu-c-policy4-common-sriov-sub-policy
  placementRules:
  - cgu-c-policy1-common-cluster-version-policy
  - cgu-c-policy4-common-sriov-sub-policy
  remediationPlan:
  - - spoke6
  status:
    currentBatch: 1
    remediationPlanForBatch:
      spoke6: 0

    1
    cgu-c 更新没有任何阻塞 CR。

19.10.6. 更新受管集群上的策略

Topology Aware Lifecycle Manager(TALM)修复了在 ClusterGroupUpgrade CR 中指定的集群的 inform 策略。TALM 通过生成受管 RHACM 策略的 enforce 副本来修复 inform 策略。每个复制的策略都有自己的对应的 RHACM 放置规则和 RHACM 放置绑定。

例如，TALM 将每个集群从当前批处理添加到与适用受管策略相对应的放置规则。如果集群已与策略兼容，TALM 会在兼容集群上跳过应用该策略。TALM 然后进入到将下一个策略应用到还没有合规的集群的步骤。TALM 在批处理中完成更新后，所有集群都会从与复制策略关联的放置规则中删除。然后，下一个批处理的更新会启动。

如果 spoke 集群没有向 RHACM 报告任何合规状态，则 hub 集群上的受管策略可能会缺少 TALM 需要的状态信息。TALM 通过以下方法处理这些情况：

  • 如果缺少策略的 status.compliant 字段，TALM 忽略策略并添加日志条目。然后，TALM 继续查看策略的 status.status 字段。
  • 如果缺少策略的 status.status，TALM 会生成错误。
  • 如果策略的 status.status 字段中缺少集群的合规状态，TALM 会将该集群视为与该策略不兼容。

ClusterGroupUpgrade CR 的 batchTimeoutAction 决定升级失败时是否有什么情况。您可以指定 continue 跳过失败的集群，并继续升级其他集群，或者指定 abort 以停止所有集群的策略补救。超时后，TALM 删除所有强制策略，以确保对集群不进行进一步的更新。

升级策略示例

apiVersion: policy.open-cluster-management.io/v1
kind: Policy
metadata:
  name: ocp-4.4.13.4
  namespace: platform-upgrade
spec:
  disabled: false
  policy-templates:
  - objectDefinition:
      apiVersion: policy.open-cluster-management.io/v1
      kind: ConfigurationPolicy
      metadata:
        name: upgrade
      spec:
        namespaceselector:
          exclude:
          - kube-*
          include:
          - '*'
        object-templates:
        - complianceType: musthave
          objectDefinition:
            apiVersion: config.openshift.io/v1
            kind: ClusterVersion
            metadata:
              name: version
            spec:
              channel: stable-4.13
              desiredUpdate:
                version: 4.4.13.4
              upstream: https://api.openshift.com/api/upgrades_info/v1/graph
            status:
              history:
                - state: Completed
                  version: 4.4.13.4
        remediationAction: inform
        severity: low
  remediationAction: inform

有关 RHACM 策略的更多信息，请参阅策略概述。

其他资源

如需有关 PolicyGenTemplate CRD 的更多信息，请参阅关于 PolicyGenTemplate CRD

19.10.6.1. 使用 TALM 为安装的受管集群配置 Operator 订阅

Topology Aware Lifecycle Manager (TALM) 只能在 Operator 的 Subscription 自定义资源(CR) 包含 status.state.AtLatestKnown 字段时批准 Operator 的安装计划。

流程

  1. 将 status.state.AtLatestKnown 字段添加到 Operator 的 Subscription CR 中：

    Subscription CR 示例

    apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: cluster-logging
  namespace: openshift-logging
  annotations:
    ran.openshift.io/ztp-deploy-wave: "2"
spec:
  channel: "stable"
  name: cluster-logging
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  installPlanApproval: Manual
status:
  state: AtLatestKnown 1

    1
    status.state: AtLatestKnown 字段用于 Operator 目录中可用的最新 Operator 版本。
    注意

    当 registry 中有新版本的 Operator 时，相关的策略将变为不合规。

  2. 使用 ClusterGroupUpgrade CR 将更改的 Subscription 策略应用到受管集群。

19.10.6.2. 将更新策略应用到受管集群

您可以通过应用策略来更新受管集群。

先决条件

  • 安装 Topology Aware Lifecycle Manager(TALM)。
  • 置备一个或多个受管集群。
  • 以具有 cluster-admin 特权的用户身份登录。
  • 在 hub 集群中创建 RHACM 策略。

流程

  1. 将 ClusterGroupUpgrade CR 的内容保存到 cgu-1.yaml 文件中。 

    apiVersion: ran.openshift.io/v1alpha1
kind: ClusterGroupUpgrade
metadata:
  name: cgu-1
  namespace: default
spec:
  managedPolicies: 1
    - policy1-common-cluster-version-policy
    - policy2-common-nto-sub-policy
    - policy3-common-ptp-sub-policy
    - policy4-common-sriov-sub-policy
  enable: false
  clusters: 2
  - spoke1
  - spoke2
  - spoke5
  - spoke6
  remediationStrategy:
    maxConcurrency: 2 3
    timeout: 240 4
  batchTimeoutAction: 5
    1
    要应用的策略的名称。
    2
    要更新的集群列表。
    3
    maxConcurrency 字段表示同时更新的集群数量。
    4
    更新超时（以分钟为单位）。
    5
    控制批处理超时时会发生什么。可能的值有 abort 或 continue。如果未指定，则默认为 continue。

  2. 运行以下命令来创建 ClusterGroupUpgrade CR： 

    $ oc create -f cgu-1.yaml

    1. 运行以下命令，检查 hub 集群中是否已创建 ClusterGroupUpgrade CR： 

      $ oc get cgu --all-namespaces

      输出示例

      NAMESPACE   NAME  AGE  STATE      DETAILS
default     cgu-1 8m55 NotEnabled Not Enabled

    2. 运行以下命令检查更新的状态： 

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

      输出示例

      {
  "computedMaxConcurrency": 2,
  "conditions": [
    {
      "lastTransitionTime": "2022-02-25T15:34:07Z",
      "message": "Not enabled", 1
      "reason": "NotEnabled",
      "status": "False",
      "type": "Progressing"
    }
  ],
  "copiedPolicies": [
    "cgu-policy1-common-cluster-version-policy",
    "cgu-policy2-common-nto-sub-policy",
    "cgu-policy3-common-ptp-sub-policy",
    "cgu-policy4-common-sriov-sub-policy"
  ],
  "managedPoliciesContent": {
    "policy1-common-cluster-version-policy": "null",
    "policy2-common-nto-sub-policy": "[{\"kind\":\"Subscription\",\"name\":\"node-tuning-operator\",\"namespace\":\"openshift-cluster-node-tuning-operator\"}]",
    "policy3-common-ptp-sub-policy": "[{\"kind\":\"Subscription\",\"name\":\"ptp-operator-subscription\",\"namespace\":\"openshift-ptp\"}]",
    "policy4-common-sriov-sub-policy": "[{\"kind\":\"Subscription\",\"name\":\"sriov-network-operator-subscription\",\"namespace\":\"openshift-sriov-network-operator\"}]"
  },
  "managedPoliciesForUpgrade": [
    {
      "name": "policy1-common-cluster-version-policy",
      "namespace": "default"
    },
    {
      "name": "policy2-common-nto-sub-policy",
      "namespace": "default"
    },
    {
      "name": "policy3-common-ptp-sub-policy",
      "namespace": "default"
    },
    {
      "name": "policy4-common-sriov-sub-policy",
      "namespace": "default"
    }
  ],
  "managedPoliciesNs": {
    "policy1-common-cluster-version-policy": "default",
    "policy2-common-nto-sub-policy": "default",
    "policy3-common-ptp-sub-policy": "default",
    "policy4-common-sriov-sub-policy": "default"
  },
  "placementBindings": [
    "cgu-policy1-common-cluster-version-policy",
    "cgu-policy2-common-nto-sub-policy",
    "cgu-policy3-common-ptp-sub-policy",
    "cgu-policy4-common-sriov-sub-policy"
  ],
  "placementRules": [
    "cgu-policy1-common-cluster-version-policy",
    "cgu-policy2-common-nto-sub-policy",
    "cgu-policy3-common-ptp-sub-policy",
    "cgu-policy4-common-sriov-sub-policy"
  ],
  "precaching": {
    "spec": {}
  },
  "remediationPlan": [
    [
      "spoke1",
      "spoke2"
    ],
    [
      "spoke5",
      "spoke6"
    ]
  ],
  "status": {}
}

      1
      ClusterGroupUpgrade CR 中的 spec.enable 字段设置为 false。

    3. 运行以下命令，检查策略的状态： 

      $ oc get policies -A

      输出示例

      NAMESPACE   NAME                                                 REMEDIATION ACTION   COMPLIANCE STATE   AGE
default     cgu-policy1-common-cluster-version-policy            enforce                                 17m 1
default     cgu-policy2-common-nto-sub-policy                    enforce                                 17m
default     cgu-policy3-common-ptp-sub-policy                    enforce                                 17m
default     cgu-policy4-common-sriov-sub-policy                  enforce                                 17m
default     policy1-common-cluster-version-policy                inform               NonCompliant       15h
default     policy2-common-nto-sub-policy                        inform               NonCompliant       15h
default     policy3-common-ptp-sub-policy                        inform               NonCompliant       18m
default     policy4-common-sriov-sub-policy                      inform               NonCompliant       18m

      1
      目前在集群中应用的策略的 spec.remediationAction 字段被设置为 enforce。在更新过程中，来自 ClusterGroupUpgrade CR 的 inform 模式的受管策略会处于 inform 模式。

  3. 运行以下命令，将 spec.enable 字段的值更改为 true ： 

    $ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-1 \
--patch '{"spec":{"enable":true}}' --type=merge

验证

  1. 运行以下命令，再次检查更新的状态： 

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

    输出示例

    {
  "computedMaxConcurrency": 2,
  "conditions": [ 1
    {
      "lastTransitionTime": "2022-02-25T15:33:07Z",
      "message": "All selected clusters are valid",
      "reason": "ClusterSelectionCompleted",
      "status": "True",
      "type": "ClustersSelected",
      "lastTransitionTime": "2022-02-25T15:33:07Z",
      "message": "Completed validation",
      "reason": "ValidationCompleted",
      "status": "True",
      "type": "Validated",
      "lastTransitionTime": "2022-02-25T15:34:07Z",
      "message": "Remediating non-compliant policies",
      "reason": "InProgress",
      "status": "True",
      "type": "Progressing"
    }
  ],
  "copiedPolicies": [
    "cgu-policy1-common-cluster-version-policy",
    "cgu-policy2-common-nto-sub-policy",
    "cgu-policy3-common-ptp-sub-policy",
    "cgu-policy4-common-sriov-sub-policy"
  ],
  "managedPoliciesContent": {
    "policy1-common-cluster-version-policy": "null",
    "policy2-common-nto-sub-policy": "[{\"kind\":\"Subscription\",\"name\":\"node-tuning-operator\",\"namespace\":\"openshift-cluster-node-tuning-operator\"}]",
    "policy3-common-ptp-sub-policy": "[{\"kind\":\"Subscription\",\"name\":\"ptp-operator-subscription\",\"namespace\":\"openshift-ptp\"}]",
    "policy4-common-sriov-sub-policy": "[{\"kind\":\"Subscription\",\"name\":\"sriov-network-operator-subscription\",\"namespace\":\"openshift-sriov-network-operator\"}]"
  },
  "managedPoliciesForUpgrade": [
    {
      "name": "policy1-common-cluster-version-policy",
      "namespace": "default"
    },
    {
      "name": "policy2-common-nto-sub-policy",
      "namespace": "default"
    },
    {
      "name": "policy3-common-ptp-sub-policy",
      "namespace": "default"
    },
    {
      "name": "policy4-common-sriov-sub-policy",
      "namespace": "default"
    }
  ],
  "managedPoliciesNs": {
    "policy1-common-cluster-version-policy": "default",
    "policy2-common-nto-sub-policy": "default",
    "policy3-common-ptp-sub-policy": "default",
    "policy4-common-sriov-sub-policy": "default"
  },
  "placementBindings": [
    "cgu-policy1-common-cluster-version-policy",
    "cgu-policy2-common-nto-sub-policy",
    "cgu-policy3-common-ptp-sub-policy",
    "cgu-policy4-common-sriov-sub-policy"
  ],
  "placementRules": [
    "cgu-policy1-common-cluster-version-policy",
    "cgu-policy2-common-nto-sub-policy",
    "cgu-policy3-common-ptp-sub-policy",
    "cgu-policy4-common-sriov-sub-policy"
  ],
  "precaching": {
    "spec": {}
  },
  "remediationPlan": [
    [
      "spoke1",
      "spoke2"
    ],
    [
      "spoke5",
      "spoke6"
    ]
  ],
  "status": {
    "currentBatch": 1,
    "currentBatchStartedAt": "2022-02-25T15:54:16Z",
    "remediationPlanForBatch": {
      "spoke1": 0,
      "spoke2": 1
    },
    "startedAt": "2022-02-25T15:54:16Z"
  }
}

    1
    反映当前批处理的更新进度。再次运行该命令以接收有关进度的更新信息。

  2. 如果策略包含 Operator 订阅，您可以在单节点集群中直接检查安装进度。

    1. 运行以下命令，导出用于检查安装的单节点集群的 KUBECONFIG 文件： 

      $ export KUBECONFIG=<cluster_kubeconfig_absolute_path>

    2. 运行以下命令，检查单节点集群中存在的所有订阅，并在您要通过 ClusterGroupUpgrade CR 安装的策略中查找您要通过 ClusterGroupUpgrade CR 安装的订阅： 

      $ oc get subs -A | grep -i <subscription_name>

      cluster-logging 策略的输出示例

      NAMESPACE                              NAME                         PACKAGE                      SOURCE             CHANNEL
openshift-logging                      cluster-logging              cluster-logging              redhat-operators   stable

  3. 如果其中一个受管策略包含 ClusterVersion CR，则根据 spoke 集群运行以下命令来检查当前批处理中的平台更新状态： 

    $ oc get clusterversion

    输出示例

    NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.4.13.5     True        True          43s     Working towards 4.4.13.7: 71 of 735 done (9% complete)

  4. 运行以下命令检查 Operator 订阅： 

    $ oc get subs -n <operator-namespace> <operator-subscription> -ojsonpath="{.status}"

  5. 运行以下命令，检查与所需订阅关联的单节点集群中是否存在安装计划： 

    $ oc get installplan -n <subscription_namespace>

    cluster-logging Operator 的输出示例

    NAMESPACE                              NAME            CSV                                 APPROVAL   APPROVED
openshift-logging                      install-6khtw   cluster-logging.5.3.3-4             Manual     true 1

    1
    安装计划在 TALM 批准安装计划后将其 Approval 字段设置为 Manual，其 Approved 字段会从 false 改为 true。
    注意

    当 TALM 修复包含订阅的策略时，它会自动批准附加到该订阅的任何安装计划。如果需要多个安装计划将 Operator 升级到最新的已知版本，TALM 可能会批准多个安装计划，通过一个或多个中间版本进行升级以进入最终版本。

  6. 运行以下命令，检查正在安装 ClusterGroupUpgrade 的策略的 Operator 的集群服务版本是否已进入 Succeeded 阶段： 

    $ oc get csv -n <operator_namespace>

    OpenShift Logging Operator 的输出示例

    NAME                    DISPLAY                     VERSION   REPLACES   PHASE
cluster-logging.5.4.2   Red Hat OpenShift Logging   5.4.2                Succeeded

19.10.7. 在升级前创建集群资源备份

对于单节点 OpenShift，Topology Aware Lifecycle Manager (TALM) 可以在升级前创建部署备份。如果升级失败，您可以恢复之前的版本并将集群恢复到工作状态，而无需重新置备应用程序。

要使用备份功能，您首先创建一个 ClusterGroupUpgrade CR，并将 backup 字段设置为 true。为确保备份内容为最新版本，在 ClusterGroupUpgrade CR 中的 enable 字段设置为 true 之前，不会进行备份。

TALM 使用 BackupSucceeded 条件来报告状态，如下所示：

  • true

    备份对于所有集群都完成，或备份运行已完成但对一个或多个集群失败。如果任何集群的备份失败，则不会为该集群进行更新。

  • false

    备份仍在为一个或多个集群处理，或者所有集群都失败。在 spoke 集群中运行的备份过程可以具有以下状态：

    • PreparingToStart

      第一个协调通过正在进行。TALM 删除所有 spoke 备份命名空间和 hub 查看在升级尝试中创建的资源。

    • Starting

      正在创建备份先决条件和备份作业。

    • Active

      备份正在进行。

    • Succeeded

      备份成功。

    • BackupTimeout

      工件备份部分完成。

    • UnrecoverableError

      备份以非零退出代码结尾。

注意

如果集群备份失败，且进入 BackupTimeout 或 UnrecoverableError 状态，集群更新不会对集群进行。对其他集群的更新不会受到影响，并继续。

19.10.7.1. 使用备份创建 ClusterGroupUpgrade CR

您可以在单节点 OpenShift 集群上升级前创建部署备份。如果升级失败，您可以使用 Topology Aware Lifecycle Manager (TALM) 生成的 upgrade-recovery.sh 脚本将系统返回到其 preupgrade 状态。备份由以下项目组成：

集群备份
etcd 和静态 pod 清单的快照。
内容备份
文件夹备份，例如 /etc、/usr/local、/var/lib/kubelet。
已更改的文件备份
由 machine-config 管理的任何文件都已更改。
Deployment
固定 ostree 部署。
镜像（可选）
使用的任何容器镜像。

先决条件

  • 安装 Topology Aware Lifecycle Manager(TALM)。
  • 置备一个或多个受管集群。
  • 以具有 cluster-admin 特权的用户身份登录。
  • 安装 Red Hat Advanced Cluster Management (RHACM)。
注意

强烈建议您创建一个恢复分区。以下是一个恢复分区的 SiteConfig 自定义资源 (CR) 示例，大小为 50 GB： 

nodes:
    - hostName: "node-1.example.com"
    role: "master"
    rootDeviceHints:
        hctl: "0:2:0:0"
        deviceName: /dev/disk/by-id/scsi-3600508b400105e210000900000490000
...
    #Disk /dev/disk/by-id/scsi-3600508b400105e210000900000490000:
    #893.3 GiB, 959119884288 bytes, 1873281024 sectors
    diskPartition:
        - device: /dev/disk/by-id/scsi-3600508b400105e210000900000490000
        partitions:
        - mount_point: /var/recovery
            size: 51200
            start: 800000

流程

  1. 在 clustergroupupgrades-group-du.yaml 文件中保存 ClusterGroupUpgrade CR 的内容，并 backup 和 enable 字段设置为 true： 

    apiVersion: ran.openshift.io/v1alpha1
kind: ClusterGroupUpgrade
metadata:
  name: du-upgrade-4918
  namespace: ztp-group-du-sno
spec:
  preCaching: true
  backup: true
  clusters:
  - cnfdb1
  - cnfdb2
  enable: true
  managedPolicies:
  - du-upgrade-platform-upgrade
  remediationStrategy:
    maxConcurrency: 2
    timeout: 240

  2. 要启动更新，请运行以下命令来应用 ClusterGroupUpgrade CR： 

    $ oc apply -f clustergroupupgrades-group-du.yaml

验证

  • 运行以下命令，检查 hub 集群中的升级状态： 

    $ oc get cgu -n ztp-group-du-sno du-upgrade-4918 -o jsonpath='{.status}'

    输出示例

    {
    "backup": {
        "clusters": [
            "cnfdb2",
            "cnfdb1"
    ],
    "status": {
        "cnfdb1": "Succeeded",
        "cnfdb2": "Failed" 1
    }
},
"computedMaxConcurrency": 1,
"conditions": [
    {
        "lastTransitionTime": "2022-04-05T10:37:19Z",
        "message": "Backup failed for 1 cluster", 2
        "reason": "PartiallyDone", 3
        "status": "True", 4
        "type": "Succeeded"
    }
],
"precaching": {
    "spec": {}
},
"status": {}

    1
    对一个集群进行备份失败。
    2
    消息确认一个集群的备份失败。
    3
    备份部分成功。
    4
    备份过程已完成。

19.10.7.2. 在升级后恢复集群

如果集群的升级失败，您可以手动登录到集群，并使用备份使集群返回到其升级前的状态。有两个阶段：

回滚（Rollback）
如果尝试升级包括对平台操作系统部署的更改，则必须在运行恢复脚本前回滚到以前的版本。
重要

回滚仅适用于从 TALM 和单节点 OpenShift 升级。这个过程不适用于从任何其他升级类型进行回滚。

恢复
恢复会关闭容器，并使用备份分区中的文件来重新启动容器并恢复集群。

先决条件

  • 安装 Topology Aware Lifecycle Manager(TALM)。
  • 置备一个或多个受管集群。
  • 安装 Red Hat Advanced Cluster Management (RHACM)。
  • 以具有 cluster-admin 特权的用户身份登录。
  • 运行为备份而配置的升级。

流程

  1. 运行以下命令来删除之前创建的 ClusterGroupUpgrade 自定义资源 (CR)： 

    $ oc delete cgu/du-upgrade-4918 -n ztp-group-du-sno
  2. 登录到要恢复的集群。

  3. 运行以下命令，检查平台操作系统部署的状态： 

    $ ostree admin status

    输出示例

    [root@lab-test-spoke2-node-0 core]# ostree admin status
* rhcos c038a8f08458bbed83a77ece033ad3c55597e3f64edad66ea12fda18cbdceaf9.0
    Version: 49.84.202202230006-0
    Pinned: yes 1
    origin refspec: c038a8f08458bbed83a77ece033ad3c55597e3f64edad66ea12fda18cbdceaf9

    1
    当前部署已被固定。不需要平台操作系统部署回滚。 
    [root@lab-test-spoke2-node-0 core]# ostree admin status
* rhcos f750ff26f2d5550930ccbe17af61af47daafc8018cd9944f2a3a6269af26b0fa.0
    Version: 410.84.202204050541-0
    origin refspec: f750ff26f2d5550930ccbe17af61af47daafc8018cd9944f2a3a6269af26b0fa
rhcos ad8f159f9dc4ea7e773fd9604c9a16be0fe9b266ae800ac8470f63abc39b52ca.0 (rollback) 1
    Version: 410.84.202203290245-0
    Pinned: yes 2
    origin refspec: ad8f159f9dc4ea7e773fd9604c9a16be0fe9b266ae800ac8470f63abc39b52ca
    1
    此平台操作系统部署标记为回滚。
    2
    以前的部署已被固定，可以回滚。

  4. 要触发平台操作系统部署的回滚，请运行以下命令： 

    $ rpm-ostree rollback -r

  5. 恢复的第一阶段会关闭容器，并将文件从备份分区恢复到目标目录。要开始恢复，请运行以下命令： 

    $ /var/recovery/upgrade-recovery.sh

  6. 提示时，运行以下命令重启集群： 

    $ systemctl reboot

  7. 重新引导后，运行以下命令重启恢复： 

    $ /var/recovery/upgrade-recovery.sh  --resume
注意

如果恢复工具失败，您可以使用 --restart 选项重试： 

$ /var/recovery/upgrade-recovery.sh --restart

验证

  • 运行以下命令检查恢复的状态： 

    $ oc get clusterversion,nodes,clusteroperator

    输出示例

    NAME                                         VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
clusterversion.config.openshift.io/version   4.4.13.23    True        False         86d     Cluster version is 4.4.13.23 1


NAME                          STATUS   ROLES           AGE   VERSION
node/lab-test-spoke1-node-0   Ready    master,worker   86d   v1.22.3+b93fd35 2

NAME                                                                           VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
clusteroperator.config.openshift.io/authentication                             4.4.13.23    True        False         False      2d7h    3
clusteroperator.config.openshift.io/baremetal                                  4.4.13.23    True        False         False      86d


..............

    1
    集群版本可用，并具有正确的版本。
    2
    节点状态为 Ready。
    3
    ClusterOperator 对象的可用性为 True。

19.10.8. 使用容器镜像预缓存功能

单节点 OpenShift 集群可能有限带宽来访问容器镜像 registry，这可能会在更新完成前造成超时。

注意

TALM 不会设置更新的时间。您可以在通过手动应用程序或外部自动化进行更新时应用 ClusterGroupUpgrade CR。

当 preCaching 字段在 ClusterGroupUpgrade CR 中被设置为 true 时，容器镜像预缓存会启动。

TALM 使用 PrecacheSpecValid 条件来报告状态信息，如下所示：

  • true

    预缓存规格有效且一致。

  • false

    预缓存规格不完整。

TALM 使用 PrecachingSucceeded 条件来报告状态信息，如下所示：

  • true

    TALM 已完成预缓存过程。如果任何集群的预缓存失败，则该集群的更新会失败，但会继续执行所有其他集群。如果任何集群预缓存失败，您会接收到一个通知信息。

  • false

    预缓存仍在为一个或多个集群处理，或者所有集群都失败。

在成功预缓存后，您可以启动补救策略。当 enable 字段设置为 true 时，补救操作会启动。如果集群中存在预缓存失败，则对该集群的升级会失败。升级过程将继续用于成功预缓存的所有其他集群。

预缓存过程可以处于以下状态：

  • NotStarted

    这是所有集群在第一次协调时会自动分配给 ClusterGroupUpgrade CR 的初始状态。在这个状态中，TALM 会删除来自之前更新中所有 spoke 集群的预缓存命名空间和 hub 查看资源。然后，TALM 为 spoke 创建一个新的 ManagedClusterView 资源，以便在 PrecachePreparing 状态验证删除。

  • PreparingToStart

    清理之前不完整更新中的所有剩余的资源，资源正在进行中。

  • Starting

    预缓存任务前提条件并创建了作业。

  • Active

    该作业的状态为"Active"状态。

  • Succeeded

    pre-cache（预缓存）作业成功。

  • PrecacheTimeout

    工件预缓存是部分完成的。

  • UnrecoverableError

    作业以非零退出代码结束。

19.10.8.1. 使用容器镜像预缓存过滤器

预缓存功能通常下载比集群进行更新所需要镜像更多的镜像。您可以控制将哪些预缓存镜像下载到集群中。这可缩短下载时间，并节省带宽和存储。

您可以使用以下命令查看要下载的所有镜像的列表： 

$ oc adm release info <ocp-version>

以下 ConfigMap 示例演示了如何使用 excludePrecachePatterns 字段排除镜像。 

apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-group-upgrade-overrides
data:
  excludePrecachePatterns: |
    azure 1
    aws
    vsphere
    alibaba
1
TALM 排除所有带有名称的镜像，其中包括此处列出的任何模式。

19.10.8.2. 使用预缓存创建 ClusterGroupUpgrade CR

对于单节点 OpenShift，在更新启动前，预缓存功能允许在 spoke 集群上存在所需的容器镜像。

注意

对于预缓存，TALM 使用 ClusterGroupUpgrade CR 中的 spec.remediationStrategy.timeout 值。您必须设置一个 timeout 值，允许足够时间完成预缓存作业。当您在预缓存完成后启用 ClusterGroupUpgrade CR 时，您可以将 timeout 值改为适合更新的持续时间。

先决条件

  • 安装 Topology Aware Lifecycle Manager(TALM)。
  • 置备一个或多个受管集群。
  • 以具有 cluster-admin 特权的用户身份登录。

流程

  1. 在 clustergroupupgrades-group-du.yaml 文件中将 preCaching 字段设置为 true 来保存 ClusterGroupUpgrade CR 的内容： 

    apiVersion: ran.openshift.io/v1alpha1
kind: ClusterGroupUpgrade
metadata:
  name: du-upgrade-4918
  namespace: ztp-group-du-sno
spec:
  preCaching: true 1
  clusters:
  - cnfdb1
  - cnfdb2
  enable: false
  managedPolicies:
  - du-upgrade-platform-upgrade
  remediationStrategy:
    maxConcurrency: 2
    timeout: 240
    1
    preCaching 字段设为 true，它允许 TALM 在开始更新前拉取容器镜像。

  2. 当您要启动预缓存时，请运行以下命令应用 ClusterGroupUpgrade CR： 

    $ oc apply -f clustergroupupgrades-group-du.yaml

验证

  1. 运行以下命令，检查 hub 集群中是否存在 ClusterGroupUpgrade CR： 

    $ oc get cgu -A

    输出示例

    NAMESPACE          NAME              AGE   STATE        DETAILS
ztp-group-du-sno   du-upgrade-4918   10s   InProgress   Precaching is required and not done 1

    1
    CR 被创建。

  2. 运行以下命令，检查预缓存任务的状态： 

    $ oc get cgu -n ztp-group-du-sno du-upgrade-4918 -o jsonpath='{.status}'

    输出示例

    {
  "conditions": [
    {
      "lastTransitionTime": "2022-01-27T19:07:24Z",
      "message": "Precaching is required and not done",
      "reason": "InProgress",
      "status": "False",
      "type": "PrecachingSucceeded"
    },
    {
      "lastTransitionTime": "2022-01-27T19:07:34Z",
      "message": "Pre-caching spec is valid and consistent",
      "reason": "PrecacheSpecIsWellFormed",
      "status": "True",
      "type": "PrecacheSpecValid"
    }
  ],
  "precaching": {
    "clusters": [
      "cnfdb1" 1
      "cnfdb2"
    ],
    "spec": {
      "platformImage": "image.example.io"},
    "status": {
      "cnfdb1": "Active"
      "cnfdb2": "Succeeded"}
    }
}

    1
    显示已识别的集群列表。

  3. 在 spoke 集群中运行以下命令来检查预缓存作业的状态： 

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

    输出示例

    NAME                  COMPLETIONS   DURATION   AGE
job.batch/pre-cache   0/1           3m10s      3m10s

NAME                     READY   STATUS    RESTARTS   AGE
pod/pre-cache--1-9bmlr   1/1     Running   0          3m10s

  4. 运行以下命令，检查 ClusterGroupUpgrade CR 的状态： 

    $ oc get cgu -n ztp-group-du-sno du-upgrade-4918 -o jsonpath='{.status}'

    输出示例

    "conditions": [
    {
      "lastTransitionTime": "2022-01-27T19:30:41Z",
      "message": "The ClusterGroupUpgrade CR has all clusters compliant with all the managed policies",
      "reason": "UpgradeCompleted",
      "status": "True",
      "type": "Ready"
    },
    {
      "lastTransitionTime": "2022-01-27T19:28:57Z",
      "message": "Precaching is completed",
      "reason": "PrecachingCompleted",
      "status": "True",
      "type": "PrecachingSucceeded" 1
    }

    1
    预缓存任务已完成。

19.10.9. 对 Topology Aware Lifecycle Manager 进行故障排除

Topology Aware Lifecycle Manager(TALM)是一个 OpenShift Container Platform Operator，用于修复 RHACM 策略。出现问题时，使用 oc adm must-gather 命令来收集详情和日志，并采取调试问题的步骤。

有关相关主题的更多信息，请参阅以下文档：

19.10.9.1. 常规故障排除

您可以通过查看以下问题来确定问题的原因：

为确保 ClusterGroupUpgrade 配置可以正常工作，您可以执行以下操作：

  1. 创建 ClusterGroupUpgrade CR，并将 spec.enable 字段设置为 false。
  2. 等待状态更新，再完成故障排除问题。
  3. 如果所有内容都如预期，在 ClusterGroupUpgrade CR 中将 spec.enable 字段设置为 true。
警告

在 ClusterUpgradeGroup CR 中将 spec.enable 字段设置为 true 后，更新过程会启动，您无法再编辑 CR 的 spec 字段。

19.10.9.2. 无法修改 ClusterUpgradeGroup CR

问题
在启用更新后，您无法编辑 ClusterUpgradeGroup CR。
解决方案

通过执行以下步骤来重启操作：

  1. 运行以下命令删除旧 ClusterGroupUpgrade CR： 

    $ oc delete cgu -n <ClusterGroupUpgradeCR_namespace> <ClusterGroupUpgradeCR_name>

  2. 检查并修复受管集群和策略的现有问题。

    1. 确保所有集群都是受管集群并可用。
    2. 确保所有策略都存在，并将 spec.remediationAction 字段设置为 inform。

  3. 使用正确的配置创建一个新的 ClusterGroupUpgrade CR。 

    $ oc apply -f <ClusterGroupUpgradeCR_YAML>

19.10.9.3. 受管策略

检查系统中的受管策略
问题
您需要检查系统中是否有正确的受管策略。
解决方案

运行以下命令: 

$ oc get cgu lab-upgrade -ojsonpath='{.spec.managedPolicies}'

输出示例

["group-du-sno-validator-du-validator-policy", "policy2-common-nto-sub-policy", "policy3-common-ptp-sub-policy"]

检查 remediationAction 模式
问题
您要检查在受管策略的 spec 中是否将 remediationAction 字段设置为 inform。
解决方案

运行以下命令: 

$ oc get policies --all-namespaces

输出示例

NAMESPACE   NAME                                                 REMEDIATION ACTION   COMPLIANCE STATE   AGE
default     policy1-common-cluster-version-policy                inform               NonCompliant       5d21h
default     policy2-common-nto-sub-policy                        inform               Compliant          5d21h
default     policy3-common-ptp-sub-policy                        inform               NonCompliant       5d21h
default     policy4-common-sriov-sub-policy                      inform               NonCompliant       5d21h

检查策略合规状态
问题
您需要检查策略的合规性状态。
解决方案

运行以下命令: 

$ oc get policies --all-namespaces

输出示例

NAMESPACE   NAME                                                 REMEDIATION ACTION   COMPLIANCE STATE   AGE
default     policy1-common-cluster-version-policy                inform               NonCompliant       5d21h
default     policy2-common-nto-sub-policy                        inform               Compliant          5d21h
default     policy3-common-ptp-sub-policy                        inform               NonCompliant       5d21h
default     policy4-common-sriov-sub-policy                      inform               NonCompliant       5d21h

19.10.9.4. Clusters

检查是否有受管集群
问题
您需要检查 ClusterGroupUpgrade CR 中的集群是受管集群。
解决方案

运行以下命令: 

$ oc get managedclusters

输出示例

NAME            HUB ACCEPTED   MANAGED CLUSTER URLS                    JOINED   AVAILABLE   AGE
local-cluster   true           https://api.hub.example.com:6443        True     Unknown     13d
spoke1          true           https://api.spoke1.example.com:6443     True     True        13d
spoke3          true           https://api.spoke3.example.com:6443     True     True        27h

  1. 或者，检查 TALM manager 日志：

    1. 运行以下命令，获取 TALM Manager 的名称： 

      $ oc get pod -n openshift-operators

      输出示例

      NAME                                                         READY   STATUS    RESTARTS   AGE
cluster-group-upgrades-controller-manager-75bcc7484d-8k8xp   2/2     Running   0          45m

    2. 运行以下命令检查 TALM manager 日志： 

      $ oc logs -n openshift-operators \
cluster-group-upgrades-controller-manager-75bcc7484d-8k8xp -c manager

      输出示例

      ERROR	controller-runtime.manager.controller.clustergroupupgrade	Reconciler error	{"reconciler group": "ran.openshift.io", "reconciler kind": "ClusterGroupUpgrade", "name": "lab-upgrade", "namespace": "default", "error": "Cluster spoke5555 is not a ManagedCluster"} 1
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem

      1
      错误消息显示集群不是受管集群。
检查受管集群是否可用
问题
您需要检查 ClusterGroupUpgrade CR 中指定的受管集群是否可用。
解决方案

运行以下命令: 

$ oc get managedclusters

输出示例

NAME            HUB ACCEPTED   MANAGED CLUSTER URLS                    JOINED   AVAILABLE   AGE
local-cluster   true           https://api.hub.testlab.com:6443        True     Unknown     13d
spoke1          true           https://api.spoke1.testlab.com:6443     True     True        13d 1
spoke3          true           https://api.spoke3.testlab.com:6443     True     True        27h 2

1 2
受管集群的 AVAILABLE 字段的值是 True。
检查 clusterLabelSelector
问题
您需要检查 ClusterGroupUpgrade CR 中指定的 clusterLabelSelector 字段是否至少与其中一个受管集群匹配。
解决方案

运行以下命令: 

$ oc get managedcluster --selector=upgrade=true 1
1
要更新的集群标签是 upgrade:true。

输出示例

NAME            HUB ACCEPTED   MANAGED CLUSTER URLS                     JOINED    AVAILABLE   AGE
spoke1          true           https://api.spoke1.testlab.com:6443      True     True        13d
spoke3          true           https://api.spoke3.testlab.com:6443      True     True        27h

检查是否有 canary 集群
问题

您要检查集群列表中是否存在 Canary 集群。

ClusterGroupUpgrade CR 示例

spec:
    remediationStrategy:
        canaries:
        - spoke3
        maxConcurrency: 2
        timeout: 240
    clusterLabelSelectors:
      - matchLabels:
          upgrade: true

解决方案

运行以下命令： 

$ oc get cgu lab-upgrade -ojsonpath='{.spec.clusters}'

输出示例

["spoke1", "spoke3"]

  1. 运行以下命令，检查与 clusterLabelSelector 标签匹配的集群列表中是否存在 Canary 集群： 

    $ oc get managedcluster --selector=upgrade=true

    输出示例

    NAME            HUB ACCEPTED   MANAGED CLUSTER URLS   JOINED    AVAILABLE   AGE
spoke1          true           https://api.spoke1.testlab.com:6443   True     True        13d
spoke3          true           https://api.spoke3.testlab.com:6443   True     True        27h

注意

集群可以存在于 spec.clusters 中，还可与 spec.clusterLabelSelector 标签匹配。

检查 spoke 集群上的预缓存状态

  1. 在 spoke 集群中运行以下命令来检查预缓存的状态： 

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

19.10.9.5. 补救策略

检查 ClusterGroupUpgrade CR 中是否存在 remediationStrategy
问题
您需要检查 ClusterGroupUpgrade CR 是否存在 remediationStrategy。
解决方案

运行以下命令: 

$ oc get cgu lab-upgrade -ojsonpath='{.spec.remediationStrategy}'

输出示例

{"maxConcurrency":2, "timeout":240}

检查 ClusterGroupUpgrade CR 中是否指定了 maxConcurrency
问题
您需要检查是否在 ClusterGroupUpgrade CR 中指定 maxConcurrency。
解决方案

运行以下命令: 

$ oc get cgu lab-upgrade -ojsonpath='{.spec.remediationStrategy.maxConcurrency}'

输出示例

2

19.10.9.6. Topology Aware Lifecycle Manager

检查 ClusterGroupUpgrade CR 中的条件消息和状态
问题
您要检查 ClusterGroupUpgrade CR 中的 status.conditions 字段的值。
解决方案

运行以下命令: 

$ oc get cgu lab-upgrade -ojsonpath='{.status.conditions}'

输出示例

{"lastTransitionTime":"2022-02-17T22:25:28Z", "message":"Missing managed policies:[policyList]", "reason":"NotAllManagedPoliciesExist", "status":"False", "type":"Validated"}

检查对应的复制策略
问题
您需要检查 status.managedPoliciesForUpgrade 的每个策略是否具有 status.copiedPolicies 对应的策略。
解决方案

运行以下命令: 

$ oc get cgu lab-upgrade -oyaml

输出示例

status:
  …
  copiedPolicies:
  - lab-upgrade-policy3-common-ptp-sub-policy
  managedPoliciesForUpgrade:
  - name: policy3-common-ptp-sub-policy
    namespace: default

检查 status.remediationPlan 是否已计算
问题
您需要检查 status.remediationPlan 是否被计算。
解决方案

运行以下命令: 

$ oc get cgu lab-upgrade -ojsonpath='{.status.remediationPlan}'

输出示例

[["spoke2", "spoke3"]]

TALM manager 容器中的错误
问题
您要检查 TALM 的 manager 容器的日志。
解决方案

运行以下命令: 

$ oc logs -n openshift-operators \
cluster-group-upgrades-controller-manager-75bcc7484d-8k8xp -c manager

输出示例

ERROR	controller-runtime.manager.controller.clustergroupupgrade	Reconciler error	{"reconciler group": "ran.openshift.io", "reconciler kind": "ClusterGroupUpgrade", "name": "lab-upgrade", "namespace": "default", "error": "Cluster spoke5555 is not a ManagedCluster"} 1
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem

1
显示错误。
在 ClusterGroupUpgrade CR 完成后，集群可能不符合一些策略
问题

TALM 用来决定是否需要补救的策略合规状态，还没有为所有集群完全更新。这可能是因为：

  • 在策略创建或更新后，CGU 很快就会运行。
  • 策略的补救会影响 ClusterGroupUpgrade CR 中后续策略的合规性。
解决方案
创建并应用具有相同规格的新 ClusterGroupUpdate CR。
在 GitOps ZTP 工作流中自动创建 ClusterGroupUpgrade CR 没有受管策略
问题
如果集群变为 Ready 时，没有用于受管集群的策略，则会自动创建一个没有策略的 ClusterGroupUpgrade CR。完成 ClusterGroupUpgrade CR 后，受管集群被标记为 ztp-done。在推送 SiteConfig 资源后，如果 PolicyGenTemplate CR 在所需时间内没有被推送到 Git 存储库，这可能会导致当集群变为 Ready 时目标集群没有可用的策略。
解决方案
验证您要应用的策略是否在 hub 集群中可用，然后使用所需策略创建一个 ClusterGroupUpgrade CR。

您可以手动创建 ClusterGroupUpgrade CR，或再次触发自动创建。要触发 ClusterGroupUpgrade CR 的自动创建，请从集群中删除 ztp-done 标签，并删除之前在 zip-install 命名空间中创建的空 ClusterGroupUpgrade CR。

预缓存失败
问题

预缓存可能会因为以下原因之一失败：

  • 节点上没有足够的可用空间。
  • 对于断开连接的环境，预缓存镜像没有正确镜像。
  • 创建 pod 时存在问题。
解决方案

  1. 要检查预缓存是否已因为空间不足而失败，请检查节点中预缓存 pod 的日志。

    1. 使用以下命令查找 pod 的名称： 

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

    2. 使用以下命令检查日志以查看错误是否与足够空间相关： 

      $ oc logs -n openshift-talo-pre-cache <pod name>

  2. 如果没有日志，使用以下命令检查 pod 状态： 

    $ oc describe pod -n openshift-talo-pre-cache <pod name>

  3. 如果 pod 不存在，请检查作业状态以查看它无法使用以下命令创建 pod 的原因： 

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

其他资源

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.