OpenShift 文档正在迁移，很快将仅在 docs.redhat.com（所有 Red Hat 产品文档的中心）提供。立即体验 新的文档体验。
  1. 文档
    2. history bug_report picture_as_pdf
×

更新 OpenShift 虚拟化

编辑

RHEL 9 上的 OpenShift 虚拟化

OpenShift 虚拟化 4.17 基于 Red Hat Enterprise Linux (RHEL) 9。您可以按照标准的 OpenShift 虚拟化更新过程，从基于 RHEL 8 的版本更新到 OpenShift 虚拟化 4.17。无需其他步骤。

与以前的版本一样，您可以执行更新而不会中断正在运行的工作负载。OpenShift 虚拟化 4.17 支持从 RHEL 8 节点到 RHEL 9 节点的实时迁移。

编辑

RHEL 9 虚拟机类型

所有包含在 OpenShift Virtualization 中的虚拟机模板现在默认使用 RHEL 9 虚拟机类型：machineType: pc-q35-rhel9.<y>.0，其中<y> 是对应于 RHEL 9 最新次要版本的单个数字。例如，pc-q35-rhel9.2.0 用于 RHEL 9.2。

更新 OpenShift Virtualization 不会更改任何现有虚拟机的machineType值。这些虚拟机将继续像更新前一样工作。您可以选择更改虚拟机的机器类型，以便它可以从 RHEL 9 的改进中受益。

在更改虚拟机的machineType值之前，必须先关闭虚拟机。
编辑

关于更新 OpenShift Virtualization

  • Operator Lifecycle Manager (OLM) 管理 OpenShift Virtualization Operator 的生命周期。在安装 Red Hat OpenShift Service on AWS 期间部署的 Marketplace Operator 使外部 Operator 可用于您的集群。

  • OLM 为 OpenShift Virtualization 提供 z 流和次要版本更新。当您将 Red Hat OpenShift Service on AWS 更新到下一个次要版本时，次要版本更新就会可用。在先更新 Red Hat OpenShift Service on AWS 之前，您无法将 OpenShift Virtualization 更新到下一个次要版本。

  • OpenShift Virtualization 订阅使用名为 **stable** 的单个更新通道。**stable** 通道确保您的 OpenShift Virtualization 和 Red Hat OpenShift Service on AWS 版本兼容。

  • 如果您的订阅审批策略设置为 **自动**，则一旦 **stable** 通道中出现新版本的 Operator，更新过程就会开始。强烈建议使用 **自动** 批准策略来维护可支持的环境。只有在运行相应的 Red Hat OpenShift Service on AWS 版本时，才支持 OpenShift Virtualization 的每个次要版本。例如，您必须在 Red Hat OpenShift Service on AWS 4.17 上运行 OpenShift Virtualization 4.17。

    • 虽然可以选择 **手动** 批准策略，但不建议这样做，因为它会危及集群的可支持性和功能。使用 **手动** 批准策略，您必须手动批准每个待处理的更新。如果 Red Hat OpenShift Service on AWS 和 OpenShift Virtualization 更新不同步，您的集群将不受支持。

  • 更新完成所需的时间取决于您的网络连接。大多数自动更新在十五分钟内完成。

  • 更新 OpenShift Virtualization 不会中断网络连接。

  • 数据卷及其关联的持久卷声明在更新期间会保留。

如果您正在运行使用 AWS Elastic Block Store (EBS) 存储的虚拟机，则无法对其进行实时迁移，并且可能会阻止 Red Hat OpenShift Service on AWS 集群更新。

作为解决方法，您可以重新配置虚拟机，以便它们可以在集群更新期间自动关闭。将evictionStrategy字段设置为None，并将runStrategy字段设置为Always。
编辑

关于工作负载更新

更新 OpenShift Virtualization 时，如果虚拟机工作负载（包括libvirt、virt-launcher和qemu）支持实时迁移，则会自动更新。

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

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

由于Evict方法会关闭 VMI pod，因此默认情况下仅启用LiveMigrate更新策略。

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

  • 支持实时迁移的 VMI 在更新过程中会被迁移。虚拟机客户机将移动到启用更新组件的新 pod 中。

  • 不支持实时迁移的 VMI 不会中断或更新。

    • 如果 VMI 具有LiveMigrate逐出策略但不支持实时迁移，则不会更新。

如果同时启用LiveMigrate和Evict

  • 支持实时迁移的 VMI 使用LiveMigrate更新策略。

  • 不支持实时迁移的 VMI 使用Evict更新策略。如果 VMI 受具有runStrategy: Always设置的VirtualMachine对象的控制，则会在具有更新组件的新 pod 中创建新的 VMI。

迁移尝试和超时

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

5 分钟

如果 pod 处于Unschedulable状态。

15 分钟

如果 pod 因任何原因而卡在挂起状态。

当 VMI 迁移失败时，virt-controller会尝试再次迁移它。它会重复此过程，直到所有可迁移 VMI 都在新的virt-launcher pod 上运行。但是，如果 VMI 配置不正确，这些尝试可能会无限期地重复。

每次尝试都对应一个迁移对象。缓冲区中仅保存最近五次尝试。这可以防止迁移对象在系统上累积，同时保留用于调试的信息。
编辑

配置工作负载更新方法

您可以通过编辑HyperConverged自定义资源 (CR) 来配置工作负载更新方法。

先决条件

  • 要将实时迁移用作更新方法，必须首先在集群中启用实时迁移。

    如果VirtualMachineInstance CR 包含evictionStrategy: LiveMigrate，并且虚拟机实例 (VMI) 不支持实时迁移，则 VMI 将不会更新。
步骤

  1. 要在默认编辑器中打开HyperConverged CR，请运行以下命令：

    $ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv

  2. 编辑HyperConverged CR 的workloadUpdateStrategy节。例如：

    apiVersion: hco.kubevirt.io/v1beta1
kind: HyperConverged
metadata:
  name: kubevirt-hyperconverged
spec:
  workloadUpdateStrategy:
    workloadUpdateMethods: (1)
    - LiveMigrate (2)
    - Evict (3)
    batchEvictionSize: 10 (4)
    batchEvictionInterval: "1m0s" (5)
# ...
    1 可用于执行自动工作负载更新的方法。可用值为LiveMigrate和Evict。如果按此示例启用这两个选项，则更新将对支持实时迁移的 VMI 使用LiveMigrate，对任何不支持实时迁移的 VMI 使用Evict。要禁用自动工作负载更新，您可以删除workloadUpdateStrategy节，或将workloadUpdateMethods: []设置为使数组为空。
    2 破坏性最小的更新方法。支持实时迁移的 VMI 通过将虚拟机 (VM) 客户机迁移到启用更新组件的新 pod 来更新。如果LiveMigrate是唯一列出的工作负载更新方法，则不支持实时迁移的 VMI 不会中断或更新。
    3 一种在升级期间关闭 VMI pod 的破坏性方法。如果在集群中未启用实时迁移，则Evict是唯一可用的更新方法。如果 VMI 受具有runStrategy: Always配置的VirtualMachine对象的控制，则会在具有更新组件的新 pod 中创建新的 VMI。
    4 可以使用Evict方法一次强制更新的 VMI 数量。这不适用于LiveMigrate方法。
    5 驱逐下一批工作负载之前的等待间隔。这并不适用于LiveMigrate方法。

    您可以通过编辑HyperConverged CR 的spec.liveMigrationConfig 部分来配置实时迁移限制和超时。

  3. 要应用更改，请保存并退出编辑器。

编辑

批准待处理的 Operator 更新

编辑

手动批准待处理的 Operator 更新

如果已安装的 Operator 的订阅中将批准策略设置为**手动**，则在其当前更新通道中发布新的更新时，必须先手动批准更新才能开始安装。

先决条件

  • 以前使用 Operator Lifecycle Manager (OLM) 安装的 Operator。

步骤

  1. 在 AWS Web 控制台的 Red Hat OpenShift Service 的**管理员**视角中，导航到**Operators → 已安装的 Operators**。

  2. 具有待处理更新的 Operator 会显示状态为**可升级**。单击要更新的 Operator 的名称。

  3. 单击**订阅**选项卡。任何需要批准的更新都显示在**升级状态**旁边。例如，它可能显示**1 个需要批准**。

  4. 单击**1 个需要批准**，然后单击**预览安装计划**。

  5. 查看列为可更新的资源。满意后，单击**批准**。

  6. 返回到**Operators → 已安装的 Operators**页面以监控更新进度。完成后，状态将更改为**成功**和**最新**。

监控更新状态

编辑

监控 OpenShift Virtualization 升级状态

要监控 OpenShift Virtualization Operator 升级的状态，请观察集群服务版本 (CSV) 的PHASE。您也可以在 Web 控制台中或通过运行此处提供的命令来监控 CSV 条件。

PHASE 和条件值是基于可用信息的近似值。
先决条件

  • 以具有cluster-admin 角色的用户身份登录集群。

  • 安装 OpenShift CLI (oc)。

步骤

  1. 运行以下命令

    $ oc get csv -n openshift-cnv

  2. 查看输出，检查PHASE字段。例如

    示例输出
    VERSION  REPLACES                                        PHASE
4.9.0    kubevirt-hyperconverged-operator.v4.8.2         Installing
4.9.0    kubevirt-hyperconverged-operator.v4.9.0         Replacing

  3. 可选：通过运行以下命令监控所有 OpenShift Virtualization 组件条件的聚合状态

    $ oc get hyperconverged kubevirt-hyperconverged -n openshift-cnv \
  -o=jsonpath='{range .status.conditions[*]}{.type}{"\t"}{.status}{"\t"}{.message}{"\n"}{end}'

    成功升级将产生以下输出

    示例输出
    ReconcileComplete  True  Reconcile completed successfully
Available          True  Reconcile completed successfully
Progressing        False Reconcile completed successfully
Degraded           False Reconcile completed successfully
Upgradeable        True  Reconcile completed successfully
编辑

查看过时的 OpenShift Virtualization 工作负载

您可以使用 CLI 查看过时工作负载的列表。

如果您的集群中存在过时的虚拟化 Pod，则会触发OutdatedVirtualMachineInstanceWorkloads 警报。
步骤

  • 要查看过时的虚拟机实例 (VMI) 列表，请运行以下命令

    $ oc get vmi -l kubevirt.io/outdatedLauncherImage --all-namespaces

配置工作负载更新以确保 VMI 自动更新。

其他资源