Kubernetes 1.34 termina su soporte upstream el 27 de octubre; EKS sigue otro calendario
La rama upstream Kubernetes 1.34 llega a EOL el 27 de octubre. Amazon EKS mantiene soporte estándar hasta el 2 de diciembre y extendido hasta el 2 de diciembre de 2027, con condiciones y coste propios.
Kubernetes 1.34 llega al fin de vida (EOL) del proyecto el 27 de octubre de 2026. La rama entró en mantenimiento el 27 de agosto y solo acepta correcciones de seguridad críticas; el listado oficial mantiene 1.34.12, publicado el 15 de septiembre, como último parche disponible. Tras la fecha EOL, el proyecto deja de ofrecer soporte y parches ordinarios de seguridad y errores para esa rama.
La fecha está a seis días, pero no todos los clústeres que muestran “1.34” comparten el mismo calendario. Los despliegues autogestionados siguen el soporte upstream del proyecto, mientras que cada proveedor gestionado puede ofrecer un periodo distinto y aplicar sus propias condiciones. La versión del API no basta para decidir la urgencia: también hay que saber quién mantiene el plano de control, los nodos y sus componentes.
-InfraCrew dice: La fecha upstream no mira si el comité de cambios ya encontró hueco en el calendario.-
La diferencia entre upstream y EKS
Amazon EKS publica soporte estándar para Kubernetes 1.34 hasta el 2 de diciembre de 2026 y soporte extendido hasta el 2 de diciembre de 2027. AWS explica que sus versiones reciben catorce meses de soporte estándar desde su disponibilidad en EKS y, después, otros doce meses de soporte extendido con coste adicional por hora de clúster. El soporte extendido viene habilitado por defecto en los clústeres nuevos y existentes salvo que se cambie la política. Ese plazo es un compromiso de AWS, no una prórroga del mantenimiento de la comunidad de Kubernetes ni una fecha aplicable a otros proveedores.
Durante el soporte extendido, AWS afirma que sigue publicando parches de seguridad para el plano de control y determinados complementos y AMI optimizadas. La documentación también advierte que, al acabar el ciclo de 26 meses, EKS puede actualizar automáticamente el plano de control; los nodos autogestionados y los grupos gestionados no se actualizan a la vez. Que el plano de control avance no significa que el clúster entero haya terminado la migración.
-InfraCrew dice: El proveedor puede sostener el control plane unos meses más; tus nodos no reciben la noticia por telepatía.-
Qué revisar antes del cambio
Empieza por inventariar versiones y separar proveedores: distingue las instalaciones autogestionadas de EKS y de otros servicios Kubernetes administrados. En EKS, identifica qué clústeres pasarían a soporte extendido, confirma la política de actualización y calcula el coste en función de su uso. En cualquier plataforma, comprueba versiones de nodos, CNI, CSI, ingress y operadores; actualizar solo el control plane deja una fila de piezas que aún puede necesitar trabajo.
La revisión de compatibilidad debe incluir las API que usan los manifiestos y charts, además de los procedimientos de mantenimiento de aplicaciones con estado. Prueba el salto en un entorno representativo, observa el comportamiento de los nodos y valida restauración y monitorización antes de repetirlo en producción. No hay una receta universal de salto: el proveedor, la versión de destino y los complementos cambian el orden y las restricciones.
-InfraCrew dice: Una subida de versión cabe en una ventana; descubrir después que el controlador de almacenamiento no cabía en ella suele ocupar bastante más.-
La diferencia de fechas permite priorizar sin caer en dos errores: dejar una instalación autogestionada en una rama que ya no recibe mantenimiento o tratar un clúster EKS como si AWS retirase su soporte el mismo día que upstream. El proyecto publica 1.35 y 1.36 como ramas vigentes; AWS conserva su propio calendario para EKS 1.34. La fecha correcta sale del proveedor y del modo de operación concretos, y la tarea de nodos y complementos debe quedar asignada explícitamente.
Diccionario de la Crew
Fin de vida (EOL) — Fecha a partir de la que el proyecto deja de mantener una rama y de publicar sus correcciones ordinarias.
Plano de control — Componentes que exponen y gestionan el estado del clúster, separados de los procesos que ejecutan las cargas.
Soporte extendido — Periodo adicional de soporte de un proveedor después del soporte estándar; alcance, coste y tareas cubiertas dependen de ese proveedor.
Fuentes
- Kubernetes — calendario de releases y soporte | https://kubernetes.io/releases/
- Amazon EKS — ciclo de vida de versiones de Kubernetes | https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html
