What you need to know about Red Hat OpenShift 4.16

Red Hat OpenShift 4.16 is currently accessible to all users. OpenShift 4.16, which is based on CRI-O 1.29 and Kubernetes 1.29, gives security, virtualization, edge computing, and telecom features a top priority. Red Hat OpenShift is a platform that is reliable, comprehensive, and consistent and seeks to accelerate contemporary application development and delivery at scale across hybrid clouds.

For Red Hat OpenShift 4.14 and later, a three-year lifecycle

For Red Hat OpenShift 4.14 and all upcoming even-numbered versions, an optional extra 12-month Extended Update Support (EUS) term is now offered as an add-on subscription. Red Hat OpenShift EUS releases now have a 3-year full lifetime available, up from the prior 6-month EUS term. For more information, see the Red Hat OpenShift Container Platform Life Cycle Policy.

Use Red Hat Advanced Cluster Security Cloud Service to scale security by making a left shift.

The Red Hat Advanced Cluster Security Cloud Service is currently being marketed as being generally available instead of limited. A fully managed Kubernetes-native security cloud service, Red Hat Advanced Cluster Security Cloud Service supports non-Red Hat Kubernetes platforms like Amazon EKS, Google GKE, and Microsoft AKS in addition to Red Hat OpenShift. Regardless of the underlying Kubernetes platform, this cloud service enables you to design, deploy, and maintain cloud-native apps at scale across the hybrid cloud using a security-forward methodology.

Hosted control planes in AWS that may be handled independently can save costs and expedite the construction of clusters.

Since version 2.4, the multicluster engine (MCE) for the Kubernetes operator has by default enabled hosted control planes. Self-managed hosted control planes on AWS are generally accessible with Red Hat OpenShift 4.16, starting with MCE version 2.6.

Multiple OpenShift clusters can be managed more effectively and economically at scale with the use of hosted control planes. It simplifies maintenance, improves resource efficiency, and centralizes control plane management. By decreasing infrastructure overhead, managing overhead, maximizing cluster deployment time, and facilitating the division of responsibilities between management and workloads, hosted control planes allow you to concentrate on applications.

Red Hat OpenShift on AWS with hosted control plane and external auth servers

Red Hat OpenShift Service on AWS (ROSA) now allows you to use your own OpenID Connect (OIDC) solution with hosted control planes, enabling you to authenticate users and groups with the Kubernetes API server directly. AWS Security Token Service (STS) and OIDC are used by ROSA clusters to provide in-cluster operators with access to the AWS resources they require. Find out more at Using external OIDC to streamline access to your ROSA clusters.

Using an admin network policy, secure networking for OpenShift clusters

OpenShift installations utilizing OVN-Kubernetes for networking now fully support the next version of the Kubernetes Network Policy. The prior Network Policy implementation from the upstream is improved by Admin Network Policy, also referred to as Global Network Policy. The most often requested features are as follows:

• Network security policies that are administrator-only and cannot be altered by developers or namespace administrators
• A scope throughout the cluster. For instance, all cluster traffic can have its egress regulations established once, in a single location.
• Namespace administrators and developers should be able to assign specific, approved security policies to them, giving them the network policy flexibility necessary for application development.

With the Admin Network Policy, you can:

• Within a cluster, isolate tenants using admin-privileged control.
• Make a final allow-list for traffic that needs to pass through at all times.
• Indicate an unchangeable policy for every cluster outflow communication. One option is to compel all traffic to pass via a gateway device so that it may be inspected.
• For extremely specialized patterns of traffic, especially to and from sensitive namespaces, establish highly specific network traffic controls.

Cut down on unauthorized individual or group access

The permissions granted to the system: anonymous user and system: unauthenticated group is limited as of OpenShift 4.16. By default, just two roles are permitted:
• Public information viewer (system:open shift:) needed for OIDC processes
• system:public-info-viewer: read-only access to the cluster’s non-sensitive data

This is exclusive to new clusters. Upgraded clusters remain unaffected.

In use cases that require anonymous access, those permissions must be added directly by the cluster administrator. For instance, you would need to specifically add system: webhook permissions if you were using webhooks for BuildConfigs from an external system (such as GitHub) that did not support transmitting auth tokens over HTTP. In such cases, we strongly advise against using cluster role bindings and instead use local role bindings. When necessary, a cluster administrator might assess the advantages and disadvantages of adding back a ClusterRoleBinding for the anonymous user.

Simpler debugging of OpenShift updates using the oc adm upgrade status

A new oc adm upgrade status command is included in Red Hat OpenShift 4.16 and is available as a technology preview. This command shows the administrator whether the upgrade is proceeding well or whether they need to step in by displaying the cluster update progress and filtering out unnecessary noise. When an update problem arises, the command provides details about the situation along with advice and pointers to pertinent resources (such as Red Hat documentation or knowledge base articles).

Transitioning in-place to Microsoft Entra Workload ID

With the least amount of downtime possible, you may now switch from self-managed Red Hat OpenShift on Azure to Microsoft Entra Workload ID (previously Azure AD Workload Identity). Red Hat OpenShift 4.14 adds support for Microsoft Entra Workload ID, allowing users to establish and operate Red Hat OpenShift clusters using temporary, limited privilege credentials. It is now possible to use Microsoft Entra Workload ID without requiring a fresh cluster installation. For more information, see Configuring OpenShift with Microsoft Entra Workload ID.

Utilize etcd tuning options to maximize cluster performance.

Now that etcd has been updated, you can let your cluster accept lower latency between etcd members. In order to achieve this, you set the leader election timeout and heartbeat interval latency parameters to values that minimize latency and maximize performance. The following values are possible:
• (blank by default)
• Normal
• More Slowly

This lets you handle situations where your disks are slower but still functional, or where your clusters are stretched but still adhere to OpenShift’s best practices for performance and scalability.

For further details, see the etcd standard.

Adapt cluster autoscaling to workload requirements.

The LeastWaste, Priority, and Random expander techniques are now used by the cluster autoscaler. When scaling your cluster, you can set these expanders to affect which machine sets are chosen.
• Random: Suggested for uniformly allocating tasks within a homogeneous cluster in which the node groups provide comparable resources
• LeastWaste: For clusters that prioritize effectiveness and reducing waste of resources, especially when dealing with dynamic workloads where flexibility and quick scaling are more crucial
• Priority: It is appropriate for complicated clusters with distinct node groups and offers a range of scaling options depending on user-defined priorities.

Bring your own load balancer when using an on-premises one.

Red Hat OpenShift 4.16 allows you to leverage any on-premises infrastructure (bare metal, VMware vSphere, Red Hat OpenStack Platform, Nutanix, and more) with a cluster and your own user-managed load balancer. The load-balancer.type: UserManaged configuration for this setup is found in the cluster’s install-config.yaml file. For additional information on this functionality, see services for a user-managed load balancer.

Increase the observability of your cluster with sophisticated monitoring and troubleshooting.

Red Hat OpenShift 4.16 brings major improvements to its observability features, including better tools for cluster monitoring, troubleshooting, and optimization. Prometheus, Thanos, and new alerting rules are among the in-cluster monitoring stack components that have been updated. Metrics collecting is made easier with the new Metrics Server, and security and teamwork are improved with the new monitoring-alert manager-view role. These functionalities are included in the Cluster Observability Operator version 0.3.0, which serves as a single entry point operator for setting up and managing observability. This release also improves OpenTelemetry and gives the Cluster Logging API more functionality.

Cluster Observability Operator offers improvements to distributed tracing with Tempo Operator support for the monolithic deployment, a new version of Observability Signal Correlation for correlating observability signals, and Incident Detection for prioritizing critical warnings. OpenShift console now shows visuals for distributed tracing.

Observability Both Signal Correlation and Incident Detection have developer previews available. Power monitoring now offers a developer user interface (UI) integration and enhances data accuracy; it is available for technology preview.

Red Hat OpenShift Virtualization can help you modernize your infrastructure administration.

Regarding Red Hat OpenShift Virtualization, we are happy to announce that metro disaster recovery is now generally available for virtual machines (VMs) that use Red Hat Advanced Cluster Management for Kubernetes (RHACM) for management in conjunction with storage deployed on Red Hat OpenShift Data Foundation.

We’ve improved the VM in several ways. Now, you can declaratively add more vCPU resources to a virtual machine that is currently operating. Safe memory overcommit improves memory density, while CPU hotplug makes it simpler to scale up virtual machines.

You may now monitor multi-cluster virtual machines (VMs) with RHACM. From a RHACM Hub, you can view every virtual machine (VM) in every OpenShift cluster. For each virtual machine, you may easily compile and create reports. By using Global Hub Search, you can see every virtual machine (VM) at an RHACM Global Hub spread over many hubs.

Along with hardware partners, storage and network infrastructure partners, and third-party data protection providers, the ecosystem is still expanding. Apart from Veeam Kasten, Trilio, and Storaware, Cohesity, Commvault, Rubrik, and Veritas will soon offer more features.

Utilizing Lifecycle Agent for image-based updates on single-node OpenShift clusters

Red Hat’s telecom partners are moving away from single-node OpenShift solutions and toward containers for Radio Access Networks (RAN). Red Hat OpenShift 4.16 uses image-based updates (IBU) and takes a “shift left” strategy. In order to minimize the amount of time spent updating at the production site, IBU offers a different method for upgrading an OpenShift cluster with a single node. Single-node OpenShift users transfer a significant percentage of the update process to a pre-production environment.

Z-stream updates, minor version updates, and direct EUS-to-EUS upgrades—which exclude the interim version—can all be carried out with IBU. This update technique installs a dedicated seed cluster as a new ostree state root on the target single node OpenShift cluster and uses the Lifecycle Agent to produce an OCI image from it. A seed cluster is an OpenShift cluster consisting of one node that has been deployed with the desired version of the OpenShift Container Platform, together with common configurations and operators that are used by all target clusters. Next, on every OpenShift cluster with a single node that shares the same hardware, operators, and cluster configuration as the seed cluster, you utilize the seed image to upgrade the platform version.

Furthermore, the application can be rolled back to its pre-update state in the event that an update fails or it does not resume operating. Note that OpenShift clusters with a single node are the only ones that can use this capability. In the event that the update is successful or unsuccessful, this guarantees that service is returned as soon as feasible. IBU is easily included in the Red Hat Advanced Cluster Management and OpenShift GitOps-based Zero Touch Provisioning processes.

Construct scalable, self-contained OpenShift appliances

Technology Preview access to the OpenShift-powered Appliance Builder is now possible. This allows partners to create bespoke turnkey appliances with self-contained OpenShift and other services on their recommended hardware at scale. A container-based tool called the OpenShift-based Appliance Builder creates a disk image including the Agent-based Installer, which is needed to set up several OpenShift clusters. See the OpenShift-based Appliance Builder User Guide for additional information.

Improved EUS updates for MicroShift, GitOps management, and networking

Three modifications have been added to the Red Hat build of MicroShift in the most recent release to improve edge management:

1. Add several network interfaces to each pod. MicroShift’s Multus CNI: Multus makes it possible for Kubernetes pods to connect to several networks, which is advantageous if you employ SR-IOV or have intricate VLAN setups. Using CNI plugins bridge, macvlan, or ipvlan, you can quickly add multiple interfaces to pods when Multus is enabled on MicroShift.

2. Use GitOps for MicroShift to automate infrastructure and application management. This tool allows you to uniformly configure and deploy Kubernetes-based applications and infrastructure across clusters and development lifecycles. Based on the Red Hat OpenShift GitOps Operator, GitOps with Argo CD for MicroShift is a small, add-on controller. Through the Argo CD command-line interface, GitOps for MicroShift interfaces with the declarative GitOps engine, the GitOps controller.

3. Upgrade MicroShift straight from Extended User Support (EUS) version 4.14 to version 4.16 with only one reboot (Red Hat Enterprise Linux 9.4 must be installed for version 4.16 to work).