Kubernetes 1.34 encara el fin de soporte upstream el 27 de octubre

El soporte upstream de Kubernetes 1.34 termina el 27 de octubre de 2026. A fecha de hoy quedan nueve días de calendario: el proyecto sitúa el inicio del modo mantenimiento el 27 de agosto y marca el fin de vida para el 27 de octubre. No es un apagado automático de los clústeres, pero sí una fecha que cambia la expectativa de correcciones para la rama; cualquier infraestructura que siga en ella necesita un plan fechado.

El ciclo de Kubernetes mantiene cada serie activa durante aproximadamente catorce meses: doce en el periodo estándar y cerca de dos en mantenimiento. En ese último tramo, sus responsables pueden aceptar correcciones de vulnerabilidades con CVE, dependencias o fallos críticos; el calendario no promete nuevas versiones indefinidamente. Cuando se alcanza el fin de vida (EOL), la serie se considera fuera de soporte y el proceso de cherry-pick de cambios para esa rama se cierra poco después.

El upstream y el proveedor usan calendarios distintos

Un servicio gestionado puede retirar una versión antes de que llegue el EOL upstream. STACKIT Kubernetes Engine (SKE) indicó que retiraría Kubernetes 1.34 de su oferta el 14 de octubre a las 08:00 UTC. Su nota establece que los clústeres que siguieran en 1.34 pasarían automáticamente a 1.35 durante su ventana de mantenimiento. Esa fecha del proveedor ya pasó; el equipo que usa SKE debería confirmar qué versión ejecuta ahora cada clúster y si la migración automática ya se produjo.

-InfraCrew dice: “EOL el 27” no retrasa una ventana del proveedor que cayó el 14; los calendarios no se sincronizan por telepatía.-

El calendario de STACKIT no se puede extrapolar a otras nubes ni a instalaciones propias. Cada servicio define qué versiones ofrece, cuándo las retira y si migra automáticamente. Quien opera Kubernetes sobre máquinas virtuales o bare metal conserva su propio proceso; la fecha de SKE solo aplica a sus clústeres. Por eso el primer filtro no es preguntar únicamente “¿seguimos en 1.34?”, sino localizar quién opera cada plano de control, cuál es la versión efectiva en todos los entornos y qué política de mantenimiento se aplica.

Un plan de salida que se pueda ejecutar

Empieza por un inventario que incluya producción, preproducción, recuperación ante desastres y clústeres de equipos de desarrollo. Registra versión del plano de control y de los nodos, proveedor, región, responsable y ventana disponible. La consola puede mostrar una versión objetivo mientras los nodos aún terminan su ciclo; comprueba el estado real por entorno y asigna una persona a cada excepción, en vez de dejar una lista de números en una hoja sin dueño.

-InfraCrew dice: Un clúster huérfano no aparece en las reuniones de capacidad, pero sí reaparece cuando alguien busca su endpoint.-

Después, elige un destino que el operador marque como soportado y revisa su ruta de actualización. No des por hecho que todas las plataformas permiten el mismo salto, orden de componentes o tiempo de indisponibilidad. Antes de mover producción, contrasta las notas de la versión objetivo con las APIs que consumen tus aplicaciones, los controladores de admisión, los operadores y las versiones de CNI y CSI instaladas. Si algo deja de estar soportado en el destino, arreglarlo en el mismo cambio multiplica las variables difíciles de depurar.

Prueba esa ruta en un entorno representativo con despliegues, almacenamiento persistente, balanceo, políticas de red y observabilidad. Comprueba que la copia de seguridad puede restaurarse y acuerda cómo detener o revertir la operación según lo que permita tu plataforma. Una prueba que solo valida que el API server responde no demuestra que los volúmenes se montan, que las rutas de entrada funcionan o que los trabajos programados terminan.

-InfraCrew dice: “El nodo está Ready” es un buen comienzo; como informe de pruebas end-to-end necesita un par de páginas más.-

Por último, reserva el cambio con tiempo para revisar alertas, coordinar a los equipos de aplicaciones y confirmar dependencias con el proveedor. Si una actualización de emergencia no cabe en la ventana prevista, registra qué riesgo queda aceptado, quién puede mitigarlo y cuándo se revisará. La fecha del 27 de octubre no obliga a hacer una actualización precipitada durante la guardia; sí obliga a decidir antes si el entorno seguirá recibiendo el mantenimiento que necesita.

Diccionario de la Crew

Modo mantenimiento — tramo final de soporte de una serie; puede aceptar solo tipos limitados de cambios.

Fin de vida (EOL) — fecha en que una serie deja de formar parte del periodo de mantenimiento previsto.

Cherry-pick — selección y aplicación de un cambio concreto a una rama de software distinta de aquella donde se desarrolló.

Ventana de mantenimiento — periodo acordado por el servicio o el operador para aplicar cambios planificados al clúster.