Kubernetes 1.34: DRA llega a GA y cambia cómo se asignan GPUs

Si administrás clústeres con GPUs u otro hardware especializado, la forma en que Kubernetes reparte esos dispositivos entre pods acaba de cambiar de raíz. Dynamic Resource Allocation (DRA) —la API que reemplaza al histórico Device Plugin API— graduó a General Availability (GA) en Kubernetes 1.34 y desde entonces no paró de sumar funciones: pasó por actualizaciones en 1.35 y 1.36, y el 3 de septiembre de 2026 llegó 1.37 con la graduación a GA del soporte de "extended resources" sobre DRA, según el blog oficial de Kubernetes v1.37: DRA Updates.

Dynamic Resource Allocation (DRA) es una API de Kubernetes, agrupada bajo resource.k8s.io, que permite pedir y compartir dispositivos —GPUs, FPGAs, NICs de alta velocidad— usando objetos declarativos como ResourceClaim, ResourceClaimTemplate, DeviceClass y ResourceSlice, en lugar del viejo esquema de Device Plugins por nodo. Es un proyecto de la comunidad de Kubernetes (WG Device Management) y su núcleo alcanzó GA en la versión 1.34.

¿Qué problema tenía el Device Plugin API que DRA viene a resolver?

El Device Plugin API obligaba a modelar cada GPU como un recurso entero por nodo, sin forma nativa de expresar preferencias, compartir un mismo dispositivo entre contenedores o filtrar por atributos como memoria o arquitectura.

En la práctica, esto se traducía en clústeres de GPU infrautilizados: si un pod pedía "una GPU" sin más detalle, el scheduler no tenía manera de razonar sobre si esa GPU era la más adecuada para la carga, ni de asignar una fracción de ella a otro pod que necesitaba mucho menos cómputo.

¿Cómo funciona DRA en la práctica?

DRA separa la definición del recurso, el pedido del workload y la asignación final en tres objetos distintos, y deja que el scheduler resuelva el matching en tiempo de programación. El administrador del clúster define DeviceClass (qué tipos de dispositivo existen y quién los provee), el desarrollador declara un ResourceClaim con los requisitos del workload, y el driver de DRA en el nodo publica en un ResourceSlice qué dispositivos concretos están disponibles.

• Selectores CEL: los ResourceClaim pueden filtrar dispositivos por atributos (memoria, arquitectura, driver version) usando Common Expression Language, en vez de labels rígidos.
• Prioritized list: una novedad de 1.34 que permite declarar varias opciones de hardware en orden de preferencia —por ejemplo, "una GPU de alta gama o, si no hay, dos de gama media"— y que el scheduler elija la mejor combinación disponible.
• Compartición de dispositivos: varios contenedores o pods pueden reclamar porciones del mismo dispositivo físico, algo que el Device Plugin no contemplaba de forma nativa.
• Reporte de salud: desde 1.34/1.35 los pods pueden enterarse cuando el dispositivo asignado falla, sin depender de que el nodo entero se marque como no disponible.

¿Por qué DRA llegó a GA justo ahora, con el boom de GPUs para IA?

La coincidencia no es casual: DRA estuvo disponible por primera vez en la versión v1.30 de Kubernetes, y su maduración se aceleró en paralelo con la demanda de scheduling fino de GPUs para entrenamiento e inferencia de modelos. El propio blog de la comunidad lo resume así: "Kubernetes 1.34 is here, and it has brought a huge wave of enhancements for Dynamic Resource Allocation (DRA)! This release marks a major milestone with many APIs in the resource.k8s.io group graduating to General Availability (GA)", según el equipo de DRA de Kubernetes.

Que las APIs sean GA implica un compromiso concreto de estabilidad: Kubernetes no va a introducir breaking changes en resource.k8s.io de acá en adelante, aunque sí va a seguir agregando features nuevas en modo alpha/beta sobre esa base. Para quien mantiene drivers de DRA o clústeres en producción, eso significa que ya se puede construir sobre esta API sin miedo a que cambie el contrato en la próxima minor.

¿Qué trajo Kubernetes 1.37 para DRA?

Kubernetes 1.37, lanzado el 3 de septiembre de 2026, llevó a GA el "DRA Extended Resource support", un mecanismo que permite a los drivers de DRA satisfacer pedidos hechos con la sintaxis clásica de extended resources (algo como example.com/gpu en el spec de un pod) sin necesidad de mantener un Device Plugin en paralelo. Según el blog oficial, firmado por Kashish Verma, esta feature venía madurando "durante tres releases consecutivas" antes de graduar a GA en 1.37.

Esto cierra una brecha práctica: muchos manifests y Helm charts existentes todavía piden GPUs con la notación vieja de extended resources. Con esta graduación, esos mismos manifests pueden empezar a resolverse por un driver DRA por debajo, sin que el equipo de aplicación tenga que reescribir nada para migrar.

¿En qué se diferencia DRA del Device Plugin API tradicional?

La diferencia central es que DRA describe recursos con objetos declarativos y filtros expresivos, mientras que el Device Plugin API expone dispositivos como contadores fijos por nodo sin lógica de selección.

¿Qué implica DRA para un equipo que corre GPUs en producción?

Para quien opera workloads de IA o HPC sobre Kubernetes, DRA GA significa que ya es momento de evaluar la migración de los manifests de GPU al nuevo modelo, en vez de seguir parchando el Device Plugin con afinidades manuales.

• Mejor utilización de hardware caro: al poder expresar preferencias graduales y compartir dispositivos, se reduce la cantidad de GPUs reservadas pero ociosas.
• Menos YAML de afinidad: los selectores CEL reemplazan combinaciones frágiles de labels, taints y nodeSelectors específicos de cada proveedor de hardware.
• Dependencia del driver del fabricante: DRA es un framework; para usarlo con GPUs reales hace falta el driver DRA específico (por ejemplo, el de NVIDIA), que también está en proceso de maduración fuera de beta.
• Requiere Kubernetes reciente: para tener el core estable hace falta 1.34 o superior; si tu clúster corre una versión anterior, DRA todavía está en beta o no está disponible.

¿Qué podés hacer hoy para probar DRA?

Podés validar DRA sin comprometer producción creando un clúster de prueba con Kubernetes 1.34 o superior y habilitando el feature gate correspondiente si tu distribución todavía lo pide.

• Confirmá la versión del clúster: corré kubectl version y verificá que el server sea 1.34+ para tener el core de DRA en GA (revisá siempre la versión vigente en la documentación oficial).
• Revisá si tu proveedor de GPU ya tiene driver DRA: antes de migrar manifests, chequeá si el fabricante de tu hardware publica un driver DRA estable o todavía en beta.
• Leé la documentación oficial de conceptos: el apartado de Dynamic Resource Allocation en kubernetes.io tiene la referencia completa de ResourceClaim, DeviceClass y ResourceSlice.
• Probá en un entorno propio: si necesitás un clúster de bajo costo para experimentar con DRA antes de tocar producción, un servidor cloud en Donweb con Kubernetes autogestionado o K3s te permite levantar y destruir el entorno de prueba sin comprometer tu infraestructura actual.

Preguntas frecuentes

¿En qué versión de Kubernetes llegó DRA a GA?

El core de Dynamic Resource Allocation graduó a General Availability en Kubernetes 1.34, publicado en septiembre de 2025, cuando la mayoría de las APIs del grupo resource.k8s.io pasaron de beta a estables.

¿DRA reemplaza por completo al Device Plugin API?

No de forma inmediata: el Device Plugin API sigue funcionando, pero DRA es el camino recomendado a futuro para GPUs y hardware especializado, y con la GA de "DRA Extended Resource support" en Kubernetes 1.37 ya se puede satisfacer sintaxis de extended resources clásica usando un driver DRA por debajo.

¿Necesito un driver especial del fabricante para usar DRA con GPUs?

Sí, DRA es un framework genérico y requiere que el fabricante del hardware (por ejemplo NVIDIA) publique un driver DRA compatible; sin ese driver, el clúster no puede exponer los dispositivos reales a través de la API.

¿Qué es la "prioritized list" que trajo Kubernetes 1.34?

Es una función que permite declarar varias opciones de dispositivo en orden de preferencia dentro de un mismo ResourceClaim, para que el scheduler intente asignar la mejor alternativa disponible en vez de fallar si el hardware ideal no está libre.

¿Qué trajo específicamente Kubernetes 1.37 sobre DRA?

Kubernetes 1.37, lanzado el 3 de septiembre de 2026, graduó a GA el soporte de extended resources sobre DRA, permitiendo que pedidos con la notación clásica (example.com/gpu) se resuelvan mediante un driver DRA sin mantener un Device Plugin aparte.

Cloud Serversby Donweb

Todo el poder de la nube a tus proyectos y aplicaciones.
Alojamiento ultra rápido, escalable y con alta disponibilidad.

• Performance que te sorprenderá
• Rápida escalabilidad y sin limitaciones
• Arquitectura de alta disponibilidad
• Soporte experto y ejecutivos de cuenta
• Pagos en tu moneda y facturación local

Descubre la mejor solución de Cloud Hosting