Kubernetes 1.34: resumen para equipos con poco tiempo

Actualizado: 2026-05-03

Kubernetes 1.34 se publicó a mediados de julio siguiendo la cadencia trimestral habitual del proyecto. Como las últimas versiones, no trae nada revolucionario sino una colección de mejoras incrementales que requieren leer las notas con cuidado para saber cuáles afectan a tu cluster y cuáles no.

Puntos clave

• El planificador mejora el cálculo de ranking de nodos con afinidades complejas, reduciendo la latencia de decisión en clusters grandes.
• IPv6 dual-stack pasa a GA — ya no es un experimento y puede tratarse como configuración estable.
• Dynamic Resource Allocation (DRA) avanza a beta con compartición de dispositivos, selectores avanzados y contabilidad por atributos — útil para GPU y NPU.
• La validación declarativa CEL en CRDs elimina la necesidad de webhooks de admisión para la mayoría de reglas, con ganancia de latencia medible.
• Deprecación crítica: batch/v1beta1 para CronJob se elimina definitivamente en 1.34 — cualquier manifiesto que la use simplemente no se aplicará.

Lo que se puede actualizar sin pensar demasiado

La mayoría de cambios en 1.34 son mejoras internas que no rompen nada y que activan ventajas inmediatas:

• Planificador: mejora en el cálculo de ranking de nodos cuando hay afinidades complejas, reduciendo la latencia de decisión en clusters grandes.
• kube-proxy: mejor manejo de reglas iptables cuando hay servicios con muchas IPs externas — un escenario que antes degradaba el rendimiento de forma visible.
• IPv6 dual-stack a GA: deja de ser un experimento y puede tratarse como configuración estable. Los plugins Calico, Cilium y Flannel no necesitan actualización.
• kubelet con cgroups v2 mejorado: ya era el modo por defecto en Debian 13 y Ubuntu 24.04. La limpieza de cgroups v1 legacy se anuncia para 1.36.

Asignación dinámica de recursos: avance, no cierre

La novedad más vistosa para quien trabaja con cargas de IA es el progreso en Dynamic Resource Allocation (DRA). En 1.34 pasan a beta varias funciones que faltaban:

• Compartir dispositivos entre pods
• Reclamaciones con selectores avanzados
• Contabilidad por atributos del dispositivo

Esto importa mucho para GPU y para hardware especializado como NPU o FPGA, donde la abstracción de device plugin tradicional se quedaba corta. DRA se propuso en 2023 y lleva varias versiones en alfa y beta. La idea es permitir que una carga diga exijo un recurso que cumpla estos criterios en vez de exijo dos GPUs, y que el planificador case criterios con dispositivos disponibles.

En 1.34 la API es más estable pero aún no es GA. Mi consejo para producción es seguir usando device plugin clásico si ya funciona. Para nuevas implementaciones en cargas de IA compleja, DRA compensa el riesgo. Para contextos donde también se trabaja con modelos grandes, el patrón de asignación de GPU de DRA encaja bien con los ciclos de entrenamiento que describen las GPUs Blackwell de NVIDIA.

Validación declarativa: el cambio menos visible y más útil

La pieza que más me ha gustado de 1.34 es la validación declarativa de recursos personalizados. Hasta ahora, para validar un CustomResource con reglas complejas hacía falta un webhook de admisión, con latencia adicional y una dependencia externa que podía caer. Con validación declarativa, las reglas se expresan en lenguaje CEL dentro del propio CRD, y el apiserver las evalúa directamente sin red.

El beneficio es doble:

• Se elimina un componente de failure: si el webhook estaba caído, los creates fallaban.
• Se reduce la latencia de creación de recursos custom — en un cluster con cinco operadores validando CRDs vía webhook, la latencia de kubectl apply bajó entre 150 y 400 ms por recurso al migrar a validación CEL.

La migración requiere reescribir la lógica de validación en CEL, que tiene curva de aprendizaje pero no es complicado. Donde todavía conviene webhook es en validaciones que requieren consultar otros recursos o servicios externos.

Deprecaciones que merece la pena marcar en rojo

La lista de deprecaciones de 1.34 no es larga pero sí importante:

• batch/v1beta1 para CronJob: se elimina definitivamente en 1.34. Cualquier manifiesto que use esa versión simplemente no se aplicará. Si tu GitOps tiene CronJobs antiguos, hay que migrar a batch/v1 antes de actualizar.
• Flag --feature-gates en varios subcomponentes: en 1.34 aparece un aviso en los logs; en 1.35 el flag será ignorado; en 1.36 no iniciará el proceso. La mayoría de usos son en scripts de arranque que pasaron de alfa a beta a GA sin limpiar la bandera.
• PodSecurityPolicy v1: deprecada desde 1.21 y eliminada en 1.25, aparece ahora con aviso firme para quienes tienen referencias en código aunque no la usen activamente.

El cambio que afecta a operadores

Para equipos que escriben o mantienen operadores, 1.34 trae una mejora notable en el ciclo de vida de controllers con leader election. La API recibió una mejora en la gestión de expiración que reduce las ventanas de doble liderazgo — un problema clásico cuando un controller pierde la conexión a apiserver temporalmente. La API es compatible hacia atrás, pero se recomienda recompilar el operador contra client-go 1.34 para aprovechar la mejora.

Otro cambio interesante es la mejora en el endpoint de health check de apiserver, que ahora expone métricas sobre latencia de validación declarativa y sobre ranking del planificador. Esto ayuda a diagnosticar cuando un cluster empieza a ir lento: ahora hay visibilidad directa de cada fase en vez de tener que inferirla de logs. Para equipos que ya usan Parca, Beyla y Grafana como pila de observabilidad, estas nuevas métricas encajan directamente en los dashboards existentes.

Lo que yo haría esta semana

Mi checklist para equipos con clusters en producción de tamaño pequeño o mediano:

1. Verificar que no haya manifiestos con APIs eliminadas en 1.34 antes de actualizar — batch/v1beta1 y algunas extensions/v1beta1 restantes. Una búsqueda simple en el repositorio GitOps encuentra el 90 % de los casos.
2. Si usas webhooks de validación para CRDs propios, planificar migrar a validación CEL para la siguiente iteración — no es urgente pero es mejora clara.
3. Si tienes cargas con GPU en producción, leer la documentación de DRA pero no migrar todavía si el sistema actual funciona.
4. Actualizar en pre-producción, observar una semana, y luego producción.

El tiempo desde que una versión sale hasta que llega a clusters managed como GKE, EKS, AKS suele ser entre seis y doce semanas. Si usas esos servicios, la ventana de preparación es clara. Si tienes clusters autogestionados, mi regla práctica es esperar al menos al parche .2 antes de llevar a producción — los primeros dos parches cierran el 70 % de bugs menores que se descubren en las primeras semanas.

Mi lectura

Kubernetes está en una fase de maduración tranquila. Las versiones ya no traen novedades deslumbrantes, y eso es sano. El proyecto tiene diez años y la mayoría de funcionalidad crítica existe desde 1.20 o antes. Lo que viene son pulidos: mejor planificación, mejor seguridad, mejor telemetría, menos componentes accesorios. La validación declarativa es un buen ejemplo: quita un sistema externo sin quitar capacidad.

Lo que me inquieta un poco es la cantidad creciente de feature gates en estados alfa, beta, GA que conviven en cada versión. Para un equipo que sigue Kubernetes de cerca esto es manejable, pero para equipos que tocan el cluster dos veces al año la carga cognitiva crece.

En general, 1.34 es una versión para actualizar con calma, verificar que nada se ha roto en deprecaciones, y quedarse tranquilo. La única excepción son equipos con cargas de IA que usan device plugin y tienen fricción por la rigidez del modelo antiguo: para esos, DRA en beta es razón suficiente para priorizar la actualización.