搜索
支持控制台（Console）开发人员开始试用联系人

第 5 章 更新

download PDF

5.1. 更新 OpenShift Virtualization

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

5.1.1. RHEL 9 上的 OpenShift Virtualization

OpenShift Virtualization 4.16 基于 Red Hat Enterprise Linux (RHEL) 9。您可以根据标准 OpenShift Virtualization 更新过程，从基于 RHEL 8 的版本升级到 OpenShift Virtualization 4.16。不需要额外的步骤。

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

5.1.1.1. 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 值前，您必须关闭虚拟机。

5.1.2. 关于更新 OpenShift Virtualization

  • Operator Lifecycle Manager (OLM) 管理 OpenShift Virtualization Operator 的生命周期。Marketplace Operator 在 OpenShift Dedicated 安装过程中部署，使外部 Operator 可供集群使用。
  • OLM 为 OpenShift Virtualization 提供 z-stream 和次要版本更新。当您将 OpenShift Dedicated 更新至下一个次版本时，次版本更新将可用。在不首先更新 OpenShift Dedicated 的情况下，您无法将 OpenShift Virtualization 更新至下一个次版本。
  • OpenShift Virtualization 订阅使用一个名为 stable 的单一更新频道。stable 频道确保 OpenShift Virtualization 和 OpenShift Dedicated 版本兼容。

  • 如果您的订阅的批准策略被设置为 Automatic，则当 stable 频道中提供新版本的 Operator 时，更新过程就会马上启动。强烈建议您使用 Automatic（自动） 批准策略来维护可支持的环境。只有在运行对应的 OpenShift Dedicated 版本时，才会支持 OpenShift Virtualization 的每个次要版本。例如，您必须在 OpenShift Dedicated 4.16 上运行 OpenShift Virtualization 4.16。

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

如果您正在运行使用 AWS Elastic Block Store (EBS)存储的虚拟机，则它们无法实时迁移，并可能会阻止 OpenShift Dedicated 集群更新。

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

5.1.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 驱除策略，但没有支持实时迁移。

如果您同时启用 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 没有被正确配置，这些尝试可能会无限期重复。

注意

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

5.1.3. 配置工作负载更新方法

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

5.1.4. 批准待处理的 Operator 更新

5.1.4.1. 手动批准待处理的 Operator 更新

如果已安装的 Operator 的订阅被设置为 Manual，则当其当前更新频道中发布新更新时，在开始安装前必须手动批准更新。

先决条件

  • 之前使用 Operator Lifecycle Manager（OLM）安装的 Operator。

流程

  1. 在 OpenShift Dedicated Web 控制台的 Administrator 视角中，进入到 Operators Installed Operators。
  2. 处于待定更新的 Operator 会显示 Upgrade available 状态。点您要更新的 Operator 的名称。
  3. 点 Subscription 标签页。任何需要批准的更新都会在 Upgrade status 旁边显示。例如：它可能会显示 1 requires approval。
  4. 点 1 requires approval，然后点 Preview Install Plan。
  5. 检查列出可用于更新的资源。在满意后，点 Approve。
  6. 返回到 Operators Installed Operators 页面，以监控更新的进度。完成后，状态会变为 Succeeded 和 Up to date。

5.1.5. 监控更新状态

5.1.5.1. 监控 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

5.1.5.2. 查看过时的 OpenShift Virtualization 工作负载

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

注意

如果集群中存在过时的虚拟化 pod，OutdatedVirtualMachineInstanceWorkloads 警报会触发。

流程

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

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

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

5.1.6. 其他资源

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

© 2024 Red Hat, Inc.