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

更新 OpenShift 虚拟化

RHEL 9 上的 OpenShift Virtualization

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

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

RHEL 9 机器类型

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

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

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

关于更新 OpenShift Virtualization

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

  • OLM 为 OpenShift Virtualization 提供 z 流和次要版本更新。当您将 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.17 上运行 OpenShift Virtualization 4.17。

    • 虽然可以选择 手动 (Manual) 审批策略，但不推荐这样做，因为它会危及集群的可支持性和功能。使用 手动 (Manual) 审批策略，您必须手动批准每个待处理的更新。如果 OpenShift Container Platform 和 OpenShift Virtualization 更新不同步，则您的集群将不受支持。

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

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

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

如果您正在运行使用 hostpath 预配程序存储的虚拟机，则无法对其进行实时迁移，并且可能会阻止 OpenShift Container Platform 集群更新。

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

关于工作负载更新

更新 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 会在更新过程中迁移。虚拟机客户机将移动到一个新的 pod 中，并启用更新后的组件。

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

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

如果同时启用LiveMigrate和Evict

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

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

迁移尝试和超时

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

5 分钟

如果 pod 处于Unschedulable状态而处于 pending 状态。

15 分钟

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

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

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

关于仅控制平面更新

OpenShift Container Platform 的每个偶数次要版本（包括 4.10 和 4.12）都是扩展更新支持 (EUS) 版本。但是，由于 Kubernetes 设计强制执行串行次要版本更新，因此您无法直接从一个 EUS 版本更新到下一个 EUS 版本。

从源 EUS 版本更新到下一个奇数次要版本后，您必须按顺序将 OpenShift Virtualization 更新到更新路径上的该次要版本的所有 z 流版本。当您升级到最新的适用 z 流版本后，您就可以将 OpenShift Container Platform 更新到目标 EUS 次要版本。

OpenShift Container Platform 更新成功后，OpenShift Virtualization 的相应更新将可用。您现在可以将 OpenShift Virtualization 更新到目标 EUS 版本。

准备更新

在开始仅控制平面更新之前，您必须

  • 在开始仅控制平面更新之前暂停工作节点的机器配置池，以防止工作节点被重新启动两次。

  • 在开始更新过程之前禁用自动工作负载更新。这是为了防止 OpenShift Virtualization 在您更新到目标 EUS 版本之前迁移或驱逐您的虚拟机 (VM)。

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

了解更多关于执行仅控制平面更新的信息。

在仅控制平面更新期间防止工作负载更新

当您从一个扩展更新支持 (EUS) 版本更新到下一个版本时，您必须手动禁用自动工作负载更新，以防止 OpenShift Virtualization 在更新过程中迁移或驱逐工作负载。

先决条件

  • 您正在运行 OpenShift Container Platform 的 EUS 版本，并希望更新到下一个 EUS 版本。您尚未更新到两者之间的奇数版本。

  • 您阅读了“准备执行仅控制平面更新”，并了解了与您的 OpenShift Container Platform 集群相关的警告和要求。

  • 按照 OpenShift Container Platform 文档的指示，您暂停了工作节点的机器配置池。

  • 建议您使用默认的自动 (Automatic) 审批策略。如果您使用手动 (Manual) 审批策略，则必须在 Web 控制台中批准所有待处理的更新。有关更多详细信息，请参阅“手动批准待处理的 Operator 更新”部分。

步骤

  1. 运行以下命令并记录workloadUpdateMethods配置

    $ oc get kv kubevirt-kubevirt-hyperconverged \
  -n openshift-cnv -o jsonpath='{.spec.workloadUpdateStrategy.workloadUpdateMethods}'

  2. 通过运行以下命令关闭所有工作负载更新方法

    $ oc patch hyperconverged kubevirt-hyperconverged -n openshift-cnv \
  --type json -p '[{"op":"replace","path":"/spec/workloadUpdateStrategy/workloadUpdateMethods", "value":[]}]'
    示例输出
    hyperconverged.hco.kubevirt.io/kubevirt-hyperconverged patched

  3. 确保HyperConverged Operator 处于Upgradeable状态，然后再继续。输入以下命令并监视输出

    $ oc get hyperconverged kubevirt-hyperconverged -n openshift-cnv -o json | jq ".status.conditions"
    示例输出 
    [
  {
    "lastTransitionTime": "2022-12-09T16:29:11Z",
    "message": "Reconcile completed successfully",
    "observedGeneration": 3,
    "reason": "ReconcileCompleted",
    "status": "True",
    "type": "ReconcileComplete"
  },
  {
    "lastTransitionTime": "2022-12-09T20:30:10Z",
    "message": "Reconcile completed successfully",
    "observedGeneration": 3,
    "reason": "ReconcileCompleted",
    "status": "True",
    "type": "Available"
  },
  {
    "lastTransitionTime": "2022-12-09T20:30:10Z",
    "message": "Reconcile completed successfully",
    "observedGeneration": 3,
    "reason": "ReconcileCompleted",
    "status": "False",
    "type": "Progressing"
  },
  {
    "lastTransitionTime": "2022-12-09T16:39:11Z",
    "message": "Reconcile completed successfully",
    "observedGeneration": 3,
    "reason": "ReconcileCompleted",
    "status": "False",
    "type": "Degraded"
  },
  {
    "lastTransitionTime": "2022-12-09T20:30:10Z",
    "message": "Reconcile completed successfully",
    "observedGeneration": 3,
    "reason": "ReconcileCompleted",
    "status": "True",
    "type": "Upgradeable" (1)
  }
]
    1 OpenShift Virtualization Operator 具有Upgradeable状态。

  4. 手动将您的集群从源 EUS 版本更新到 OpenShift Container Platform 的下一个次要版本

    $ oc adm upgrade
    验证

    • 运行以下命令检查当前版本

      $ oc get clusterversion

      更新 OpenShift Container Platform 到下一个版本是更新 OpenShift Virtualization 的前提条件。更多详情，请参考 OpenShift Container Platform 文档的“更新集群”部分。

  5. 更新 OpenShift Virtualization。

    • 使用默认的**自动**审批策略，更新 OpenShift Container Platform 后，OpenShift Virtualization 会自动更新到相应的版本。

    • 如果您使用**手动**审批策略，请使用 Web 控制台审批待处理的更新。

  6. 运行以下命令监控 OpenShift Virtualization 更新

    $ oc get csv -n openshift-cnv

  7. 将 OpenShift Virtualization 更新到非 EUS 次要版本可用的每个 z 流版本，并运行上一步中显示的命令监控每次更新。

  8. 运行以下命令确认 OpenShift Virtualization 已成功更新到非 EUS 版本的最新 z 流版本

    $ oc get hyperconverged kubevirt-hyperconverged -n openshift-cnv -o json | jq ".status.versions"
    示例输出
    [
  {
    "name": "operator",
    "version": "4.17.3"
  }
]

  9. 在执行下一次更新之前，请等待 HyperConverged 运算符的状态变为 Upgradeable。输入以下命令并监控输出

    $ oc get hyperconverged kubevirt-hyperconverged -n openshift-cnv -o json | jq ".status.conditions"

  10. 将 OpenShift Container Platform 更新到目标 EUS 版本。

  11. 检查集群版本，确认更新成功

    $ oc get clusterversion

  12. 将 OpenShift Virtualization 更新到目标 EUS 版本。

    • 使用默认的**自动**审批策略，更新 OpenShift Container Platform 后，OpenShift Virtualization 会自动更新到相应的版本。

    • 如果您使用**手动**审批策略，请使用 Web 控制台审批待处理的更新。

  13. 运行以下命令监控 OpenShift Virtualization 更新

    $ oc get csv -n openshift-cnv

    当 VERSION 字段与目标 EUS 版本匹配且 PHASE 字段显示 Succeeded 时，更新完成。

  14. 使用以下命令恢复您在步骤 1 中记录的 workloadUpdateMethods 配置

    $ oc patch hyperconverged kubevirt-hyperconverged -n openshift-cnv --type json -p \
  "[{\"op\":\"add\",\"path\":\"/spec/workloadUpdateStrategy/workloadUpdateMethods\", \"value\":{WorkloadUpdateMethodConfig}}]"
    示例输出
    hyperconverged.hco.kubevirt.io/kubevirt-hyperconverged patched
    验证

    • 运行以下命令检查虚拟机迁移的状态

      $ oc get vmim -A
后续步骤

  • 您现在可以取消暂停工作节点的机器配置池。

配置工作负载更新方法

您可以通过编辑 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. 要应用更改，请保存并退出编辑器。

审批待处理的运算符更新

手动审批待处理的运算符更新

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

先决条件

  • 以前使用运算符生命周期管理器 (OLM) 安装的运算符。

步骤

  1. 在 OpenShift Container Platform Web 控制台的**管理员**视角中，导航到**运算符 → 已安装的运算符**。

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

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

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

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

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

监控更新状态

监控 OpenShift Virtualization 升级状态

要监控 OpenShift Virtualization 运算符升级的状态，请观察集群服务版本 (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 自动更新。

其他资源