Ilustración conceptual de los calendarios de soporte que compara el artículo. La imagen llama Extended Support a la fecha posterior de Azure; la tabla del artículo la llama LTS.
Kubernetes 1.34 llega al final de su ciclo de soporte upstream (el del propio proyecto Kubernetes) el 27 de octubre de 2026. A partir de esa fecha, el proyecto Kubernetes dejará de publicar de forma habitual actualizaciones de seguridad o correcciones de errores para la rama de la versión 1.34.
Para las organizaciones que operan sus propios planos de control de Kubernetes, esa fecha límite les afecta directamente. Un clúster con la 1.34 puede seguir dando servicio a sus cargas de trabajo, pero es posible que los problemas que se descubran a partir de ahora ya no reciban correcciones upstream para esa versión.
La situación es distinta para los equipos que usan Kubernetes gestionado.
Amazon EKS, Azure Kubernetes Service (AKS) y Google Kubernetes Engine (GKE) mantienen sus propios calendarios de versiones y, en algunos casos, opciones de soporte extendido. Por eso, un clúster con Kubernetes 1.34 en un proveedor puede seguir teniendo soporte durante más tiempo que la misma versión menor en otro.
La pregunta operativa inmediata no es solo si un clúster ejecuta la 1.34. Es quién mantiene esa distribución, qué periodo de soporte se aplica y si el clúster puede completar una actualización con soporte sin interrumpir sus cargas de trabajo.
Una versión de Kubernetes, cuatro calendarios de soporte
El proyecto Kubernetes mantiene actualmente las tres ramas menores más recientes: 1.35, 1.36 y 1.37. La versión 1.34 entró en modo de mantenimiento el 27 de agosto de 2026, y su último parche publicado en el momento de esta revisión es el 1.34.12.
Los proveedores de servicios gestionados amplían o gestionan de otro modo el soporte mediante sus propias versiones probadas, políticas de mantenimiento y condiciones de ciclo de vida.
| Plataforma | Fin del soporte de Kubernetes 1.34 | Qué significa |
|---|---|---|
| Upstream / autogestionado | 27 de octubre de 2026 | Terminan las versiones de parche upstream (desde el 27 de agosto solo se aceptaban correcciones de seguridad críticas) |
| Amazon EKS | Estándar: 2 de diciembre de 2026. Extendido: 2 de diciembre de 2027 | El soporte extendido está activado por defecto (política de actualización EXTENDED) con un costo adicional por hora de clúster. Al terminar el soporte extendido, el clúster se actualiza automáticamente |
| Azure AKS | Fin de vida estándar: noviembre de 2026. LTS: noviembre de 2027 | El ciclo de vida ampliado depende de la inscripción y de cumplir los requisitos. Los meses publicados no son fechas exactas |
| Google GKE | Estándar: 25 de enero de 2027. Extendido: 25 de noviembre de 2027 | El soporte extendido solo se aplica a los clústeres inscritos en el canal de versiones Extended |
Fuentes: calendario de versiones de Kubernetes, ciclo de vida de Amazon EKS, versiones compatibles de AKS y calendario de versiones de GKE. Las fechas están vigentes a 26 de octubre de 2026, y los calendarios de los proveedores pueden cambiar.
Las diferencias tienen importancia operativa.
Un equipo de EKS con un clúster cerca de la fecha límite del soporte estándar de diciembre puede tener tiempo para programar una actualización controlada, aunque los cargos del soporte extendido y las futuras actualizaciones gestionadas por el proveedor influyen en esa decisión.
En AKS, la situación exacta de soporte de un clúster depende de su inscripción en el ciclo de vida y de la versión compatible. El soporte a largo plazo nunca se activa automáticamente. El clúster debe inscribirse de forma explícita.
El canal Extended de GKE mantiene el soporte de una versión menor hasta el final de su soporte extendido, mientras que los clústeres de los demás canales de versiones (Rapid, Regular y Stable) siguen el calendario de soporte estándar y de actualizaciones automáticas.
Un clúster autogestionado no recibe ninguno de esos acuerdos por el mero hecho de que sus componentes upstream sigan funcionando. Para seguir teniendo soporte necesitaría un proveedor de distribución adecuado, un proveedor de soporte o una estrategia de parches mantenida internamente.
Qué deben revisar primero los equipos de plataforma
Antes de modificar un clúster, determina la versión real de su plano de control y las versiones que se ejecutan en sus nodos.
Para un clúster accesible mediante kubectl, dos comandos útiles son:
kubectl version
kubectl get nodes -o wideEl primero muestra la información de versión del cliente y del servidor. El segundo muestra los detalles de los nodos, incluidas las versiones de kubelet.
Estos comandos sirven como punto de partida, pero no le dicen al operador si la política de soporte del servicio gestionado cubre esa versión.
En EKS, AKS o GKE, revisa la versión de Kubernetes configurada en el clúster, su canal de versiones o su política de soporte en la interfaz de administración o la CLI del proveedor. Incluye en el inventario los grupos de nodos (node pools) y los componentes que se gestionan por separado.
El plano de control y los nodos no pasan necesariamente a una nueva versión menor al mismo tiempo.
Un proveedor de servicios gestionados puede actualizar el plano de control automáticamente y, aun así, exigir una acción aparte para algunos grupos de nodos. En los clústeres autogestionados, normalmente son los operadores quienes deben coordinar ambas partes del proceso.
Por lo tanto, un inventario debería recoger la distribución de Kubernetes, la versión del plano de control, las versiones de los nodos y de los grupos de nodos, la fecha límite de soporte, la política de actualización y cualquier restricción de mantenimiento documentada.
Esa información determina si el siguiente paso es una actualización urgente de una versión sin soporte, un cambio de mantenimiento planificado o la verificación de que ya hay activo un acuerdo de soporte extendido.
Planifica la actualización en función de la compatibilidad, no solo de la fecha
En los clústeres de Kubernetes autogestionados con kubeadm, actualizar de la 1.34 a la 1.35 es el siguiente paso de versión menor con soporte. El proceso de actualización de kubeadm no admite saltar directamente de la 1.34 a la 1.36 o a la 1.37.
Los servicios gestionados pueden automatizar partes de la actualización, pero hay que seguir por separado sus rutas compatibles y sus requisitos previos.
Kubernetes también mantiene una política de desfase de versiones (version skew) que regula las versiones de los componentes del plano de control, de los kubelets y de otros servicios del clúster.
Un kubelet no debe ser más reciente que el servidor de API con el que se comunica. Según la política actual, en general puede ser hasta tres versiones menores más antiguo, con restricciones adicionales en los clústeres que tienen servidores de API de versiones distintas.
Esto permite actualizar el plano de control y los nodos por etapas, pero no significa que todas las combinaciones de versiones tengan soporte.
El proyecto Kubernetes recomienda actualizar al último parche de la versión menor actual y, después, apuntar al último parche disponible de la siguiente versión menor.
Antes de actualizar clústeres de producción, las comprobaciones de compatibilidad más importantes afectan a los componentes que interactúan estrechamente con la API de Kubernetes.
Los webhooks de admisión pueden depender de versiones de API o de campos que cambian entre versiones. Los componentes de red y de almacenamiento deben ser compatibles con la versión de destino. Los operadores, las definiciones de recursos personalizados y los complementos del clúster también pueden requerir actualizaciones.
Las cargas de trabajo también requieren atención. Los PodDisruptionBudgets, la disponibilidad de réplicas, las restricciones de planificación y el comportamiento del almacenamiento determinan si los nodos pueden vaciarse (drain) sin una interrupción inaceptable.
Una actualización de versión menor que se completa con éxito en el servidor de API no es necesariamente una actualización correcta de las aplicaciones si cargas de trabajo esenciales no consiguen reprogramarse o si un complemento incompatible deja de funcionar.
Una comprobación práctica de preparación para la actualización
Para los equipos que siguen con la 1.34, la siguiente evaluación es un punto de partida razonable.
- Soporte: confirma la fecha límite real de soporte de la distribución y si el soporte extendido está activado, disponible o sujeto a cargos adicionales.
- Compatibilidad: revisa, frente a la versión de destino, el uso de API obsoletas, los webhooks de admisión, las CRD, los controladores, los drivers CNI y CSI y los complementos del clúster necesarios.
- Disponibilidad: verifica las réplicas de las cargas de trabajo, los PodDisruptionBudgets, la capacidad de los nodos, el comportamiento del vaciado y las ventanas de mantenimiento.
- Recuperación: confirma los procedimientos de copia de seguridad y restauración pertinentes, incluida la recuperación de etcd en los planos de control autogestionados, y conoce las limitaciones del proveedor para volver a una versión anterior o revertir la actualización.
- Validación: prueba la actualización en un clúster o grupo de nodos representativo que no sea de producción y, después, supervisa el estado de las cargas de trabajo, la red, el almacenamiento y las tasas de error de las aplicaciones durante el despliegue en producción.
Estas comprobaciones deben ser proporcionales al entorno. Un pequeño clúster de desarrollo y una plataforma de producción multirregión no necesitan procedimientos de cambio idénticos, pero ambos necesitan una ruta de actualización conocida.
Los equipos también deberían evitar dar por hecho que el soporte extendido equivale a aplazar todas las obligaciones de actualización. Ofrece tiempo adicional en las condiciones que indica el proveedor, no el mantenimiento permanente de una versión concreta de Kubernetes.
¿Qué cambia después del 27 de octubre?
En los entornos autogestionados de Kubernetes 1.34 que dependen del mantenimiento upstream, el 27 de octubre marca el fin de las correcciones habituales para esa rama. Las organizaciones que sigan en ella deben aceptar el riesgo de mantenimiento que eso implica o gestionarlo por su cuenta.
En EKS, AKS y GKE, la fecha límite es un recordatorio para verificar el ciclo de vida específico de cada proveedor, no una señal de que todos los clústeres gestionados con la 1.34 se queden sin soporte de la noche a la mañana.
La decisión correcta depende del modelo operativo. Una organización con una ruta de actualización probada puede, razonablemente, pasar ya a una versión menor con soporte. Otra puede usar una ampliación con soporte formal para completar el trabajo de compatibilidad y programar un cambio de menor riesgo.
Lo que no debería ocurrir es dejar un clúster en una versión que envejece porque las cargas de trabajo parecen estar bien y nadie ha confirmado quién es responsable de mantenerlo.
El ciclo de vida upstream de Kubernetes 1.34 termina el 27 de octubre de 2026. La responsabilidad operativa consiste en establecer la fecha límite que realmente se aplica a cada clúster y completar una actualización probada y con soporte antes de que expire esa cobertura.
Para profundizar
- Kubernetes: Version 1.34 Release Schedule. Ciclo de vida oficial de la versión, fecha de entrada en modo de mantenimiento y fecha límite del fin de vida upstream.
- Kubernetes: Version Skew Policy. Relaciones de versiones admitidas entre servidores de API, kubelets, controladores y otros componentes del clúster.
- Kubernetes: Upgrading kubeadm Clusters. Proceso oficial de actualización de clústeres autogestionados y requisitos de secuencia entre versiones menores.
- Amazon EKS: Kubernetes Version Lifecycle. Fechas del soporte estándar y extendido de EKS, políticas de versiones y aspectos de facturación relacionados.
- Microsoft Learn: Supported Kubernetes Versions in AKS. Ciclo de vida estándar de AKS, soporte a largo plazo y calendarios de actualizaciones iniciadas por la plataforma.
- Google Cloud: GKE Release Schedule. Fechas del soporte estándar y extendido de GKE, disponibilidad por canal de versiones y programación de actualizaciones.
Lecturas relacionadas en este sitio
- Ingress-NGINX ha sido retirado: qué deben hacer ahora los equipos de Kubernetes (en inglés), sobre otro componente de Kubernetes que ha dejado de recibir correcciones de seguridad y cómo planificar la migración.
- Kubernetes 1.37: tres cambios que los equipos de plataforma deben entender antes de actualizar (en inglés), sobre la versión menor más reciente de las que este artículo enumera entre las ramas con soporte.
Investigación revisada el 26 de octubre de 2026. Las fechas de soporte dependen del momento y deben volver a comprobarse en la documentación de los proveedores antes de publicar o de hacer cambios operativos. Este artículo describe la planificación del ciclo de vida y de las actualizaciones. No sustituye a las instrucciones de actualización específicas de cada plataforma.