基于 Kubernetes 1.34 和 CRI-O 1.34 的红帽 OpenShift 4.21 现已全面发布。此版本与红帽 OpenShift 平台 Plus 一起，体现了我们对提供值得信赖、全面且一致的应用平台的一贯承诺，让企业能够在不影响安全性的情况下，跨混合云处理生产工作负载。
此版本强调在相同的基础架构上使用相同的运维模型运行 AI 训练作业、容器化微服务和虚拟化应用。借助 OpenShift 4.21，可在单个经济高效的平台上同时实现现有 IT 基础架构的现代化并加速 AI 创新，该平台可根据实时业务需求自动扩展。
想象一下，一家大型金融机构需要维护用于核心银行业务的传统虚拟机（VM），同时还要训练新的 AI 模型来检测欺诈行为。以前，这两个世界存在于不同的系统中，造成了“孤岛”和成本浪费。
但使用 OpenShift 4.21 后，该公司可以在同一基础架构上同时运行这两个平台。借助新的动态资源分配（DRA）operator，甚至可在白天优先将高端 GPU 用于 AI 训练，并在夜间自动转移这些资源或将其缩减为零，以节省资金。此外，可在数据中心之间移动活动虚拟机，实现零停机，确保银行服务在硬件维护期间也能保持在线状态。
无论将 OpenShift 部署为自助式平台，还是将其用作完全托管的云服务，都可获得一整套集成工具和服务，适用于云原生、AI、虚拟和传统工作负载。本博客介绍了 OpenShift 4.21 在 AI、核心平台功能和虚拟化方面的关键创新。如需完整详情，请参阅 OpenShift 4.21 发行说明。
AI
人工智能已成为现代工业的基石，推动着从个性化医疗到自主系统等各个领域的突破。然而，随着 AI 模型变得越来越复杂，底层基础架构也必须不断演进，以高效处理大量计算需求。在此版本的 OpenShift 中，我们继续在平台中添加 AI 功能，以大规模支持生产性 AI 工作负载。
利用红帽版 Kueue v1.2 简化 AI 工作负载
借助 OpenShift 4.21，红帽版 Kueue v1.2 提供了两项对大规模 AI 团队至关重要的功能：
- 支持KubeFlow Trainer v2在红帽 OpenShift AI 3.2 中:数据科学家现在只需使用单个 TrainJob API，无需为每个机器学习（ML）框架管理单独的资源。专注于模型代码，而平台团队则通过训练运行时来定义基础架构。
- 用于待处理工作负载的可见性 API：在此之前，批处理作业位于队列中，无法了解位置或等待时间。用户分不清自己是排在第一名还是第一百名。管理员无法发现资源瓶颈。现在，双方都清楚发生了什么。用户可以获得预计的开始时间。管理员可识别出哪些特定资源（如 GPU 类型）存在超额订阅。队列不再是一个黑匣子。
使用 JobSet 管理分布式工作负载
JobSet Operator 在此版本中正式发布。团队可以使用现有的 GitOps 工作流、基于角色的访问控制（RBAC）策略和监控工具来编排分布式工作负载。JobSet 为相互依赖的复杂作业提供灵活的调度和容错能力，使企业能够大规模运行要求苛刻的机器学习和分布式计算工作负载，同时保持运维一致性。
精准灵活地将工作负载与 GPU 硬件相匹配
随着 AI 工作负载在整个企业范围内扩展，传统上通过简单计算设备数量并期望其能满足需求的 GPU 分配方法很快就会失效。OpenShift 4.21 在 DRA 中引入了三项功能，从根本上改变了企业组织请求和使用 GPU 资源的方式。
使用 DRA 驱动程序进行基于属性的 GPU 分配
现在，不必请求 GPU，而是指定实际需要的内容（例如，“具有至少 40GB VRAM 的 GPU”）。调度程序直接使用通用表达式语言（CEL）查询硬件属性，无需手动标记节点，因此无需再在整个集群中维护 gpu-type=h100 标签。系统会读取硬件功能，并自动将其与工作负载要求进行匹配。若要使用此功能，需要使用供应商提供的 operator 或启用了 DRA 功能的驱动程序。
DRA 中受命名空间控制的管理员访问权限
标准 DRA 将 GPU 锁定到其分配的 pod，因此即使是监控工具和调试器也无法触及它们。管理员访问权限可为基础架构工作负载创建特权例外，而不会中断用户分配。这对于集群范围的监控和实时调试特别有用。
设备请求中优先选择的替代方案
直接在资源请求中定义回退策略。可指定一个有序列表，而不是“H100 or fail”：首先是 H100，然后是 A100，最后是 V100。调度程序按顺序尝试每个选项，直到找到可用容量。
核心
OpenShift 的核心基础架构通过不断发展以满足现代性能和成本要求，始终是混合云弹性的行业标准。在这个最新版本中，我们通过创新优化了资源效率，例如自动扩展托管控制平面以动态调整内存，或扩展到零以消除闲置基础架构成本。
此外，OpenShift 继续通过与 VMware Cloud Foundation 9 和甲骨文数据库机等平台的有效集成来扩展其生态系统，确保客户能够跨混合云部署 OpenShift。
在托管控制平面中正确调整大小
在 OpenShift 4.21 中，红帽 OpenShift 的托管控制平面现在包含原生 VerticalPodAutoscaler（VPA）集成。控制平面组件会根据实时内存消耗自动扩展，而不是静态估计或节点数。系统会监控实际使用情况并动态调整资源，无需人工干预，从容量规划转变为需求响应。该平台不会预测六个月后的需求，而是会观察现在发生的情况并做出响应。控制平面会根据当前工作负载精确调整大小。这意味着不会因置备不足而导致性能下降，也不会因置备过多而造成支出浪费。
在托管控制平面上自动伸缩至零
托管控制平面现在在不活动期间缩减到零。控制平面在保留配置和状态的同时休眠，然后在需要时自动恢复，从而消除了闲置基础架构的成本。节点池遵循相同的模式，在开发、测试和临时（ephemeral）环境中缩减至零个节点。这使得托管控制平面成为运行 OpenShift 最具成本效益的方式。此功能可确保托管控制平面在备用状态下保持正常运行，在快速可用性和积极的成本优化之间实现完美平衡。
在 VMware Cloud Foundation 9 上运行 OpenShift
从 OpenShift 4.18 开始，OpenShift 增加了对 VMware vSphere Foundation 9（VVF9）和 VMware Cloud Foundation 9（VCF9）的支持。这为基础架构网络提供了与 VMware NSX 的兼容性，为覆盖网络提供了与 OVN-Kubernetes 的兼容性。红帽 Kubernetes 高级集群管理 2.15.1+ 版本将机群管理功能扩展到这些平台，而红帽 OpenShift 数据基础 4.19.7 和 4.20 则以技术预览版形式提供，并计划于 2026 年初全面推出。从 vSphere 8 和 VCF 5 到 VCF9 的迁移指南将于 2026 年发布，确保客户能够在 OpenShift 的全面支持下实现 VMware 基础架构的现代化。
如需了解详情，请参阅对 VMware vSphere Foundation 9 和 VMware Cloud Foundation 9 上的红帽 OpenShift 的 GA 支持。
将 OpenShift 引入甲骨文数据库机
甲骨文数据库机 是一个预配置的集成硬件、存储、网络和软件捆绑包，专为运行 Oracle 数据库而设计。它通常被称为“盒中数据库”，因为它消除了从头开始构建自定义服务器堆栈的复杂性。现在可在甲骨文数据库机上部署 OpenShift，并享受运维简便性、安全性和合规性带来的诸多益处。
使用机密容器在微软 Azure 和微软 Azure 红帽 OpenShift 中部署零信任工作负载
在 OpenShift 4.21 中，我们在微软 Azure 中的客户管理集群上增加了对机密容器的支持，或通过微软 Azure 红帽 OpenShift将其作为托管服务提供支持。机密容器提供基于硬件的安全层，可在数据于内存中处理时对其进行保护。这有助于确保代码和数据与云提供商、主机操作系统甚至虚拟机监控程序隔离，这使其成为金融和医疗保健等高度监管行业的关键选择。
借助微软 Azure 中的机密容器，可有效地将云操作程序从可信计算库（TCB）中剔除。这意味着，即使攻击者获得了物理主机或微软 Azure 控制平面的 root 访问权限，也无法读取容器内存中的明文数据。
虚拟化
红帽 OpenShift 虚拟化在同一平台上运行虚拟机和容器，让一个团队能够在单个基础架构上使用一组工具。这一点很重要，因为大多数公司仍然依赖虚拟机来处理关键工作负载，一夜之间将所有内容迁移到容器中既不现实，也没有必要。借助 OpenShift 虚拟化，可使用 OpenShift 通过同一网络、存储和安全层管理容器化和虚拟化工作负载，从而按照自己的节奏实现现代化。
跨集群迁移虚拟机，实现零停机
通过 OpenShift 虚拟化实现跨集群实时迁移，管理员可以在不同的 OpenShift 集群之间移动运行中的虚拟机，且停机时间为零。管理员现在可以执行集群维护、跨区域重新平衡资源或将工作负载迁移到较新的硬件，而不会中断服务，同时根据严格的服务级别协议管理多集群环境。
仅 IPv6 控制平面和辅助网络支持
现已全面提供仅 IPv6 控制平面和辅助网络支持。对于 IPv4 地址不足的企业来说，这是向前迈出的重要一步。它允许在现代 IPv6 原生环境中部署 OpenShift 集群和虚拟化工作负载，无需复杂的网络地址转换（NAT）变通办法，从而简化网络架构。
通过在集群的核心管理层及其辅助接口上支持 IPv6，OpenShift 虚拟化可确保高密度部署能够无限扩展，同时满足严格的政府和电信合规要求。这种过渡不仅简化了网络路由并提高了端到端安全性，而且还为下一代全球连接服务提供了面向未来的基础架构。
Google Cloud 上的 OpenShift 虚拟化
Google Cloud 裸机上的 OpenShift 虚拟化允许企业直接在专用硬件上运行虚拟机，绕过传统嵌套虚拟化的开销。这种部署模式对于需要直接访问物理 CPU 功能和硬件加速的性能敏感型工作负载（如低延迟数据库或专用电信应用）至关重要。通过在裸机上运行，可获得云的灵活性，同时保持本地服务器的原始性能和可预测的延迟。这种集成简化了基于虚拟机的传统应用向 Google Cloud 的迁移，在单个 OpenShift 控制平面内实现容器和虚拟机的统一管理体验。
如需了解详情，请参阅将红帽 OpenShift 虚拟化引入 Google Cloud。
使用增强的虚拟化 UI 配置虚拟网络
OpenShift 虚拟化的增强型 UI 可引导管理员进行正确的网络配置，同时保留高级控制。管理员现在可以使用 localnet 拓扑创建辅助 ClusterUserDefinedNetworks，其内置防护措施可防止意外删除 UDN 派生的 NetworkAttachmentDefinitions。增强的主机网络流首先显示常见的配置路径，从而加快从意图到工作配置的设置。物理网络抽象将 NodeNetworkConfigurationPolicies 组织为逻辑单元，使团队能够一致地管理主机连接，同时保留所需的深度自定义。
使用红帽 OpenShift Lightspeed 对虚拟机进行故障排除
我们已将红帽 OpenShift Lightspeed 虚拟 AI 助手与 OpenShift 虚拟化用户界面集成，因此虚拟化管理员无需再切换界面或手动上传文件。相反，虚拟化管理员现在可以获得基于 AI 的上下文相关任务洞察，例如对虚拟机错误进行故障排除。
立即试用红帽 OpenShift 4.21
立即开始使用红帽混合云控制台，充分利用 OpenShift 中的最新功能和增强功能。如需了解后续动态，请查看以下资源：
如需红帽 OpenShift 4.21 更新的完整列表，请参见 OpenShift 4.21 发行说明。通过您的红帽联系人向我们发送反馈，或在 GitHub 上创建问题。
关于作者
Ju Lim works on the core Red Hat OpenShift Container Platform for hybrid and multi-cloud environments to enable customers to run Red Hat OpenShift anywhere. Ju leads the product management teams responsible for installation, updates, provider integration, and cloud infrastructure.
