第 7 章 更新 OpenShift Virtualization

了解 Operator Lifecycle Manager (OLM) 如何为 OpenShift Virtualization 提供 z-stream 和次要版本更新。

注意
  • OpenShift Virtualization 不再提供 Node Maintenance Operator (NMO)。您可以从 OpenShift Container Platform Web 控制台中的 OperatorHub 或 OpenShift CLI (oc) 安装 NMO。如需有关补救、隔离和维护节点的更多信息,请参阅 Red Hat OpenShift 文档中的工作负载可用性

    在从 OpenShift Virtualization 4.10.2 及更新版本升级到 OpenShift Virtualization 4.11 前,您必须执行以下任务之一:

    • 将所有节点从维护模式移出。
    • 安装独立 NMO,将 nodemaintenances.nodemaintenance.kubevirt.io 自定义资源 (CR) 替换为 nodemaintenances.nodemaintenance.medik8s.io CR。

7.1. 关于更新 OpenShift Virtualization

  • Operator Lifecycle Manager (OLM) 管理 OpenShift Virtualization Operator 的生命周期。Marketplace Operator 在 OpenShift Container Platform 安装过程中部署,使外部 Operator 可供集群使用。
  • OLM 为 OpenShift Virtualization 提供 z-stream 和次要版本更新。在将 OpenShift Container Platform 更新至下一个次版本时,次版本更新将变为可用。在不先更新 OpenShift Container Platform 的情况下,您无法将 OpenShift Virtualization 更新至下一个次版本。
  • OpenShift Virtualization 订阅使用一个名为 stable 的单一更新频道。stable 频道确保 OpenShift Virtualization 和 OpenShift Container Platform 版本兼容。
  • 如果您的订阅的批准策略被设置为 Automatic,则当 stable 频道中提供新版本的 Operator 时,更新过程就会马上启动。强烈建议您使用 Automatic(自动) 批准策略来维护可支持的环境。只有在运行对应的 OpenShift Container Platform 版本时,才会支持 OpenShift Virtualization 的每个次要版本。例如,您必须在 OpenShift Container Platform 4.12 上运行 OpenShift Virtualization 4.12。

    • 虽然可以选择 Manual(手工) 批准策略,但并不建议这样做,因为它存在集群的支持性和功能风险。使用 Manual 批准策略时,您必须手动批准每个待处理的更新。如果 OpenShift Container Platform 和 OpenShift Virtualization 更新不同步,您的集群将无法被支持。
  • 更新完成所需时间取决于您的网络连接情况。大部分自动更新可在十五分钟内完成。
  • 更新 OpenShift Virtualization 不会中断网络连接。
  • 数据卷及其关联的持久性卷声明会在更新过程中保留。
重要

如果您的虚拟机正在运行,使用 hostpath 置备程序存储,则无法实时迁移,并可能会阻止 OpenShift Container Platform 集群更新。

作为临时解决方案,您可以重新配置虚拟机以便在集群更新过程中自动关闭它们。删除 evictionStrategy: LiveMigrate 字段,并将 runStrategy 字段设置为 Always

7.1.1. 关于工作负载更新

更新 OpenShift Virtualization 时,虚拟机工作负载(包括 libvirtvirt-launcher )和 qemu (如果支持实时迁移)会自动更新。

注意

每个虚拟机均有一个 virt-launcher pod,用于运行虚拟机实例(VMI)。virt-launcher pod 运行一个 libvirt 实例,用于管理虚拟机(VM)进程。

您可以通过编辑 HyperConverged 自定义资源 (CR) 的 spec.workloadUpdateStrategy 小节来配置工作负载的更新方式。可用的工作负载更新方法有两种: LiveMigrateEvict

因为 Evict 方法关闭 VMI pod,所以只启用 LiveMigrate 更新策略。

LiveMigrate 是唯一启用的更新策略时:

  • 支持实时迁移的 VMI 会在更新过程中进行迁移。VM 客户机会进入启用了更新组件的新 pod。
  • 不支持实时迁移的 VMI 不会中断或更新。

    • 如果 VMI 有 LiveMigrate 驱除策略,但没有支持实时迁移。

如果您同时启用 LiveMigrateEvict

  • 支持实时迁移的 VMI 使用 LiveMigrate 更新策略。
  • 不支持实时迁移的 VMI 使用 Evict 更新策略。如果 VMI 由具有 alwaysrunStrategy 值的 VirtualMachine 对象控制,则会在带有更新组件的新 pod 中创建一个新的 VMI。
迁移尝试和超时

更新工作负载时,如果 pod 在以下时间段内处于 Pending 状态,实时迁移会失败:

5 分钟
如果 pod 因为是 Unschedulable 而处于 pending 状态。
15 分钟
如果 pod 因任何原因处于 pending 状态。

当 VMI 无法迁移时,virt-controller 会尝试再次迁移它。它会重复这个过程,直到所有可可迁移的 VMI 在新的 virt-launcher Pod 上运行。如果 VMI 没有被正确配置,这些尝试可能会无限期重复。

注意

每次尝试都会对应于一个迁移对象。只有最近五个尝试才在缓冲区中。这可防止迁移对象在系统上进行积累,同时保留用于调试的信息。

7.1.2. 关于 EUS 到 EUS 更新

每个 OpenShift Container Platform 的次版本号为偶数(包括 4.10 和 4.12)都是延长更新支持(EUS)版本。但是,由于 Kubernetes 设计了串行次版本更新,所以您无法直接从一个 EUS 版本更新到下一个版本。

从源 EUS 版本升级到下一个奇数次版本后,您必须按顺序将 OpenShift Virtualization 更新至更新路径中的所有次版本的 z-stream 版本。当您升级到最新的适用 z-stream 版本时,您可以将 OpenShift Container Platform 更新至目标 EUS 次版本。

当 OpenShift Container Platform 更新成功时,OpenShift Virtualization 的对应更新将变为可用。现在,您可以将 OpenShift Virtualization 更新至目标 EUS 版本。

7.1.2.1. 准备更新

在开始 EUS 到 EUS 更新前,您必须:

  • 在启动 EUS 到 EUS 更新前,暂停 worker 节点的机器配置池,以便 worker 不会重启两次。
  • 在开始更新过程前禁用自动工作负载更新。这是为了防止 OpenShift Virtualization 迁移或驱除虚拟机(VM),直到您升级到目标 EUS 版本。
注意

默认情况下,当您更新 OpenShift Virtualization Operator 时,OpenShift Virtualization 会自动更新工作负载,如 virt-launcher pod。您可以在 HyperConverged 自定义资源的 spec.workloadUpdateStrategy 小节中配置此行为。

了解有关准备执行 EUS 到 EUS 更新的更多信息。