Siete años después de la 4.0, OpenShift cambia de número mayor y Red Hat promete que no hará falta reinstalar nada. OpenShift 5, disponible de forma general desde el 9 de noviembre de 2026, se actualiza in situ desde la 4.22 con el mismo procedimiento que cualquier versión menor. Lo que sí cambia es el calendario de soporte, el sistema operativo de los clústeres nuevos y el papel de los agentes de IA en la operación.
Qué trae OpenShift 5 que importe en el día a día
La base es Kubernetes 1.36 y CRI-O 1.36. Por encima, las novedades se agrupan en tres frentes.
Agentes para operar, con aprobación humana. OpenShift Lightspeed pasa de responder preguntas a investigar incidencias: le describes el síntoma en lenguaje natural, busca la causa probable y propone el arreglo, que el administrador revisa y aplica. Ese modo supervisado está disponible de forma general; el autónomo, en el que una alerta dispara la investigación sin que nadie la pida, está en technology preview y también espera aprobación antes de tocar el clúster. Lo mismo con las actualizaciones: el análisis de riesgo previo es GA y el agente que planifica y ejecuta la actualización, preview. Red Hat insiste en que todas estas funciones de IA son opcionales.
MCP como canal oficial. El servidor MCP de OpenShift y el gateway MCP llegan a GA. El servidor se integra con proveedores OAuth y OIDC, aplica el RBAC de Kubernetes, arranca en solo lectura y etiqueta cada acción para auditoría; el gateway filtra datos personales, inyección de prompts y contenido inseguro. Es la parte más útil para quien ya conecta agentes de código a sus clústeres con servidores MCP de terceros: ahora hay uno soportado y gobernable con las mismas reglas que el resto de la plataforma.
Seguridad por defecto. La configuración TLS se centraliza y se aplica en el núcleo y en los productos superpuestos; los namespaces de los componentes del plano de control llevan políticas de red propias; la criptografía poscuántica entra en las imágenes y en la configuración TLS; y el Red Hat build of Agent Sandbox (preview) aísla en máquinas virtuales, con contenedores sandboxed de Kata, el código que generan y ejecutan los agentes.
Para desarrolladores, la consola admite el SDK de Helm 4 junto a Helm 3, el clúster puede autenticarse con un proveedor OIDC externo (Keycloak, Okta, Entra ID, GitLab) en lugar del servidor OAuth integrado, y llegan versiones nuevas de los operadores habituales: Service Mesh 3.5 (Istio 1.31), GitOps 1.22 y Pipelines 1.24.
Lo que cambia en el ciclo de vida
Aquí está la novedad con más impacto para quien planifica:
| OpenShift 4 | OpenShift 5 | |
|---|---|---|
| Soporte estándar por versión | 18 meses | 24 meses (12 completo + 12 mantenimiento) |
| Versiones de soporte largo | EUS | ELC: una de cada tres, desde la 5.2, hasta 5 años con un complemento |
| Cuándo salen las de soporte largo | — | Siempre entre junio y septiembre |
| Versiones mayores | — | Cada 3 años, un año después de cada RHEL mayor |
Además, ACM, Quay, OpenShift Data Foundation, OpenShift Virtualization y, desde la 5.0, Advanced Cluster Security comparten el ciclo de vida de la plataforma, y habrá versiones de Logging, GitOps, Pipelines, Service Mesh y cert-manager alineadas con cada ELC. Red Hat dice que un despliegue con esos complementos puede quedar fijado hasta cinco años aplicando solo parches de seguridad y correcciones. También anuncia, como plan, actualizaciones que salten directamente de una ELC a la siguiente con un único reinicio de nodos.
Lo que hay que mirar antes de actualizar
No hay APIs que desaparezcan en el anuncio, pero sí tres cosas que cambian la planificación:
- Solo se llega desde la 4.22. Un clúster en 4.21 o anterior tiene que pasar antes por la 4.22.
- Dos sistemas operativos. Un clúster actualizado desde la 4.22 sigue en RHEL CoreOS 9; uno instalado de cero en 5.0 arranca con RHEL CoreOS 10. Si tienes clústeres de los dos tipos, tendrás nodos con kernels y paquetes distintos bajo la misma versión de OpenShift. Red Hat promete poder mezclar ambos en un clúster en una versión futura, no en la 5.0.
- Los operadores, uno a uno. El nuevo planificador de actualizaciones de operadores reúne en una vista el estado de ciclo de vida, la compatibilidad con el clúster y las versiones disponibles de cada operador. Es lo primero que hay que abrir: el ejemplo de Red Hat muestra operadores que siguen funcionando pero ya están fuera de soporte o son incompatibles con la versión del clúster.
Cómo actualizar desde la 4.22
Red Hat describe el salto como una actualización menor más: mismo flujo, sin plan de migración. En palabras de Mike Barrett, vicepresidente de plataformas de nube híbrida: "si estás acostumbrado a ir de la 4.21 a la 4.22, puedes ir de la 4.22 a la 5.0". El procedimiento es el habitual de oc; antes de lanzarlo, comprueba el estado del clúster:
# Versión actual, canal y actualizaciones disponibles
oc get clusterversion
oc adm upgrade
# Ningún operador del clúster degradado ni a medio actualizar
oc get clusteroperators
# Nodos listos y pools de máquinas sin cambios pendientes
oc get nodes
oc get machineconfigpoolsLos canales y las rutas exactas hacia la 5.0 están en las notas de la versión y en la herramienta de rutas de actualización de Red Hat; el análisis de preparación de la consola hace la misma comprobación de forma automática.
Checklist antes de producción
- Llevar un clúster de preproducción a la 4.22 y dejarlo estable unos días.
- Revisar en el planificador de operadores que todos los operadores instalados tienen versión compatible con la 5.0 y siguen en soporte; actualizar antes los que no.
- Ejecutar el análisis de preparación de la actualización y resolver los bloqueos que señale.
- Decidir qué hacer con los clústeres nuevos: si se instalan en 5.0 llevarán RHEL CoreOS 10, así que hay que validar ahí los DaemonSets, módulos de kernel y agentes de seguridad que hoy corren en RHCOS 9.
- Actualizar preproducción a la 5.0, pasar las pruebas de las aplicaciones y repetir el proceso en producción.
- Revisar el calendario: con 24 meses de soporte y la primera ELC en la 5.2, quien hoy vive en una EUS de la 4 puede planificar su siguiente parada larga.
Fuentes
- What's new in Red Hat OpenShift 5 (Red Hat Blog, 2026-11-09)
- Red Hat OpenShift 5 delivers innovation and predictability for the long haul (Red Hat Blog, 2026-11-09)
- Red Hat OpenShift 5 for developers (Red Hat Developer, 2026-11-09)
- Red Hat OpenShift 5 update focused on AI, extending life cycles (SDxCentral, 2026-11-09)
- Red Hat OpenShift 5 Brings AI Agents to Cluster Troubleshooting and Upgrades (Virtualization Review, 2026-11-09)