7.2. 关于更新 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.13 上运行 OpenShift Virtualization 4.13。
- 虽然可以选择 Manual（手工） 批准策略，但并不建议这样做，因为它存在集群的支持性和功能风险。使用 Manual 批准策略时，您必须手动批准每个待处理的更新。如果 OpenShift Container Platform 和 OpenShift Virtualization 更新不同步，您的集群将无法被支持。
- 更新完成所需时间取决于您的网络连接情况。大部分自动更新可在十五分钟内完成。
- 更新 OpenShift Virtualization 不会中断网络连接。
- 数据卷及其关联的持久性卷声明会在更新过程中保留。
如果您的虚拟机正在运行，使用 hostpath 置备程序存储，则无法实时迁移，并可能会阻止 OpenShift Container Platform 集群更新。
作为临时解决方案，您可以重新配置虚拟机以便在集群更新过程中自动关闭它们。删除 evictionStrategy: LiveMigrate 字段，并将 runStrategy 字段设置为 Always。
7.2.1. 关于工作负载更新
更新 OpenShift Virtualization 时，虚拟机工作负载（包括 libvirt、virt-launcher ）和 qemu （如果支持实时迁移）会自动更新。
每个虚拟机均有一个 virt-launcher pod，用于运行虚拟机实例(VMI)。virt-launcher pod 运行一个 libvirt 实例，用于管理虚拟机(VM)进程。
您可以通过编辑 HyperConverged 自定义资源 (CR) 的 spec.workloadUpdateStrategy 小节来配置工作负载的更新方式。可用的工作负载更新方法有两种： LiveMigrate 和 Evict。
因为 Evict 方法关闭 VMI pod，所以只启用 LiveMigrate 更新策略。
当 LiveMigrate 是唯一启用的更新策略时：
- 支持实时迁移的 VMI 会在更新过程中进行迁移。VM 客户机会进入启用了更新组件的新 pod。
不支持实时迁移的 VMI 不会中断或更新。
-
如果 VMI 有
LiveMigrate驱除策略，但没有支持实时迁移。
-
如果 VMI 有
如果您同时启用 LiveMigrate 和 Evict ：
-
支持实时迁移的 VMI 使用
LiveMigrate更新策略。 -
不支持实时迁移的 VMI 使用
Evict更新策略。如果 VMI 由具有always的runStrategy值的VirtualMachine对象控制，则会在带有更新组件的新 pod 中创建一个新的 VMI。
迁移尝试和超时
更新工作负载时，如果 pod 在以下时间段内处于 Pending 状态，实时迁移会失败：
- 5 分钟
-
如果 pod 因为是
Unschedulable而处于 pending 状态。 - 15 分钟
- 如果 pod 因任何原因处于 pending 状态。
当 VMI 无法迁移时，virt-controller 会尝试再次迁移它。它会重复这个过程，直到所有可可迁移的 VMI 在新的 virt-launcher Pod 上运行。如果 VMI 没有被正确配置，这些尝试可能会无限期重复。
每次尝试都会对应于一个迁移对象。只有最近五个尝试才在缓冲区中。这可防止迁移对象在系统上进行积累，同时保留用于调试的信息。
7.2.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.2.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 更新的更多信息。
