Kubernetes 1.34.13 aparece un día después del EOL de la rama
El tag oficial 1.34.13 se publicó el 28 de octubre, tras el EOL de Kubernetes 1.34 del día 27; la página de ciclo de vida aún muestra 1.34.12.
Kubernetes 1.34 llegó a su fin de vida upstream (EOL) el 27 de octubre, pero el repositorio oficial publicó el tag 1.34.13 el día 28. La ficha de releases del proyecto sigue indicando 1.34.12, publicada el 15 de septiembre, como el parche más reciente de la serie. Para el equipo que mantiene un clúster propio, la diferencia entre calendario de soporte y artefacto disponible deja de ser una nota académica.
El desfase no significa que la fecha de fin de soporte haya cambiado: la política conserva el 27 de octubre y la rama 1.34 ya no forma parte de las tres series menores que el proyecto mantiene activas: 1.35, 1.36 y 1.37. El tag confirma que existe una compilación 1.34.13, pero la página de ciclo de vida no anuncia una prórroga de mantenimiento. Es una publicación posterior al EOL; por sí sola no promete que vayan a llegar más parches.
-InfraCrew dice: un tag nuevo al día siguiente del EOL merece atención; convertirlo en un contrato de soporte extendido ya es otro deporte.-
Una excepción que no cambia el calendario
No sería la primera publicación que llega después de la fecha prevista para una rama. La ficha oficial recoge precedentes como Kubernetes 1.26.15, publicado después del EOL para incorporar una versión nueva de Go, y 1.25.16, publicado después de su fecha para corregir CVE-2023-5528. Esos antecedentes explican por qué puede aparecer un parche tardío, pero no transforman cada lanzamiento extraordinario en una ampliación del ciclo de vida.
Aquí hay además dos vistas oficiales que conviene no mezclar. El repositorio de Kubernetes muestra v1.34.13 con fecha de publicación del 28 de octubre; la página central de releases todavía sitúa 1.34.12 como último parche de la serie y mantiene el EOL del día 27. La divergencia documental es concreta: una fuente confirma el nuevo tag y la otra conserva el estado de soporte que tenía la rama al cerrarse su calendario.
Para producción, la disponibilidad de un binario upstream tampoco demuestra que el proveedor de un servicio Kubernetes gestionado lo haya publicado, probado o incluido en su compromiso de soporte. Cada plataforma puede mantener una cadencia y una matriz propias. El inventario debe distinguir la versión upstream de la versión ofrecida por el proveedor y de la que realmente ejecuta cada entorno.
-InfraCrew dice: el número de versión que muestra una consola del proveedor y el que aparece en el tag upstream pueden describir calendarios distintos; las dos etiquetas no se sincronizan por telepatía.-
Qué revisar en los clústeres
Empieza por identificar los clústeres que aún ejecutan la rama 1.34, incluidos los entornos de pruebas olvidados que terminan atendiendo una recuperación real. Registra la versión del plano de control y de los nodos según la información que exponga tu distribución, junto con la fecha de la última actualización. No deduzcas la versión del servidor a partir de la versión local de kubectl: son componentes distintos y pueden avanzar en momentos diferentes.
Si el proveedor ya ofrece 1.34.13, revisa qué incluye ese paquete y qué instrucciones de actualización aplican a su distribución antes de programar una ventana. Si el proveedor no lo ofrece, no instales binarios upstream por intuición: confirma su ruta soportada y el estado de las imágenes de nodo, plugins de red y almacenamiento, controladores y webhooks. La misma versión upstream no vuelve idénticas dos plataformas administradas.
En instalaciones propias, trata 1.34.13 como una corrección que merece evaluación, no como motivo para aplazar el cambio a una rama mantenida. Comprueba también las APIs usadas por tus cargas y los requisitos de las extensiones antes de migrar; un clúster puede estar sano hoy y descubrir incompatibilidades justo cuando el equipo intenta salir de una rama sin mantenimiento ordinario.
-InfraCrew dice: el parche excepcional puede comprar tiempo para una actualización ordenada; no convierte ese tiempo en soporte garantizado.-
El proyecto mantiene actualmente 1.35, 1.36 y 1.37. La decisión operativa es revisar tanto el artefacto como el ciclo de vida: confirmar si 1.34.13 está disponible para tu distribución, aplicar la ruta que su fabricante respalda y planificar la salida de 1.34. La presencia de un tag nuevo es una buena señal para quien espera un arreglo concreto, pero una mala excusa para dejar el inventario sin fecha de migración.
Diccionario de la Crew
EOL — Fecha en que una rama upstream termina su periodo ordinario de mantenimiento; una publicación excepcional no implica por sí misma una prórroga.
Clúster — Conjunto de componentes y nodos Kubernetes que colaboran para ejecutar y administrar cargas.
