Red Hat OpenShift Container Platform 4.12, based on Kubernetes 1.25 and Crio 1.25, is here. This new release brings many updates to the open source container platform that accelerates the development and delivery of cloud-native applications consistently across the hybrid and multi cloud environments, all the way to the edge.

Built on Red Hat Enterprise Linux (RHEL) and Kubernetes, OpenShift provides a more secure and scalable multi-tenant platform for today’s enterprise-class applications, while also delivering integrated application runtimes and libraries. OpenShift enables organizations to meet security, privacy, compliance, and governance requirements with open source solutions to large-scale software problems. This blog highlights the latest OpenShift 4.12 innovations and notable updates. A comprehensive list of the OpenShift 4.12 changes can be seen in the OpenShift 4.12 Release Notes.

A chart of the new features in OpenShift 4.12

What’s New in OpenShift 4.12 Infographic by Julia Hiadlovska

49 Customers’ Requested Enhancements Delivered

Our customers directly influence our product development, and we’re delighted to introduce 49 customer requests for enhancements (RFEs) in our latest release. Many of the top requested enhancements focus on network configuration. This included adding the ability to disable DNS management in Ingress Controllers, limiting access to the load balancer for the Ingress Controller to IP address ranges, and adding the ability to tune CoreDNS caching and change the cache time-to-live (TTL) values. Another top requested enhancement in OpenShift 4.12 is a notification or banner in the OpenShift Console which only appears during upgrades.

OpenShift lifecycle extended to 24 months for Extended Update Support releases

In addition to the 49 RFE’s delivered, we’re pleased to announce that Red Hat OpenShift Extended Update Support (EUS) releases are now supported for 24 months, beginning with OpenShift 4.12 and continuing on all subsequent even numbered releases. This additional six months EUS phase, taking the total lifecycle to 24 months, pertains only to OpenShift deployments that use x86_64 architecture for 4.12. OpenShift deployments using architectures such as AArch64, Power, and zSystems remain at 18 months but continue to benefit from the streamlining of upgrades between EUS releases. Expansion to include these other architectures will be reviewed in subsequent EUS releases.

This lifecycle extension provides customers and partners six additional months to effectively plan, deploy, and support their infrastructure. All previous OpenShift releases remain supported for 18 months from their initial release date. Refer to Red Hat OpenShift Container Platform Life Cycle Policy for additional details.

OVN Kubernetes as Default Networking Solution

Beginning with OpenShift 4.12, new clusters will be installed with the OVN-Kubernetes network plugin as the default networking plugin across all support platforms and topologies. All prior OpenShift releases will continue to use OpenShift SDN as the default networking plugin.

The OVN-Kubernetes network plugin includes a rich set of capabilities that include support for the following:

Refer to About the OVN-Kubernetes network plugin for the feature comparison matrix with OpenShift SDN. To migrate from OpenShift SDN to OVN-Kubernetes, review Migrating from the OpenShift SDN cluster network provider.

Tame upgrades at massive scale with Topology Aware Lifecycle Manager

Topology Aware Lifecycle Manager (TALM) allows organizations to manage the deployment and updates of multiple single node OpenShift (SNO) clusters. TALM is now generally available. TALM uses Red Hat Advanced Cluster Management (RHACM) policies to perform changes and enforce policies against a user-defined group of clusters. The administrator defines application-specific deployment policies and topologies, which TALM then automatically deploys to a large, complex network of clusters via phased rollout policies to clusters in limited batches while ensuring applications are always available and performing optimally. With TALM, Administrators control the the timing of the updates, the number of RHACM-managed clusters, the subset of managed clusters to apply the policies to, the update order of the clusters, the set of policies remediated to the cluster, and the order of policies remediated to the cluster. Learn more or watch a demo about TALM at Taming Upgrades at Massive Scale for Telco.

Single click to scale control plane on AWS

You can now scale control plane nodes automatically in an OpenShift cluster on AWS just like you would your worker nodes. This operational flexibility is especially useful to tackle growth or a control plane node failure. Previously, you would execute a lengthy procedure to recover a failed control plane and to add new control plane nodes. Refer to About the Control Plane Machine Set Operator for additional information.

Enhanced resource allocation management via cgroup v2 (Technology Preview)

OpenShift support for Linux Control Group version 2 (cgroup v2) has been promoted to Technology Preview. cgroup v2 is the next version of the kernel control groups. cgroups v2 offers multiple improvements, including a unified hierarchy, safer sub-tree delegation, new features, such as Pressure Stall Information, as well as enhanced resource management and isolation. It also includes unified accounting for different types of memory allocations for network memory and kernel memory, as well as accounting for non-immediate resource changes, such as page cache write backs.

Cgroup v2 provides better control, performance, and stability for nodes where Out-Of-Memory (OOM) kill conditions occur, especially where workloads consume more than the allocated memory. In the future, cgroup v2 replaces cgroup v1 and creates a platform that offers many new v2 specific kernel features, such as PSI, user space OOM kill daemons, as well as memory QoS improvements. See Enabling Linux Control Group version 2 (cgroup v2) to learn more about cgroup v2. Note that cgroup v2 uses a different API versus cgroup v1, so if any applications directly access the cgroup file system, those applications need to be updated to newer versions that support cgroup v2.

Fast and low-memory footprint container runtime with crun (Technology Preview)

With OpenShift 4.12 comes support for the crun container runtime in Technology Preview. Users can switch between the crun container runtime and the default container runtime as needed by using a ContainerRuntimeConfig custom resource (CR) as detailed in About the container engine and container runtime. crun uses less memory than runc and has a lower overhead at steady state such as running exec hooks.

Install in disconnected or air-gapped environments

In OpenShift 4.12, we’re promoting the agent-based installer to general availability. The agent-based Installer is optimized for disconnected and air-gapped OpenShift deployments for baremetal, vSphere, and agnostic platforms. Using the agent-based installer, customers can deploy all supported OpenShift topologies including single node clusters, three-node compact clusters, or standard high availability clusters. With the agent-based installer, an in-place bootstrap is provided, so there is no need for a dedicated provisioning node. Customers can optionally automate the agent-based installer workflow with their preferred automation tooling for a complete hands-off deployment. Try it today at console.redhat.com.

Hybrid cloud adoption from Google Cloud Platform Marketplace

Furthering Red Hat’s commitment to customer choice and flexibility across the open hybrid cloud, you can now use committed Google Cloud Platform (GCP) spend to purchase and run Red Hat offerings directly through GCP Marketplace. This provides you with an easier path to digital transformation and more efficient operations, while being better able to meet dynamic market demands. Installing OpenShift using a GCP Marketplace image lets you create self-managed cluster deployments that are billed on pay-per-use basis (hourly, per core) through GCP, while still being supported directly by Red Hat.

Install private clusters in IBM Cloud Virtual Private Cloud

You can now deploy private clusters in IBM Virtual Private Cloud (VPC) using installer provisioned infrastructure (IPI) in OpenShift 4.12. To install OpenShift in IBM Cloud VPC, see Preparing to install on IBM Cloud VPC. Note that IBM Cloud Classic is not supported at this time.

Use OpenShift Container Platform on Arm

OpenShift is now supported on Arm architecture-based Azure installer-provisioned infrastructure in addition to AWS Graviton 3-based AWS installer-provisioned infrastructure clusters. Refer to Supported installation methods for different platforms for instance availability and installation details.

New load balancer option for deployments on AWS

Beginning with OpenShift 4.12, you can specify either Network Load Balancer (NLB) or Classic as a persistent load balancer type in AWS during installation. Afterwards, if an Ingress Controller is deleted, the load balancer type persists with the lbType configured during installation. Learn more at Configuring an Ingress Controller Network Load Balancer on a new AWS cluster.

Deliver latency sensitive applications closer to end users and on-premises

If you’re using self-managed OpenShift in AWS, you can now provision OpenShift clusters to take advantage of AWS Local Zones.  Specifically,  we’re extending workers to the edge with Local Zones. You install OpenShift to an existing Amazon Virtual Private Cloud (VPC), which has subnets in Local Zones. To deploy in Local Zones, customers would need to use the user provisioned infrastructure (UPI) and use the AWS Application Load Balancer (ALB) Operator on services deployed in Local Zones for custom ingress. Learn more at Installing a cluster using AWS Local Zones.

Make OpenShift Install More Flexible

For some time now, there’s been an increasing desire to move away from "one size fits all" cluster installations, and towards flexibility about what should or should not exist in a new cluster out-of-the-box to reduce security exposure and resource overhead. This can be seen from efforts, such as hosted control planes, single node OpenShift, Red Hat OpenShift Local, and Red Hat Device Edge. In conjunction with each of these efforts to make the installation more flexible, we continue to make OpenShift more composable by providing a mechanism for a cluster administrator to exclude one or more optional components for the installation. This in turn determines which payload components are installed or not installed in the cluster.

In the previous release (OpenShift 4.11), we made it possible to disable the marketplace operator, the samples operator, and the cluster bare metal operator. In OpenShift 4.12, we’ve expanded the components you can disable to include the console operator, Insights operator, cluster storage operator, and cluster CSI snapshot controller operator. You disable these features by setting the baselineCapabilitySet and additionalEnabledCapabilities parameters in the install-config.yaml configuration file prior to installation. If you disable any of these capabilities during the installation, you can enable them after the cluster is installed. Removing these capabilities from the cluster will require you to provide alternatives if and when they are required by other parts of Openshift or for your workloads.

To further make OpenShift more flexible, Operator Lifecycle Manager (OLM) introduces a new type of Operator called platform Operators, which is available as Technology Preview. A platform Operator is an OLM-based Operator that is installed during or after the initial cluster installation and participates in the cluster’s lifecycle. Through the platform Operator mechanism, you can customize your OpenShift deployment to specify which OLM-based Operators are installed at cluster installation time and block cluster rollout if the Operator fails to install successfully. In OpenShift 4.12, in this Technology Preview feature, we focus on the basic platform Operator mechanism to build a foundation for expanding the concept in upcoming releases.

Manage firewall configurations at the node level

OpenShift 4.12 introduces a new stateless Ingress Node Firewall Operator. Administrators configure firewall rules at the node level to control the flow of network traffic to/from the node by controlling which interface and remote hosts the Kubernetes API server can be accessed from. For more information, see Understanding the Ingress Node Firewall Operator.

Dynamically scale the Ingress Controller (Technology Preview)

You can now use the Custom Metrics Autoscaler Operator to dynamically scale the default Ingress Controller based on metrics in your deployed cluster, such as the number of worker nodes available. The Custom Metrics Autoscaler is available as a Technology Preview feature.

OpenShift in vSphere is zone aware (Technology Preview)

Beginning in OpenShift 4.12, we’re introducing the ability to install OpenShift zonal clusters in vSphere using installer provisioned infrastructure (IPI) as a Technology Preview feature. This feature leverages VMware vCenter tags to associate those tags with openshift-regions and openshift-zones. Now customers can associate vCenter datacenters with openshift regions, or vCenter clusters with openshift-zones.

screenshot of zone awareness in vSphere

Zone aware OpenShift in vSphere

In conjunction, we’ve added support for the vSphere Container Storage Interface (CSI) topology in OpenShift 4.12. This means you can define zones across compute clusters and ensure persistent volumes (PVs) are stored in the same datastore zone as the worker running the pod.

Install in Google Cloud Platform into a shared VPC (Technology Preview)

You can now deploy OpenShift cluster(s) into a shared Virtual Private Cloud (VPC) in Google Cloud Platform (GCP) using Installer Provisioned Infrastructure (IPI). This feature is available as a Technology Preview with OpenShift 4.12. With this installation method, you configure the cluster to use an existing shared VPC from a different GCP project. To learn more, see Installing a cluster on GCP into a shared VPC.

Install OpenShift on Nutanix AOS with OpenShift Assisted Installer

You can now use the OpenShift Assisted Installer, a web-based OpenShift installation solution, to deploy OpenShift on Nutanix AOS. You now have full control with user-provisioned infrastructure using the Assisted Installer, in addition to the full stack automation with installer-provisioned infrastructure on Nutanix AOS. Get started today at Red Hat Hybrid Cloud Console.

screenshot of Nutanix OpenShift integrations

Install OpenShift on Nutanix with Assisted Installer

Run Windows workloads in Google Cloud Platform

In OpenShift 4.12, you can now run Windows container workloads on OpenShift in Google Cloud Platform (GCP). Run Windows workloads by using the Red Hat Windows Machine Config Operator (WMCO) to install and manage Windows machines running in GCP.

Unified OpenShift CLI delivery with OpenShift CLI Manager (Technology Preview)

We’re improving how Kubernetes CLI developers can deliver their CLI, and OpenShift administrators can download the Kubernetes CLI with OpenShift CLI Manager, which is available as a Technology Preview in OpenShift 4.12. The OpenShift CLI Manager, based on Krew, eases the burden of the OpenShift administrators, who no longer have to worry about managing different lifecycles for the various Kubernetes CLIs. With Openshift 4.12, Openshift administrators can only download the Kubernetes CLI via krew-index . In the future, we plan to deliver OpenShift CLI via Krew.  

Container Storage Interface updates

In OpenShift 4.12, Container Storage Interface (CSI) updates include general availability for CSI Migration for Google Compute Engine (GCE) Persistent Disk and CSI Migration for Amazon Elastic Block Store (EBS).  We have also added support for the CSI operator for Google Cloud Platform (GCP) Filestore, which is available as a Technology Preview feature. Refer to CSI drivers supported by OpenShift Container Platform for the list of supported CSI drivers.

Custom tags for OpenShift in AWS

Many customers have asked for the ability to define user-defined tags to keep track of resources created by OpenShift at install time and during continuous operations for chargeback and access control purposes.  With OpenShift 4.12, you can define up to 25 user-defined tags in OpenShift clusters in AWS.

Multi-network-policy supported for SR-IOV (Technology Preview)

OpenShift Container Platform 4.12 adds support for configuring multi-network policy for SR-IOV devices. You can now configure multi-network for SR-IOV additional networks. Configuring SR-IOV additional networks is a Technology Preview feature and is only supported with kernel network interface cards (NICs). See Configuring multi-network policy for how to take advantage of this new capability.

Troubleshoot network issues with OpenShift Network Observability Operator

The OpenShift Network Observability Operator is now generally available in OpenShift 4.12. This operator provides a set of tools for monitoring and observability of network traffic for identifying network bottlenecks, troubleshooting connectivity issues, and optimizing network performance in OpenShift clusters. Check out the  Network Observability guide in addition to the OpenShift product documentation for further information.

visualizations from the OpenShift Network Observability Operator

OpenShift network observability

Improve your security posture using the Security Profiles Operator

The Security Profiles Operator (SPO) exposes the power of SELinux, seccomp, and AppArmor to end users. The technologies are not mutually exclusive, and these are combined in the SPO to make it easier to consume. Seccomp reduces the chance that a kernel vulnerability will be successfully exploited, whereas SELinux and AppArmor prevent applications from accessing files they should not. Get started today with understanding the Security Profiles Operator.

Build and deploy serverless services

OpenShift Serverless 1.27, based on Knative version 1.6, is now generally available. This release boasts serverless functions with Quarkus, support for Persistent Volume Claim (PVC) and General Availability of Kafka Broker and Kafka Sink with FIPS mode enabled. For security, we have added the TLS authentication for internal traffic natively as a Tech Preview feature. You will also find our upgraded Developer Preview of serverless logic, which offers workflow capabilities for orchestration of services and functions for event-driven applications.

Deliver bespoke user experiences

Dynamic Plugins has been promoted to General Availability in OpenShift 4.12. This enables partners and customers to build high quality, unique user experiences natively in the OpenShift Console. This feature allows you to create new pages, navigation items, tab resources, and more. The sky is truly the limit with Dynamic plugins. Clone the OpenShift Console Plugin Template to get started.

Insights recommendation as Prometheus alerts

With the latest release, Insights Advisor for OpenShift provides Insights recommendations as Prometheus alerts. Insights uses predictive analytics and deep domain expertise to reduce complex operational tasks from hours to minutes, including identifying security and performance risks. You now can be proactively notified of active Insights recommendations, in addition to seeing them in the OpenShift Console.

Deliver small footprint Kubernetes at the edge with Red Hat Device Edge (Developer Preview)

With OpenShift 4.12, customers and partners can now deploy production grade Kubernetes to resource constrained edge devices, providing greater consistency for edge deployments using Red Hat Device Edge, which is now available as a Developer Preview.

Red Hat Device Edge, includes MicroShift, an Kubernetes distribution derived from OpenShift. Red Hat Device Edge enables customers and partners to deploy traditional or containerized workloads on small form factor edge devices, such as robots, drones, internet of things (IoT) gateways, points of sale, public transport, and more. Customers like Lockheed Martin are leveraging Red Hat Device Edge to modernize and standardize its application delivery and artificial intelligence (AI) workloads in extreme conditions including wildland fire management, contested military environments, and space. In addition, ABB uses Red Hat Device Edge for ABB Ability™ Edgenius™ to streamline the transition from automated to autonomous operations for the manufacturing industry. Start your journey with Red Hat Device Edge by taking a look at the documentation and Getting started with MicroShift.

Secure Kubernetes deployments in minutes

Last but not least, we recently announced the service preview for Red Hat Advanced Cluster Security Cloud Service. With fully-managed Advanced Cluster Security as a service, you install minimal software on supported Kubernetes clusters across your hybrid cloud, and start securing the cluster in minutes. This is available through our early access program to Red Hat customers as a trial. Request early access to Red Hat Advanced Cluster Security Cloud Service today!

Try OpenShift 4.12 Today!

Beyond what’s highlighted in this blog, check out the following resources to learn more about the new OpenShift 4.12 release:

Thank you for reading about what’s new in OpenShift 4.12. Please comment or send us feedback either through your usual Red Hat contacts or as an issue on OpenShift on GitHub.


About the author

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.

Read full bio