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

第 5 章 安装

5.1. 为 OpenShift Virtualization 准备集群

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

重要

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

单节点 Openshift 的不同

您可以在单节点集群中安装 OpenShift Virtualization。如需更多信息，请参阅关于单节点 OpenShift。单节点 OpenShift 不支持高可用性，这会产生以下区别：

FIPS 模式

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

IPv6

您无法在单堆栈 IPv6 集群上运行 OpenShift Virtualization。(BZ#2193267)

5.1.1. 硬件和操作系统要求

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

支持的平台

重要

在 AWS 裸机实例或 IBM Cloud Bare Metal 服务器上安装 OpenShift Virtualization 只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议（SLA）支持，且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能，并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的更多信息，请参阅技术预览功能支持范围。

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

CPU 要求

  • Red Hat Enterprise Linux(RHEL)8 支持
  • 支持 Intel 64 或 AMD64 CPU 扩展
  • 启用 Intel VT 或 AMD-V 硬件虚拟化扩展
  • 启用 NX（无执行）标记

存储要求

  • OpenShift Container Platform 支持
警告

如果使用 Red Hat OpenShift Data Foundation 部署 OpenShift Virtualization，您必须为 Windows 虚拟机磁盘创建一个专用存储类。详情请参阅为 Windows 虚拟机优化 ODF PersistentVolume。

操作系统要求

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

    注意

    不支持 RHEL worker 节点。

  • 如果您的集群使用具有不同 CPU 的 worker 节点，则可能会出现实时迁移失败，因为不同的 CPU 具有不同的容量。为了避免这种故障，请为每个节点使用适当的容量，并在虚拟机上设置节点关联性以确保迁移成功。如需更多信息，请参阅配置所需的节点关联性规则。

其他资源

5.1.2. 物理资源开销要求

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

重要

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

5.1.2.1. 内存开销

使用以下因素计算 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) \
              + 216 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 额外的内存开销。

5.1.2.2. 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 数量的具体规则。

5.1.2.3. 存储开销

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

集群存储开销

Aggregated storage overhead per node ≈ 10 GiB

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

虚拟机存储开销

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

5.1.2.4. Example

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

5.1.3. 对象最大值

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

5.1.4. 受限网络环境

如果在没有互联网连接的受限环境中安装 OpenShift Virtualization，您必须为受限网络配置 Operator Lifecycle Manager。

如果您拥有有限的互联网连接，您可以在 Operator Lifecycle Manager 中配置代理支持 以访问红帽提供的 OperatorHub。

5.1.5. 实时迁移

实时迁移有以下要求：

  • 使用 ReadWriteMany (RWX)访问模式的共享存储.
  • 足够的 RAM 和网络带宽。
  • 如果虚拟机使用主机型号 CPU，则节点必须支持虚拟机的主机型号 CPU。
注意

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

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

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

5.1.6. 快照和克隆

有关快照和克隆要求，请参阅 OpenShift Virtualization 存储功能。

5.1.7. 集群高可用性选项

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

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

    注意

    在使用安装程序置备的基础架构安装并正确配置 MachineHealthCheck 的 OpenShift Container Platform 集群中，如果节点上的 MachineHealthCheck 失败且对集群不可用，则该节点可以被回收使用。在故障节点上运行的虚拟机之后会发生什么，这取决于一系列条件。如需了解更多有关潜在结果以及 RunStrategies 如何影响这些结果的信息，请参阅虚拟机的 RunStrategies。

  • 通过在 OpenShift Container Platform 集群上使用 Node Health Check Operator 来部署 NodeHealthCheck 控制器，可以使用 IPI 和非 IPI 自动高可用性。控制器标识不健康的节点，并使用 Self Node Remediation Operator 来修复不健康的节点。

    重要

    Node Health Check Operator 只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议（SLA）支持，且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能，并有机会在开发阶段提供反馈意见。

    有关红帽技术预览功能支持范围的更多信息，请参阅技术预览功能支持范围。

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

    注意

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

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.