Release Notes

This page lists notable changes in OpenShift releases which we find important. Reading release notes for you as a service.

OpenShift 4.18

OpenShift version 4.18 is available since 2025-02-25. This version is based on Kubernetes 1.31 and CRI-O 1.31. The RHCOS image still uses RHEL 9.4 packages. Find the release notes in the upstream documentation at OpenShift Container Platform 4.18 release notes. The Red Hat unveils OpenShift 4.18 blog post is also a valuable resource.

Improved OLM v1 now Generally Available

The original OLM is now renamed to OLM (Classic). Starting with OpenShift 4.18, the new OLM v1 is enabled by default, alongside the old OLM (Classic). OLM (Classic) remains fully supported.

OLM v1 provides a better declarative workflow with a simplified API compared to OLM (Classic), and introduces some new features like continuous reconciliation and rollbacks, granular update control, and user-provided service accounts.

At the moment, OLM v1 only supports installing certain cluster extensions. See OLM v1 supported extensions.

Although the acronym "OLM" still stands for "Operator Lifecycle Manager," Red Hat is now using the term "Extensions" or "Cluster Extensions" to refer to OLM-managed Operators.

See Red Hat documentation on Extensions for further information on this feature.

Secret Store CSI Driver Operator is becoming Generally Available

The Secret Store CSI Driver Operator allows OCP to mount secrets, keys or certificates stored in external secret stores directly into pods. Supported secret store providers include AWS Secrets Manager, Azure Key Vault, Google Secret Manager, and HashiCorp Vault.

See Secrets Store CSI Driver for further information on this feature.

Deploy OpenShift across multiple vSphere vCenters now Generally Available

Deploying OCP across multiple vCenter clusters can be helpful for high availability. This feature has to be configured during installation and can’t be enabled after the fact on an already running cluster. There is no support for shared storage between multiple vCenters using this feature.

User workload monitoring improvements

OpenShift 4.18 brings multiple improvements in the user-workload monitoring stack:

  • User workload alerting and recording rules can query multiple projects (namespaces) at the same time

  • Scrape and rule evaluation intervals are configurable

Route annotation updates

OpenShift 4.18 deprecates the haproxy.router.openshift.io/ip_whitelist and haproxy.router.openshift.io/ip_blacklist annotations in favor of haproxy.router.openshift.io/ip_allowlist and haproxy.router.openshift.io/ip_denylist.

These annotations can also be used on Ingress objects.
crun is the default container runtime for new clusters

New clusters setup with OpenShift 4.18 use crun as the container runtime by default. runC is still supported, and upgrading existing clusters from OpenShift 4.17 to 4.18 doesn’t change the container runtime.

OpenShift 4.17

OpenShift version 4.17 is available since 2024-10-01. This version is based on Kubernetes 1.30 and CRI-O 1.30. The RHCOS image still uses RHEL 9.4 packages. Find the release notes in the upstream documentation at OpenShift Container Platform 4.17 release notes. The Red Hat OpenShift 4.17: What you need to know blog post is also a valuable resource.

Node disruption policies

The node disruption policies feature has been promoted to GA. A node disruption policy allows you to define the configuration changes that cause a disruption to your cluster, and which changes don’t. This allows you to reduce node downtime when making small machine configuration changes in your cluster.

OpenShift SDN network plugin removed

The OpenShift SDN network plugin has been removed from the OpenShift Container Platform.

VSHN Managed OpenShift 4 clusters are installed with Cilium, a fully certified and supported 3rd party CNI plugin for OpenShift 4. Therefore VSHN Managed OpenShift clusters aren’t affected by this block.

Validating Admission Policies

Validating Admission Policies are now available in OpenShift 4.17. These policies allow you to validate the incoming requests to the API server.