Red Hat OpenShift 4.16: What you need to know

Red Hat OpenShift 4.16 is now generally available. Based on Kubernetes 1.29 and CRI-O 1.29,  OpenShift 4.16 focuses on the core, security, virtualization, and capabilities for telecommunications and edge computing. Red Hat OpenShift aims to accelerate modern application development and delivery at scale across the hybrid cloud through a trusted, comprehensive and consistent platform.

3 year lifecycle for Red Hat OpenShift 4.14 and beyond

Available as an add-on subscription, there's now an optional additional 12 months Extended Update Support (EUS) term for Red Hat OpenShift 4.14 and all subsequent even-numbered releases. This takes the full lifecycle available for these EUS releases of Red Hat OpenShift to 3 years, extended from the previous 6 month EUS term. Refer to Red Hat OpenShift Container Platform Life Cycle Policy for additional details.

Shift left and scale security with Red Hat Advanced Cluster Security Cloud Service

Red Hat Advanced Cluster Security Cloud Service is now promoted from limited availability to general availability. Red Hat Advanced Cluster Security Cloud Service is a fully managed Kubernetes-native security cloud service supporting both Red Hat OpenShift as well as non-Red Hat Kubernetes platforms, including Amazon EKS, Google GKE and Microsoft AKS. This cloud service lets you  take a security-forward approach to building, deploying, and maintaining cloud-native applications at scale across the hybrid cloud, regardless of the underlying Kubernetes platform.

Reduce cost and optimize cluster deployment time with self-managed hosted control planes in AWS

Hosted control planes have been enabled by default in the multicluster engine (MCE) for Kubernetes operator since version 2.4. With MCE version 2.6, self-managed hosted control planes in AWS are generally available alongside Red Hat OpenShift 4.16.

Hosted control planes make it more efficient and cost effective for you to manage multiple OpenShift clusters at scale. It centralizes the control plane management and allows for better resource utilization and simpler maintenance. With hosted control planes, you get to focus on applications by reducing infrastructure overhead, management overhead, optimizing cluster deployment time, and enabling separation of concerns between management and workloads.

External auth servers in Red Hat OpenShift on AWS with hosted control plane

You can now bring your own OpenID Connect (OIDC) solution to Red Hat OpenShift Service on AWS (ROSA) with hosted control planes, so you can authenticate users and groups directly with the Kubernetes API server. ROSA clusters use AWS Security Token Service (STS) and OIDC to grant in-cluster operators access to necessary AWS resources. Learn more at Simplify access to your ROSA clusters using external OIDC | Red Hat Developer.

Secure OpenShift cluster networking with Admin Network Policy

The next generation of Kubernetes Network Policy is now fully supported in OpenShift deployments using OVN-Kubernetes for networking. Admin Network Policy (also known as Global Network Policy) provides enhancements to the upstream's previous Network Policy implementation. The most requested features include:

• Administrator-privileged-only network security policies that cannot be overridden by namespace admins and developers
• A cluster-wide scope. For example, egress policies can be defined a single time in one place and apply to all cluster traffic
• The ability to delegate specific, vetted security policy to namespace administrators and developers, so they have the network policy flexibility they need for application development

The Admin Network Policy allows you to:

• Isolate tenants within a cluster with admin-privileged control
• Create a definitive allow-list for traffic that must always flow
• Specify an immutable policy for all cluster egress traffic. For example, you can force all traffic through a gateway device for inspection
• Define network traffic policy with fine resolution for highly selective traffic patterns, especially to and from sensitive namespaces

Reduce unauthenticated user or group access

Beginning with OpenShift 4.16, there's a limit on the permissions given to the system:anonymous user and system:unauthenticated group. Only two roles are allowed by default:

• system:openshift:public-info-viewer: required for OIDC workflows
• system:public-info-viewer: read-only access to non-sensitive information about the cluster

This applies to new clusters only. Clusters that are upgraded are not affected.

For use cases where anonymous access is needed, the cluster administrator must explicitly add those permissions. For example, if you're using webhooks for BuildConfigs from an external system (like GitHub) that don't support sending auth tokens over HTTP, then you'd need to explicitly add system:webhook permissions. We strongly recommend using local rolebindings instead of clusterrole bindings in such scenarios. A cluster administrator can add back a ClusterRoleBinding for the anonymous user as needed, after evaluating the risks and benefits associated with it.

Easier OpenShift update troubleshooting with oc adm upgrade status

Red Hat OpenShift 4.16 includes a new oc adm upgrade status command, which is available as a technology preview. This command displays cluster update progress, eliminating irrelevant noise, and shows the admin whether the update is going well or whether they need to intervene. In the event of an update issue, the command returns information about what's happening, accompanied with guidance and links to relevant resources (such as Red Hat documentation or knowledge base articles).

oc adm upgrade status
undefinedAn update is in progress for 55m7s: Working towards 4.16.0: 198 of 951 done (20% complete)
undefined= Control Plane =
undefinedAssessment:  Progressing
undefinedCompletion:  97%
undefinedDuration:  55m6.974951563s
undefinedOperator Status: 36 Total, 36 Available, 1 Progressing, 0 Degraded
undefined= Worker Upgrade =
undefined= Worker Pool =
undefinedWorker Pool: worker
undefinedAssessment:  Progress
ingundefinedCompletion:  7%
undefinedWorker Status: 42 Total, 22 Available, 20 Progressing, 39 Outdated, 19 Draining, 0 Excluded, 0 
Degraded
undefinedWorker Pool Node(s)
NAME                                       ASSESSMENT    PHASE      VERSION       EST    MESSAGE 
build0-gstfj-ci-builds-worker-b-25ptt      Progressing   Draining   4.16.0-ec.3   +30m   
build0-gstfj-ci-longtests-worker-b-ppxvc   Progressing   Draining   4.16.0-ec.3   +30m   
build0-gstfj-ci-prowjobs-worker-b-gvthg    Progressing   Draining   4.16.0-ec.3   +30m   
build0-gstfj-ci-tests-worker-b-7hvhq       Progressing   Draining   4.16.0-ec.3   +30m   
... 
Omitted additional 32 Total, 3 Completed, 22 Available, 10 Progressing, 29 Outdated, 9 Draining, 0 
Excluded, and 0 Degraded nodes.
Pass along --details to see all information. 
= Update Health = 
SINCE   LEVEL   IMPACT   MESSAGE 
55m7s   Info    None     Upgrade is proceeding well

In-place migration to Microsoft Entra Workload ID

If you're using self-managed Red Hat OpenShift on Azure, then you can now migrate to Microsoft Entra Workload ID (formerly Azure AD Workload Identity) with minimal downtime. Microsoft Entra Workload ID support was added in Red Hat OpenShift 4.14, which provides customers a way to create and manage Red Hat OpenShift clusters with temporary, limited privilege credentials. Now you can adopt Microsoft Entra Workload ID without having to start over with a new cluster. See Configuring OpenShift with Microsoft Entra Workload ID for details.

Optimize cluster performance with etcd tuning parameters

You can now update etcd to allow your cluster to tolerate decreased latency between etcd members. To do this, you set the latency parameters for the heartbeat interval and leader election timeouts to values that optimize performance and decreased latency. The possible values are:

• "" (the default is blank)
• Standard
• Slower

This allows you to accommodate scenarios where you may have slower but acceptable disks, or stretched clusters that fall within the OpenShift performance and scalability best practices.

Refer to the etcd specification for more information.

Optimize cluster autoscaling according to workload needs

The cluster autoscaler now uses the LeastWaste, Priority, and Random expander strategies. You configure these expanders to influence the selection of machine sets when scaling your cluster.

• Random: Recommended for distributing workloads evenly across a homogenous cluster where the node groups offer similar resources
• LeastWaste: For clusters where efficiency and minimizing resource waste are priorities, particularly with dynamic workloads where rapid scaling and flexibility are more important
• Priority: For sophisticated scaling decisions based on user-defined priorities, and it is suitable for complex clusters with diverse node groups

Bring your own load balancer for on-premises deployment

With Red Hat OpenShift 4.16, you can use your own user-managed load balancer in conjunction with a cluster on any on-premises infrastructure (bare metal, VMware vSphere, Red Hat OpenStack Platform, Nutanix, and more). For this configuration, you specify loadBalancer.type:UserManaged in your cluster's install-config.yaml file. See services for a user-managed load balancer to learn more about this feature.

Boost your cluster observability with advanced monitoring and troubleshooting

Red Hat OpenShift 4.16 introduces significant enhancements to its observability capabilities, providing improved tools for monitoring, troubleshooting, and optimizing a cluster. There have been updates to in-cluster monitoring stack components such as Prometheus, Thanos, and new alerting rules. A new Metrics Server simplifies metrics collection, and the new monitoring-alertmanager-view role enhances security and collaboration. These features are included in the Cluster Observability Operator version 0.3.0, which serves as a single entry point operator for installing and managing observability. This release also adds improvements to OpenTelemetry and increased Cluster Logging API functionality.

Cluster Observability Operator introduces a new version of Observability Signal Correlation for correlating observability signals, Incident Detection for prioritizing critical alerts, and enhancements to distributed tracing with Tempo Operator support for the monolithic deployment. Distributed tracing visualizations are now displayed in the OpenShift console.

Observability Signal Correlation and Incident Detection are both available for developer preview. Power monitoring, which is available for technology preview, now provides a developer user interface (UI) integration and improves data accuracy. 

Modernize your infrastructure management with Red Hat OpenShift Virtualization

On the Red Hat OpenShift Virtualization front, we’re pleased to announce the general availability of metro disaster recovery for virtual machines (VMs) which use storage deployed on Red Hat OpenShift Data Foundation in conjunction with Red Hat Advanced Cluster Management for Kubernetes (RHACM) for management.

We’ve added a number of VM enhancements. You now have the ability to add additional vCPU resources to a running VM in a declarative manner. There's improved memory density with safe memory overcommit, and we've made it easier to scale up VMs with CPU hotplug.

Using RHACM, you're now able to monitor multi-cluster VMs. From a RHACM Hub, you're able to view all VMs across multiple OpenShift clusters. You can collect and quickly build reports for all VMs. At a RHACM Global Hub using Global Hub Search, you're able to view all VMs across multiple hubs.

The ecosystem continues to grow with hardware partners, storage and network infrastructure partners, as well as third-party data protection providers. In addition to Veeam Kasten, Trilio, and Storaware, there are upcoming capabilities from Cohesity, Commvault, Rubrik, and Veritas.

Image-based update for single-node OpenShift clusters using Lifecycle Agent

Red Hat's telecommunication partners are shifting to use containers for Radio Access Networks (RAN), deploying solutions on single node OpenShift. Red Hat OpenShift 4.16 features a "shift left" approach with image-based updates (IBU). IBU provides an alternative way to update a single node OpenShift cluster, whereby single node OpenShift users shift a large portion of the update process to a pre-production environment to reduce the time spent updating at the production site.

IBU allows you to perform z-stream updates, minor version updates, as well as direct EUS-to-EUS update, where the interim version is skipped. This update method utilizes the Lifecycle Agent to generate an OCI image from a dedicated seed cluster that is installed on the target single node OpenShift cluster as a new ostree stateroot. A seed cluster is a single node OpenShift cluster deployed with the target OpenShift Container Platform version, deployed operators, and configurations that are common to all target clusters. You then use the seed image to update the platform version on any single node OpenShift cluster that has the same combination of hardware, operators, and cluster configuration as the seed cluster.

In addition, if an update fails or the application does not return to a functioning state, it can be rolled back to the pre-update state – note: this applies only to single node OpenShift clusters. This ensures service is restored as quickly as possible in either an update success or failure scenario. IBU is seamlessly integrated into the Zero Touch Provisioning flows that use Red Hat OpenShift GitOps and Red Hat Advanced Cluster Management.

Build self-contained OpenShift appliance at scale

Partners who want to build customized turnkey appliances with self-contained OpenShift and added services on their prescribed hardware at scale can now do so using the OpenShift-based Appliance Builder, which is available for Technology Preview. The OpenShift-based Appliance Builder is a container-based utility that builds a disk image that includes the Agent-based Installer, which is used to install multiple OpenShift clusters. Refer to the OpenShift-based Appliance Builder User Guide for more information.

Enhanced networking, GitOps management, and seamless EUS Updates for MicroShift

For the Red Hat build of MicroShift, the latest release introduces three updates to enhance edge management:

1. Attach multiple network interfaces to pods Multus CNI for MicroShift: Multus enables Kubernetes pods to attach to multiple networks, which is useful when you use SR-IOV or have complex VLAN configurations. With Multus enabled on MicroShift, you can easily add multiple interfaces to pods using CNI plugins bridge, macvlan, or ipvlan
2. Automate infrastructure and application management with GitOps for MicroShift: With GitOps for MicroShift, you can consistently configure and deploy Kubernetes-based infrastructure and applications across clusters and development lifecycles. GitOps with Argo CD for MicroShift is a lightweight, optional add-on controller derived from the Red Hat OpenShift GitOps Operator. GitOps for MicroShift uses the Argo CD command-line interface to interact with the GitOps controller that acts as the declarative GitOps engine
3. Direct EUS updates for MicroShift: MicroShift now directly updates from Extended User Support (EUS) version 4.14 to version 4.16 in a single reboot (Red Hat Enterprise Linux 9.4 is required for version 4.16)

Try Red Hat OpenShift 4.16 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
• OpenShift YouTube Channel
• OpenShift Blogs
• OpenShift Commons
• Red Hat Developer Blogs
• Red Hat Portfolio Architecture Center

A complete list of the Red Hat OpenShift 4.16 updates are in the Red Hat OpenShift 4.16 Release Notes. Send us feedback through your Red Hat contacts, message us at OpenShift Commons slack, or create an issue on GitHub.