红帽 OpenShift 4.20 加速虚拟化和企业 AI 创新

红帽 OpenShift 4.20 现已全面上市。该版本基于 Kubernetes 1.33 和 CRI-O 1.33，并与红帽 OpenShift 平台 Plus 一起构建，这体现了我们的承诺：提供一个备受信赖，全面且一致的应用平台。在 OpenShift 上，AI 工作负载、容器和虚拟化可以无缝共存，使企业能够在不影响安全性的情况下跨混合云更快地进行创新。

OpenShift 提供自助式或完全托管式云服务版本，提供了一个应用平台，其中包含一整套集成工具和服务，适用于云原生、AI、虚拟和传统工作负载等。本文重点介绍 OpenShift 4.20 的最新创新和关键增强功能。有关更新和改进的完整列表，请参阅 OpenShift 4.20 发行说明。

最新版本增强了平台处理 AI 工作负载的能力，并全面推出了 LeaderWorkerSet、Gateway API 推理扩展和运行时开放容器计划（OCI）镜像卷源。还增强了核心功能，引入了重大改进，如自带外部身份提供商、零信任工作负载身份管理器、用户命名空间、红帽 OpenShift 外部机密 Operator、边界网关协议（BGP）的支持。此外，OpenShift 4.20 还带来了虚拟化方面的关键进步，如 CPU 负载感知再平衡和更快的实时迁移，为满足不同的计算需求提供了一个更强大、更通用的平台。

OpenShift 4.20 现在通过 Go 1.24 版本 启用了 X25519MLKEM768 混合密钥交换机制，这是我们增加对后量子加密（PQC）支持进程中的一部分。这增强了核心 Kubernetes 控制平面组件（如 API 服务器、kubelet、调度程序和控制器管理器）之间的 TLS 通信，帮助保护它们免受基于量子的攻击。

红帽最新发布的 Trusted Artifact Signer 1.3 和 Trusted Profile Analyzer 2.2 提供了加密签名功能和高级供应链分析的强大组合。

使用 LeaderWorkerSet 和 JobSet 分发和扩展 AI/ML 工作负载

OpenShift 4.20 简化了复杂的分布式 AI 工作负载的部署。借助普遍可用的 LeaderWorkerSet，平台团队可以使用领导者 pod 无缝编排工作节点之间的通信，从而高效地分发和扩展超出单个 pod 容量的 AI 模型。结合以技术预览形式提供的 JobSet（通过灵活的调度和容错功能对分布式作业进行分组和管理），团队可以利用熟悉的 GitOps、基于角色的访问权限控制（RBAC）和监控模式，即使是要求最苛刻的机器学习工作流。它们共同支持大规模训练（JobSet）和推理（LeaderWorkerSet）工作负载的端到端编排，在 OpenShift 中提供可靠、可扩展且高效的 AI/ML 生命周期管理。

红帽 OpenShift AI 3 的原生 AI 路由

AI 和机器学习工作负载面临着独特的挑战，使得轮询等传统负载平衡策略不再适用。 红帽 OpenShift AI 3 通过 llm-d 的分布式推理，并利用 Kubernetes Gateway API 推理扩展 (GIE) 来应对这些挑战。OpenShift 4.20 包含基于 Kubernetes 网关 API 构建的 GIE，可为 AI/ML 工作负载提供专门的路由和流量管理。如果您已在应用中使用 Kubernetes Gateway API，现在可以将相同的声明式方法应用于 AI 模型服务。

创建推理池资源时，GIE 在 OpenShift 4.20 中自动可用。推理池资源代表一组 AI 或机器学习推理容器集，以及一个包含专用路由逻辑的“端点选择器”。llm-d 推理调度程序是红帽 OpenShift AI 3 的一部分，可充当端点选取器，通过使用模型服务器协议捕获 vLLM 公开的遥测数据，从而实现基于任何给定时间最佳可用模型实例的智能路由决策。

GIE 是通过 OpenShift 服务网格 3.2 使用由 Envoy 代理支持的 Istio 网关实施来实施的。目前，只有红帽 OpenShift AI 3 支持此功能。借助 GIE，可以通过相同的 GitOps 管道和 RBAC 策略来管理 AI 工作负载。无论您是为单个模型提供服务，还是编排复杂的多模型推理管道，GIE 都能将曾经专用的 AI 基础架构转变为集群中的另一条路由。

在不影响 pod 的情况下更新 AI 模型

LLM 和 ML 模型通常超过 10GB，导致容器重建速度缓慢且需要占用大量存储资源。您不再需要在每次更新 AI 模型时都重新构建容器。在 OpenShift 4.20 中，您可以直接从容器镜像仓库将模型权重挂载为卷，这样数据科学家就可以将新的模型版本推送到镜像仓库，同时模型服务容器保持不变。只需在 pod 规范中引用 OCI 镜像，OpenShift 就会处理其余的工作。现在，模型成为独立于代码的受版本控制的工件，使用熟悉的注册表身份验证按需拉取，在本地缓存以提高性能，并且在不影响部署的情况下进行更新。

使用自然语言与 OpenShift 或 Kubernetes 集群对话

我们很高兴地宣布，适用于 OpenShift 和 Kubernetes 的 Kubernetes 模型上下文协议（MCP）服务器已推出开发人员预览版。Kubernetes MCP 服务器通过将 VS Code、微软 Copilot 和 Cursor 等 AI 助手与 OpenShift 和 Kubernetes 环境桥接起来，彻底改变了基础架构管理。Kubernetes MCP 服务器具有全面的 CRUD 操作、高级容器集管理、Helm 集成和跨平台部署功能，通过自然语言查询实现集群管理和故障排除的转型。

此外，我们还通过 MCP 将事件检测集成到 OpenShift Lightspeed 中。这将事件分析直接引入到对话界面中，改变您探索和解决集群问题的方式。

利用 NVIDIA Bluefield DPU 加速 AI 工作负载

作为技术预览，红帽 OpenShift 与 NVIDIA Bluefield DPU 搭配提供了一种简化的方法，用于部署适用于 AI、电信和企业工作负载的安全防护、路由和存储解决方案。该解决方案侧重于为基础架构和应用工作负载提供硬件加速和安全隔离，从而提高资源利用率并最大限度地提高服务器容量。 Bluefield 数据处理单元（DPU）是 NVIDIA Spectrum-X 和 AI 工厂设计不可或缺的一部分，未来的 OpenShift 版本有望实现 NVIDIA Spectrum-X 解决方案和 AI 工厂设计的无缝部署和编排。

通过原生 OIDC 支持简化身份管理

OpenShift 4.20 现在支持与外部 OpenID Connect（OIDC）身份提供商直接集成，以颁发用于身份验证的令牌，让您能够更好地控制身份验证系统。 通过直接与外部 OIDC 提供商集成，您可以利用首选 OIDC 提供商的高级功能，而不受内置 OAuth 服务器功能的限制。您的企业组织可以从单个界面管理用户和组，同时还可以跨多个集群和混合环境简化身份验证。

在 OpenShift 上使用零信任管理工作负载身份

零信任工作负载身份管理器将在未来几周内在 OpenShift 4.20 中全面可用。零信任工作负载身份管理器为所有工作负载提供经过运行时证明、可加密验证的身份。零信任工作负载身份管理器基于 SPIFFE/SPIRE 构建，提供核心功能，如工作负载自动注册、用于在混合云和多云环境中实现普遍信任的 SPIRE 至 SPIRE 联合、用于与现有企业身份系统集成的 OIDC 联合，以及使用 Hashicorp Vault 集成进行身份验证。

零信任工作负载身份管理器可建立普遍信任，消除静态机密，并为安全至上的工作负载间通信启用可验证的短期身份。它为从传统服务到新兴代理式 AI 系统的所有云原生工作负载提供经过运行时验证的一致身份，确保每个工作负载操作的问责制和可追溯性，并为整个应用环境中的零信任架构奠定基础。零信任工作负载身份管理器需要 OpenShift 平台 Plus、红帽 Kubernetes 高级集群安全防护或红帽高级集群管理订阅，以便在多个集群中使用时启用跨云工作负载身份管理。 

使用外部机密 Operator 简化机密管理

在 OpenShift 4.20 中，红帽 OpenShift 外部机密操作器 (ESO) 现已正式发布。ESO 是一项集群范围的服务，可为从外部机密管理系统获取的机密提供生命周期管理。通过与外部机密管理系统（如 AWS Secrets Manager、HashiCorp Vault 和 Azure Key Vault）集成，ESO 在集群内执行机密提取、刷新和置备，从而确保敏感机密更安全、更高效地流动集成到工作负载中，而无需应用直接参与。

利用用户命名空间消除容器特权升级风险

随着 OpenShift 4.20 中用户命名空间的全面推出，红帽使工作负载能够在增强隔离的情况下运行，同时保持开发人员构建现代应用所需的灵活性。 OpenShift 中的用户命名空间可将容器用户与主机用户隔离开来，降低特权升级攻击的风险，并允许容器以非 root 用户身份在主机上运行，同时保留操作的内部 root 特权，从而显着增强安全性。这有助于打造更安全的多租户环境，并更好地遵循企业安全标准。

使用 Istio 环境模式的无边车服务网格

OpenShift 服务网格 3.2 通过 Istio 的环境模式引入了对没有边车的服务网格的普遍支持。这是 Istio 的全新数据平面，它使用两级代理，以最少的额外资源使用量按需启用服务网格功能。 

第一个代理是节点级 ztunnel（“Z 代表零信任”），提供第 4 层双向 TLS 加密、遥测和基本授权策略。虽然它是节点代理，但它会重定向来自每个 pod 唯一网络命名空间内的流量，确保流量在 pod 级别隔离和加密。下一个代理是面向应用的路点，可以选择部署以提供第 7 层网格功能，例如基于应用细节（如 HTTP 请求类型或标头）的遥测和策略。 

这种架构可显着降低运行服务网格的资源成本，尤其是对于仅需要 ztunnel 代理的功能，如容器集到容器集的双向 TLS 加密。如需更多信息，请参阅利用 OpenShift 服务网格 3 优化流量和可观测性。 

OpenShift 网络中的原生 BGP 支持

红帽 OpenShift 网络现在在其默认网络插件 OVN-Kubernetes 中提供原生边界网关协议（BGP）路由功能。这一增强功能显着扩展了以前由 MetalLB（外部服务负载平衡）和集群网络 Operator（第 3 层网络结构、多宿主、链路冗余和快速收敛）支持的网络用例。 

从 OpenShift 4.20 开始，BGP 支持通过外部网络的 BGP 路由器将集群范围的容器集和虚拟机（VM）网络直接公告到支持 BGP 的提供商网络。相反，来自提供商网络的 BGP 学习路由可以导回到 OVN-Kubernetes，既可以导回到默认的容器集网络，也可以导回到指定的用户定义网络（UDN）。这种双向集成可实现 OpenShift 和外部网络结构之间的无缝路由交换。支持最初针对裸机平台，云平台支持的目标是后续版本。

为了提高可扩展性，可以选择在集群和外部网络之间部署路由反射器。虚拟机迁移或故障转移事件是说明基于 BGP 的路由播发的动态特性和优势的一个常见示例。当虚拟机移动到另一个节点时，它会保留其静态 IP 地址，BGP 表会自动并快速更新该虚拟机网络的公告路由，从而确保持续连接，并将中断降至最低。

在更新集群之前发现问题

在 OpenShift 4.20 中，两个新命令可让用户在更新之前和期间了解潜在的更新问题。oc adm upgrade recommend 和 oc adm upgrade status 命令现已全面可用。 

在您开始更新之前，oc adm upgrade recommend 会分析集群中的已知警报。它会显示导致问题的警报，例如 PodDisruptionBudgets 达到限值、集群操作器不可用，或者可能会减慢节点排空的警报。您将看到更新通道中提供了哪些版本，这些版本的任何已知问题，更重要的是，与正常集群行为相比，哪些情况实际上是有问题的。 

$ oc adm upgrade recommend Failing=True： Reason: ClusterOperatorNotAvailable 消息：集群操作器监控不可用 在将此集群更新到更高版本时，以下情况未发现任何问题：recommended/NodeAlerts (AsExpected)、recommended/PodImagePullAlerts (AsExpected) 在将此集群更新到更高版本时，发现以下情况需要引起关注：recommended/PodDisruptionBudgetAlerts/PodDisruptionBudgetAtLimit/1 recommended/PodDisruptionBudgetAlerts/PodDisruptionBudgetAtLimit/1=False： Reason: Alert: firing 消息：PodDisruptionBudgetAtLimit 警告警报正在触发，这可能会减慢节点排空速度。 Namespace=openshift-monitoring, PodDisruptionBudget-prometheus-k8s。 pod 中断预算可防止 pod 进一步中断。 警报描述为：pod 中断预算处于允许的最低中断级别。 当前健康运行的 pod 数量等于所需的健康运行 pod。 https://github.com/openshift/runbooks/blob/master/alerts/cluster-kube-controller-manager-operator/PodDisruptionBudgetAtLimit.md 上游更新服务：https://api.integration.openshift.com/api/upgrades_info/graph 通道：candidate-4.18（可用通道：candidate-4.18、candidate-4.19、candidate-4.18、eus-4.18、fast-4.18、fast-4.19、stable-4.18、stable-4.19） 4.18 更新： 版本问题 4.18.32 没有与此集群相关的已知问题 4.18.30 没有与此集群相关的已知问题 您还可以通过“--show-outdated-releases”或“--version VERSION”查看两个旧版 4.18 更新。

更新后，oc adm upgrade status 会向用户实时显示发生的情况：控制平面和工作节点进度、完成百分比、时间估算，以及出现问题时发出的警告。这两个命令都是只读的，不会更改 OpenShift 集群中的任何内容。有关详情，请参阅使用 CLI 更新集群。

利用双节点 OpenShift 优化边缘部署

利用带仲裁器的双节点 OpenShift 简化边缘部署。这提供了与标准三节点 OpenShift 集群相同的高可用性特征，同时只需要两台全尺寸服务器，并辅以一个用于仲裁的轻量级仲裁节点。 

仲裁节点作为仲裁的第三个 etcd 实例运行，仅具有 2 个 vCPU 和 8 GB 内存。同时，两个全尺寸节点处理所有实际工作负载，而小型仲裁器则确保集群能够容忍单个节点中断而不会失去可用性。只需要两个裸机订阅，并且仲裁器节点不承担许可成本。如需了解详情，请参阅红帽 OpenShift 和 Portworx/Pure Storage 提供的高效双节点边缘基础架构。

红帽 OpenShift 虚拟化 4.20 中的负载感知再平衡和更快的虚拟机迁移

红帽 OpenShift 虚拟化 4.20 中基于 CPU 压力的负载感知再平衡功能现已全面推出。通过动态考虑节点的实时资源利用率，将虚拟机从过度利用的节点迁移到具有可用容量的节点，从而改善了集群节点之间的工作负载分布。

OpenShift 虚拟化还引入了具有多集群功能的简化虚拟机管理，通过主要存储供应商解决方案提供的虚拟化迁移工具包的存储卸载功能，提高了向 OpenShift 的迁移速度，实时迁移到特定节点以及扩展的 Arm 支持。网络改进（如用于 L2 用户定义网络的 BGP）进一步提高了虚拟化工作负载的效率和灵活性。

在 Oracle Cloud Infrastructure 中扩展虚拟化工作负载

Oracle 云基础架构中裸机实例上的 OpenShift 虚拟化现已全面可用。这使我们的共同客户能够灵活地通过 OCI 的分布式云从任何位置运行其虚拟机工作负载。如需了解更多信息，请参阅在 OCI 上大规模解锁虚拟化。

将 OpenShift 扩展到 Oracle 主权云

最后但并非最不重要的一点是，OpenShift 扩大了对 Oracle 云基础架构的支持，特别强调主权云，如 Oracle EU 主权云、Oracle US Government Cloud、Oracle Cloud for UK Government & Defence、Oracle Cloud 隔离区域和 Oracle Alloy。这一增强功能为企业在云中部署 OpenShift 提供了更大的灵活性和更多选择，可满足专业云环境中对数据主权、监管合规性和增强安全性的关键需求。如需更多信息，请参阅扩展的 Oracle 云基础架构支持。

立即试用红帽 OpenShift 4.20

立即开始使用红帽混合云控制台，充分利用 OpenShift 中的最新功能和增强功能。如需了解后续动态，请查看以下资源：

• 红帽 OpenShift 的新功能和后续功能
• 红帽 OpenShift 4.20 新功能
• 体验更多全新 OpenShift 4.20 互动演示
• 在云端
• OpenShift YouTube 频道
• OpenShift 博客
• OpenShift Commons
• 红帽开发人员博客
• 红帽产品组合架构中心
• 经过验证的模式

如需红帽 OpenShift 4.20 更新的完整列表，请参阅 OpenShift 4.20 发行说明。通过您的红帽联系人向我们发送反馈，或在 GitHub 上创建问题。