Kubernetes 1.34 se publico a mediados de julio siguiendo la cadencia trimestral habitual del proyecto. Como las últimas versiones, no trae nada revolucionario sino una coleccion de mejoras incrementales que requieren leer las notas con cuidado para saber cuales afectan a tu cluster y cuales no. En este post recojo lo que me ha parecido relevante desde la silla del operador de Swarm y Kubernetes pequenios, pensando sobre todo en equipos que no pueden dedicar una semana entera a leer el changelog.
Lo que se puede actualizar sin pensar demasiado
La mayoria de cambios en 1.34 son mejoras internas que no rompen nada y que activan ventajas inmediatas. El planificador recibe mejoras en el cálculo de ranking de nodos cuando hay afinidades complejas, lo que reduce la latencia de decision en clusters grandes. El componente kube-proxy gana mejor manejo de reglas iptables cuando hay servicios con muchas IPs externas, un escenario que antes degradaba de forma visible el rendimiento.
Hay también mejoras en la pila de red. El soporte nativo de IPv6 dual-stack ha pasado a GA, lo que significa que deja de ser un experimento y se puede contar con el como configuración estable. Para quien ya lo usa en beta no cambia mucho, pero para quien lo evitaba por estatus, ahora hay luz verde. La integración con CNI mantiene compatibilidad total; los plugins Calico, Cilium y Flannel no necesitan actualizacion para esta versión.
El componente kubelet ha mejorado su gestión de cgroups v2, que ya era el modo por defecto en Debian 13 y Ubuntu 24.04. Si vienes de una versión anterior montada sobre cgroups v1, la migración sigue siendo transparente porque el kubelet detecta ambos. La limpieza de cgroups v1 legacy se anuncia para 1.36, tres versiones mas adelante.
Asignacion dinámica de recursos: avance, no cierre
La novedad mas 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, y contabilidad por atributos del dispositivo. Esto importa mucho para GPU y para hardware especializado como NPU o FPGA, donde la abstraccion 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 exigo un recurso que cumpla estos criterios en vez de exigo dos GPUs, y que el planificador case criterios con dispositivos disponibles. Esto es critico en flotas mixtas donde una H100 y una L40 no son equivalentes aunque ambas sean GPUs NVIDIA. En 1.34 la API es mas estable pero aun no es GA, y mi consejo para produccion es seguir usando device plugin clasico si ya funciona. Para nuevas implementaciones en cargas de IA compleja, DRA compensa el riesgo.
Validación declarativa: el cambio menos visible y mas útil
La pieza que mas me ha gustado de 1.34 es la validación declarativa de recursos personalizados. Hasta ahora, para validar un CustomResource con reglas complejas hacia falta un webhook de admision, con latencia adicional y una dependencia externa que podia caer. Con validación declarativa, las reglas se expresan en lenguaje CEL dentro del propio CRD, y el apiserver las evalua directamente sin red.
El beneficio es doble. Por un lado, se elimina un componente de failure: si el webhook estaba caido, los creates fallaban. Por otro, se reduce la latencia de creacion de recursos custom, que en clusters con muchos operadores puede ser visible. En un cluster que tengo con cinco operadores validando CRDs via webhook, la latencia de kubectl apply bajo entre 150 y 400 ms por recurso al migrar a validación CEL. Para aplicaciones con scripts de despliegue que aplican decenas de recursos, la diferencia se nota.
La migración requiere reescribir la lógica de validación en CEL, que tiene curva de aprendizaje pero no es complicado. La documentación de Kubernetes incluye ejemplos prácticos y los casos mas comunes se resuelven con expresiones de una linea. Donde todavia conviene webhook es en validaciones que requieren consultar otros recursos o servicios externos, porque CEL es deliberadamente restringido.
Deprecaciones que merece la pena marcar en rojo
La lista de deprecaciones de 1.34 no es larga pero si importante. La API v1 de PodSecurityPolicy, deprecada desde 1.21 y eliminada en 1.25, aparece ahora en la documentación de migración con aviso firme para quienes todavia tienen referencias en código aunque no la usen activamente. Si tu repo Helm o tus charts todavia mencionan PodSecurityPolicy, es buen momento para limpiar.
Mas relevante es la deprecacion del flag –feature-gates en varios subcomponentes que antes lo aceptaban por conveniencia. En 1.34 aparece un aviso en los logs; en 1.35 el flag sera ignorado; en 1.36 no iniciara el proceso. La mayoria de usos son en scripts de arranque que pasaron de fase alfa a beta a GA sin limpiar la bandera. Es trivial de corregir pero solo si alguien lo encuentra antes de que rompa un arranque.
La API batch/v1beta1 para CronJob, deprecada hace ya varias versiones, se elimina definitivamente en 1.34. Cualquier manifest que use esa versión simplemente no se aplicara. Si tu GitOps tiene CronJob antiguos, hay que migrar a batch/v1 antes de actualizar.
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. El API de leader election ha recibido una mejora en la gestión de expiracion que reduce las ventanas de doble liderazgo, un problema clasico cuando un controller pierde la conexión a apiserver temporalmente. La API es compatible hacia atras, pero se recomienda recompilar el operador contra client-go 1.34 para aprovechar la mejora.
Otro cambio interesante para operadores 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.
Lo que yo haria esta semana
Mi checklist para equipos con clusters en produccion de tamanio pequenio o mediano. Primero, verificar que no haya manifestos con APIs eliminadas en 1.34 antes de actualizar: batch/v1beta1 y algunas extensions/v1beta1 restantes. Una busqueda simple en el repositorio GitOps encuentra el 90% de los casos. Segundo, si usas webhooks de validación para CRDs propios, planificar migrar a validación CEL para la siguiente iteracion, no es urgente pero es mejora clara. Tercero, si tienes cargas con GPU en produccion, leer la documentación de DRA pero no migrar todavia si el sistema actual funciona. Cuarto, actualizar en pre-produccion, observar una semana, y luego produccion.
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 preparacion es clara. Si tienes clusters autogestionados, el momento depende de tu ciclo, pero mi regla práctica es esperar al menos al parche .2 antes de llevar a produccion. Los primeros dos parches cierran el 70% de bugs menores que se descubren en las primeras semanas.
Mi lectura
Kubernetes esta en una fase de maduracion tranquila. Las versiones ya no traen novedades deslumbrantes, y eso es sano. El proyecto tiene diez anios y la mayoria de funcionalidad critica existe desde 1.20 o antes. Lo que viene son pulidos: mejor planificacion, mejor seguridad, mejor telemetria, 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 cluster dos veces al anio la carga cognitiva crece. Creo que en 2026 el proyecto tendra que hacer una limpieza y plantearse si todas las banderas activas siguen teniendo sentido.
En general, 1.34 es una versión para actualizar con calma, verificar que nada se ha roto en deprecaciones, y quedarse tranquilo. No hay nada que obligue a correr. La unica exception son equipos con cargas de IA que usan device plugin y tienen friccion por la rigidez del modelo antiguo: para esos, DRA en beta es razon suficiente para priorizar la actualizacion. El resto puede esperar al siguiente ciclo sin perderse nada.
