Kubernetes 1.34 dejará de recibir mantenimiento el 27 de octubre
La rama 1.34 llega a fin de vida el 27 de octubre de 2026. Quedan doce días para planificar el salto a una versión mantenida y comprobar la compatibilidad de extensiones.
Kubernetes 1.34 tiene fijado el 27 de octubre de 2026 como fecha de fin de vida. A 15 de octubre quedan doce días para que la rama salga de mantenimiento. Después de esa fecha, el proyecto deja de aceptar backports de correcciones a 1.34, salvo excepciones puntuales que pudiera decidir; no conviene planificar como si los parches continuaran por inercia.
La rama entró en mantenimiento el 27 de agosto, tras cerrar su periodo ordinario de parches. Ese intervalo final permite corregir algunos problemas de seguridad importantes mientras los equipos preparan la actualización. El EOL afecta a la rama menor completa, no a un único patch level: estar en 1.34.12 resuelve problemas conocidos hoy, pero no mantiene la rama bajo soporte una vez alcanzado el corte.
La fecha es el comienzo de la planificación
El calendario oficial publica el último patch release y la fecha EOL; las notas de la serie 1.34 documentan cambios desde el lanzamiento. La noticia no obliga a saltar directamente a la versión más reciente sin pruebas: el destino depende de la distribución del clúster, el proveedor y las versiones de APIs, runtime, CNI, CSI y operadores desplegados.
Para clústeres gestionados, comprueba primero el calendario del servicio cloud o de la distribución comercial. Algunos proveedores mantienen una ventana propia que puede diferir del upstream o imponer límites adicionales. En clústeres autogestionados, revisa la política de skew entre control plane y nodos, las APIs deprecadas y las instrucciones de actualización de la plataforma. Un upgrade de Kubernetes es una operación de plataforma, no un cambio aislado de imagen de contenedor.
-InfraCrew dice: doce días parecen una ventana generosa hasta que entran en la matriz CSI, tres operadores y el único clúster que nadie quiere tocar.-
-InfraCrew dice: un clúster sin fecha de upgrade no tiene calendario; tiene una sorpresa con fecha conocida.-
Qué revisar antes del salto
Inventaría versiones exactas de control plane y workers, proveedor, add-ons y controladores. Cruza esa matriz con la versión objetivo y sus notas. Si un operador usa una API retirada en el destino, corrige manifiestos y valida reconciliación antes del mantenimiento. Prueba restauración y recuperación del plano de control cuando aplique y acuerda un orden que permita detectar fallos antes de ampliar el cambio.
No confundas soporte upstream con soporte contractual: un proveedor puede ofrecer cobertura extendida, pero hay que confirmarlo en sus propios términos. Tampoco des por hecho que el clúster se actualizará porque la consola muestre un botón. El mecanismo automatizado puede tener condiciones de versión, canal o ventana que conviene validar.
La fecha es concreta; el impacto depende de cada instalación. Si el cambio no cabe en la ventana operativa, deja registrado quién mantiene la rama, qué cobertura existe y cuándo se completa la migración. El 28 de octubre ya no será razonable esperar correcciones ordinarias del proyecto para una rama cerrada.
La cadencia upstream es una referencia, no un sustituto del ciclo de vida de la distribución. Una distribución empresarial puede aplicar parches propios o extender soporte de componentes concretos, mientras un proveedor gestionado puede bloquear upgrades por compatibilidad o facturación. Confirma cuál de esas capas responde por el clúster antes de decidir que una fecha de upstream describe exactamente tu cobertura. El manifiesto por sí solo no revela toda la dependencia: anota también charts, webhooks y agentes instalados fuera del repositorio principal.
-InfraCrew dice: instalar el patch release más nuevo no compensa saltarse la matriz de compatibilidad.-
Diccionario de la Crew
EOL — Fin de vida: fecha tras la cual una rama deja de recibir mantenimiento ordinario.
Backport — Adaptación de una corrección nueva a una versión anterior mantenida.
CNI / CSI — Interfaces de Kubernetes para integrar redes y almacenamiento.
Fuentes
- Kubernetes — https://kubernetes.io/releases/patch-releases/
- Kubernetes 1.34 — https://kubernetes.io/releases/1.34/
