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

准备您的集群以用于 OpenShift Virtualization

在安装 OpenShift Virtualization 之前，请查看本节内容，以确保您的集群满足要求。

安装方法注意事项

您可以使用任何安装方法（包括用户预配、安装程序预配或辅助安装程序）来部署 OpenShift Container Platform。但是，安装方法和集群拓扑可能会影响 OpenShift Virtualization 的功能，例如快照或实时迁移。

Red Hat OpenShift Data Foundation

如果使用 Red Hat OpenShift Data Foundation 部署 OpenShift Virtualization，则必须为 Windows 虚拟机磁盘创建一个专用存储类。有关详细信息，请参阅针对 Windows VM 优化 ODF PersistentVolume。

IPv6

您不能在单栈 IPv6 集群上运行 OpenShift Virtualization。
FIPS 模式

如果您在FIPS 模式下安装集群，则 OpenShift Virtualization 无需额外设置。

支持的平台

您可以将以下平台与 OpenShift Virtualization 配合使用

不支持其他云提供商提供的裸机实例或服务器。

AWS 裸机上的 OpenShift Virtualization

您可以在 Amazon Web Services (AWS) 裸机 OpenShift Container Platform 集群上运行 OpenShift Virtualization。

OpenShift Virtualization 也支持 Red Hat OpenShift Service on AWS (ROSA) Classic 集群，其配置要求与 AWS 裸机集群相同。

在设置集群之前，请查看以下支持的功能和限制的摘要

安装

  • 您可以使用安装程序预配的基础架构安装集群，确保为工作节点指定裸机实例类型。例如，您可以对基于 x86_64 架构的机器使用c5n.metal类型值。您可以通过编辑install-config.yaml文件来指定裸机实例类型。

    有关更多信息，请参阅有关在 AWS 上安装 OpenShift Container Platform 的文档。

访问虚拟机 (VM)

  • 使用virtctl CLI 工具或 OpenShift Container Platform Web 控制台访问 VM 的方式没有任何变化。

  • 您可以使用NodePort或LoadBalancer服务公开 VM。

    • 负载均衡器方法更可取，因为 OpenShift Container Platform 会在 AWS 中自动创建负载均衡器并管理其生命周期。还会为负载均衡器创建一个安全组，您可以使用注释来附加现有的安全组。删除服务时，OpenShift Container Platform 会删除负载均衡器及其关联的资源。

网络

  • 您不能使用单根 I/O 虚拟化 (SR-IOV) 或桥接容器网络接口 (CNI) 网络，包括虚拟局域网 (VLAN)。如果您的应用程序需要平面 2 层网络或对 IP 池的控制，请考虑使用 OVN-Kubernetes 二次覆盖网络。

存储

  • 您可以使用任何存储供应商已认证可与底层平台一起使用的存储解决方案。

    AWS 裸机和 ROSA 集群可能具有不同的受支持存储解决方案。请确保您已与您的存储供应商确认支持。

  • 将 Amazon Elastic File System (EFS) 或 Amazon Elastic Block Store (EBS) 与 OpenShift Virtualization 一起使用可能会导致性能和功能限制，如下表所示

    表 1. EFS 和 EBS 性能和功能限制
    功能 EBS 卷 EFS 卷 共享存储解决方案

    gp2

    gp3

    io2

    VM 实时迁移

    不可用

    不可用

    可用

    可用

    可用

    使用克隆快速创建 VM

    可用

    不可用

    可用

    使用快照备份和还原 VM

    可用

    不可用

    可用

    考虑使用支持 ReadWriteMany (RWX)、克隆和快照的 CSI 存储，以启用实时迁移、快速 VM 创建和 VM 快照功能。

托管控制平面 (HCP)

  • 目前不支持在 AWS 基础架构上使用用于 OpenShift Virtualization 的 HCP。

其他资源

硬件和操作系统要求

查看 OpenShift Virtualization 的以下硬件和操作系统要求。

CPU 要求

  • 受 Red Hat Enterprise Linux (RHEL) 9 支持。

    请参阅Red Hat 生态系统目录了解受支持的 CPU。

    如果您的工作节点具有不同的 CPU，则实时迁移可能会失败，因为不同的 CPU 具有不同的功能。您可以通过确保您的工作节点具有具有足够容量的 CPU 并为您的虚拟机配置节点亲和性规则来缓解此问题。

    请参阅配置必需的节点亲和性规则了解详情。

  • 支持 AMD 和 Intel 64 位架构 (x86-64-v2)。

  • 支持 Intel 64 或 AMD64 CPU 扩展。

  • 启用了 Intel VT 或 AMD-V 硬件虚拟化扩展。

  • 启用了 NX（禁止执行）标志。

操作系统要求

  • 在工作节点上安装 Red Hat Enterprise Linux CoreOS (RHCOS)。

    请参阅关于 RHCOS了解详情。

    不支持 RHEL 工作节点。

存储要求

  • 受 OpenShift Container Platform 支持。请参阅优化存储。

  • 您必须创建一个默认的 OpenShift Virtualization 或 OpenShift Container Platform 存储类。这样做是为了解决 VM 工作负载的独特存储需求，并提供优化的性能、可靠性和用户体验。如果同时存在 OpenShift Virtualization 和 OpenShift Container Platform 默认存储类，则在创建 VM 磁盘时，OpenShift Virtualization 类优先。

要将存储类标记为虚拟化工作负载的默认存储类，请将注释storageclass.kubevirt.io/is-default-virt-class设置为"true"。

  • 如果存储供应程序支持快照，则必须将VolumeSnapshotClass对象与默认存储类关联。

关于虚拟机磁盘的卷和访问模式

如果您将存储 API 与已知的存储提供程序一起使用，则会自动选择卷和访问模式。但是，如果您使用的存储类没有存储配置文件，则必须配置卷和访问模式。

为了获得最佳结果，请使用ReadWriteMany (RWX) 访问模式和Block卷模式。这很重要，原因如下：

  • 实时迁移需要ReadWriteMany (RWX) 访问模式。

  • Block卷模式的性能明显优于Filesystem卷模式。这是因为Filesystem卷模式使用了更多存储层，包括文件系统层和磁盘映像文件。这些层对于 VM 磁盘存储不是必需的。

    例如，如果您使用 Red Hat OpenShift Data Foundation，则 Ceph RBD 卷优于 CephFS 卷。

您无法实时迁移具有以下配置的虚拟机：

  • 具有ReadWriteOnce (RWO) 访问模式的存储卷

  • 直通功能，例如 GPU

对于这些虚拟机，请将evictionStrategy字段设置为None。None策略会在节点重新启动期间关闭 VM。

实时迁移要求

  • 具有ReadWriteMany (RWX) 访问模式的共享存储。

  • 足够的 RAM 和网络带宽。

    您必须确保集群中有足够的内存请求容量来支持导致实时迁移的节点耗尽。您可以使用以下计算来确定大约需要的备用内存：

    Product of (Maximum number of nodes that can drain in parallel) and (Highest total VM memory request allocations across nodes)

    集群中默认可以并行运行的迁移数量为 5。

  • 如果虚拟机使用主机模型 CPU，则节点必须支持虚拟机的主机模型 CPU。

  • 强烈建议使用专用的 Multus 网络进行实时迁移。专用网络最大限度地减少了迁移期间网络饱和对租户工作负载的影响。

物理资源开销要求

OpenShift Virtualization 是 OpenShift Container Platform 的附加组件，它会增加额外的开销，您在规划集群时必须考虑这些开销。除了 OpenShift Container Platform 要求之外，每台集群机器还必须满足以下开销要求。过度使用集群中的物理资源会影响性能。

本文档中提到的数字基于 Red Hat 的测试方法和设置。这些数字可能会因您自己的个人设置和环境而异。

内存开销

使用以下等式计算 OpenShift Virtualization 的内存开销值。

集群内存开销
Memory overhead per infrastructure node ≈ 150 MiB
Memory overhead per worker node ≈ 360 MiB

此外，OpenShift Virtualization 环境资源需要总共 2179 MiB 的 RAM，这些 RAM 分布在所有基础架构节点上。

虚拟机内存开销
Memory overhead per virtual machine ≈ (1.002 × requested memory) \
              + 218 MiB \ (1)
              + 8 MiB × (number of vCPUs) \ (2)
              + 16 MiB × (number of graphics devices) \ (3)
              + (additional memory overhead) (4)
1 在virt-launcher pod 中运行的进程需要此内存。
2 虚拟机请求的虚拟 CPU 数量。
3 虚拟机请求的虚拟显卡数量。
4 其他内存开销

  • 如果您的环境包含单根 I/O 虚拟化 (SR-IOV) 网络设备或图形处理单元 (GPU)，则为每个设备分配 1 GiB 的额外内存开销。

  • 如果启用了安全加密虚拟化 (SEV)，则添加 256 MiB。

  • 如果启用了可信平台模块 (TPM)，则添加 53 MiB。

CPU 开销

使用下面的公式计算 OpenShift Virtualization 的集群处理器开销需求。每个虚拟机的 CPU 开销取决于您的具体设置。

集群 CPU 开销
CPU overhead for infrastructure nodes ≈ 4 cores

OpenShift Virtualization 会增加集群级服务的整体利用率，例如日志记录、路由和监控。为了应对此工作负载，请确保托管基础设施组件的节点分配了用于 4 个额外内核（4000 毫核）的容量，这些容量分布在这些节点上。

CPU overhead for worker nodes ≈ 2 cores + CPU overhead per virtual machine

每个托管虚拟机的 worker 节点必须额外拥有 2 个内核（2000 毫核）的容量用于 OpenShift Virtualization 管理工作负载，此外还需要虚拟机工作负载所需的 CPU。

虚拟机 CPU 开销

如果请求专用 CPU，则对集群 CPU 开销需求的影响为 1:1。否则，没有关于虚拟机需要多少 CPU 的具体规则。

存储开销

使用以下指导原则来估算 OpenShift Virtualization 环境的存储开销需求。

集群存储开销
Aggregated storage overhead per node ≈ 10 GiB

安装 OpenShift Virtualization 时，集群中每个节点的磁盘存储影响估计为 10 GiB。

虚拟机存储开销

每个虚拟机的存储开销取决于虚拟机内部资源分配的具体请求。请求可以是节点上的临时存储，也可以是集群其他位置托管的存储资源。OpenShift Virtualization 目前不会为正在运行的容器本身分配任何额外的临时存储。

示例

作为集群管理员，如果您计划在集群中托管 10 个虚拟机，每个虚拟机具有 1 GiB 的 RAM 和 2 个 vCPU，则整个集群的内存影响为 11.68 GiB。集群中每个节点的磁盘存储影响估计为 10 GiB，托管虚拟机工作负载的 worker 节点的 CPU 影响至少为 2 个内核。

单节点 OpenShift 的差异

您可以在单节点 OpenShift 上安装 OpenShift Virtualization。

但是，您应该注意，单节点 OpenShift 不支持以下功能

  • 高可用性

  • Pod 中断

  • 实时迁移

  • 配置了驱逐策略的虚拟机或模板

其他资源

对象最大值

规划集群时，必须考虑以下经过测试的对象最大值

集群高可用性选项

您可以为您的集群配置以下高可用性 (HA) 选项之一

  • 通过部署 安装程序预配的基础设施 (IPI) 的自动高可用性可通过部署 机器健康检查 来实现。

    在使用安装程序预配的基础设施安装的 OpenShift Container Platform 集群中，并且具有正确配置的 MachineHealthCheck 资源的情况下，如果节点未能通过机器健康检查并且对集群不可用，则会对其进行回收。接下来发生在故障节点上运行的虚拟机上的情况取决于一系列条件。有关潜在结果以及运行策略如何影响这些结果的更多详细信息，请参阅 运行策略。

  • 通过在 OpenShift Container Platform 集群上使用 **节点健康检查操作符** 部署 NodeHealthCheck 控制器，可以实现 IPI 和非 IPI 的自动高可用性。控制器识别不健康的节点，并使用修复提供程序（例如自节点修复操作符或 Fence Agents 修复操作符）来修复不健康的节点。有关修复、隔离和维护节点的更多信息，请参阅 Red Hat OpenShift 的工作负载可用性 文档。

  • 任何平台的高可用性都可以通过使用监控系统或合格人员来监控节点可用性来实现。当节点丢失时，将其关闭并运行 oc delete node <lost_node>。

    如果没有外部监控系统或合格人员监控节点健康状况，虚拟机将失去高可用性。