Today we are pleased to introduce Red Hat OpenShift 4.10. This new 4.10 release, available now, is based on Kubernetes 1.23 with the CRI-O 1.23 runtime. OpenShift 4.10 has a number of exciting new enhancements and features for both developers and administrators. This blog is a guide to some of the highlights, additions and features we’re introducing. A more complete list of the changes in this release can be seen in the OpenShift 4.10 Release Notes.
45 Things We Changed Because You Asked Us To
From energy to industrial, organizations across the world rely on OpenShift as their Kubernetes platform to power their business applications. Customers like ANZ Bank, Audi, BP, Deutsche Bank, GE, HCA Healthcare, HM Land Registry, Kohl’s, NASA, Sabre, TIAA, Turkcell, and Verizon have embraced OpenShift to transform their businesses with new, value-creating applications while also modernizing their legacy projects.
With OpenShift 4.10, we addressed 45 requests for enhancements (RFEs) from customers. We’ve added the ability to change static network configurations after cluster deployment with enhanced networking metrics and debuggability. We’ve provided a way to check configurations regularly, so the administrator can be more proactive in addressing problems sooner with MachineConfigDaemon Events. OpenShift 4.10 supports Microsoft Azure AvailabilitySets in MachineSets for better resilience and high availability. We’ve also included the ability to change the maximum transmission unit (MTU) of openshift-sdn, post cluster deployment.
OpenShift Sandboxed Containers
OpenShift sandbox containers, which were introduced in 4.8 as a Technology Preview, are now generally available in OpenShift 4.10. This is complementary to the numerous existing security features of OpenShift: SELinux, role based access control (RBAC), projects, security context constraints (SCCs), and Kubernetes network policies, which already provide a great deal of protection for isolating pods that run on the same node.
OpenShift sandboxed containers, based on the open source Kata Containers project, provides an additional layer of isolation for applications with stringent security requirements, as well as strong isolation for untrusted workloads or third-party applications. This can be useful for establishing stronger tenancy boundaries when privileged workloads are deployed, securely running CI/CD jobs from multiple sources without requiring dedicated nodes per job, or generally reducing the blast radius for workloads with elevated privileges or with misconfigured resource boundaries. Sandboxed containers can be used today as an optional runtime on OpenShift with bare metal nodes.
New Compliance Profiles
For customers concerned with regulatory readiness and compliance, we added two new compliance operator profiles covering PCI-DSS and NERC CIP, as well as additional controls for the FedRAMP Moderate profile. The compliance operator provides relief to the operational complexity of managing the security compliance of the cluster, by automating, auditing, and remediation of compliance with technical controls for the cluster administrator.
Additional Infrastructure Providers and ARM
We have expanded the supported providers to include IBM Cloud (Technology Preview), Alibaba Cloud (Technology Preview), and Azure Stack Hub with a single-click fully automated installation experience, which automatically provisions the infrastructure resources.
There’s been a lot of interest in Arm-based systems today since Arm offers cost savings, reduced power consumption, and performance gains in some scenarios. To give our customers the ability to run their workloads and applications on infrastructure that best fits their needs, with 4.10, customers can use OpenShift on the latest AWS EC2 A1 instances and RHEL-supported bare metal platforms, and systems that meet Arm SystemReady/ServerReady specification. Learn more about this exciting new feature in the OpenShift Container Platform on ARM.
Streamlined Disconnected Clusters
For on-premises, disconnected OpenShift cluster deployments, we are simplifying and streamlining the process for setting up a mirror registry with a minimal Red Hat Quay deployment serving as a registry to bootstrap your first disconnected cluster. This Quay deployment is a single-node registry offering for customers who need to bootstrap their first cluster for disconnected environments. This is included in every OpenShift subscription.
To make it easier to maintain OpenShift content in the mirror registry over the course of many OpenShift releases, we are starting to consolidate all relevant operations into a single plugin for the oc client. It condenses multiple different tools and steps previously required into a single command. This greatly simplifies the process of selecting and mirroring OpenShift versions and operator catalogs for offline deployment and updates.
In the future, oc mirror will be the single entry point for disconnected content management and launches as Technology Preview in 4.10.
More Powerful Tools for Seamless Upgrades
In 4.10, we introduce Extended Update Support (EUS)-to-EUS updates to provide customers a quicker and safer update experience while reducing disruptions to their workloads. Beginning with the upgrade between 4.8 and 4.10, OpenShift now offers customers the option to update between two EUS versions with only a single restart of non-Control-Plane nodes. This reduces total update duration and workload restarts while adhering to Kubernetes Version Skew Policies, which require serialized updates of all components other than the Kubelet. We added guardrails to help ensure updates are compatible and do not violate version skew policies. In addition, we reduced non-worker update duration significantly – we saved 12 hours for a 250-nodes cluster update for a 4.8 to 4.10 update.
To further safeguard against risky updates, we added enhancements for conditional updates. Specifically, the OpenShift Update Service (OSUS) may declare conditionally recommended updates associated with known risks. The Cluster Version Operator (CVO) continually evaluates known risks associated with updates from the current OpenShift Container Platform release to later releases. When no risks apply, the update is recommended. Conversely, if risks are found, the OpenShift CLI informs the administrator of the potential risks, so they can decide if the update is acceptable for the current cluster, or waive the safety guards and proceed with an update. Make sure to review Preparing to perform an EUS-to-EUS update before performing an update.
OpenShift on Bare Metal
OpenShift on bare metal can provide customers with numerous benefits, including cost savings, more control, simplified management, and improved performance. In 4.10, the coreos-installer utility now has features for more flexible customization when installing RHCOS on bare metal from live ISO and PXE images. Administrators can now deploy OpenShift on bare metal using static IP address assignments without the need of DHCP servers using the installer-provisioned infrastructure installation method — this improvement was made possible by the Kubernetes NMState Operator, which lets Administrators configure static IP addresses, Linux bonding, Linux bonding with VLAN, and VLAN configurations.
MetalLB with BGP mode
In 4.9, we introduced MetalLB operating in L2 mode as the native load balancers for bare metal infrastructure deployments. For 4.10, we enhanced MetalLB to support Border Gateway Protocol (BGP) mode to enable routers to load balance traffic across multiple nodes in a cluster using equal-cost multi-path routing (ECMP).
OpenShift Virtualization Brings Together Virtual Machines and Containers
For OpenShift Virtualization, we’ve added support for OpenShift Service Mesh, virtual GPU (Tech Preview for vGPU), and warm migration of RHV VMs. With Service Mesh support, developers can easily monitor, visualize and control traffic between pods and VMs. Cluster administrators can now configure specific nodes with specific vGPU types to have better control over the vGPUs configuration, so that the newly configured vGPUs are available for consumption by workloads owners.
For customers looking to modernize their virtualized applications and take advantage of containers, administrators can now use warm migration to import VMware or Red Hat Virtualization (RHV) virtual machines into OpenShift. While the VMs continue to run as server users on their source infrastructure, data seamlessly migrates to the offline VM on OpenShift. During a convenient maintenance window, the source is powered off, the rest of the data copied, and the new VMs boot and start serving users, with a minimal disruption.
Test the Latest in OpenShift Serverless
OpenShift Serverless is now updated to Knative 1.0. In conjunction, we’ve added multiple new features in Technology Preview:
- Knative Broker lets developers maximize Kafka performance and avoid event duplications by preventing tight coupling with Kafka and eliminates use of the Kafka client by event producers.
- Knative Kafka Sink enables developers to receive CloudEvents from Source/Subscription/Trigger on a Kafka topic, without writing custom code.
- Developers can now develop functions across different languages including Node.js, TypeScript, Quarkus, Python, Rust, Go and Spring Boot.
- Developers can develop, debug, and test EDA applications by sending CloudEvents via the kn CLI.
A Smarter OpenShift Console
There are other improvements, including a better onboarding experience with a Getting Started Guide and developer experience improvements in the OpenShift console that displays the cluster support level, provides support for dynamic plugins (Technology Preview), runs pods in debug mode, treats OpenShift Pipelines as code (Technology Preview), signs and verifies pipelines with Tekton Chains (Developer Preview), and the Argo CD dashboard which displays health status of OpenShift resources.
Try out OpenShift 4.10 Today!
Beyond what’s highlighted in this blog, check out the following resources to learn more about the new OpenShift 4.10 release:
- What's New in OpenShift 4.10
- OpenShift YouTube Channel
- What’s Next in OpenShift on April 14 2022
- OpenShift Blogs
- OpenShift Commons community
- Try Red Hat OpenShift
Thank you for reading about OpenShift 4.10. Please leave a comment or send us feedback either through your usual Red Hat contacts or as an issue on OpenShift on Github.