Explorando RHCOS 10: la nueva era para sysadmins de OpenShift en Linux

octubre 5, 2026 Alfonso Moreno | Sysadmin Senior 24 Visitas 11 min de lectura

TL;DR — Lo que vas a tener al final

Tiempo de setup: 30 minutos a 2 horas dependiendo de la complejidad del entorno.
Requisitos: Acceso root, Linux moderno, conexión a internet para descargar dependencias.
Resultado: Servicio funcional y estable, documentado paso a paso.
Troubleshooting: Logs estándar en /var/log/, comandos de verificación al final de cada sección.

Qué hay detrás del nuevo sistema operativo de los nodos de OpenShift

Red Hat acaba de anunciar que a partir de Q4 2026 OpenShift Container Platform (OCP) enviará por defecto la versión 10 de Red Hat Enterprise Linux CoreOS (RHCOS) en todas las instalaciones nuevas. Hasta ahora veníamos arrastrando RHCOS 9 desde 2022, y este es el primer salto mayor que rompe con la base RHEL 9 para subirse a RHEL 10. El cambio parece menor porque RHCOS es invisible para la mayoría de los operadores — un sistema inmutable, entregado dentro del payload de OpenShift, que solo se reconfigura vía Machine Config Operator — pero toca tres capas sensibles: hardware, criptografía y ciclo de vida de los operadores certificados. Si administras un cluster OpenShift, esto te afecta más pronto que tarde.

El anuncio oficial (Daniel Messer, Red Hat Blog, 2 de octubre de 2026) confirma tres cosas que necesitas saber antes de seguir leyendo:

RHCOS 10 está disponible como Technology Preview en OpenShift 4.21 y 4.22 desde hace meses.
Pasará a GA en Q4 2026 como sistema por defecto para instalaciones nuevas.
RHCOS 9 seguirá siendo soportado al menos hasta mediados de 2027, así que no hay apuro para migrar, pero el camino está marcado.

Lo interesante es la feature nueva que viene con este ciclo: OS Streams. Es la primera vez que OpenShift permite tener pools de nodos en versiones distintas de RHCOS dentro del mismo cluster, lo cual cambia completamente la planificación de upgrades.

Por qué este anuncio importa a sysadmins que no corren OpenShift

Aunque trabajes con Kubernetes vanilla, k3s, EKS o GKE, este movimiento de Red Hat te afecta por capilaridad. Tres razones:

1. RHEL 10 fija el patrón “drop x86_64 v1/v2”. Cualquier distribución seria que se base en RHEL 10 o en Fedora 40+ (RHEL 10 viene de Fedora 40) va a exigir CPU con x86_64 v3 o superior en algún momento del ciclo 2026-2028. Tu próximo servidor bare-metal debería validar esa característica antes de comprarlo — los Xeon Scalable de 3ª generación y los EPYC de Roma en adelante cumplen; los Xeon E3 v3 o Atom viejos no. Consulta el catálogo de hardware certificado RHEL si tienes dudas.

2. Criptografía post-cuántica por defecto. RHEL 10 trae OpenSSL 3.5 con ML-KEM y ML-DSA activados en la política DEFAULT. Esto va a llegar a RHCOS 10, y pronto a Fedora, Rocky, AlmaLinux y derivados. Si tienes appliances de seguridad, middleboxes o HSMs en medio del tráfico, pruébalos con un nodo RHEL 10 antes de que te toque en producción. La falla típica: el appliance rechaza el grupo nuevo en vez de ignorarlo, y la conexión muere silenciosa.

3. UBI7 desaparece. Si tienes containers basados en ubi7 corriendo en producción, tienen los meses contados para correr en nodos RHCOS 10. RHCOS 9 los seguirá aceptando, pero los partners certificados ya están migrando a ubi9 como mínimo.

Qué cambia realmente en un nodo cuando migra a RHCOS 10

RHCOS sigue siendo el mismo concepto: sistema operativo inmutable, entregado como una imagen OCI, actualizado por el Machine Config Operator vía rpm-ostree, sin acceso SSH por defecto y sin gestor de paquetes tradicional. El nodo sigue arrancando desde una imagen boot, recibe su config vía Ignition, y el MCO orquesta todo. Eso no cambia.

Lo que sí cambia es la base RHEL bajo el árbol ostree. RHCOS 9 = RHEL 9. RHCOS 10 = RHEL 10. En concreto (basado en la nota de Thomas Hall sobre RHCOS 10 en OpenShift 4.22):

Kernel 6.12 (vs 5.14 en RHCOS 9). Mejor soporte para GPU, NIC, NVMe/TCP y CXL. Scheduler y comportamiento de reclaim cambian en nodos densos.
OpenSSL 3.5 con post-quantum en política por defecto.
systemd y paths de SELinux actualizados al modelo RHEL 10. Si tienes MachineConfigs que asumen rutas o módulos de RHEL 9, se rompen.
composefs/fs-verity como modelo de integridad destino para image mode sellado.
Drop de x86_64 v1/v2: solo v3+ (ver arriba).

Importante: los pods siguen corriendo en containers. Un pod sobre UBI9 no se convierte automáticamente en RHEL 10 porque el nodo lo sea. El sistema operativo del nodo y la imagen base del contenedor son relojes de upgrade separados. Mantén esa separación cuando presentes los planes de upgrade a tu equipo.

OS Streams: la pieza que resuelve el acantilado del upgrade

Este es el cambio operativo más relevante. Antes, cuando Red Hat liberaba una nueva versión mayor de RHCOS, el upgrade era un acantilado: o migrabas todo el cluster el mismo fin de semana que hacías el minor de OpenShift, o te quedabas en una versión vieja hasta estar listo. Los equipos retrasaban upgrades de plataforma para evitar el corte de OS, y como consecuencia perdían features que sí necesitaban.

OS Streams invierte eso. A partir de OpenShift 4.22, el Machine Config Operator expone un nuevo objeto cluster-scoped, OSImageStream, que lista las corrientes de OS disponibles. La instalación por defecto sigue siendo RHCOS 9 (construido sobre RHEL 9.8), pero el operador puede conmutar a RHCOS 10 en un pool específico.

Pregunta	OpenShift 4.22 hoy	Destino que Red Hat está preparando
OS por defecto	RHCOS 9 (paquetes RHEL 9.8)	Instalaciones nuevas en RHCOS 10
RHCOS 10	10.2 como Technology Preview, solo clusters de prueba	GA como node OS
Mezcla RHCOS 9 y 10 en un cluster	No soportado en docs de 4.22	Transición soportada, un MachineConfigPool a la vez
Upgrade desde 4.22	Los nodos siguen en RHCOS 9 salvo opt-in	Sin migración forzada en day-one del upgrade
Cómo seleccionar la corriente	`OSImageStream` + `TechPreviewNoUpgrade`	Mismo API, sin feature gate de un solo sentido

El truco está en el FeatureGate TechPreviewNoUpgrade: activarlo te da acceso a osImageStream: rhel-10, pero tiene un costo duro — el cluster queda bloqueado para futuros upgrades menores. Es una puerta de un solo sentido mientras la feature esté marcada así. Úsalo solo en clusters que estés dispuesto a tirar al final de la prueba.

Cómo probar RHCOS 10 hoy mismo (sin romper tu cluster)

El procedimiento documentado por Red Hat en el Knowledgebase article 7139678 aplica para OpenShift 4.21.2+ o 4.22. Si lo quieres correr hoy, el camino más limpio es levantar un cluster nuevo descartable y elegir el stream desde el install-config.yaml:

apiVersion: v1
featureSet: TechPreviewNoUpgrade
osImageStream: rhel-10

El campo osImageStream acepta los valores rhel-9 y rhel-10. Si lo omitís, OpenShift te instala RHCOS 9 como siempre.

Para un cluster existente donde quieres validar la migración sin redeploy, el flujo es:

# 1. Activar el FeatureGate en el cluster
oc apply -f - <<'EOF'
apiVersion: config.openshift.io/v1
kind: FeatureGate
metadata:
  name: cluster
spec:
  featureSet: TechPreviewNoUpgrade
EOF
# 2. Esperar a que aparezca el stream
oc get osimagestreams/cluster -o yaml | grep rhel-10
# Si rhel-10 no aparece, todavia no estas en 4.21.2+ o no hay payload
# 3. Conmutar los MachineConfigPools uno por uno
oc patch mcp worker --type merge -p '{"spec":{"osImageStream":{"name":"rhel-10"}}}'
oc patch mcp master --type merge -p '{"spec":{"osImageStream":{"name":"rhel-10"}}}'

El MCO se encarga del drain/reboot a la nueva imagen. El proceso es destructivo para ese pool — los pods se mueven antes de rebootear, pero si tienes PDBs mal configurados o cuotas de disruption budget agotadas, el nodo se queda atascado. prueba primero con un pool custom de un solo nodo antes de tocar el master.

Troubleshooting típico: la imagen de boot puede quedar en una versión vieja de RHCOS 9 incluso después de migrar el OS corriendo a 10. Los nodos nuevos se bootean en 9, y el MCO los sube a 10 después. Si estás escalando agresivamente, vas a ver “misteriosos downgrades” de OS en los logs del MCO hasta que actualices la imagen de boot. El procedimiento está en Manually updating the boot image.

Implicancias de compatibilidad: lo que tienes que revisar antes del GA

Cuando RHCOS 10 pase a GA en Q4 2026, todos los containers certificados para OpenShift van a tener que soportarlo. Red Hat ya está avisando a los ISVs. El criterio de quién rompe y quién no depende de si tu container toca el host OS:

Tipo de container	Riesgo de romper en RHCOS 10
Drivers CSI / CNI	Alto — tocan kernel modules, paths de /etc, sysfs. Recompilar contra RHEL 10.
Agentes de host (monitoring, logging)	Alto — asumen paths y unidades systemd de RHEL 9.
Operadores que escriben en /etc del nodo	Medio — verificar que las rutas y módulos sigan existiendo en RHEL 10.
Workloads sin acceso privilegiado	Bajo — no tocan host OS, deberían funcionar sin cambios. Igual probar.
Containers basados en UBI7	No soportado en RHCOS 10. Migrar a UBI9.
Containers que requieren FIPS 140	Usa UBI9 por ahora. Las librerías de cifrado de RHEL 10/UBI10 todavía están en proceso de certificación FIPS 140.

El criterio formal está en la RHEL Container Compatibility Matrix. Si eres partner ISV, tu container cae en la categoría de “privileged host access” si hace cualquiera de: instalar drivers kernel, alterar /etc, escribir en /proc o /sys, o usar hostPath con permisos elevados. En todos esos casos, Red Hat te pide testing adicional contra RHEL 10 antes del GA de RHCOS 10.

¿Vale la pena actualizar? La opinión honesta

Si tu cluster OpenShift corre en producción con cargas estables y certificados ISV críticos, no migres a RHCOS 10 el día del GA. espera al menos un minor con parches (4.23 o 4.24 según calendario) para que la base certificada de partners haya pasado por el ring de actualización. El riesgo de incompatibilidad es real y está documentado en la nota de Red Hat: “partners are encouraged to transition certified workloads to UBI9 or later if they haven’t already”. Eso es código vendor para “teníamos que haberlo hecho antes”.

Si estás planeando una instalación nueva de OpenShift en Q4 2026 o más tarde, deja que Red Hat ponga RHCOS 10 por defecto y prueba tus workloads en un cluster de prueba con osImageStream: rhel-10 antes de ir a producción. La gran pregunta no es técnica sino operativa: ¿tienes el inventario de containers certificados que vas a correr? Si tienes drivers CSI custom, agentes de host o stacks de monitoring viejas, ese inventario es lo que define tu fecha de upgrade, no la fecha de GA.

Si no corres OpenShift pero mantienes un fleet de servidores Linux físicos o VMs, este anuncio te da el horizonte temporal para auditar hardware: ¿tu próxima generación de servidores soporta x86_64 v3? Si compraste hardware en los últimos cinco años, casi seguro que sí. Si tienes servidores de 2014-2017 que pensabas mantener hasta 2027, este es el momento de empezar el presupuesto de reemplazo. RHEL 10 (y por lo tanto RHCOS 10) marca el final de la era de los x86 de instruction set legacy.

El otro ángulo a vigilar es post-quantum en producción. Si tienes appliances de seguridad, VPN concentrators, HSMs o middleboxes que negocian TLS, RHCOS 10 va a empezar a ofrecer ML-KEM híbrido por defecto. La mayoría interoperará y caerá al grupo clásico si el peer no entiende. La falla que tienes que probar en laboratorio es el appliance que rechaza el handshake nuevo en lugar de hacer fallback silencioso. Es un bug común en appliances viejos.

Resumen: lo que tienes que recordar

RHCOS 10 sale GA en Q4 2026, Tech Preview ya disponible en OpenShift 4.21.2+ y 4.22.
RHCOS 9 sigue vivo hasta mid-2027, no hay apuro inmediato.
OS Streams es la pieza nueva que permite migración gradual pool por pool.
Cambios duros: kernel 6.12, OpenSSL 3.5 con post-quantum, drop x86_64 v1/v2, drop UBI7.
Si tu container toca el host OS (CSI, CNI, monitoring agent), testing obligatorio contra RHEL 10 antes del GA.
El FeatureGate TechPreviewNoUpgrade bloquea upgrades menores — solo en clusters descartables.

Preguntas frecuentes

¿Por qué Explorando RHCOS 10: la nueva era para sysadmins de OpenShift en Linux es relevante para sysadmins Linux?

Forma parte del flujo diario de administración. Los conceptos explicados se aplican directamente a servidores en producción y resuelven problemas reales que enfrentan sysadmins hispanohablantes.

¿Qué necesito para empezar con Explorando RHCOS 10: la nueva?

Distribución Linux actualizada (Debian, Ubuntu, RHEL, Fedora o Arch), acceso root, y conexión a internet. Para producción: entorno de staging separado antes de aplicar cambios.

¿Cuáles son los errores más comunes con Explorando RHCOS 10: la nueva?

Los tres más frecuentes: (1) saltar la lectura de logs, (2) aplicar cambios directos en producción sin probar, (3) olvidar permisos y ownership. La documentación y un plan de rollback siempre.

¿Cuándo usar Explorando RHCOS 10: la nueva y cuándo una alternativa?

Esta solución es ideal para el caso descrito. Alternativas como Docker, Ansible o configuración manual pueden ser mejores según contexto: portabilidad, escala y reproducibilidad son los factores clave.

¿Cómo migro desde una configuración previa a Explorando RHCOS 10: la nueva?

Documentar el estado actual, probar la nueva configuración en staging, validar funcionalmente, y aplicar en producción con rollback plan listo. Los posts de SoyLinux incluyen troubleshooting para los problemas más comunes.