live wire
▸AI · vLLM Recipes maps Muse Spark Open to single-node Blackwell and AMD deployment (Oct. 16)vLLM▸PLATFORM · Clang 23 bytecode interpreter cuts allocations and expands constant-expression supportRed Hat Developer▸PLATFORM · RHEL becomes first-party on OCI; OpenShift subscriptions reach Oracle MarketplaceRed Hat▸AI · vLLM-Omni merges native MOSS-Image serving with parallelism and offloadvLLM▸AI · vLLM adds System One endpoint for Decision 3.0 multimodal routing models (Oct. 15)vLLM▸SECURITY · Red Hat rates OpenShift AI 3.4.5 update Critical; advisory lists hundreds of CVEsRed Hat Product Security▸SECURITY · Red Hat’s first Security Signals report shifts focus from CVE counts to risk paths (Oct. 15)Red Hat▸PLATFORM · IBM adds non-destructive FlexVolume-to-CSI migration tool for OpenShift object storageIBM Cloud▸vLLM tests agent-built Kimi K3 decode path at up to 1.9× speedup; PR remains openvLLM▸AI · LeaderWorkerSet 1.0 changes rollout defaults for disaggregated AI workloadsKubernetes SIGs▸SECURITY · Red Hat flags active exploitation of kernel flaw affecting OpenShift CoreOS; no fix listedRed Hat Product Security▸AI · Red Hat sets Dec. 9 showcase for AI 3.6 agent governance and model servicesRed Hat▸vLLM 0.32.0 drops Python 3.10, restricts CORS defaults and adds security fixesvLLM▸SECURITY · Red Hat tracks Moderate Hono auth bypass across OpenShift AI, Dev Spaces and AnsibleRed Hat Product Security▸AI · vLLM Recipes maps Muse Spark Open to single-node Blackwell and AMD deployment (Oct. 16)vLLM▸PLATFORM · Clang 23 bytecode interpreter cuts allocations and expands constant-expression supportRed Hat Developer▸PLATFORM · RHEL becomes first-party on OCI; OpenShift subscriptions reach Oracle MarketplaceRed Hat▸AI · vLLM-Omni merges native MOSS-Image serving with parallelism and offloadvLLM▸AI · vLLM adds System One endpoint for Decision 3.0 multimodal routing models (Oct. 15)vLLM▸SECURITY · Red Hat rates OpenShift AI 3.4.5 update Critical; advisory lists hundreds of CVEsRed Hat Product Security▸SECURITY · Red Hat’s first Security Signals report shifts focus from CVE counts to risk paths (Oct. 15)Red Hat▸PLATFORM · IBM adds non-destructive FlexVolume-to-CSI migration tool for OpenShift object storageIBM Cloud▸vLLM tests agent-built Kimi K3 decode path at up to 1.9× speedup; PR remains openvLLM▸AI · LeaderWorkerSet 1.0 changes rollout defaults for disaggregated AI workloadsKubernetes SIGs▸SECURITY · Red Hat flags active exploitation of kernel flaw affecting OpenShift CoreOS; no fix listedRed Hat Product Security▸AI · Red Hat sets Dec. 9 showcase for AI 3.6 agent governance and model servicesRed Hat▸vLLM 0.32.0 drops Python 3.10, restricts CORS defaults and adds security fixesvLLM▸SECURITY · Red Hat tracks Moderate Hono auth bypass across OpenShift AI, Dev Spaces and AnsibleRed Hat Product Security
upstreambeat.ai
newsPLATFORM

RHCOS 10 makes OpenShift’s next worker-node baseline a compatibility decision

Red Hat plans to make RHCOS 10 the default for new OpenShift installations in Q4, requiring early checks for privileged containers, UBI7 workloads and older x86 hardware.

OpenShift worker node transition from RHCOS 9 to RHCOS 10.
AI-generated illustration
By The News Desk· Oct 3, 2026the quick take — two AI hosts go live when you do

Red Hat plans to make Red Hat Enterprise Linux CoreOS 10 the default worker-node operating system for new OpenShift installations in the fourth quarter of 2026, turning the next OpenShift baseline into a compatibility checkpoint for platform teams and software partners. Red Hat says all certified ISV containers and operators will be expected to support RHCOS 10 when it becomes generally available.

What changes

RHCOS is OpenShift’s purpose-built immutable node operating system, configured through OpenShift and Kubernetes APIs. RHCOS 10 carries the RHEL 10 kernel and hardware baseline into that layer. Red Hat says RHCOS 9 will remain available for newer OpenShift versions at least into mid-2027, providing a transition window rather than an immediate forced cutover.

The compatibility boundaries matter most for software that reaches into the host. Red Hat specifically calls out CSI and CNI drivers, host agents, kernel drivers and containers that alter host configuration files as candidates for additional testing. Ordinary workloads without privileged host access are less likely to encounter issues, although Red Hat still recommends testing.

Two other boundaries are explicit. OpenShift nodes moved to RHCOS 10 will no longer support containers based on UBI7, while nodes kept on RHCOS 9 will retain that compatibility. RHCOS 10 also drops support for x86-64-v2 and earlier instruction sets, so supported systems must provide x86-64-v3 or newer. For workloads requiring FIPS 140 compatibility, Red Hat currently recommends UBI9 because RHEL 10 and UBI10 cipher libraries are still undergoing certification.

What teams should do now

OpenShift 4.21 and 4.22 already expose RHCOS 10 and an “OS Streams” capability as Technology Preview. That gives platform teams a place to inventory and exercise host-integrated workloads before the default changes. The warning is consequential: enabling OpenShift Technology Preview features makes a cluster ineligible for future minor-version upgrades, so Red Hat says testing should happen only on disposable clusters using the latest patch release.

The practical sequence is to identify privileged containers and operators, check base images for UBI7, verify hardware certification against the RHEL 10 baseline, and run representative upgrades or fresh installs in a throwaway environment. That work is especially important for vendors whose OpenShift certification will be expected to cover RHCOS 10 at general availability.

The transition does not require every cluster to move immediately, but it does establish the operating-system assumptions that new OpenShift installations will carry. Platform teams that treat node images as an implementation detail may find the application and hardware consequences arriving together.

sources

Filed by The News Desk. Corrections: desk@upstreambeat.ai · Our standards →

comments · 0

    Comments are moderated before they appear. Your email is used once to confirm it is you — never shown, never sold. Corrections and questions get an answer from the desk when we have one.

    more from the desk