Search

What you must be familiar with

Share it

Red Hat OpenShift 4.16 has been officially released. Operating on Kubernetes 1.29 and CRI-O 1.29, OpenShift 4.16 emphasizes the core foundation, security features, virtualization capabilities, and enhancements tailored for telecommunications and edge computing. Red Hat OpenShift is designed to expedite modern application development and deployment on a large scale across hybrid cloud environments, offering a trustworthy, comprehensive, and uniform platform.

3 year lifespan for Red Hat OpenShift 4.14 and beyond

As an optional add-on subscription, there is now an extended 12 months of Extended Update Support (EUS) available for Red Hat OpenShift 4.14 and all subsequent even-numbered releases. This prolongs the lifespan of these EUS versions of Red Hat OpenShift to 3 years, up from the previous 6-month EUS term. Refer to Red Hat OpenShift Container Platform Life Cycle Policy for more information.

Prioritize Security Measures with Red Hat Advanced Cluster Security Cloud Service

Red Hat Advanced Cluster Security Cloud Service has transitioned from a limited availability status to general availability. This fully managed Kubernetes-native security cloud service supports both Red Hat OpenShift and non-Red Hat Kubernetes platforms, such as Amazon EKS, Google GKE, and Microsoft AKS. This service empowers a security-centric approach to constructing, deploying, and managing cloud-native applications at scale in hybrid cloud environments, regardless of the underlying Kubernetes platform.

Standalone control plane vs. hosted control planes

Decrease Cost and Streamline Cluster Deployment with Independent Hosted Control Planes in AWS

Hosted control planes have been activated by default in the multicluster engine (MCE) for Kubernetes operator starting from version 2.4. With MCE version 2.6, self-managed hosted control planes in AWS are now readily available in conjunction with Red Hat OpenShift 4.16.

Hosted control planes enhance efficiency and cost-effectiveness in managing multiple OpenShift clusters at scale. Centralizing control plane management aids in better resource utilization and easier maintenance. By leveraging hosted control planes, you can concentrate on applications, minimize infrastructure overhead, simplify cluster deployment processes, and establish a clear separation between management tasks and workloads.

Utilize External Authentication Servers in Red Hat OpenShift on AWS with Hosted Control Plane

Incorporate your OpenID Connect (OIDC) solution into Red Hat OpenShift Service on AWS (ROSA) with hosted control planes to authenticate users and groups directly through the Kubernetes API server. ROSA clusters utilize AWS Security Token Service (STS) and OIDC to grant in-cluster operators access to essential AWS resources. Explore Simplify access to your ROSA clusters using external OIDC for further details.

Ensure Secure OpenShift Cluster Networking with Admin Network Policy

Admin Network Policy (also known as Global Network Policy) is now fully supported in OpenShift deployments utilizing OVN-Kubernetes for networking, offering enhancements over the previous Network Policy implementation. Key features include:

  • Network security policies exclusive to administrators that cannot be overridden by namespace administrators or developers
  • Cluster-wide scope to enable centralized definition of egress policies applying to all cluster traffic
  • Delegating specific vetted security policies to namespace administrators and developers, granting the necessary network policy flexibility for application development

Admin Network Policy allows for:

  • Tenant isolation within a cluster with administrator-privileged control
  • Establishing a definitive allow-list for essential traffic flow
  • Defining immutable policy for all cluster egress traffic, e.g., routing all traffic through an inspection gateway device
  • Configuring network traffic policy with precise resolution for highly selective traffic patterns, especially to and from sensitive namespaces

Minimize Unauthorized Access by Users or Groups

Starting with OpenShift 4.16, limitations are imposed on the permissions granted to the system:anonymous user and system:unauthenticated group. By default, only two roles are permitted:

  • system:openshift:public-info-viewer: essential for OIDC workflows
  • system:public-info-viewer: permits read-only access to non-sensitive cluster information

This restriction applies exclusively to new clusters. Upgraded clusters remain unaffected. In scenarios necessitating anonymous access, the cluster administrator must explicitly assign relevant permissions. For instance, for utilizing webhooks for BuildConfigs from systems that can’t transmit auth tokens via HTTP, like GitHub, you must explicitly add system:webhook permissions. It’s advised to prefer local role bindings over cluster role bindings in such scenarios. Following a risk and benefit evaluation, a cluster administrator can reinstate a ClusterRoleBinding for the anonymous user if required.

Simplify OpenShift Update Troubleshooting with oc adm upgrade status

Red Hat OpenShift 4.16 introduces a new oc adm upgrade status command, accessible as a technology preview. This command monitors cluster update progress, filtering out irrelevant details to inform administrators about the status of the update process. In case of update complications, the command provides detailed feedback, guiding administrators with relevant resources like Red Hat documentation or knowledge base articles.

# oc adm upgrade status
An update is in progress for 55m7s: Working towards 4.16.0: 198 of 951 done (20% complete)
= Control Plane =
Assessment: Progressing
Completion: 97%
Duration: 55m6.974951563s
Operator Status: 36 Total, 36 Available, 1 Progressing, 0 Degraded
= Worker Upgrade =
= Worker Pool =
Worker Pool: worker
Assessment: Progressing
Completion: 7%
Worker Status: 42 Total, 22 Available, 20 Progressing, 39 Outdated, 19 Draining, 0 Excluded, 0 Degraded
Worker 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
...
Additional nodes omitted
Provide --details to view all information.
= Update Health =
SINCE LEVEL IMPACT MESSAGE
55m7s Info None Upgrade is proceeding well

Simplified Migration to Microsoft Entra Workload ID

For users of self-managed Red Hat OpenShift on Azure, migrating to Microsoft Entra Workload ID (formerly Azure AD Workload Identity) with minimal downtime is now possible. Support for Microsoft Entra Workload ID was added in Red Hat OpenShift 4.14, enabling customers to transition to this service without the need for recreating clusters. View Configuring OpenShift with Microsoft Entra Workload ID for detailed instructions.

Fine-Tune Cluster Performance with etcd Parameters

Customize etcd settings to enhance your cluster’s efficiency in tolerating reduced latency between etcd members. Adjust the heartbeat interval and leader election timeouts to optimize performance and reduce latency. Options include:

  • “” (default setting)
  • Standard
  • Slower

These settings cater to scenarios where slower but acceptable disks are involved, or in stretched clusters adhering to OpenShift’s performance and scalability guidelines.

Consult the etcd specification for additional details.

Maximize Cluster Autoscaling to Match Workload Requirements

The cluster autoscaler now implements the LeastWaste, Priority, and Random expander strategies. These expanders allow you to influence the selection of machine sets when scaling your cluster.

  • Random: Suitable for even workload distribution across homogenous clusters with node groups offering similar resources
  • LeastWaste: Ideal for clusters prioritizing efficiency and resource minimalism, especially with dynamic workloads requiring rapid scaling and flexibility
  • Priority: Suited for sophisticated scaling decisions based on user-defined priorities, valuable for complex clusters with diverse node groups

Implement Your Load Balancer for On-Premises Deployments

In Red Hat OpenShift 4.16, you can leverage your user-managed load balancer alongside a cluster on various on-premises infrastructures like bare metal, VMware vSphere, Red Hat OpenStack Platform, Nutanix, and more. For such setups, specify loadBalancer.type:UserManaged in your cluster’s install-config.yaml file. Refer to services for a user-managed load balancer to explore this feature further.

Enhance Cluster Observability with Advanced Monitoring and Troubleshooting Capabilities

Red Hat OpenShift 4.16 introduces significant advancements in its observability toolkit, providing enhanced tools for monitoring, diagnosing, and optimizing clusters. Updates have been made to in-cluster monitoring stack components like Prometheus, Thanos, and new alerting rules. A new Metrics Server simplifies metric collection, and the monitoring-alertmanager-view role enhances security and collaboration. These features are encompassed in the Cluster Observability Operator version 0.3.0, serving as a centralized operator for observability management. This release also introduces enhancements to OpenTelemetry and expands Cluster Logging API functionality.

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

Observability Signal Correlation and Incident Detection are both in the developer preview stage. Power monitoring, available in technology preview, now integrates a developer user interface (UI) and boosts data accuracy.

Modernize Infrastructure Management with Red Hat OpenShift Virtualization

Red Hat OpenShift Virtualization brings the metro disaster recovery feature for virtual machines (VMs) operating on storage deployed via Red Hat OpenShift Data Foundation, managed through Red Hat Advanced Cluster Management for Kubernetes (RHACM).

Several VM enhancements have been introduced, including the ability to add extra vCPU resources to a running VM declaratively. There’s increased memory density with safe memory overcommit, and scaling VMs with CPU hotplug has become more streamlined.

With RHACM, monitoring multi-cluster VMs is now possible. Through a RHACM Hub, all VMs across multiple OpenShift clusters can be monitored. VM data collection for comprehensive reporting is simplified. Utilizing the Global Hub Search in a RHACM Global Hub allows viewing all VMs across multiple hubs.

The ecosystem continues to expand with contributions from hardware partners, storage and network infrastructure partners, and third-party data protection providers. Alongside Veeam Kasten, Trilio, and Storaware, upcoming capabilities from Cohesity, Commvault, Rubrik, and Veritas are on the horizon.

Image-based Updates for Single-Node OpenShift Clusters with Lifecycle Agent

Telecommunication partners at Red Hat have begun transitioning to container usage for Radio Access Networks (RAN) by deploying solutions on single-node OpenShift. Red Hat OpenShift 4.16 introduces an “shift left” approach with image-based updates (IBU) for single-node OpenShift clusters, enabling a significant portion of the update process to be completed in a pre-production environment to reduce update duration at the production site.

IBU facilitates z-stream updates, minor version updates, and direct EUS-to-EUS updates, skipping intermediary versions. This update method leverages the Lifecycle Agent to create an OCI image from a specialized seed cluster installed on the target single-node OpenShift cluster as a new ostree stateroot. A seed cluster is a single-node OpenShift cluster configured with the target OpenShift Container Platform version, related operators, and common configurations across all target clusters. The seed image can then be used to update the platform version on any single-node OpenShift cluster sharing hardware, operator setup, and cluster configuration with the seed cluster.

In case of update failures or application malfunction post-update, a rollback to the pre-update state is feasible – please note, this feature only applies to single-node OpenShift clusters. This ensures swift service restoration in successful and unsuccessful update scenarios. IBU seamlessly integrates into Zero Touch Provisioning flows utilizing Red Hat OpenShift GitOps and Red Hat Advanced Cluster Management.

Create Scalable OpenShift Appliance at Volume

Partners aiming to develop customized turnkey appliances with self-contained OpenShift and additional services on specific hardware at scale can use the OpenShift-based Appliance Builder, available for Technology Preview. This container-based utility generates a disk image incorporating the Agent-based Installer to deploy multiple OpenShift clusters. For detailed guidelines, refer to the OpenShift-based Appliance Builder User Guide.

Enhanced Networking, GitOps Management, and Unified EUS Updates for MicroShift

In the latest release of the Red Hat build of MicroShift, three enhancements have been introduced to bolster edge management:

  1. Attach multiple network interfaces to pods Multus CNI for MicroShift: Multus facilitates Kubernetes pods to connect with multiple networks, valuable for scenarios involving SR-IOV or intricate VLAN setups. Through enabling Multus on MicroShift, adding multiple interfaces to pods using CNI plugins like bridge, macvlan, or ipvlan is straightforward
  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 stages. GitOps with Argo CD for MicroShift, derived from the Red Hat OpenShift GitOps Operator, is lightweight and serves as an optional add-on controller. Operate GitOps for MicroShift through Argo CD command-line interface, acting 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)

Experience Red Hat OpenShift 4.16 Today

Embark on your journey today with the Red Hat Hybrid Cloud Console and leverage the latest features and improvements in OpenShift. To learn more about upcoming developments, explore:

Comprehensive details on the Red Hat OpenShift 4.16 updates are detailed in the Red Hat OpenShift 4.16 Release Notes. Provide feedback through your designated Red Hat contacts, reach out via OpenShift Commons slack, or raise an issue on GitHub.

Source:

Red Hat OpenShift 4.16 Information Source

🤞 Don’t miss these tips!

🤞 Don’t miss these tips!

Solverwp- WordPress Theme and Plugin