Kubernetes 1.34: checklist para planificar la actualización

La fecha importa; primero confirma qué clúster tienes

Al 18 de octubre de 2026, el calendario oficial lista 1.34.12 como el parche más reciente y fija el fin de vida de Kubernetes 1.34 para el 27 de octubre. La rama entró en mantenimiento el 27 de agosto: durante ese período, el equipo de releases puede publicar correcciones para vulnerabilidades con CVE asignado, problemas de dependencias —incluidas imágenes base— y fallos críticos de componentes centrales. No es mantenimiento general para cualquier corrección. El proyecto mantiene las ramas 1.35, 1.36 y 1.37 según la revisión de esta guía; valida el calendario vigente antes de decidir.

El fin de soporte upstream no apaga automáticamente un clúster. Sí marca el cierre del mantenimiento comunitario de esa rama. La distribución o el proveedor pueden tener condiciones y fechas propias: compruébalas por separado antes de planificar el cambio.

1. Registra versión, distribución y estado actual

Confirma que el contexto de kubectl apunta al entorno correcto. Guarda el resultado en un registro interno con acceso restringido; no publiques nombres de clúster, nodos, namespaces ni salidas que identifiquen a tu organización.

kubectl config current-context
kubectl version
kubectl get nodes -o wide
kubectl get pods --all-namespaces

Anota la versión del plano de control y de cada nodo, el método de instalación y el responsable de la plataforma. Si usas un servicio administrado, confirma la versión disponible y su procedimiento con el proveedor. No deduzcas la versión del servidor solo a partir de la versión local de kubectl.

2. Haz inventario de dependencias y cambios de API

La compatibilidad no depende solo de los binarios Kubernetes. Revisa CNI, CSI, DNS, Gateway o Ingress, webhooks, operadores, charts, políticas, almacenamiento, controladores cloud y herramientas de respaldo. Marca quién mantiene cada componente y qué versión admite.

Compara los manifiestos y clientes con las notas de cada versión que planeas recorrer. Busca APIs eliminadas o cambios de comportamiento en la guía de APIs obsoletas. Un manifiesto que todavía se guarda en Git no demuestra que el API server destino vaya a servir esa versión.

• Lista CRD, operadores y sus ventanas de compatibilidad.
• Revisa políticas de admisión y webhooks que validan recursos.
• Comprueba complementos de red, almacenamiento y observabilidad.
• Identifica cargas con una sola réplica o dependencias con estado.

3. Elige una ruta admitida, paso menor por paso menor

La política de Kubernetes mantiene las tres ramas menores más recientes. Para la ruta publicada en octubre de 2026, esas ramas son 1.35, 1.36 y 1.37. La documentación de kubeadm declara que saltarse versiones menores no está soportado: diseña y valida los saltos admitidos en orden para ese método. Si tu proveedor publica otra ruta para su distribución, confirma que esté soportada y documenta esa decisión.

La guía de alto nivel recalca que el procedimiento depende de cómo se desplegó y modificó el clúster. Sigue la documentación de tu proveedor o herramienta, revisa el desfase permitido entre componentes y confirma primero las versiones objetivo disponibles para tu plataforma.

4. Define recuperación y prueba antes de la ventana

Acordar una ventana no sustituye un plan de recuperación. Identifica el estado de aplicación que debes respaldar, confirma una restauración en un entorno aislado y documenta quién puede detener el procedimiento. Para kubeadm, Kubernetes recomienda respaldar componentes importantes, incluido el estado de aplicación almacenado en bases de datos.

• Prueba cada salto en staging con versiones y complementos equivalentes.
• Define capacidad, orden de nodos, drenado y presupuesto de interrupción.
• Prepara validaciones de red, DNS, almacenamiento, autenticación y APIs.
• Especifica criterios de pausa y recuperación antes de intervenir.

En clústeres kubeadm, el flujo documentado actualiza primero un nodo de control plane, después los demás y luego los workers. Cada nodo requiere preparación y comprobación; el proveedor CNI puede tener pasos propios. Otros métodos de instalación pueden usar secuencias diferentes.

5. Comprueba el resultado con señales de servicio

Una actualización termina cuando las cargas y servicios dentro del alcance pasan sus validaciones, no solo cuando cambia el número de versión. Confirma nodos Ready, controladores y Pods sanos, almacenamiento disponible, conectividad entre servicios y una transacción representativa de cada aplicación crítica.

Guarda versiones, eventos relevantes, pruebas y decisiones tomadas. Si el plan depende de un complemento o proveedor, registra también su confirmación de compatibilidad. Así el siguiente mantenimiento parte de evidencia y no de una suposición.

Convierte la fecha en un plan verificable

Si operas Kubernetes 1.34, identifica primero distribución y dependencias; después acuerda secuencia, pruebas y recuperación con quienes mantienen el entorno. No envíes credenciales ni kubeconfigs en formularios.