Release notes

You can configure advanced OIDC authentication scenarios using structured authentication fields and Common Expression Language (CEL) expressions. This feature exposes additional fields from the Kubernetes AuthenticationConfiguration API for flexible claim mapping and token validation. Use CEL expressions to define username and group claim fallback logic, add validation rules, and handle non-standard claim structures. This feature is available for both standalone clusters and hosted control planes.

For more information, see About advanced direct authentication fields.

You can change the network configuration of a single-node OpenShift cluster without performing a full cluster redeployment by using the Lifecycle Agent. This feature supports critical edge computing scenarios such as disaster recovery and network rehoming with a stage-driven workflow that includes the ability to rollback changes on failure.

You can change network properties such as node IP addresses, machine network CIDRs, default gateways, VLAN settings, and DNS servers.

For more information, see Understand single-node OpenShift network reconfiguration.

The deploymentConfig API in the ClusterExtension resource enables declarative customization of Operator pod deployments, providing feature parity with Subscription.spec.config in OLM (Classic). Configure resource limits, node placement, environment variables, volumes, affinity rules, and pod annotations when installing cluster extensions. The format is compatible with OLM (Classic) configurations, simplifying migration.

For more information, see Configuring cluster extensions.

Operator Lifecycle Manager (OLM) v1 introduces the ClusterObjectSet API, which enables safe, phased rollouts of Kubernetes resources during ClusterExtension deployments and upgrades. A ClusterObjectSet object applies resources sequentially in ordered phases with built-in readiness checks, ensuring resources are created after any resources they are dependent on.

For more information, see ClusterObjectSets.

New features on IBM Power® include:

New features on IBM Z® and IBM® LinuxONE include:

With this release, the Insights Operator now collects the opentelemetrycollectors.opentelemetry.io custom resource to improve data retrieval efficiency and system performance.

To maintain security and prevent the collection of sensitive information, the Insights Operator applies the following constraints:

These improvements allow OpenShift Container Platform to better analyze the efficiency of the data gathering process and provide more precise environment insights. (OCPBUGS-78115)

You can enable a user-provisioned domain name server (DNS) instead of the default cluster-provisioned DNS solution. For example, your organization’s security policies might not allow the use of public DNS services such as Microsoft Azure DNS. As a result, you can manage the API and Ingress DNS records in your own system rather than adding the records to the DNS of the cloud. If you use this feature, you must provision the cluster first and then provide your own DNS solution that includes records for api.<cluster_name>.<base_domain>. and *.apps.<cluster_name>.<base_domain>..

Installing a cluster on Azure with a user-provisioned DNS was introduced in OpenShift Container Platform 4.21 with Technology Preview status. In OpenShift Container Platform 4.22, it is now generally available.

For more information, see Enabling a user-managed DNS and Provisioning your own DNS records.

With this release, you can map OpenShift Container Platform failure domains to VMware vSphere host groups. This means that you can make use of the high availability offered by a vSphere stretched cluster configuration.

OpenShift zones support for vSphere host groups was introduced in OpenShift Container Platform 4.19 with Technology Preview status. In OpenShift Container Platform 4.22, it is now generally available.

For information on configuring host groups at installation, see VMware vSphere host group enablement.

For information on configuring host groups for existing clusters, see Specifying multiple host groups for your cluster on vSphere.

You can now install OpenShift Container Platform on Amazon Web Services (AWS) in the European Sovereign Cloud (EUSC) region (eusc-de-east-1). The AWS EUSC region is separate and independent from other AWS regions, with all the infrastructure located within the European Union (EU). You must specify a custom Amazon Machine Image (AMI) in the platform.aws.defaultMachinePlatform.amiID field of your install-config.yaml file. Other limitations also apply. The AWS EUSC region is available as a Technology Preview feature.

For more information, see AWS EUSC.

With this update, you can install a OpenShift Container Platform cluster on Google Cloud with N4A machine types.

N4A Virtual Machines (VMs) use highly efficient Arm-based processors. N4A machines deliver exceptional performance compared to current-generation x86-based VMs, making them ideal for containerized applications and microservices on OpenShift Container Platform.

For more information, see Tested instance types for Google Cloud and N4A machine series (Google documentation).

With this update, you can install a cluster using RHEL version 10 as the base image for all machines in the cluster. This feature is available as a Technology Preview. To enable this feature, enable the TechPreviewNoUpgrade feature set and set the osImageStream parameter to rhel-10 in your install-config.yaml file.

For more information, see Installation configuration parameters.

With this update, you can add the openShiftUpdatePrecheck label to alerts in a PrometheusRule custom resource (CR) so that, when you run the oc adm upgrade recommend command, any firing alerts with this label appear in the command output.

For more information, see Adding custom alerts to oc adm upgrade recommend command output.

You can use KubeVirt Redfish to deploy OpenShift Container Platform clusters with control plane nodes running as virtual machines on a hosting cluster with OpenShift Virtualization. Running control plane nodes as VMs provides VM-level isolation for control plane components. KubeVirt Redfish exposes VMs through the standard Redfish API, enabling existing installation methods such as installer-provisioned infrastructure, Agent-based Installer, and GitOps Zero Touch Provisioning (ZTP) to manage VM power states and boot media. The feature is available as a Technology Preview.

For more information, see Understanding virtualized control planes.

When installing or upgrading an OpenShift Container Platform cluster on Google Cloud with short-term credentials, you can now use the --key-storage-method=pool-jwk-file option with the ccoctl gcp create-all command to attach OIDC signing keys directly to the workload identity pool provider. This method eliminates the need to create a publicly accessible Google Cloud Storage (GCS) bucket for OIDC configuration, which reduces the public attack surface and can help meet security and network policies in restricted environments.

For more information, see Creating GCP resources with the Cloud Credential Operator utility.

With this update, you can boot new nodes directly into a custom machine config pool. Before this update, you needed to create the node in the worker machine config pool, then move the node into the custom machine config pool, which requires a node reboot. By launching the node directly into the new pool, you save a node reboot cycle.

For information, see Creating a custom machine config pool with a new node.

With this update, the Machine Config Operator (MCO) examines the boot image version reported in the MachineConfiguration object to determine if that boot image is appropriate for the cluster. If the boot image version is too old, the Operator reports that boot image version skew is detected and blocks cluster updates until you manually update the boot image or disable boot image skew enforcement.

For more information, see Boot image skew enforcement.

With this update, the boot image management feature for control plane nodes is generally available. With boot image management enabled, you can configure your cluster to update the node boot image whenever you update your cluster. Before this update, boot image management was supported for worker nodes only. Boot image management for control plane nodes was introduced in OpenShift Container Platform 4.21 for AWS, Google Cloud, and Azure clusters, and is now generally available for the platforms in 4.22. The boot image management feature for control plane nodes is not supported for VMware vSphere.

For more information, see Boot image management.

With this update, the boot image management feature for worker nodes is default behavior in Azure and vSphere clusters. As such, after updating to OpenShift Container Platform 4.22, the boot images in your cluster are automatically updated to version 4.22. With subsequent updates, the Machine Config Operator (MCO) again updates the boot images in your cluster. Any new nodes you create after updating are based on the new version. Current nodes are not affected by this feature.

Before updating to 4.22, you must acknowledge this change or opt-out of this default behavior before proceeding. For information on opting out, see Disabling boot image management.

For more information on the boot image management feature, see Boot image management.

With this update, the Machine Config Operator documentation contains procedures to update the boot image on compute nodes for most supported OpenShift Container Platform platforms.

For OpenShift Container Platform platforms that do not support automatic boot image updating or for clusters configured with the boot image management feature disabled, you can manually update the boot image used by the compute nodes in your cluster.

For more information, see Manually updating the boot image.

With this update, the AppliedFilesAndOS condition reported by the machine config node has been split into the AppliedFiles and AppliedOSImage conditions as a Technology Preview feature. The machine config nodes custom resource monitors the progress of machine configuration updates to nodes. The AppliedFiles condition reports whether MCO has updated files on the node. The AppliedOSImage condition reports whether the MCO has updated the operating system.

For more information, see About node status during updates.

You can now place compute machines on Amazon Web Services (AWS) Dedicated Hosts. Dedicated Hosts are physical servers that are fully dedicated to your use. With Dedicated Hosts, you can use your existing per-socket, per-core, or per-VM software licenses and comply with corporate policies that require physical CPU assignment.

You can configure Dedicated Host placement in the following ways:

For more information, see Installation configuration parameters for AWS, Machine sets that place machines on Dedicated Hosts, and Place machines on Dedicated Hosts by using machine templates.

To reduce the cluster attack surface and ensure predictable network behavior, OpenShift Container Platform now enforces least-privilege network policies on critical networking components. Starting in 4.22, OpenShift Container Platform includes default NetworkPolicy objects in some of its own namespaces. Specifically, the operators that manage cluster DNS and cluster Ingress automatically install and maintain default deny-all NetworkPolicy objects in their respective namespaces.

To check the namespaces that include the objects by default, you can run the following command:

$ oc get networkpolicies --all-namespaces

The OpenShift Container Platform 4.22 release did not include these objects in all OpenShift Container Platform namespaces; later OpenShift Container Platform releases might include the objects in additional namespaces.

You can enable IPv4 forwarding on specific network interfaces by using the Kubernetes NMState Operator. By setting the forwarding: true field in a NodeNetworkConfigurationPolicy custom resource, you can configure individual interfaces to forward IP packets without enabling global IP forwarding on the cluster. This approach improves security by keeping global forwarding disabled while allowing forwarding only on the interfaces that require it, such as secondary interfaces used by MetalLB load balancers.

For more information, see Enable IP forwarding on specific interfaces.

The Kubernetes NMState Operator can now collect metrics from the following Kubernetes components:

Assign alternative names to network interfaces by using the Kubernetes NMState Operator. Alternative names provide consistent, descriptive labels for interfaces across cluster nodes, simplifying automation in environments where interface names vary across nodes.

For more information, see Configure alternative network interface names.

The commatrix plugin generates nftables firewall rules in Butane format for deployment to cluster nodes. These rules restrict ingress traffic to only the flows required by deployed services, promoting a zero-trust security posture. The plugin also generates a NodeDisruptionPolicy patch to apply rule updates without node reboots.

For more information, see Generate nftables firewall rules in Butane format.

You can now use the new ConfigurationState custom resource to verify that MetalLB has successfully applied your settings across the cluster. This feature provides a single, consistent location to identify configuration errors that were previously only visible by searching through individual node logs or FRR status reports

MetalLB creates a ConfigurationState resource for the controller and for each speaker node. Each resource reports whether your configuration is valid and surfaces specific error details if validation fails, such as issues with IPAddressPool, BGPPeer, or BFDProfile objects. This centralized reporting helps you monitor system integrity and resolve networking conflicts more quickly.

For more information, see Checking MetalLB configuration status.

With this release, the multi-network policy backend uses nftables instead of iptables. The iptables backend has been removed and there is no option to revert to it. The MultiNetworkPolicy API and user-facing configuration are unchanged, so your existing multi-network policies continue to work without modification.

For more information, see Configuring multi-network policy.

With MetalLB, you can now set spec.serviceSelectors on BGPAdvertisement and L2Advertisement custom resources (CRs). This allows you to match LoadBalancer services by label so each advertisement applies its own BGP or Layer 2 settings to the services you choose, even when those services use the same IPAddressPool.

For more information, see About advertising for the IP address pools.

With this release, Border Gateway Protocol Ethernet Virtual Private Network (BGP EVPN) is available for primary cluster user-defined networks. Enabling this feature on OpenShift Container Platform allows a ClusterUserDefinedNetwork overlay network to use the EVPN control plane for deeper integration with the data center network.

For more information, see About BGP EVPN for primary cluster user-defined networks.

With this release, no-overlay mode with Border Gateway Protocol (BGP) routing is available as a Technology Preview feature on bare-metal clusters that use OVN-Kubernetes. No-overlay mode forwards layer 3 pod traffic on the underlay network using BGP-learned routes instead of Geneve encapsulation, which can improve east-west performance. You can enable no-overlay mode on the default layer 3cluster network and on primary ClusterUserDefinedNetwork resources.

For more information, see Improve east-west performance by routing pods on the underlay with BGP.

You can now configure Precision Time Protocol (PTP) boundary clock (BC) without holdover on Intel Granite Rapids-D (GNR-D) hardware that uses onboard Network Acceleration Complex (NAC) ports and optional Carter Flat expansion network interface cards (NICs).

In this deployment, one time receiver (TR) port synchronizes to an upstream timing source while time transmitter (TT) ports distribute synchronized time downstream. GNR-D BC without holdover deployments on Carter Flat hardware require a continuous upstream PTP timing source because monitored holdover is not supported.

For more information, see Boundary clocks without holdover on Intel Granite Rapids-D hardware.

You can configure an Intel® Granite Rapids-D (GNR-D) platform device as telecom boundary clock (T-BC) with holdover support by using the PTP Operator.

With this technology preview feature, you can configure T-BC holdover on GNR-D platforms dell/XR8720t and hpe/EL140-Gen12.

In this configuration, one time receiver (TR) port synchronizes to an upstream telecom grandmaster clock, while time transmitter (TT) ports distribute synchronized time to downstream devices. If the upstream timing source degrades, disconnects, or becomes unavailable, the system enters holdover mode and maintains timing by using configured digital phase-locked loop (DPLL) devices.

For more information, see Configuring GNR-D T-BC holdover on a GNR-D platform.

You can configure a Precision Time Protocol (PTP) Telecom Grandmaster (T-GM) on Intel Granite Rapids-D (GNR-D) servers so a single Global Navigation Satellite System (GNSS) feed synchronizes timing across onboard Network Acceleration Complex (NAC) ports and optional Carter Flat expansion network interface cards (NICs). The PTP Operator supports GNR-D deployments with the e830 and e825 hardware plugins and an example PtpConfig custom resource (CR) that you customize for your qualified hardware layout. PTP T-GM on GNR-D is available as a Technology Preview feature.

For more information, see Telecom Grandmaster clocks on Intel Granite Rapids-D hardware.

With this update, administrators can use the imagePullCredentialsVerificationPolicy parameter in a KubeletConfig custom resource to enforce credential verification for cached images. This parameter forces the kubelet to re-authenticate with the container registry before it deploys a pod, ensuring that the requesting namespace has valid access rights to the image.

The underlying KubeletEnsureSecretPulledImages feature gate is enabled by default. Administrators can configure specific credential provider policies to balance security and stability:

With this update, the system-reserved-compressible parameter is enabled for all clusters that do not use the reserved CPU feature. This addresses previous issues where the system reserved CPU exceeded the desired limit. This default can be overridden by configuring the systemReservedCPU: "" parameter in a kubelet configuration.

For more information, see How OpenShift Container Platform enforces system-reserved CPU.

With this update, you can use an image volume to mount an Open Container Initiative (OCI)-compliant artifact directly into a pod. OCI artifacts enable users to store and distribute arbitrary files and metadata using OCI compliant container registries.

For more information, see Mounting OCI images and artifacts into a pod.

With this update, you can create additional, non-default artifact storage locations in CRI-O that your pods can pull from. By using storage locations for the CRI-O container engine other than the default for OCI artifacts, complete container images, or container image layers, you can reduce application startup time and make your applications run more efficiently.

For more information, see Additional CRI-O storage locations for faster container startup.

With this update, you can pull images from mirrored registries by using project-scoped pull secrets as a technology preview feature. Before this update, you needed to use node-level secrets when pulling from a mirrored registry because the kublet does not recognize the mirror configuration, which is configured at the container-runtime level.

For more information, see Configuring project-scoped image pull secrets for mirrored registries.

With this update, the dynamic resource allocation feature supports partitioning physical hardware into smaller, logical instances, such as Multi-Instance GPUs, based on workload demands. With this technology preview feature, you can safely and efficiently share GPUs across multiple pods.

For more information, see Allocating GPUs to pods by using DRA.

With this release, the Peripheral Component Interconnect (PCI) address for each network interface controller (NIC) is available in two separate custom resources (CRs). The PCI address is located in the status.hardware.nics[] section of the BareMetalHost CR and in the spec.hardware.nics[] section of the HardwareData CR. While these are separate resources, the values in the pciAddress fields, for example 0000:00:03.0, are identical.

For more information, see About the BareMetalHost resource and The BareMetalHost status.

With this update, you can add ARM nodes to bare metal clusters with x86 control planes using PXE or virtual media. You can expand your cluster by creating a BareMetalHost object with the aarch64 architecture, and then scaling the machine set to deploy the new machine.

For more information, see Preparing the bare metal node.

With this release, you can scale the NUMA-aware secondary scheduler to support clusters with up to 500 nodes. The scheduler defaults to a Burstable quality of service (QoS) profile, which reduces baseline resource consumption while allowing the scheduler to scale up during peak loads.

For more information, see Topology-aware scheduler scalability.

With this release, you can protect latency-sensitive workloads from performance degradation caused by oc exec and shell processes. When you apply a PerformanceProfile, the CRI-O ExecCPUAffinity feature automatically pins exec processes to a designated CPU within the container’s allocated set, preventing them from running on your workload CPUs. This feature is enabled by default for Guaranteed QoS pods with whole-integer CPU requests and requires no additional configuration. You can disable it per profile by adding the performance.openshift.io/exec-cpu-affinity: "disable" annotation to the PerformanceProfile.

For more information, see How ExecCPUAffinity prevents latency spikes from exec operations.

The OpenShift Container Platform web console now fully supports browsing, inspecting, and installing Open Container Initiative (OCI)-based Helm charts directly from configured repositories to provide functional parity with traditional HTTP(S) Helm charts. This enhancement removes the previous discovery-only limitation, enabling users to interact with and deploy OCI-based charts seamlessly within the console’s repository views.

For more information, see Configuring custom Helm chart repositories.

In the web console, you can now install a Helm chart directly from a URL, without first adding the chart to a Helm chart repository or the console catalog. Both oci:// and https:// URLs are supported.