Actualizado: 2026-07-07

Kubernetes 1.34 salió el 27 de agosto, cerrando el ciclo de quince semanas que el proyecto mantiene desde hace años (tres versiones al año, no cuatro, pese a lo que mucha gente asume). Como en las últimas rondas, no trae nada revolucionario: una colección de mejoras incrementales que conviene leer con calma para separar lo que afecta a tu cluster de lo que no.

Puntos clave

  • El núcleo de Dynamic Resource Allocation (DRA) se gradúa a estable: la API resource.k8s.io/v1 ya es la versión por defecto para asignar GPU y otro hardware especializado.

  • El planificador mejora su rendimiento con Queueing Hints, ya estable, y llamadas asíncronas a la API en beta, que reducen reintentos y latencia de decisión en clusters grandes.

  • Las Mutating Admission Policies llegan a estable: se puede escribir lógica de mutación en CEL dentro del propio apiserver, sin desplegar un webhook aparte.

  • El trazado (tracing) de kubelet y del apiserver pasa a estable, con soporte OpenTelemetry de extremo a extremo para diagnosticar latencia.

  • No hay APIs eliminadas ni deprecaciones mayores en esta versión. El único cambio de nomenclatura es que PreferClose en TrafficDistribution queda como alias de PreferSameZone (beta).

Lo que se puede actualizar sin pensar demasiado

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

  • Planificador: Queueing Hints (estable) evita reintentos innecesarios de pods sin plaza, y las llamadas asíncronas a la API (beta) mejoran el rendimiento en clusters con muchos nodos.

  • kube-proxy en Windows: soporte estable para Direct Server Return (DSR) y redes overlay. Si administras clusters Windows esto ya es producción; en Linux no cambia nada.

  • Volúmenes: VolumeAttributesClass llega a estable, para ajustar IOPS o throughput de un volumen en caliente sin recrear el PVC.

  • Variables de entorno del kubelet: en beta, ahora aceptan casi cualquier carácter ASCII imprimible salvo =, lo que evita rodeos para frameworks como .NET Core que usan dos puntos en las claves de configuración.

DRA llega a estable: ahora sí, para producción

La novedad más relevante para quien trabaja con cargas de IA es que el núcleo de Dynamic Resource Allocation (DRA) se gradúa a estable. Los tipos ResourceClaim, DeviceClass, ResourceClaimTemplate y ResourceSlice forman ya la API v1 que no debería romperse en el futuro cercano.

DRA se propuso en 2023 y pasó por varias rondas de alfa y beta. La idea sigue siendo la misma: en vez de pedir dos GPUs concretas, una carga puede pedir un recurso que cumpla ciertos criterios, y el planificador casa la petición con el hardware disponible. Esto importa para GPU y para hardware especializado como NPU o FPGA, donde el device plugin clásico se quedaba corto.

Junto al núcleo estable, tres piezas adicionales llegan a beta: etiquetado de acceso administrativo (para que solo usuarios autorizados accedan a dispositivos ya en uso), listas priorizadas (una carga puede pedir varios tipos de dispositivo aceptables, en orden de preferencia, y el planificador prueba cada uno) y reporte del kubelet sobre qué recursos DRA tiene asignados cada pod, útil para monitorización. Compartir un mismo dispositivo físico entre varias reclamaciones (consumable capacity) sigue en alfa, así que todavía no cuentes con ello en producción.

Mi consejo cambia respecto a versiones anteriores: para cargas nuevas de IA con GPU, el núcleo estable de DRA ya es una base razonable. Si el device plugin clásico te funciona hoy y no tienes necesidades de selección avanzada, no hay prisa por migrar. Para equipos que también trabajan con modelos grandes, el patrón de asignación de GPU de DRA encaja con los ciclos de entrenamiento que describen las GPUs Blackwell de NVIDIA.

Menos webhooks, más CEL

La pieza que más me gusta de 1.34 es que las Mutating Admission Policies se gradúan a estable. Hasta ahora, para mutar un recurso en el flujo de admisión hacía falta un webhook: un servidor HTTP aparte, certificados TLS, un proceso más que puede caerse. Con MutatingAdmissionPolicy, la lógica se expresa en CEL y el apiserver la aplica directamente, sin red de por medio.

(La validación declarativa de CRDs con x-kubernetes-validations no es nueva de 1.34; lleva tiempo disponible. Lo que cambia ahora es que también puedes evitar el webhook del lado de la mutación, además del de validación.)

El beneficio es doble: se elimina un componente que puede fallar (si el webhook estaba caído, las creaciones fallaban) y se evita la latencia de red de la llamada HTTP al webhook. La migración implica reescribir la lógica en CEL, que tiene curva de aprendizaje pero no es complicada. Donde sigue mereciendo la pena un webhook es en validaciones que necesitan consultar otros recursos o servicios externos, algo que CEL no puede hacer.

Diagrama de contenedores mostrando la separación de capas que Kubernetes orquesta, incluyendo el plano de control donde aplican las mejoras de CEL y planificador de 1.34
Diagrama de MoreInput, Wikimedia Commons[1], CC BY-SA 4.0.

Sin grandes deprecaciones esta vez

Según las notas oficiales de la versión[2], 1.34 no elimina ninguna API mayor ni introduce deprecaciones críticas. Si tu memoria te dice lo contrario, seguramente piensas en batch/v1beta1 para CronJob: eso se eliminó hace tiempo, en la versión 1.25, no ahora.

El único cambio de nomenclatura que vale la pena anotar está en TrafficDistribution: el valor PreferClose queda deprecado en favor de un PreferSameZone explícito (beta), aunque se mantiene como alias por compatibilidad. También aparece, en fase alfa y detrás de un feature gate desactivado por defecto, GracefulLeaderTransition: permite que kube-scheduler, kube-controller-manager y el cloud-controller-manager suelten el liderazgo sin reiniciar el proceso completo. Nada de esto obliga a tocar manifiestos existentes.

Trazado de extremo a extremo para operadores

Para quien escribe o mantiene operadores, lo más útil de 1.34 no es una API nueva sino una mejora de observabilidad: el trazado (tracing) de kubelet y del apiserver se gradúa a estable, con soporte OpenTelemetry de extremo a extremo desde el plano de control hasta las llamadas gRPC al runtime del contenedor. Las trazas se exportan a Jaeger, Zipkin o Grafana Tempo, así que si tu equipo ya usa Parca, Beyla y Grafana como pila de observabilidad, esto encaja directamente en los dashboards existentes en vez de obligar a inferir la latencia a partir de logs sueltos.

Lo que yo haría esta semana

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

  • No busques APIs eliminadas: esta vez no hay ninguna. Sí revisa si usas PreferClose en algún Service con trafficDistribution, para planear el cambio a PreferSameZone sin prisa.

  • Si mantienes webhooks de mutación para tus propios recursos, valora migrarlos a MutatingAdmissionPolicy en la siguiente iteración: no es urgente, pero quita un componente operativo.

  • Si tienes cargas con GPU, mira si el núcleo estable de DRA cubre tu caso de uso; las piezas más avanzadas, como compartir un dispositivo entre varias reclamaciones, siguen en alfa.

  • Actualiza primero en pre-producción, observa una semana y después ve a producción.

Los proveedores managed (GKE, EKS, AKS) tardan varias semanas en ofrecer cada versión nueva, así que si usas uno de ellos tienes margen de sobra para prepararte. En clusters autogestionados mi regla sigue siendo esperar al menos al parche .2 antes de tocar producción: los primeros parches suelen recoger los bugs menores que solo aparecen con uso real.

Mi lectura

Kubernetes lleva más de diez años como proyecto y es un graduado de la CNCF[3] desde 2018. Está en una fase de maduración tranquila: las versiones ya no traen novedades deslumbrantes, y eso es sano. Lo que llega ahora son pulidos: mejor planificación, mejor observabilidad, menos componentes accesorios. Que DRA por fin tenga un núcleo estable, tras dos años entre alfa y beta, me parece el ejemplo perfecto: quita incertidumbre sin quitar capacidad.

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

En general, 1.34 es una versión para actualizar con calma, sin miedo a deprecaciones que esta vez no existen. La excepción son los equipos con cargas de IA que ya sufren la rigidez del device plugin clásico: para esos, tener un núcleo de DRA estable es razón de sobra para priorizar la actualización.

Este artículo también está disponible en inglés.

Fuentes

  1. Wikimedia Commons
  2. notas oficiales de la versión
  3. graduado de la CNCF
  4. Kubernetes Blog — Kubernetes v1.34: DRA Updates
  5. Kubernetes CHANGELOG-1.34.md