Kubernetes caduca cada catorce meses, y no se saltan versiones

El 27 de octubre de 2026, la rama 1.34 de Kubernetes deja de recibir parches. No es una noticia ni un susto de última hora: esa fecha estaba publicada desde que la versión salió. Y aun así, en octubre habrá quien se entere leyendo un aviso de seguridad.

La política está escrita en una sola frase de la documentación del proyecto: la comunidad mantiene cada serie de parches durante «roughly fourteen (14) months». Doce meses normales más dos finales en modo mantenimiento. El proyecto mantiene «release branches for the most recent three minor releases» —hoy la 1.35, la 1.36 y la 1.37—, y por el solape de esos dos meses finales la 1.34 todavía recibe parches hasta el 27 de octubre.

Las fechas de caducidad publicadas son estas, y conviene verlas juntas porque juntas dicen algo que por separado no se ve: la 1.35 entra en modo mantenimiento el 28 de diciembre de 2026 y muere el 28 de febrero de 2027; la 1.36, el 28 de abril y el 28 de junio de 2027; la 1.37, el 28 de agosto y el 28 de octubre de 2027. Resta las tres fechas de defunción: febrero, junio, octubre. Cada cuatro meses caduca una versión, mientras el proyecto mantenga esa cadencia. Eso es lo que firmas el día que adoptas Kubernetes, y lo firmas para todos los años, no para el primero.

Qué significa «modo mantenimiento»

Los dos últimos meses de cada rama no son iguales que los doce anteriores, y la diferencia está escrita. En modo mantenimiento, los responsables de publicación solo sacan versiones nuevas para tres cosas: vulnerabilidades con identificador CVE asignado, problemas de dependencias —incluida la actualización de la imagen base— y fallos críticos de componentes del núcleo. Nada más.

Traducido a una mañana de trabajo: ese fallo raro que te encontraste, el que no es crítico ni tiene CVE, el que vas a reportar con un caso de reproducción bien hecho, ya no se arregla en tu rama. Se arregla en otra, a la que todavía no te has movido. Es una decisión razonable de un proyecto que va a su ritmo, pero es una decisión que tomas tú por omisión cuando llegas tarde.

La regla que convierte el calendario en un proyecto

Aquí está la parte que la gente descubre tarde. La política de versiones del proyecto exige que «kube-apiserver to not skip minor versions when upgrading, even in single-instance clusters». No se saltan versiones menores en el plano de control. Ni siquiera en un clúster de una sola máquina, donde uno pensaría que nadie se va a enterar.

La cuenta de los saltos

Así que la deuda no se paga de una vez. Si hoy corres la 1.33 y quieres llegar a la 1.37, son cuatro actualizaciones encadenadas: 1.34, 1.35, 1.36 y 1.37. Cuatro juegos de notas de versión que leer, cuatro tandas de APIs retiradas que comprobar contra tus manifiestos, cuatro ventanas. Una versión por detrás es una tarde. Cuatro versiones por detrás es un proyecto con nombre, presupuesto y una reunión para decidir cuándo se hace.

Los nodos, en cambio, tienen holgura: el kubelet puede ir hasta tres versiones menores por detrás del kube-apiserver —dos si es anterior a la 1.25—, y kubectl se soporta dentro de una versión por arriba o por abajo. Esa holgura es útil y está pensada para que una actualización pueda hacerse por fases. También es, en nuestra experiencia, la razón por la que un clúster parece sano mientras se va quedando atrás: los nodos siguen funcionando, nadie ve nada roto, y el margen se consume en silencio.

El calendario que no sale en ese calendario

Las fechas de arriba son las del proyecto Kubernetes. Tu clúster no es solo Kubernetes. Encima hay un controlador de entrada, un plugin de red, uno o varios controladores de almacenamiento, un emisor de certificados, la pila de métricas y, casi siempre, algún operador que gestiona una base de datos que a nadie le apetece tocar. Cada una de esas piezas tiene ciclo propio, matriz de compatibilidad propia y un mantenedor que no sabe que existes, y ninguna de esas fechas aparece en la página de versiones de Kubernetes.

Ya contamos aquí lo que pasó con el controlador de entrada que estaba en media plataforma Kubernetes y lo mantenían dos personas. Ese aviso no llegó en las notas de una versión menor de Kubernetes, porque no era de Kubernetes. Llegó por su lado, con su propio plazo. Actualizar un clúster de verdad es resolver la intersección de varias matrices de compatibilidad que van a ritmos distintos; el comando es el último paso y el más corto. Esa intersección es la que decide qué día puedes actualizar y qué día no.

Esto no es un defecto de Kubernetes

Conviene decirlo claro, porque el texto podría leerse como una pega y no lo es. Publicar tres versiones menores al año es precisamente lo que permite que el proyecto avance a la velocidad a la que avanza, y publicar las fechas de caducidad con más de un año de antelación es lo contrario de un fabricante que retira un producto por sorpresa. Nosotros preferimos un calendario duro y público a una promesa blanda.

Lo que sí cambia es la pregunta que hay que hacerse antes de adoptarlo. Antes de adoptarlo hay que contestar una pregunta que no es de tecnología sino de plantilla: quién ejecuta tres ventanas de mantenimiento al año en esta casa, durante los próximos cinco años. En everyWAN operamos Kubernetes y Docker Swarm, ofrecemos Kubernetes gestionado igual que operamos Swarm, y elegimos según el caso y no según la comisión, porque no somos revendedores de ninguna plataforma. Y por eso lo decimos sin rodeos: un clúster bien diseñado envejece mal en cuanto el calendario se queda sin dueño.

Hay además un detalle de método que va en la misma dirección y que ya escribimos en otro sitio: «latest» no es una versión. Si tus despliegues no fijan versiones, este calendario no te sirve de nada, porque no sabes qué estás ejecutando y por tanto no sabes qué día caduca.

Cinco preguntas que deberías poder contestar hoy

• ¿Qué versión menor corres y qué día caduca? Un kubectl version y la tabla de versiones de parches del proyecto. Si la respuesta tarda más de cinco minutos, ya tienes el primer hallazgo.
• ¿Cuántos saltos te separan de la rama viva más antigua? Cada salto es una ventana, porque el plano de control no se salta versiones. Ese número es tu deuda.
• ¿Qué versión mínima de Kubernetes pide cada add-on que tienes puesto? Y, la que duele más, ¿cuál de ellos no soporta todavía la versión a la que quieres ir? Esta pregunta lleva una tarde y no cinco minutos, y es la que manda en tu fecha.
• ¿Quién ejecuta la ventana y con qué plan de vuelta atrás? Con nombre de persona y con el procedimiento escrito, no «lo mira el que esté». Sin marcha atrás documentada, la ventana es una apuesta.
• ¿Quién mira la alerta a las tres de la madrugada del día siguiente? Las 48 horas siguientes a la ventana son las que duelen. Ya escribimos sobre qué alerta merece despertar a alguien y cuál es ruido; esa distinción se decide antes, no esa noche.

Lo que no estamos diciendo

No estamos diciendo que no uses Kubernetes. Lo operamos, lo ofrecemos gestionado y nos parece la herramienta correcta en bastantes casos. Tampoco estamos diciendo que estas fechas sean inamovibles: son las que el proyecto publica hoy, 24 de septiembre de 2026, y el proyecto se reserva variar los calendarios de parcheo según la gravedad de los fallos. Y no hemos comprobado para este post qué ofrece cada proveedor de Kubernetes gestionado en la nube cuando una versión caduca, ni a qué precio; lo que sí sale del calendario oficial es la fecha del proyecto, y esa aplica a todos por igual.

Lo único que defendemos aquí es una cuenta y una consecuencia. La cuenta: catorce meses por rama, tres ramas vivas, una caducidad cada cuatro meses, sin saltos en el plano de control. La consecuencia: el coste de Kubernetes no está en montarlo, está en sostenerlo, y ese coste se paga en ventanas de mantenimiento. Si ese trabajo tiene dueño, el calendario es una agenda. Si no lo tiene, el calendario es una fecha de caducidad que llega sola, un martes, con un aviso de seguridad debajo. Eso es exactamente lo que cubre nuestro soporte IT 24x7, y lo que miramos primero cuando alguien nos pide consultoría sobre una plataforma que ya está en marcha.

Fuentes (consultadas el 24-sep-2026): la frase «roughly fourteen (14) months», el reparto en doce meses más dos en modo mantenimiento, la lista de motivos por los que se corta una versión durante ese periodo (vulnerabilidades con CVE asignado, problemas de dependencias incluida la imagen base, y fallos críticos de componentes del núcleo) y las fechas de modo mantenimiento y fin de vida de la 1.34 (27-08-2026 y 27-10-2026), la 1.35 (28-12-2026 y 28-02-2027), la 1.36 (28-04-2027 y 28-06-2027) y la 1.37 (28-08-2027 y 28-10-2027) están en Patch Releases. Que se mantienen «release branches for the most recent three minor releases» (1.35, 1.36, 1.37) y que las versiones 1.19 y posteriores reciben aproximadamente un año de soporte de parches está en Releases. Las reglas de desfase de versiones —«kube-apiserver to not skip minor versions when upgrading, even in single-instance clusters», el kubelet hasta tres versiones menores por detrás (dos si es anterior a la 1.25), kubectl dentro de una versión, y los apiserver de un clúster en alta disponibilidad dentro de una versión menor— están en Version Skew Policy. Lo que este post NO afirma: el cálculo de «una caducidad cada cuatro meses» es nuestro, hecho restando las tres fechas de fin de vida publicadas, y depende de que la cadencia se mantenga; el proyecto se reserva variar los calendarios de parcheo según la gravedad de los fallos. No hemos verificado qué soporte extendido ofrece cada proveedor de Kubernetes gestionado tras el fin de vida upstream, ni su coste, y por eso no damos ninguna cifra al respecto. No afirmamos que ninguna otra plataforma de contenedores sea mejor ni peor por tener otro ciclo de vida: son compromisos distintos. Y la recomendación de contar los saltos y asignar dueño a la ventana es criterio nuestro, no una recomendación del proyecto.