Red Hat OpenShift 4.17: What you need to know

Red Hat OpenShift 4.17 is now generally available. Based on Kubernetes 1.30 and CRI-O 1.30,  OpenShift 4.17 features expanded control plane options, increased flexibility for virtualization and networking, new capabilities to leverage generative AI, and continued investment in Red Hat OpenShift Platform Plus. These additions further accelerate innovation with OpenShift without compromising on security. OpenShift provides a trusted, comprehensive, and consistent application platform enabling enterprises to innovate faster across the hybrid cloud. Available in self-managed or fully managed cloud service editions, OpenShift offers a complete set of integrated tools and services for cloud-native, AI, virtual, and traditional workloads alike.

Red Hat OpenShift 4.17 Highlights

Modernize your infrastructure management with Red Hat OpenShift Virtualization

For Red Hat OpenShift Virtualization, we've made several key capabilities generally available. Amongst the key capabilities is memory oversubscription to enable higher workload density. This is particularly useful for development and test environments, where you typically prioritize workloads over available physical memory. In conjunction, we’ve added memory hot pluggability that completes the dynamic reconfiguration capabilities for virtual machines. Specifically, this allows for on-the-fly adjustments to memory, complementing existing features for disks, network interfaces (NIC), and CPUs. As a result, you can now dynamically modify all key VM components without downtime, enhancing flexibility and resource management in virtualized environments.

Workload rebalancing has also been promoted to general availability, marking a significant enhancement in resource management. The descheduler dynamically moves both pods and virtual machines during ongoing operations, whether you're performing an OpenShift cluster upgrade, or starting or stopping workloads.

For storage, you can now perform live migration of virtual machine (VM) storage with a feature available for technology preview. This means you can non-disruptively move hot or cold persistent volumes on a running VM, so you can easily move data from one storage class to another. Migration Toolkit for Virtualization 2.7 also includes the ability to preserve static IP and drive letters for warm migrations.

For monitoring, we’re introducing a Virtual Admin Perspective in OpenShift Console to make it easier for you to find relevant views and tasks without distractions of unrelated cluster information. We’ve also expanded our fleet-wide monitoring of VMs across multiple clusters within Red Hat Advanced Cluster Management. These enhancements give you improved visibility, streamlined diagnostics, and proactive issue identification, which ultimately leads to more effective multi-cluster VM management with reduced downtime. These improvements include:

• Expanded operator health checks
• Filter and search VMs based on key attributes
• Detailed individual VM information with views of configuration, resource utilization, and alerts
• Dashboard views highlighting VM health, status, and alerts

Enable active-active OpenShift Virtualization deployments to support stateful workloads

We've also introduced the ability to have four and five-node control plane architectures for OpenShift on bare metal clusters. This is particularly important if you require active-active cluster deployments across two locations to support stateful, traditional applications. This is common for OpenShift Virtualization VMs that only run a single instance, and have dependencies on the underlying infrastructure to provide availability. A two-site scenario is a common architecture for VM deployments on traditional virtualization stacks and enhances the resiliency for such deployments.

For example, organizations often deploy OpenShift Virtualization stretched across two failure domains using a 3+2 control plane, or 5-nodes control plane configuration. This 5-nodes control plane configuration offers enhanced reliability and fault tolerance beyond the minimum 3-nodes control plane configuration, which makes it suitable for critical production environments where the ability to withstand multiple node failures or a domain failure is crucial. The 3+2 configuration strikes a balance between providing high availability and keeping the cluster architecture relatively simple to manage. If there is a domain failure in a  3+2 configuration, cluster stability is preserved. Specifically, if you lose the 2-node failure domain, quorum is retained. If you lose the 3-node failure domain, your cluster is still operational with the remaining 2-node control plane, however the cluster is now in a state with reduced redundancy and cannot tolerate another control plane node failure without losing quorum. The main advantage 3+2 provides over a 2+1 configuration is more robust protection and resiliency against multiple node failures or data corruption.

4 or 5 Node Highly Available Control Plane for Bare Metal Deployments

Enhance your productivity and efficiency with Red Hat OpenShift Lightspeed

Red Hat OpenShift Lightspeed is now available as a technology preview. OpenShift Lightspeed is a generative AI based conversational assistant for Red Hat OpenShift. Enabled through an Operator, OpenShift Lightspeed is fully integrated into the OpenShift web console. You need to provide your own large language model (LLM) subscription for Red Hat Enterprise Linux AI, Red Hat OpenShift AI, OpenAI, Microsoft Azure AI, or IBM watsonx. With OpenShift Lightspeed, you can pose OpenShift product-related questions directly to the AI assistant and troubleshoot problems. Learn more about the technology preview.

Minimize downtime with node disruption policies

The node disruption policies feature has been promoted to generally available. Historically, the main reason for reboots was to ensure your changes not only work but survive a restart. In general, if it’s going to fail, it’s better to fail fast and find out while it’s fresh. That said, we've heard many customers ask about reducing reboots. We acknowledge that cluster admins know best about when you need to reboot and when you don’t. For example, you don’t  need a reboot for trivial changes, such as updating sudo rules. Node disruption policies let you define a set of Red Hat Enterprise Linux CoreOS (RHCOS) configuration changes that require little or no disruption to your workloads. See Using node disruption policies to minimize disruption from machine config changes for more information.

Create multiple networks and isolation with native network isolation for namespaces

The first step in our Universal Connectivity plans is native network isolation for namespaces. Our mission is to provide seamless integration between OVN-Kubernetes, the default networking solution, and your external networks and targeted networking solutions crossing over that boundary. Native network isolation for namespaces, available as a technology preview, introduces user-defined networks (UDN).

Traditionally, a cluster pod network would be a monolithic Layer-3 network across cluster nodes. If you wanted a different network, you had to load one or more additional CNI plug-ins. Those secondary networks are good for some deployments, but they don’t have all the advantages of a Kubernetes primary network. Additionally, they can increase complexity and operational burden. Furthermore, not all of Kubernetes networking supports those Multus-enabled secondary networks.

With UDN and the recently added virtual routing and forwarding (VRF) support, you can now carve out additional, isolated-by-default, primary networks for your pods and VMs. There will always be a default network for Kubernetes control plane traffic like pod health checks, but you can think of a UDN as a tenant network, and each one can host multiple namespaces.  Pods and VMs designate a primary UDN, which is where all traffic flows by default, and then any number of additional UDNs after that. Each UDN can have a specific purpose of your designation.  All UDNs have support for clusterIP services and external services like the traditional Kubernetes primary network, and they fully support Kubernetes Network and Admin Network Policy.

Overlapping IPs within different UDNs are handled by OVN-Kubernetes so that tenants are independent.  We're not breaking your deployments currently using traditional Multus-enabled secondary networks, but we expect that new deployments will prefer to use UDNs to carve out those additional networks going forward.

You now have the ability to create a flat Layer-2 network as the primary network across your cluster for live migration of your VMs across nodes. You can also directly attach your VM or pod networks to a provider network.  In addition, you can have a combination of the two.

Native Network Isolation for Namespaces

In future releases, we plan to provide BGP and EVPN support so that your pods and VMs are directly addressable within the cluster without having to traverse NAT at the cluster’s edge.

Simplify deployment and administration of eBPF programs

Based on the community bpfman project, eBPF Manager is now available as technology preview with OpenShift 4.17. eBPF Manager enables internal teams, partners, and customers to manage eBPF program execution and visibility on the platform. eBPF programs allow developers to create a user-space program that has kernel-space privileges to observe and affect network traffic. Because of this power and especially in multi-tenant environments, administrators want to govern who is able to execute eBPF programs, control what those programs are allowed to do, and observe all eBPF programs on a system. eBPF Manager targets this additional level of security and scrutiny that does not exist elsewhere in Kubernetes marketplace and strengthens eBPF implementation security.

For this technology preview release, eBPF Manager functions with customer deployments and initially integrates with OpenShift Networking’s Ingress Node Firewall. In the future, eBPF Manager will be integrated with all current and future Red Hat internal eBPF implementations, including Network Observability Operator, Power monitoring for Red Hat OpenShift, and Red Hat Advanced Cluster Security for Kubernetes.

Enhance your containers with user namespaces

In OpenShift 4.17, we introduce user namespace in pods as technology preview. User namespaces allow pods to run with distinct user IDs inside the container, while mapping them to different IDs on the host. This improves security by transparently limiting the container's access to host resources, thus protecting against privilege escalation, by running the process as a non-root user, regardless of what user is configured in the container. Initially, this capability was introduced in Kubernetes for stateless pods only, and now user namespaces apply to all types of pods.

Attest your workloads with the Confidential Compute Attestation operator

Together with OpenShift sandboxed containers, the Confidential Compute Attestation Operator, based on the community Trustee project, provides attestation services for confidential containers workloads, attestation to retrieve container image signing or decryption keys, and attestation for releasing application secrets. Learn more at Introducing Confidential Containers Trustee: Attestation Services Solution Overview and Use Cases and Exploring the OpenShift confidential containers solution.

Embrace hosted control planes for enhanced efficiency and cost savings

Hosted control planes enable you to consolidate and host the control plane functions for multiple clusters into a single hosting cluster. This means you gain the efficiency of not having the overhead of multiple RHCOS instances and consolidate management functionality in the hosting cluster. For clusters deployed using hosted control planes, there are several noteworthy enhancements added with OpenShift 4.17.

First, we've simplified the installation experience for clusters using hosted control planes in disconnected environments. Enhancements include making the mirroring process more intuitive, enhancing TLS management for image pulling/pushing, simplifying troubleshooting processes, clearly documenting the transition from ImageContentSourcePolicy to ImageDigestMirrorSet and ImageTagMirrorSet, and addressing OpenShift Assisted Service issues. This helps make the process more intuitive and streamlined, so it’s faster and easier to instantiate new clusters in disconnected environments.

Additionally, you can now use OpenShift API for Data Protection to backup and restore hosted clusters in AWS and bare metal to any S3-compatible storage provider.

In this latest release, we've expanded support for different multi-architecture configurations,  enabling improved performance and cost savings with Arm, and also infrastructure specific to different customer workloads.

Hosted Control Planes for Customer-managed Red Hat OpenShift

Manage your fleet at scale with Red Hat OpenShift Platform Plus

Red Hat OpenShift Platform Plus (OPP) is an expanded version of Red Hat OpenShift that provides a comprehensive hybrid cloud platform with built-in security features for enterprises to build, deploy, run, manage, and automate applications at scale. Notable OPP highlights include policy as code with ArgoCD and VEX support in the scanner with Red Hat Advanced Cluster Security for Kubernetes version 4.6 (coming soon).

Red Hat Advanced Cluster Management for Kubernetes version 2.12 adds life cycle management for Red Hat OpenShift Service on AWS clusters (available as developer preview), as well as CSV file export support.

Red Hat Quay version 3.13 adds keyless authentication and enhanced auto pruning policies. Keyless authentication lets you access Quay using short-lived, regularly rotated tokens instead of traditional passwords. This not only improves security by reducing the risk of credential theft but simplifies the authentication process as well. Enhanced auto-pruning policies allow you to create more granular auto-pruning rules based on tag patterns. This means you can now specifically target or exclude certain image tags.

For Red Hat OpenShift Data Foundation (ODF), we’re promoting to general availability the use of customer-managed ODF with Red Hat OpenShift Service on AWS with hosted control planes clusters in ODF 4.17.z.  VMware vSphere 8 support has also been added in ODF.

Try Red Hat OpenShift 4.17 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
• In the Clouds featuring Red Hat OpenShift 4.17
• What’s new in OpenShift 4.17 for Virtualization Admins
• OpenShift YouTube Channel
• OpenShift blog posts
• OpenShift Commons
• Red Hat Developer Blogs
• Red Hat Portfolio Architecture Center

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