RHCOS 10 será el sistema por defecto de los OpenShift nuevos en el cuarto trimestre

Red Hat anunció el 2 de octubre que RHCOS 10 será el sistema por defecto de las instalaciones nuevas de OpenShift cuando llegue a disponibilidad general en el cuarto trimestre de 2026. Hoy no lo es. Está como Technology Preview en OpenShift 4.21 y 4.22, bajo la función OS Streams. RHCOS 9 seguirá pudiendo usarse al menos hasta mediados de 2027.

Qué cambia, y qué no cambia todavía

El nodo worker de OpenShift no es una máquina que cada equipo componga a su gusto. Llega con Red Hat Enterprise Linux CoreOS, inmutable, actualizado por el clúster y pensado para no acumular paquetes locales. Pasar el default de RHCOS 9 a RHCOS 10 mueve esa base: kernel, librerías y el contrato que los proveedores certificados tienen con el host. No es un parche de canal. Es el sistema sobre el que arranca el nodo nuevo.

Red Hat limita el anuncio a instalaciones nuevas una vez que RHCOS 10 esté en GA. No dice que los clústeres actuales vayan a rehacerse solos ese día. RHCOS 9 permanece disponible para versiones nuevas de OpenShift al menos hasta mediados de 2027. Hay margen para convivir. El margen no es infinito, y el default empuja a quien despliega desde cero a partir del GA.

Los ISV con oferta certificada en OpenShift tendrán que soportar RHCOS 10 cuando esa GA llegue. Eso incluye a quien entrega operadores, drivers o agentes de host. Un catálogo que hoy se prueba solo sobre RHCOS 9 se queda corto para un clúster nacido el trimestre que viene.

-InfraCrew dice: El nodo nuevo no avisa de que el operador de almacenamiento se certificó en el sistema anterior. Lo descubre el día del alta.-

Preview no es el sistema por defecto

En 4.21 y 4.22, RHCOS 10 se prueba con OS Streams. Red Hat lo marca como Technology Preview y remite a un artículo de base de conocimiento para activarlo en un clúster de laboratorio, a ser posible en el último parche de esas ramas. Activar una función en Technology Preview deja el clúster fuera de futuras actualizaciones menores. La recomendación explícita es probar en un entorno que se pueda tirar, no en el que tiene el siguiente upgrade ya aprobado.

Esa condición importa más que la curiosidad por ver el sistema nuevo. Un clúster de integración que quede marcado como no actualizable deja de servir para ensayar precisamente el salto que se quería ensayar. Mejor un clúster efímero con OS Streams que un preproductivo hipotecado.

Tampoco conviene contar RHCOS 10 como ya disponible para producción. El blog fija el default en el momento de la GA del cuarto trimestre, no en la preview de octubre. Quien escriba en una arquitectura que los workers nuevos «ya van con RHCOS 10» se adelanta al calendario que Red Hat ha publicado.

Qué merece una prueba antes del GA

Red Hat separa dos familias de carga. Los contenedores sin acceso privilegiado al host no deberían romperse: viven en su runtime y no dependen del árbol de ficheros del nodo. Aun así pide validarlos. El grupo que sí necesita banco de pruebas es el que toca el host: drivers CSI y CNI, agentes que montan en el nodo, módulos de kernel y cualquier contenedor que reescriba configuración del sistema.

Ese grupo es pequeño en número de pods y grande en capacidad de parar un clúster. Un CNI que no levanta interfaces en el kernel nuevo no se arregla con un rollback de despliegue. Un CSI que no presenta volúmenes deja a las aplicaciones sin disco aunque el scheduler las coloque. Probar esos dos en OS Streams, con la versión exacta que el proveedor piensa certificar, es el trabajo útil de este anuncio. El resto puede esperar a la nota de GA.

-InfraCrew dice: El pod de la aplicación seguirá verde. El que instala la tarjeta de red en el nodo es el que va a pedir la ventana.-

Hasta que Red Hat publique la GA, el hecho es una fecha de plataforma y una preview acotada. No hay build de producción que instalar mañana, ni una orden de migrar los workers actuales. Sí hay una razón para sacar el operador de red y el de almacenamiento del cajón de «ya certificado» y volver a mirarlos sobre RHCOS 10 antes de que el instalador lo elija solo.

Diccionario de la Crew

CSI — Interfaz de almacenamiento de contenedores. Aquí, el driver que corre en el nodo y presenta volúmenes al pod.
CNI — Interfaz de red de contenedores. El plugin que da conectividad al pod y, a menudo, privilegios sobre el host.

Fuentes

Red Hat | https://www.redhat.com/en/blog/rhcos10-red-hats-new-worker-node-os-openshift