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

第 4 章 安装

4.1. 为 OpenShift Virtualization 准备集群

在安装 OpenShift Virtualization 前，参阅这个部分以确保集群满足要求。

重要
安装方法注意事项
您可以使用任何安装方法（包括用户置备的、安装程序置备或辅助安装程序）来部署 OpenShift Container Platform。但是，安装方法和集群拓扑可能会影响 OpenShift Virtualization 功能，如快照或实时迁移。
Red Hat OpenShift Data Foundation
如果使用 Red Hat OpenShift Data Foundation 部署 OpenShift Virtualization，您必须为 Windows 虚拟机磁盘创建一个专用存储类。详情请参阅为 Windows 虚拟机优化 ODF PersistentVolume。
IPv6
您无法在单堆栈 IPv6 集群上运行 OpenShift Virtualization。

FIPS 模式

如果使用 FIPS 模式安装集群，则 OpenShift Virtualization 不需要额外的设置。

4.1.1. 支持的平台

您可以在 OpenShift Virtualization 中使用以下平台：

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

4.1.1.1. AWS 裸机上的 OpenShift Virtualization

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

注意

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

在设置集群前，请查看以下支持的功能和限制概述：

安装

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

    如需更多信息，请参阅在 AWS 上安装 OpenShift Container Platform 文档。

访问虚拟机 (VM)
  • 使用 virtctl CLI 工具或 OpenShift Container Platform Web 控制台没有更改您如何访问虚拟机。

  • 您可以使用 NodePort 或 LoadBalancer 服务公开虚拟机。

    • 负载均衡器方法是首选的，因为 OpenShift Container Platform 会在 AWS 中自动创建负载均衡器并管理其生命周期。另外，还会为负载均衡器创建一个安全组，您可以使用注解来附加现有的安全组。删除服务时，OpenShift Container Platform 会移除负载均衡器及其关联的资源。
网络
  • 您不能使用单根 I/O 虚拟化 (SR-IOV) 或桥接 Container Network Interface (CNI) 网络，包括虚拟 LAN (VLAN)。如果您的应用程序需要扁平第 2 层网络或对 IP 池进行控制，请考虑使用 OVN-Kubernetes 二级覆盖网络。
Storage

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

    重要

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

  • 在 OpenShift Virtualization 中使用 Amazon Elastic File System (EFS) 或 Amazon Elastic Block Store (EBS) 可能会导致性能和功能限制。考虑使用支持 ReadWriteMany (RWX)、克隆和快照的 CSI 存储来启用实时迁移、快速虚拟机创建和虚拟机快照功能。
托管 control plane (HCP)
  • 目前 AWS 基础架构不支持 OpenShift Virtualization 的 HCP。

其他资源

4.1.2. 硬件和操作系统要求

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

4.1.2.1. CPU 要求

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

    参阅用于支持的 CPU 红帽生态系统目录。

    注意

    如果您的 worker 节点有不同的 CPU，则可能会出现实时迁移失败，因为不同的 CPU 具有不同的功能。您可以通过确保 worker 节点具有适当容量的 CPU，并为虚拟机配置节点关联性规则来缓解这个问题。

    详情请参阅配置所需的节点关联性规则。

  • 支持 AMD 和 Intel 64 位架构 (x86-64-v2)。
  • 支持 Intel 64 或 AMD64 CPU 扩展。
  • 启用 Intel VT 或 AMD-V 硬件虚拟化扩展。
  • 启用 NX （无执行）标记。

4.1.2.2. 操作系统要求

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

    详情请参阅 RHCOS。

    注意

    不支持 RHEL worker 节点。

4.1.2.3. 存储要求

  • OpenShift Container Platform 支持。请参阅优化存储。
  • 您必须创建一个默认的 OpenShift Virtualization 或 OpenShift Container Platform 存储类。这样做的目的是解决虚拟机工作负载的唯一存储需求，并提供优化的性能、可靠性和用户体验。如果 OpenShift Virtualization 和 OpenShift Container Platform 默认存储类都存在，则 OpenShift Virtualization 类在创建虚拟机磁盘时具有优先权。
注意

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

  • 如果存储置备程序支持快照，您必须将 VolumeSnapshotClass 对象与默认存储类关联。
4.1.2.3.1. 关于虚拟机磁盘的卷和访问模式

如果您将存储 API 与已知的存储供应商搭配使用，则会自动选择卷和访问模式。但是，如果您使用没有存储配置集的存储类，您必须配置卷和访问模式。

要获得最佳结果，请使用 ReadWriteMany (RWX)访问模式和 Block 卷模式。这一点非常重要：

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

  • 块 卷模式的性能优于 Filesystem 卷模式。这是因为 Filesystem 卷模式使用更多存储层，包括文件系统层和磁盘镜像文件。虚拟机磁盘存储不需要这些层。

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

重要

您不能使用以下配置实时迁移虚拟机：

  • 具有 ReadWriteOnce (RWO) 访问模式的存储卷
  • 透传功能，比如 GPU

对于这些虚拟机，将 evictionStrategy 字段设置为 None。None 策略会在节点重启过程中关闭虚拟机。

4.1.3. 实时迁移要求

  • 使用 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 网络进行实时迁移。专用网络可最小化迁移期间对租户工作负载网络饱和的影响。

4.1.4. 物理资源开销要求

OpenShift Virtualization 是 OpenShift Container Platform 的一个附加组件，它会带来额外的开销。除了 OpenShift Container Platform 要求外，每个集群机器都必须满足以下开销要求。覆盖集群中的物理资源可能会影响性能。

重要

本文档中给出的数字基于红帽的测试方法和设置。这些数字会根据您自己的设置和环境而有所不同。

内存开销

使用以下因素计算 OpenShift Virtualization 的内存开销值。

集群内存开销

Memory overhead per infrastructure node ≈ 150 MiB

Memory overhead per worker node ≈ 360 MiB

另外，OpenShift Virtualization 环境资源需要总计 2179 MiB 的内存，分布到所有基础架构节点。

虚拟机内存开销

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

除了虚拟机工作负载所需的 CPU 外，每个托管虚拟机的 worker 节点都必须有 2 个额外内核（2000 毫秒）用于 OpenShift Virtualization 管理工作负载。

虚拟机 CPU 开销

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

存储开销

使用以下指南来估算 OpenShift Virtualization 环境的存储开销要求。

集群存储开销

Aggregated storage overhead per node ≈ 10 GiB

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

虚拟机存储开销

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

Example

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

4.1.5. 单节点 Openshift 的不同

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

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

  • 高可用性
  • Pod 中断预算
  • 实时迁移
  • 配置了驱除策略的虚拟机或模板

其他资源

4.1.6. 对象最大值

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

4.1.7. 集群高可用性选项

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

  • 通过部署机器健康检查，可以使用安装程序置备的基础架构 (IPI)自动高可用性。

    注意

    在使用安装程序置备的基础架构安装的 OpenShift Container Platform 集群中，并使用正确配置的 MachineHealthCheck 资源，如果节点无法进行机器健康检查，且对集群不可用，则会回收它。在故障节点上运行的虚拟机之后会发生什么，这取决于一系列条件。如需有关潜在结果以及运行策略如何影响这些结果的详细信息，请参阅运行策略。

  • 通过在 OpenShift Container Platform 集群上使用 Node Health Check Operator 来部署 NodeHealthCheck 控制器，可以使用 IPI 和非 IPI 自动高可用性。控制器识别不健康的节点并使用补救供应商，如 Self Node Remediation Operator 或 Fence Agents Remediation Operator 来修复不健康的节点。如需有关补救、隔离和维护节点的更多信息，请参阅 Red Hat OpenShift 文档中的工作负载可用性。

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

    注意

    如果没有外部监控系统或合格的人类监控节点运行状况，虚拟机就失去高可用性。

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.