了解单节点 OpenShift 集群的基于镜像的升级 - 单节点 OpenShift 集群的基于镜像的升级 | 边缘计算 | OpenShift Container Platform 4.17

基于映像的升级阶段
基于映像的升级指南

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

此升级方法利用从专用种子集群生成的 OCI 镜像，该镜像作为新的ostree 状态根安装在目标单节点 OpenShift 集群上。种子集群是使用目标 OpenShift Container Platform 版本、第 2 天运营商和所有目标集群通用的配置部署的单节点 OpenShift 集群。

您可以使用从种子集群生成的种子镜像来升级任何具有与种子集群相同的硬件组合、第 2 天运营商和集群配置的单节点 OpenShift 集群上的平台版本。

基于映像的升级使用特定于集群运行的硬件平台的自定义镜像。每个不同的硬件平台都需要一个单独的种子镜像。

生命周期代理在参与集群上使用两个自定义资源 (CR) 来协调升级

在种子集群上，SeedGenerator CR 允许生成种子镜像。此 CR 指定要将种子镜像推送到哪个存储库。
在目标集群上，ImageBasedUpgrade CR 指定用于升级目标集群的种子镜像以及工作负载的备份配置。

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	目标平台版本、要使用的种子镜像以及访问镜像所需的密钥。
3	可选：升级在第一次重新引导后未在该时间范围内完成时回滚的秒数时间范围。如果未定义或设置为`0`，则使用默认值`1800` 秒（30 分钟）。
4	可选：包含升级后要保留的自定义目录源以及要应用于目标集群但不属于种子镜像的额外清单的`ConfigMap` 资源列表。
5	包含 OADP `Backup` 和 `Restore` CR 的`ConfigMap` 资源列表。

基于映像的升级阶段

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

空闲
准备
升级
Rollback（可选）

图 1. 基于映像的升级阶段

空闲阶段

当操作员首次部署时，生命周期代理会创建一个设置为stage: Idle的ImageBasedUpgrade CR。这是默认阶段。没有正在进行的升级，集群已准备好进入Prep阶段。

图 2. 从空闲阶段转换

您还可以转到Idle阶段以执行以下步骤之一

完成成功的升级
完成回滚
取消正在进行的升级，直到Upgrade阶段中的预枢轴阶段。

转到Idle阶段可确保生命周期代理清理资源，以便集群再次准备好进行升级。

图 3. 转到空闲阶段

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

准备阶段

您可以在计划的维护窗口之前完成此阶段。

对于Prep阶段，您需要在ImageBasedUpgrade CR 中指定以下升级详细信息

要使用的种子镜像
要备份的资源
要应用的额外清单和升级后要保留的自定义目录源（如有）。

然后，根据您的指定，生命周期代理准备升级，而不会影响当前运行的版本。在此阶段，生命周期代理通过检查目标集群是否满足某些条件来确保它已准备好进入升级阶段。操作员将种子镜像以及种子镜像中指定的其他容器镜像拉取到目标集群。生命周期代理检查容器存储磁盘上是否有足够的可用空间，如有必要，操作员将删除未固定的镜像，直到磁盘使用率低于指定阈值。有关如何配置或禁用容器存储磁盘清理的更多信息，请参见“配置容器存储磁盘的自动镜像清理”。

您还可以使用 OADP 运算符的备份和恢复 CR 来准备备份资源。这些 CR 用于升级阶段重新配置集群、将集群注册到 RHACM 以及恢复应用程序工件。

除了 OADP 运算符之外，生命周期代理还使用ostree版本控制系统创建备份，这允许在升级和回滚后完全重新配置集群。

准备阶段完成后，您可以通过进入空闲阶段取消升级过程，也可以通过在ImageBasedUpgrade CR 中进入升级阶段来启动升级。如果您取消升级，操作员将执行清理操作。

图 4. 从准备阶段转换

升级阶段

升级阶段包含两个阶段

预切换: 在切换到新的 statoroot 之前，生命周期代理会收集所需的集群特定工件并将其存储在新 statoroot 中。您在准备阶段指定的集群资源备份将创建在兼容的对象存储解决方案上。生命周期代理导出在ImageBasedUpgrade CR 的extraManifests字段中指定的 CR，或导出绑定到目标集群的 ZTP 策略中描述的 CR。预切换阶段完成后，生命周期代理将新的 statoroot 部署设置为默认引导条目并重新启动节点。
后切换: 从新的 statoroot 引导后，生命周期代理还会重新生成种子镜像的集群加密。这确保了使用相同种子镜像升级的每个单节点 OpenShift 集群都具有唯一且有效的加密对象。然后，操作员通过应用在预切换阶段收集的集群特定工件来重新配置集群。操作员应用所有保存的 CR 并恢复备份。

升级完成后，并且您对更改感到满意，您可以通过进入空闲阶段来完成升级。

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

图 5. 从升级阶段转换

如果您想取消升级，您可以在升级阶段的预切换阶段之前这样做。如果您在升级后遇到问题，您可以进入回滚阶段进行手动回滚。

回滚阶段

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

如果您在回滚后进入空闲阶段，生命周期代理将清理可用于排查升级失败的资源。

如果升级在指定的时间限制内未完成，生命周期代理将启动自动回滚。有关自动回滚的更多信息，请参见“使用生命周期代理进入回滚阶段”或“使用生命周期代理和 GitOps ZTP 进入回滚阶段”部分。

图 6. 从回滚阶段转换

其他资源

基于镜像的升级指南

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

您可以使用不同的部署方法来执行基于镜像的升级

GitOps ZTP: 您可以使用 GitOps 零接触配置 (ZTP) 来部署和配置您的集群。
非 GitOps: 您可以手动部署和配置您的集群。

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

其他资源

为断开连接的安装镜像镜像

组件的最低软件版本

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

表 1. 组件的最低软件版本
组件	软件版本	必需
生命周期代理	4.16	是
OADP 运算符	1.4.1	是
托管集群版本	4.14.13	是
中心集群版本	4.16	否
RHACM	2.10.2	否
GitOps ZTP 插件	4.16	仅适用于 GitOps ZTP 部署方法
Red Hat OpenShift GitOps	1.12	仅适用于 GitOps ZTP 部署方法
拓扑感知生命周期管理器 (TALM)	4.16	仅适用于 GitOps ZTP 部署方法
本地存储操作员 ^[1]	4.14	是
逻辑卷管理器 (LVM) 存储 ^[1]	4.14.2	是

持久性存储必须由 LVM 存储或本地存储操作员提供，不能同时提供两者。

中心集群指南

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

为避免在种子镜像中包含任何 RHACM 资源，您需要在生成种子镜像之前禁用所有可选 RHACM 附加组件。
在对目标单节点 OpenShift 集群执行基于镜像的升级之前，必须将您的中心集群升级到至少目标版本。

种子镜像指南

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

CPU 拓扑
- CPU 内核数
- 已调整的性能配置，例如保留的 CPU 数
目标集群的MachineConfig资源
IP 版本

此版本不支持双协议栈网络。
第二天的运营商集合，包括生命周期代理和 OADP 运算符
断开连接的注册表
FIPS 配置

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

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

有关种子镜像中包含内容的更多信息，请参见“种子镜像配置”和“使用 RAN DU 配置文件进行种子镜像配置”。

其他资源

OADP 备份和恢复指南

使用 OADP 运算符，您可以通过使用包含在ConfigMap对象中的Backup和Restore CR 来备份和恢复目标集群上的应用程序。应用程序必须在当前和目标 OpenShift Container Platform 版本上运行，以便在升级后可以恢复。备份必须包含最初创建的资源。

备份必须排除以下资源：

Pod
Endpoints
ControllerRevision
PodMetrics
PackageManifest
ReplicaSet
如果使用本地存储运算符 (LSO)，则排除localvolume。

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

本地存储运算符 (LSO): 生命周期代理会自动备份和恢复所需的工件，包括localvolume资源及其关联的StorageClass资源。您必须在应用程序Backup CR 中排除persistentvolumes资源。
LVM 存储: 您必须为 LVM 存储工件创建Backup和Restore CR。您必须在应用程序Backup CR 中包含persistentVolumes资源。

对于基于镜像的升级，在给定的目标集群上只支持一个运算符。

对于这两个运算符，您都不得通过ImageBasedUpgrade CR 将运算符 CR 作为额外的清单应用。

持久卷内容在枢轴点后保留并继续使用。配置DataProtectionApplication CR 时，必须确保对于基于镜像的升级，.spec.configuration.restic.enable设置为false。这将禁用容器存储接口集成。

lca.openshift.io/apply-wave 指南

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

在您的平台Restore CR（例如 RHACM 和 LVM 存储工件）中，lca.openshift.io/apply-wave批注的数值必须低于应用程序的数值。这样，平台工件会在您的应用程序之前恢复。

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

lca.openshift.io/apply-label 指南

您可以使用lca.openshift.io/apply-label批注专门备份特定资源。根据您在批注中定义的资源，生命周期代理会在创建Backup CR 时应用lca.openshift.io/backup: <backup_name>标签，并将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。

额外清单指南

生命周期代理使用额外清单在使用新的 stateroot 部署重新引导后以及在恢复应用程序工件之前恢复目标集群。

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

GitOps ZTP

您可以使用lca.openshift.io/target-ocp-version: <target_ocp_version>标签来标记生命周期代理必须在枢轴点后提取和应用的额外清单。您可以使用ImageBasedUpgrade CR 中的lca.openshift.io/target-ocp-version-manifest-count批注来指定标记有lca.openshift.io/target-ocp-version的清单数量。如果指定了该数量，则生命周期代理会在准备和升级阶段验证从策略中提取的清单数量是否与批注中提供数量匹配。

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

非 GitOps

您可以使用lca.openshift.io/apply-wave批注标记您的额外清单以确定应用顺序。标记的额外清单包含在ConfigMap对象中，并在生命周期代理在枢轴点后使用的ImageBasedUpgrade CR 中引用。

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

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

MachineConfig 对象
OLM 运算符订阅

其他资源