Red Hat OpenShift 4.20 accelerates virtualization and enterprise AI innovation

Red Hat OpenShift 4.20 is now generally available. It's based on Kubernetes 1.33 and CRI-O 1.33 and, together with Red Hat OpenShift Platform Plus, this release underscores our commitment to provide a trusted, comprehensive, and consistent application platform. On OpenShift, AI workloads, containers, and virtualization seamlessly co-exist, enabling enterprises to innovate faster across the hybrid cloud, without compromising on security.

Available in self-managed or fully managed cloud service editions, OpenShift offers an application platform with a complete set of integrated tools and services for cloud-native, AI, virtual and traditional workloads alike. This article highlights the latest OpenShift 4.20 innovations and key enhancements. For a comprehensive list of updates and improvements, refer to the OpenShift 4.20 release notes.

This latest release boosts the platform’s capabilities for AI workloads with the general availability of LeaderWorkerSet, Gateway API inference extension, and runtime Open Container Initiative (OCI) image volume source. It also strengthens core functionalities, introducing vital improvements like bring-your-own external identity provider, Zero Trust Workload Identity Manager, user namespace, External Secrets Operator for Red Hat OpenShift, Border Gateway Protocol (BGP) support. Furthermore, OpenShift 4.20 brings key advancements in virtualization, such as CPU load aware rebalancing and faster live migration, providing a more robust and versatile platform for diverse computing needs.

OpenShift 4.20 now enables the X25519MLKEM768 hybrid key exchange mechanism with the Go 1.24 release as part of our journey to add support for post-quantum cryptography (PQC). This enhances TLS communications between core Kubernetes control plane components like the API server, kubelet, scheduler, and controller-manager, helping protect them from quantum-based attacks.

Red Hat's latest releases of Trusted Artifact Signer 1.3 and Trusted Profile Analyzer 2.2 deliver a powerful combination of cryptographic signing capabilities and advanced supply chain analysis.

Distribute and scale AI/ML workloads with LeaderWorkerSet and JobSet

OpenShift 4.20 simplifies the deployment of complex distributed AI workloads. With the generally available LeaderWorkerSet, platform teams can efficiently distribute and scale AI models that exceed a single pod's capacity, using a leader pod to seamlessly orchestrate communication across worker pods. Coupled with JobSet, available as a technology preview, which groups and manages distributed jobs with flexible scheduling and fault tolerance, teams can leverage familiar GitOps, role-based access control (RBAC), and monitoring patterns for even the most demanding machine learning  workflows. Together, they enable end-to-end orchestration of both training (JobSet) and inference (LeaderWorkerSet) workloads at scale, delivering robust, scalable, and efficient AI/ML lifecycle management within OpenShift.

Native AI routing with Red Hat OpenShift AI 3

AI and machine learning workloads have unique challenges that make traditional load balancing strategies like round robin a poor fit. Red Hat OpenShift AI 3 addresses these challenges with distributed inference with llm-d, leveraging Kubernetes Gateway API Inference Extensions (GIE). OpenShift 4.20 includes GIE, building on the Kubernetes Gateway API to provide specialized routing and traffic management for AI/ML workloads. If you're already using Kubernetes Gateway API for your applications, you can now apply the same declarative approach to AI model serving.

GIE is automatically made available in OpenShift 4.20 when an InferencePool resource is created. An InferencePool resource represents a set of AI or machine learning inference pods and an “end point picker” that contains specialized routing logic. The llm-d inference scheduler, part of Red Hat OpenShift AI 3, serves as the end point picker by capturing telemetry data exposed by vLLM using the model server protocol, enabling smart routing decisions based on the best available model instance at any given time.

GIE is implemented using Istio’s gateway implementation backed by Envoy proxy through OpenShift Service Mesh 3.2. Currently, it is only supported with Red Hat OpenShift AI 3. Using the GIE, AI workloads can be managed through the same GitOps pipelines and RBAC policies. Whether you're serving a single model or orchestrating a complex multi-model inference pipeline, GIE turns what was once specialized AI infrastructure into just another route in your cluster.

Update AI models without touching your pods

LLMs and ML models often exceed 10GB, making container rebuilds slow and storage-intensive. You no longer have to rebuild containers every time your AI model updates. In OpenShift 4.20, you can mount model weights directly from your container registry as volumes, so data scientists can push new model versions to the registry while model-serving containers remain unchanged. Simply reference the OCI image in your pod spec and OpenShift handles the rest. Now, models become versionable artifacts separate from code, pulled on-demand using familiar registry auth, cached locally for performance, and updated without touching your deployments.

Chat with your OpenShift or Kubernetes clusters with natural language

We’re pleased to announce the developer preview of the Kubernetes Model Context Protocol (MCP) server for OpenShift and Kubernetes. The Kubernetes MCP server revolutionizes infrastructure management by bridging AI assistants, such as VS Code, Microsoft Copilot, and Cursor, with OpenShift and Kubernetes environments. Featuring comprehensive CRUD operations, advanced pod management, Helm integration, and cross-platform deployment, the Kubernetes MCP server transforms cluster management and troubleshooting through natural language queries.

In addition, we’ve also integrated incident detection into OpenShift Lightspeed with MCP. This brings incident analysis directly into the conversational interface, changing how you explore and resolve cluster issues.

Accelerate AI workloads with NVIDIA Bluefield DPUs

Available as a technology preview, Red Hat OpenShift together with NVIDIA Bluefield DPUs offers a streamlined approach to deploying security, routing, and storage solutions for AI, telco, and enterprise workloads. This solution emphasizes hardware acceleration and security isolation for infrastructure and application workloads, enhancing resource utilization and maximizing server capacity. Bluefield data processing units (DPUs) are integral to NVIDIA’s Spectrum-X and AI factory designs, with future OpenShift releases poised to enable seamless deployment and orchestration of NVIDIA’s Spectrum-X solution and AI factory designs.

Streamline identity management with native OIDC support

OpenShift 4.20 now enables direct integration with external OpenID Connect (OIDC) identity providers to issue tokens for authentication, giving you more control over your authentication systems. By integrating directly with an external OIDC provider, you can leverage the advanced capabilities of your preferred OIDC provider instead of being limited by the capabilities of the built-in OAuth server. Your organization can manage users and groups from a single interface, while also streamlining authentication across multiple clusters and in hybrid environments.

Manage workload identities with Zero Trust on OpenShift

Zero Trust Workload Identity Manager will be generally available in OpenShift 4.20 in the coming weeks. Zero Trust Workload Identity Manager provides runtime-attested, cryptographically verifiable identities for all workloads. Built on SPIFFE/SPIRE, Zero Trust Workload Identity Manager offers core capabilities such as workload auto-registration, SPIRE-to-SPIRE Federation for universal trust across hybrid and multi-cloud environments, OIDC federation for integration with existing enterprise identity systems, and secretless authentication with Hashicorp Vault integration.

Zero Trust Workload Identity Manager establishes universal trust, eliminates static secrets, and enables short-lived, verifiable identities for security-focused workload-to-workload communication. It provides consistent, runtime-attested identities for all cloud-native workloads, from traditional services to emerging agentic AI systems, ensuring accountability and traceability for every workload action and forming the foundation for Zero Trust architectures across the entire application landscape. Zero Trust Workload Identity Manager requires OpenShift Platform Plus, Red Hat Advanced Cluster Security for Kubernetes, or Red Hat Advanced Cluster Management subscriptions to enable cross-cloud workload identity management when used in more than one cluster. 

Streamline secrets management with External Secrets Operator

In OpenShift 4.20, the External Secrets Operator for Red Hat OpenShift (ESO) is now generally available. ESO is a cluster-wide service that provides lifecycle management for secrets fetched from external secret management systems. By integrating with external secret management systems, such as AWS Secrets Manager, HashiCorp Vault, and Azure Key Vault, ESO performs secret fetching, refreshing, and provisioning within the cluster, thus ensuring sensitive secrets flow more securely and efficiently into workloads without direct application involvement.

Eliminate container privilege escalation risks with user namespaces

With the general availability of user namespaces in OpenShift 4.20, Red Hat enables workloads to be run with enhanced isolation while maintaining the flexibility developers need to build modern applications. User namespaces in OpenShift significantly enhance security by isolating container users from host users, reducing the risk of privilege escalation attacks, and allowing containers to run as non-root users on the host while retaining internal root privileges for operations. This leads to safer multi-tenant environments and greater compliance with enterprise security standards.

Service mesh without sidecars with Istio’s ambient mode

OpenShift Service Mesh 3.2 introduces generally available support for service mesh without sidecars with Istio’s ambient mode. This is an all-new data plane for Istio that uses two levels of proxy to enable service mesh features as needed with minimal added resource usage. 

The first proxy is the node-level ztunnel ("Z for zero trust") that provides layer 4 mutual TLS encryption, telemetry, and basic authorization policies. Though it is a node proxy, it redirects traffic from within each pod’s unique network namespace, ensuring traffic is isolated and encrypted at the pod level. The next proxy is the application oriented waypoint, which can optionally be deployed to provide layer 7 mesh features, such as telemetry and policies based on application specifics like HTTP request types or headers. 

This architecture significantly reduces the resource costs of running a service mesh, particularly for features that only require the ztunnel proxy, such as pod-to-pod mTLS encryption. More at Optimizing Traffic and Observability with OpenShift Service Mesh 3. 

Native BGP support in OpenShift Networking

Red Hat OpenShift Networking now provides native Border Gateway Protocol (BGP) routing capabilities within its default network plug-in, OVN-Kubernetes. This enhancement significantly extends the networking use cases previously supported by MetalLB (external service load balancing) and the Cluster Network Operator (Layer 3 network fabric, multi-homing, link redundancy, and fast convergence). 

Starting with OpenShift 4.20, BGP enables cluster-scoped pod and virtual machine (VM) networks to be directly advertised into a BGP-enabled provider network through the external network’s BGP router. Conversely, BGP-learned routes from the provider network can be imported back into OVN-Kubernetes—either into the default pod network or a specified user-defined network (UDN). This bidirectional integration allows for seamless route exchange between OpenShift and external network fabrics. Support is initially available for bare metal platforms, with cloud platform support targeting a follow-on release.

For improved scalability, route reflectors can optionally be deployed between the cluster and external networks. A common example illustrating the dynamic nature and benefits of BGP-based route advertisement is a VM migration or failover event. When a VM moves to another node, it retains its static IP address, and the BGP table automatically and rapidly updates the advertised route for that VM’s network, ensuring continuous connectivity with minimal disruption.

Catch issues before updating your cluster

In OpenShift 4.20, two new commands give users visibility into potential update issues before and during updates. The oc adm upgrade recommend and oc adm upgrade status commands are both now generally available. 

Before you begin an update, oc adm upgrade recommend analyzes the cluster for known alerts. It surfaces alerts that cause problems, such as PodDisruptionBudgets at their limit, unavailable cluster operators, or alerts that might slow down node drains. You'll see which versions are available in your update channel, any known issues with those releases, and more importantly, which conditions are actually problematic compared to normal cluster behavior. 

$ oc adm upgrade recommend
Failing=True:
Reason: ClusterOperatorNotAvailable
Message: Cluster operator monitoring is not available
The following conditions found no cause for concern in updating this cluster to later releases: recommended/NodeAlerts (AsExpected), recommended/PodImagePullAlerts (AsExpected)
The following conditions found cause for concern in updating this cluster to later releases: recommended/PodDisruptionBudgetAlerts/PodDisruptionBudgetAtLimit/1
recommended/PodDisruptionBudgetAlerts/PodDisruptionBudgetAtLimit/1=False:
Reason: Alert: firing
Message: warning alert PodDisruptionBudgetAtLimit firing, which might slow node drains. Namespace=openshift-monitoring, PodDisruptionBudget-prometheus-k8s. The pod disruption budget is preventing further disruption to pods. The alert description is: The pod disruption budget is at the minimum disruptions allowed level. The number of current healthy pods is equal to the desired healthy pods.
https://github.com/openshift/runbooks/blob/master/alerts/cluster-kube-controller-manager-operator/PodDisruptionBudgetAtLimit.md
Upstream update service: https://api.integration.openshift.com/api/upgrades_info/graph
Channel: candidate-4.18 (available channels: candidate-4.18, candidate-4.19, candidate-4.18, eus-4.18, fast-4.18, fast-4.19, stable-4.18, stable-4.19)
Updates to 4.18:
VERSION    ISSUES
4.18.32    no known issues relevant to this cluster
4.18.30    no known issues relevant to this cluster
And 2 older 4.18 updates you can see with '--show-outdated-releases' or '--version VERSION'.

After the update, oc adm upgrade status shows users what is happening in real-time: control plane and worker node progress, completion percentages, time estimates, and warnings if something gets stuck. Both commands are read-only and do not change anything in the OpenShift cluster. More at Updating a cluster by using the CLI.

Optimize edge deployments with two node OpenShift

Streamline your edge deployments with two node OpenShift with arbiter. This provides the same high availability characteristics as a standard three-node OpenShift cluster, while requiring only two full-sized servers, complemented by a lightweight arbiter node for quorum. 

The arbiter node runs as a third etcd instance for quorum with only 2 vCPUs and 8 GB of memory. Meanwhile, the two full-sized nodes handle all the actual workload, while the small arbiter ensures the cluster can tolerate a single node outage without losing availability. Only two bare metal subscriptions are required, and the arbiter node doesn't contribute to the licensing costs. Learn more at Efficient Two Node Edge Infrastructure delivered by Red Hat OpenShift and Portworx/Pure Storage.

Load-aware rebalancing and faster VM migration in Red Hat OpenShift Virtualization 4.20

Load-aware rebalancing based on CPU pressure in Red Hat OpenShift Virtualization 4.20 is also now generally available. This improves workload distribution across cluster nodes by dynamically considering real-time resource utilization of nodes, migrating VMs from overutilized nodes to those with available capacity.

OpenShift Virtualization also introduces simplified VM management with multi-cluster capabilities, enhanced migration speeds to OpenShift through the migration toolkit for virtualization storage offloading functionality from major storage vendor solutions, live migration to a specific node, and expanded Arm support. Networking improvements, such as BGP for L2 user-defined networks, further boost efficiency and flexibility for virtualized workloads.

Scale virtualization workloads in Oracle Cloud Infrastructure

OpenShift Virtualization on bare metal instances in Oracle Cloud Infrastructure is now generally available. This gives our joint customers the flexibility to run their VM workloads from any location via OCI’s distributed cloud. More at Unlocking Virtualization at Scale on OCI.

Expand OpenShift into Oracle sovereign clouds

Last but not least, OpenShift expands its support for Oracle Cloud Infrastructure, particularly emphasizing sovereign clouds like the Oracle EU Sovereign Cloud, Oracle US Government Cloud, Oracle Cloud for UK Government & Defence, Oracle Cloud Isolated Regions, and Oracle Alloy. This enhancement provides organizations with greater flexibility and choice in deploying OpenShift in clouds that address critical needs for data sovereignty, regulatory compliance, and enhanced security within specialized cloud environments. More at Expanded Oracle Cloud Infrastructure Support.

Try Red Hat OpenShift 4.20 today

Get started today with the Red Hat Hybrid Cloud Console and take advantage of the latest features and enhancements in OpenShift. To find out what’s next, check out the following resources:

• What’s New and What’s Next in Red Hat OpenShift
• What’s New in Red Hat OpenShift 4.20
• Try more of the new OpenShift 4.20 interactive demos
• In the Clouds
• OpenShift YouTube Channel
• OpenShift Blogs
• OpenShift Commons
• Red Hat Developer Blogs
• Red Hat Portfolio Architecture Center
• Validated Patterns

The complete list of the Red Hat OpenShift 4.20 updates are in the OpenShift 4.20 Release Notes. Send us feedback through your Red Hat contacts or create an issue on GitHub.