Kubernetes 1.34 llega hoy a EOL upstream: planifica la salida de la rama
El proyecto fija el 27 de octubre como fin de vida de Kubernetes 1.34. El último parche es 1.34.12; el cambio afecta al soporte upstream, no detiene por sí solo los clústeres.
Kubernetes 1.34 llega hoy, 27 de octubre, a su fecha de fin de vida en upstream. El proyecto deja de mantener la rama comunitaria con parches regulares, incluidos los de seguridad; el último publicado es 1.34.12, del 15 de septiembre. No es una alarma de caída automática: los clústeres continúan ejecutándose, pero el contrato de soporte de la rama ya cambió.
La página de releases de Kubernetes mantiene ahora las ramas 1.35, 1.36 y 1.37 como las tres series activas. La 1.34 sale de ese conjunto, así que un equipo que dependa de correcciones nuevas upstream tiene que planificar la actualización y comprobar qué piezas del clúster siguen usando componentes de esa línea.
-InfraCrew dice: El control plane no se apaga al llegar la fecha, pero la próxima CVE tampoco espera a que termine tu CAB.-
Qué termina y qué no
El ciclo habitual del proyecto reserva alrededor de catorce meses a cada serie: un periodo estándar y una fase de mantenimiento de dos meses. Durante esta última pueden aparecer correcciones de seguridad con CVE, dependencias y problemas críticos; al llegar a EOL, el equipo de releases considera cerrada la rama y deja de aceptar nuevos backports ordinarios. EOL describe el soporte del proyecto, no una acción que detenga procesos ya desplegados.
Por eso conviene separar tres preguntas que a menudo aparecen juntas en un ticket: qué versión corre cada componente, si el proveedor que entrega el clúster aún la soporta y qué riesgo implica seguir en ella. Un entorno autogestionado depende directamente del ciclo upstream; un servicio gestionado puede aplicar otro calendario comercial o de soporte extendido. Ese calendario no prolonga automáticamente el mantenimiento de la rama comunitaria ni debe deducirse de la versión que muestra el panel del proveedor.
La última versión upstream de la serie es 1.34.12. Quien siga en un patch anterior no solo se queda fuera de futuras correcciones: también debe comparar su punto de partida con la ruta de actualización disponible y con los requisitos de los componentes añadidos por la distribución. No hay una recomendación universal de saltar directamente a 1.37 sin revisar el soporte del fabricante, los complementos instalados y las restricciones de cambio del entorno.
-InfraCrew dice: “El clúster sigue verde” mide salud ahora; no responde si alguien seguirá publicando el parche que necesitas mañana.-
La versión del nodo no cuenta toda la historia
La política de desfase de Kubernetes permite que kubelet esté hasta tres versiones menores por detrás del API server, dentro de las combinaciones documentadas. Eso significa que un nodo en 1.34 puede seguir dentro de la ventana de skew frente a un control plane más nuevo, dependiendo de la versión exacta. El margen de compatibilidad no equivale a soporte de seguridad para la rama 1.34: una combinación aceptada por la política no devuelve a la serie al calendario de parches.
Antes de abrir una ventana, inventaría control plane, kubelets y herramientas de gestión por separado. Añade la versión del proveedor de Kubernetes, el CNI, CSI, admission controllers y operadores que tengan su propio ciclo de releases. En clusters gestionados, consulta la tabla de versión y las fechas del servicio concreto; en autogestionados, revisa la secuencia de upgrades soportada por la herramienta de bootstrap. El inventario debe terminar en un mapa de dependencias, no en una sola cifra pegada al nombre del clúster.
El plan más seguro es ensayar la transición en un entorno representativo y verificar APIs retiradas, operadores, almacenamiento y ventanas de disponibilidad antes de tocar producción. Si la organización no puede actualizar todos los nodos a la vez, puede estudiar una secuencia compatible de control plane y workers con su proveedor, siempre dentro de las reglas de skew. No mantengas un componente sin parches solo porque la aplicación aún responde: estabilidad funcional y mantenimiento de seguridad son señales distintas.
-InfraCrew dice: El upgrade que solo probó el API server deja para la ventana real la sorpresa de los CSI, que suelen tener su propio calendario.-
Una fecha para convertir en trabajo
Hoy no hace falta declarar incidente cada clúster en 1.34; sí hace falta cambiar su prioridad en el backlog. Marca los entornos que siguen en esa serie, asigna dueño y versión objetivo, y separa las excepciones justificadas de los sistemas que simplemente no tienen inventario. Cuando el proveedor ofrece una rama extendida, registra sus fechas y condiciones; cuando no, la rama queda sin cobertura upstream para nuevos fallos.
La actualización debe cerrarse con evidencia: versión real del API server y de los nodos, workloads recuperados, políticas de red y almacenamiento operativas, y una ruta de rollback probada según el procedimiento del entorno. El final de soporte no prueba que haya una vulnerabilidad nueva en tu instalación; indica que la siguiente puede no recibir una corrección para esa rama. Esa diferencia basta para que 1.34 deje de ser una versión “pendiente algún día” y pase a una decisión con fecha y responsable.
Diccionario de la Crew
EOL — Fin del ciclo de mantenimiento de una versión; para Kubernetes upstream, deja de recibir parches ordinarios.
Rama menor — Línea x.y de Kubernetes que recibe sus propias versiones de parche, como 1.34.x.
kubelet — Agente que se ejecuta en cada nodo y mantiene los pods asignados a ese nodo.
Version skew — Diferencia de versiones entre componentes que la política del proyecto permite durante una actualización.
Fuentes
Kubernetes — versiones y fin de vida
Kubernetes — política de desfase de versiones
