Red Hat turns the RHEL CoreOS 10 move into a pool-by-pool OpenShift migration

Red Hat is preparing to loosen one of the tightest couplings in an OpenShift upgrade: the relationship between the cluster release and the operating-system stream on every node. In a technical overview, the company says Red Hat Enterprise Linux CoreOS (RHCOS) 10 is available as a technology preview in OpenShift 4.22, with mixed RHCOS 9 and 10 clusters planned for a future OpenShift release.

That distinction matters. RHCOS 10 can be tested now, but the full multi-stream migration model described by Red Hat is forward-looking rather than generally available in 4.22.

What changes

Red Hat’s planned design introduces OSStreams, a cluster-level API that lets the Machine Config Operator manage more than one RHCOS stream. Instead of moving every worker to the new operating system as an automatic consequence of a platform upgrade, administrators will be able to migrate selected MachineConfigPools.

The intended workflow is deliberately incremental: place one or more nodes in a custom pool, point that pool at RHCOS 10, drain and reboot through the existing Machine Config Operator process, and validate workloads before expanding the migration. Red Hat says a node can be moved back if testing fails.

For clusters upgraded from OpenShift 4.22, Red Hat says nodes will remain on RHCOS 9 initially. Fresh installations are expected to default to RHCOS 10 once the future multi-stream model arrives, while retaining a documented RHCOS 9 installation path where certification or validation requirements demand it.

Who should care

Platform teams with long hardware-certification cycles are the clearest audience. Red Hat positions RHCOS 10 as the route to the RHEL 10 kernel’s newer GPU, NIC, NVMe and CXL enablement, as well as updated scheduler and memory-management behavior. The company also points to the RHEL 10 foundation for sealed image mode and post-quantum cryptography testing.

Teams using on-cluster layering have an extra dependency to examine. MachineOSConfigs are scoped to MachineConfigPools, so OS-sensitive build steps and layered images need testing against both RHCOS 9 and RHCOS 10 bases during the transition.

What to do now

OpenShift administrators should treat RHCOS 10 in 4.22 as a test-cluster exercise, not a production migration signal. Red Hat recommends starting with a single node in a custom MachineConfigPool and running representative validation workloads there.

The practical preparation is to inventory hardware certifications, layered MachineOSConfigs and workloads that depend on kernel or driver behavior. That work will determine which pools can move first when mixed-stream support becomes generally available. The useful shift is not simply a newer node OS; it is a migration model that lets platform and operating-system validation proceed on separate schedules.