Kubernetes 1.34 se publico a mediados de julio siguiendo la cadencia trimestral habitual del proyecto. Como las ultimas 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 calculo 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 tambien 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 configuracion estable. Para quien ya lo usa en beta no cambia mucho, pero para quien lo evitaba por estatus, ahora hay luz verde. La integracion con CNI mantiene compatibilidad total; los plugins Calico, Cilium y Flannel no necesitan actualizacion para esta version.
El componente kubelet ha mejorado su gestion de cgroups v2, que ya era el modo por defecto en Debian 13 y Ubuntu 24.04. Si vienes de una version anterior montada sobre cgroups v1, la migracion sigue siendo transparente porque el kubelet detecta ambos. La limpieza de cgroups v1 legacy se anuncia para 1.36, tres versiones mas adelante.
Asignacion dinamica 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.
Validacion declarativa: el cambio menos visible y mas util
La pieza que mas me ha gustado de 1.34 es la validacion 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 validacion 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 validacion CEL. Para aplicaciones con scripts de despliegue que aplican decenas de recursos, la diferencia se nota.
La migracion requiere reescribir la logica de validacion en CEL, que tiene curva de aprendizaje pero no es complicado. La documentacion de Kubernetes incluye ejemplos practicos 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 documentacion de migracion con aviso firme para quienes todavia tienen referencias en codigo 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 version 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 gestion de expiracion que reduce las ventanas de doble liderazgo, un problema clasico cuando un controller pierde la conexion 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 metricas sobre latencia de validacion 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 validacion para CRDs propios, planificar migrar a validacion CEL para la siguiente iteracion, no es urgente pero es mejora clara. Tercero, si tienes cargas con GPU en produccion, leer la documentacion 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 version 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 practica 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 validacion 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 version. 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 version 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.
