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

第 15 章 单节点 OpenShift 集群的基于镜像的升级

15.1. 了解单节点 OpenShift 集群的基于镜像的升级

从 OpenShift Container Platform 4.14.13，生命周期代理为您提供了升级单节点 OpenShift 集群的平台版本的替代方法。基于镜像的升级比标准升级方法快，允许您直接从 OpenShift Container Platform <4.y> 升级到 <4.y+2>，并将 <4.y.z> 升级到 <4.y.z+n>。

此升级方法从目标单节点 OpenShift 集群上安装的专用 seed 集群中生成 OCI 镜像作为新的 ostree stateroot。seed 集群是一个单节点 OpenShift 集群，它部署了目标 OpenShift Container Platform 版本、第 2 天 Operator 和配置，适用于所有目标集群。

您可以使用 seed 镜像（从 seed 集群生成的镜像）升级任何单节点 OpenShift 集群上的平台版本，这些版本与 seed 集群相同的硬件、第 2 天 Operator 和集群配置组合。

重要

基于镜像的升级使用特定于集群在其上运行的硬件平台的自定义镜像。每个不同的硬件平台都需要单独的看到的镜像。

Lifecycle Agent 在参与集群中使用两个自定义资源 (CR) 来编配升级：

  • 在 seed 集群中，SeedGenerator CR 允许 seedGenerator CR 生成。此 CR 指定要将 seed 镜像推送到的存储库。
  • 在目标集群中，ImageBasedUpgrade CR 为升级目标集群和工作负载的备份配置指定 seed 镜像。

示例 SeedGenerator CR

apiVersion: lca.openshift.io/v1
kind: SeedGenerator
metadata:
  name: seedimage
spec:
  seedImage: <seed_image>

ImageBasedUpgrade CR 示例

apiVersion: lca.openshift.io/v1
kind: ImageBasedUpgrade
metadata:
  name: upgrade
spec:
  stage: Idle 1
  seedImageRef: 2
    version: <target_version>
    image: <seed_container_image>
    pullSecretRef:
      name: <seed_pull_secret>
  autoRollbackOnFailure: {}
#    initMonitorTimeoutSeconds: 1800 3
  extraManifests: 4
  - name: example-extra-manifests
    namespace: openshift-lifecycle-agent
  oadpContent: 5
  - name: oadp-cm-example
    namespace: openshift-adp

1
定义 ImageBasedUpgrade CR 所需的阶段。该值可以是 Idle、Prep、Upgrade 或 Rollback。
2
定义目标平台版本、要使用的 seed 镜像以及访问镜像所需的 secret。
3
（可选）指定当升级在第一次重启后没有完成时回滚的时间帧（可选）。如果没有定义或设置为 0，则使用默认值 1800 秒 (30 分钟)。
4
（可选）指定要在升级后保留的自定义目录源的 ConfigMap 资源列表，以及要应用到不是 seed 镜像一部分的目标集群的额外清单。
5
指定包含 OADP Backup 和 Restore CR 的 ConfigMap 资源列表。

15.1.1. 基于镜像的升级的阶段

在 seed 集群中生成 seed 镜像后，您可以通过将 spec.stage 字段设置为 ImageBasedUpgrade CR 中的以下值之一来进入目标集群的阶段：

  • Idle
  • Prep
  • Upgrade（升级）
  • Rollback (可选)

图 15.1. 基于镜像的升级的阶段

基于镜像的升级的阶段

15.1.1.1. 空闲阶段

Lifecycle Agent 创建一个 ImageBasedUpgrade CR 设置为 stage: Idle （当 Operator 首次部署时）。这是默认的阶段。没有持续升级，集群已准备好移至 Prep 阶段。

图 15.2. 从 Idle 阶段过渡

从 Idle 阶段过渡

您还可以移至 Idle 阶段来执行以下步骤之一：

  • 完成成功升级
  • 完成回滚
  • 取消持续升级，直到 Upgrade 阶段的 pre-pivot 阶段为止

移到 Idle 阶段可确保 Lifecycle Agent 清理资源，以便集群可以再次升级。

图 15.3. 转换为空闲阶段

转换为空闲阶段
重要

如果在取消升级时使用 RHACM，则必须从目标受管集群中删除 import.open-cluster-management.io/disable-auto-import 注解，以重新启用集群的自动导入。

15.1.1.2. Prep 阶段

注意

您可以在调度的维护窗口前完成此阶段。

对于 Prep 阶段，您可以在 ImageBasedUpgrade CR 中指定以下升级详情：

  • 要使用的 seed 镜像
  • 要备份的资源
  • 升级后要应用和自定义目录源的额外清单（若有）

然后，根据您指定的内容，生命周期代理准备升级，而不影响当前运行的版本。在这个阶段，生命周期代理通过检查它是否满足特定条件来确保目标集群已准备好进入 Upgrade 阶段。Operator 使用在 seed 镜像中指定的额外容器镜像将 seed 镜像拉取到目标集群。Lifecycle Agent 检查容器存储磁盘中是否有足够空间，如果需要，Operator 会删除未固定的镜像，直到磁盘用量低于指定阈值。有关如何配置或禁用清理容器存储磁盘的更多信息，请参阅"配置容器存储磁盘自动镜像清理"。

您还可以使用 OADP Operator 的 Backup 和 Restore CR 准备备份资源。这些 CR 在 Upgrade 阶段用于重新配置集群，使用 RHACM 注册集群，并恢复应用程序工件。

除了 OADP Operator 外，生命周期代理使用 ostree 版本系统创建一个备份，它允许在升级和回滚后完成集群重新配置。

在 Prep 阶段完成后，您可以通过移到 Idle 阶段来取消升级过程，或者您可以通过移到 ImageBasedUpgrade CR 中的 Upgrade 阶段来启动升级。如果取消升级，Operator 会执行清理操作。

图 15.4. 从 Prep 阶段过渡

从 Prep 阶段过渡

15.1.1.3. 升级阶段

Upgrade 阶段由两个阶段组成：

pre-pivot
在点新 stateroot 之前，生命周期代理会收集所需的特定于集群的工件，并将其存储在新的 stateroot 中。在 Prep 阶段指定的集群资源备份会在兼容对象存储解决方案中创建。Lifecycle Agent 导出在 ImageBasedUpgrade CR 中的 extraManifests 字段中指定的 CR，或绑定到目标集群的 ZTP 策略中描述的 CR。在 pre-pivot 阶段完成后，生命周期代理会将新的 stateroot 部署设置为默认的引导条目并重启节点。
post-pivot
从新 stateroot 引导后，生命周期代理还会重新生成 seed 镜像的集群加密。这样可确保每个单节点 OpenShift 集群使用相同的 seed 镜像升级都有唯一的且有效的加密对象。然后，Operator 会应用在 pre-pivot 阶段收集的特定于集群的工件来重新配置集群。Operator 应用所有保存的 CR，并恢复备份。

升级完成后，您可以对更改满意，您可以通过移至 Idle 阶段来完成升级。

重要

完成升级后，您无法回滚到原始版本。

图 15.5. 从 Upgrade stage 过渡

从 Upgrade stage 过渡

如果要取消升级，可以直到 Upgrade 阶段的 pre-pivot 阶段为止。如果在升级后遇到问题，您可以移到手动回滚的 Rollback 阶段。

15.1.1.4. 回滚阶段

Rollback 阶段可以手动启动，或者在失败时自动启动。在 Rollback 阶段，生命周期代理会将原始 ostree stateroot 部署设置为默认值。然后，节点会使用以前的 OpenShift Container Platform 和应用程序配置重启。

警告

如果在回滚后移至 Idle 阶段，则 Lifecycle Agent 会清理可用于对失败的升级进行故障排除的资源。

如果升级没有在指定时间限制内完成，则 Lifecycle Agent 将启动自动回滚。如需有关自动回滚的更多信息，请参阅 "Moving to the Rollback stage with Lifecycle Agent" 或 "Moving to the Rollback stage with Lifecycle Agent and GitOps ZTP" 部分。

图 15.6. 从 Rollback 阶段过渡

从 Rollback 阶段过渡

其他资源

15.1.2. 基于镜像的升级指南

要成功进行基于镜像的升级，您的部署必须满足某些要求。

您可以在执行基于镜像的升级时有不同的部署方法：

GitOps ZTP
您可以使用 GitOps Zero Touch Provisioning (ZTP) 来部署和配置集群。
Non-GitOps
您可以手动部署和配置集群。

您可以在断开连接的环境中执行基于镜像的升级。有关如何为断开连接的环境镜像镜像的更多信息，请参阅"为断开连接的安装镜像镜像"。

其他资源

15.1.2.1. 组件的最低软件版本

根据您的部署方法，基于镜像的升级需要以下最低软件版本。

表 15.1. 组件的最低软件版本
组件软件版本必填

生命周期代理

4.16

是

OADP Operator

1.4.1

是

受管集群版本

4.14.13

是

hub 集群版本

4.16

否

RHACM

2.10.2

否

GitOps ZTP 插件

4.16

只适用于 GitOps ZTP 部署方法

Red Hat OpenShift GitOps

1.12

只适用于 GitOps ZTP 部署方法

Topology Aware Lifecycle Manager (TALM)

4.16

只适用于 GitOps ZTP 部署方法

Local Storage Operator [1]

4.14

是

逻辑卷管理器 (LVM) 存储 [1]

4.14.2

是

  1. 持久性存储必须由 LVM Storage 或 Local Storage Operator 提供，不能由这两个 Operator 提供。

15.1.2.2. hub 集群指南

如果使用 Red Hat Advanced Cluster Management (RHACM)，您的 hub 集群需要满足以下条件：

  • 为了避免在 seed 镜像中包含任何 RHACM 资源，您需要在生成 seed 镜像前禁用所有可选 RHACM 附加组件。
  • 在执行基于镜像的升级前，您的 hub 集群必须至少升级到目标版本，然后才能执行目标单节点 OpenShift 集群。

15.1.2.3. seed 镜像指南

seed 镜像以一组具有相同硬件和类似配置的单节点 OpenShift 集群为目标。这意味着 seed 集群必须与以下项目的目标集群配置匹配：

  • CPU 拓扑

    • CPU 内核数
    • 调整的性能配置，如保留 CPU 的数量
  • 目标集群的 MachineConfig 资源

  • IP 版本

    注意

    这个版本不支持双栈网络。

  • 第 2 天 Operator 集，包括 Lifecycle Agent 和 OADP Operator
  • 断开连接的 registry
  • FIPS 配置

以下配置只需要在参与的集群中部分匹配：

  • 如果目标集群有代理配置，seed 集群必须具有代理配置，但配置不必相同。
  • 所有参与的集群都需要在主磁盘上的一个专用分区。但是，分区的大小和起始不必相同。只有 MachineConfig CR 中的 spec.config.storage.disks.partitions.label: varlibcontainers 标签必须在 seed 和目标集群上匹配。有关如何创建磁盘分区的更多信息，请参阅"在使用 GitOps ZTP 时在 ostree stateroots 之间配置共享容器分区或"在使用 GitOps ZTP 时配置共享容器分区"。

有关 seed 镜像中包含的内容的更多信息，请参阅 "Seed image configuration" 和 "Seed image configuration using the RAN DU profile"。

其他资源

15.1.2.4. OADP 备份和恢复指南

使用 OADP Operator，您可以使用 ConfigMap 对象中的 Backup 和 Restore CR 来备份和恢复目标集群上的应用程序。应用程序必须在当前和目标 OpenShift Container Platform 版本中工作，以便在升级后恢复它们。备份必须包含初始创建的资源。

备份中必须排除以下资源：

  • pods
  • 端点
  • controllerrevision
  • podmetrics
  • packagemanifest
  • replicaset
  • localvolume, 如果使用 Local Storage Operator (LSO)

单节点 OpenShift 有两个本地存储实现：

Local Storage Operator (LSO)
Lifecycle Agent 会自动备份和恢复所需的工件，包括 localvolume 资源及其关联的 StorageClass 资源。您必须在应用程序 Backup CR 中排除 persistentvolumes 资源。
LVM 存储
您必须为 LVM Storage 工件创建 Backup 和 Restore CR。您必须在应用程序 Backup CR 中包含 persistentVolumes 资源。

对于基于镜像的升级，给定目标集群只支持一个 Operator。

重要

对于这两个 Operator，您不能通过 ImageBasedUpgrade CR 将 Operator CR 应用为额外清单。

持久性卷内容会被保留并在 pivot 后使用。当您配置 DataProtectionApplication CR 时，您必须确保基于镜像的升级将 .spec.configuration.restic.enable 设置为 false。这禁用了容器存储接口集成。

15.1.2.4.1. lca.openshift.io/apply-wave guidelines

lca.openshift.io/apply-wave 注解决定 Backup 或 Restore CR 的应用顺序。注解的值必须是字符串号。如果您在 Backup 或 Restore CR 中定义 lca.openshift.io/apply-wave 注解，它们会根据注解值以递增顺序应用。如果没有定义注解，则会一起应用它们。

lca.openshift.io/apply-wave 注解必须在平台 Restore CR 中数字较低，如 RHACM 和 LVM Storage 工件，而不是应用程序工件。这样，在应用程序前会恢复平台工件。

如果应用程序包含集群范围的资源，则必须创建单独的 Backup 和 Restore CR，将备份范围限制为应用程序创建的特定集群范围资源。在剩余的应用程序 Restore CR 前，必须恢复集群范围的资源的 Restore CR。

15.1.2.4.2. lca.openshift.io/apply-label guidelines

您可以使用 lca.openshift.io/apply-label 注解来专门备份特定资源。根据您在注解中定义的资源，生命周期代理应用 lca.openshift.io/backup: <backup_name> 标签，并在创建 Backup CR 时将 labelSelector.matchLabels.lca.openshift.io/backup: <backup_name> 标签选择器应用到指定的资源。

要使用 lca.openshift.io/apply-label 注解来备份特定资源，注解中列出的资源也必须包含在 spec 部分。如果在 Backup CR 中使用 lca.openshift.io/apply-label 注解，则只备份注解中列出的资源，即使 spec 部分中指定了其他资源类型。

CR 示例

apiVersion: velero.io/v1
kind: Backup
metadata:
  name: acm-klusterlet
  namespace: openshift-adp
  annotations:
    lca.openshift.io/apply-label: rbac.authorization.k8s.io/v1/clusterroles/klusterlet,apps/v1/deployments/open-cluster-management-agent/klusterlet 1
  labels:
    velero.io/storage-location: default
spec:
  includedNamespaces:
   - open-cluster-management-agent
  includedClusterScopedResources:
   - clusterroles
  includedNamespaceScopedResources:
   - deployments

1
该值必须是以 group/version/resource/name 格式为集群范围的资源或 group/version/resource/namespace/name 格式的逗号分隔列表，且必须附加到相关的 Backup CR。

15.1.2.5. 额外清单指南

使用新的 stateroot 部署重启后，在恢复应用程序工件前，生命周期代理使用额外的清单来恢复您的目标集群。

不同的部署方法需要不同的方法来应用额外清单：

GitOps ZTP

您可以使用 lca.openshift.io/target-ocp-version: <target_ocp_version> 标签标记 Lifecycle Agent 必须提取并应用的额外清单。您可以使用 ImageBasedUpgrade CR 中的 lca.openshift.io/target-ocp-version 指定标记为 lca.openshift.io/target-ocp-version-manifest-count 注解的清单数量。如果指定，生命周期代理会验证从策略中提取的清单数量是否与 prep 和 upgrade 阶段注解中提供的数字匹配。

lca.openshift.io/target-ocp-version-manifest-count 注解示例

apiVersion: lca.openshift.io/v1
kind: ImageBasedUpgrade
metadata:
  annotations:
    lca.openshift.io/target-ocp-version-manifest-count: "5"
  name: upgrade

Non-Gitops
您可以使用 lca.openshift.io/apply-wave 注解标记额外的清单，以确定应用顺序。标记的额外清单嵌套在 ConfigMap 对象中，并在 Lifecycle Agent 在 pivot 后使用 ImageBasedUpgrade CR 中引用。

如果目标集群使用自定义目录源，您必须将它们作为指向正确发行版本的额外清单包含。

重要

您不能将以下项目作为额外清单应用：

  • MachineConfig 对象
  • OLM Operator 订阅

其他资源

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.