OpenShift 4.22 makes Bare Metal as a Service generally available
The supported add-on extends OpenShift’s Metal3-based lifecycle management to external physical hosts, with separate subscription and infrastructure prerequisites.
What changed
Red Hat OpenShift 4.22 makes Red Hat Bare Metal as a Service for OpenShift generally available. The capability uses the Metal3 API and Bare Metal Operator to provision and manage physical hosts that sit outside the OpenShift cluster and run workloads directly on an operating system, rather than as containers or virtual machines. Red Hat positions it for legacy applications and workloads that need direct hardware access, including GPU-heavy AI and high-performance computing.
The supported lifecycle covers initial provisioning, power operations, firmware configuration and updates, and decommissioning. Administrators define physical systems as BareMetalHost resources and connect to their baseboard management controllers through Redfish virtual media. The OpenShift 4.22 release notes separately mark expansion with images pulled from an OCI registry as Technology Preview, so that image path does not carry production service-level support.
This is an extension of OpenShift’s existing bare-metal machinery, not a way to turn every managed server into an OpenShift worker. The external hosts remain standalone systems while OpenShift supplies the control plane for their hardware lifecycle.
Who is affected
The release is relevant to platform teams that manage mixed estates of containers, virtual machines and OS-only physical servers. It gives those teams one Kubernetes-native management model for hardware that cannot be containerized or virtualized, or where virtualization overhead is unacceptable.
The production boundary matters. Red Hat’s documentation says managed hosts require a Redfish-capable baseboard management controller with virtual-media support, a boot interface that can receive a DHCP lease, and network reachability to customer-provided operating-system images and checksums. RHEL and CentOS Stream 9 are the operating systems Red Hat says it tested, although the service can provision other operating systems. The Red Hat announcement also says OS-only bare-metal nodes require a dedicated subscription; OpenShift control-plane nodes do not consume that SKU.
What to do
Teams considering adoption should first confirm that the cluster is on OpenShift 4.22 and inventory server-management interfaces, boot-interface MAC addresses, Layer 2 DHCP coverage and image-hosting capacity. The documentation requires cluster-admin access for setup and recommends a dedicated namespace so externally managed BareMetalHost resources do not mix with OpenShift infrastructure resources.
Start with a limited hardware pool and the documented web-server image path. Treat OCI-registry image access as evaluation-only until Red Hat promotes it beyond Technology Preview. Define the required BMC secrets and BareMetalHost resources, then validate provisioning, firmware operations, deprovisioning and recovery before expanding the fleet.
Organizations that also need guest operating-system or network-device lifecycle automation can evaluate Red Hat Ansible Automation Platform, but it is optional and separately licensed. The immediate decision is whether OpenShift should become the control point for OS-only hardware; the GA support in 4.22 makes that a production architecture choice rather than a preview experiment.
sources
comments · 0