Kubernetes DRA in 2026: GPU Scheduling Without the Device Plugin Headache

Las GPU solían ser territorio de laboratorios de investigación y grandes tecnológicas. En 2026, una PYME con una sola instancia de GPU corre inferencia de LLM, fine-tuning y transcripción por lotes — y paga por segundo por ello. Eso convierte la eficiencia de GPU en una partida real del presupuesto, no en una nota. Y durante años, cómo Kubernetes repartía las GPU hizo la eficiencia casi imposible: el modelo de device plugin daba a cada carga de trabajo una GPU completa o nada.

That changed with Dynamic Resource Allocation (DRA). It went stable in Kubernetes v1.35 and is enabled by default. If you run GPU workloads on Kubernetes — or you’re about to — DRA is the most important scheduler change in years. Here’s what it is, how to use it, and whether your SMB should adopt it now.

Por Qué el Modelo de Device Plugin Perjudica a las PYMEs

Desde Kubernetes 1.8, el hardware especial se expone a través de device plugins. En un clúster NVIDIA, eso significa ejecutar el device plugin de NVIDIA como DaemonSet, etiquetar los nodos de GPU y solicitar una tarjeta así:

resources:
  limits:
    nvidia.com/gpu: 1   # one whole GPU, or nothing

That works, but it’s crude in exactly the ways that cost SMBs money:

Asignación de todo o nada. A pod that needs 4 GB of VRAM to serve a small model consumes an entire 24 GB card. On a two-node GPU cluster, that’s the difference between running two workloads and six.
Decisiones estáticas. The kubelet hands out devices at container start. The scheduler never sees GPU health, memory, or topology, so you compensate with taints, labels, and guesswork.
Vendor lock-in a nivel de API. The device plugin API is effectively per-vendor. Moving from NVIDIA to AMD means rewriting how you request hardware.
Sin uso compartido, sin metadatos. Nothing tells Kubernetes “any GPU with at least 16 GB of memory” or “a GPU on the same PCIe switch as this NIC.”

Nada de esto es fatal con un nodo de GPU. Se vuelve fatal con tres — que es exactamente donde aterrizan las PYMEs cuando las cargas de trabajo de IA dejan de ser un experimento.

Cómo Funciona DRA: DeviceClasses, ResourceClaims y ResourceSlices

DRA reemplaza el modelo de device plugin con una API de dispositivos general y neutral respecto al proveedor, construida alrededor de cuatro piezas:

DeviceClass — an admin-defined category of devices, with CEL selection rules (“NVIDIA GPU with at least 16 GiB memory”).
ResourceClaim / ResourceClaimTemplate — what a workload asks for. Claims can be per-pod or shared by several pods.
ResourceSlice — a live inventory of devices published by the driver (“node-a has 2 A10s, node-b has 4 L4s”).
Un driver de DRA — vendor software (NVIDIA’s ships in the GPU Operator) that publishes slices, allocates devices, and exposes them to containers via the Container Device Interface (CDI).

El flujo es simple: el planificador hace coincidir cada claim con los slices disponibles, elige un nodo, el driver prepara el dispositivo y CDI hace bind-mount de los archivos correctos dentro de tu contenedor. Sin taints, sin etiquetas, sin reinicios del kubelet.

Two 2026 details worth knowing: DRA went estable en v1.35 (enabled by default), and v1.36 added listas de solicitudes priorizadas — you can say “prefer a big GPU, fall back to two small ones.” That’s the kind of flexibility that makes GPU nodes schedulable the way CPU nodes are.

Un Ejemplo Práctico: Cómo Solicitar una GPU con DRA

Paso 1 — instala un driver de DRA. On NVIDIA hardware, the GPU Operator enables DRA with a single flag:

helm repo add nvidia https://helm.ngc.nvidia.com/nvidia
helm repo update

helm install gpu-operator nvidia/gpu-operator \
  --namespace gpu-operator --create-namespace \
  --set driver.enabled=true \
  --set toolkit.enabled=true \
  --set dra.enabled=true

Paso 2 — define un DeviceClass. This one matches any NVIDIA GPU:

apiVersion: resource.k8s.io/v1
kind: DeviceClass
metadata:
  name: nvidia-gpu
spec:
  selectors:
    - cel:
        expression: |
          device.driver == "nvidia.com" &&
          device.attributes["nvidia.com"].type == "gpu"

Attribute names come from your driver. Run kubectl get resourceslices -o yaml to see exactly what fields your driver publishes, then write selectors against them — for example device.attributes["nvidia.com"].memory >= 16Gi.

Paso 3 — solicita el dispositivo. A ResourceClaimTemplate plus a Deployment that references it:

apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
metadata:
  name: gpu-claim
spec:
  spec:
    devices:
      requests:
        - name: gpu
          exactly:
            deviceClassName: nvidia-gpu
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: llm-inference
spec:
  replicas: 1
  selector:
    matchLabels:
      app: llm-inference
  template:
    metadata:
      labels:
        app: llm-inference
    spec:
      resourceClaims:
        - name: gpu
          resourceClaimTemplateName: gpu-claim
      containers:
        - name: inference
          image: nvcr.io/nvidia/pytorch:24.12-py3
          resources:
            claims:
              - name: gpu

Kubernetes crea un claim por pod automáticamente. Verifícalo con:

kubectl get resourceclaims
kubectl describe resourceclaim gpu-claim-<pod-name>

Want several pods to share one device (common for sharded inference)? Create a single claim with allocationMode: All and adminAccess: true, then reference it by name from each pod’s spec.resourceClaims.

Qué Cambia DRA para las PYMEs — y Cuándo Esperar

Reduce el gasto en GPU. Request 8 GiB of VRAM instead of a whole card and two jobs pack onto one device. On hourly-priced GPU instances that is real money — the same math we covered in cómo recortar costos de Kubernetes, applied at the device level.

Hace el autoscaling más inteligente. Because claims are scheduler-aware, DRA pairs naturally with node autoscaling: Karpenter provisions the node, DRA picks the device. No more manually tainting GPU nodes to keep jobs off them.

Elimina el pegamento específico del proveedor. The same YAML requests NVIDIA, AMD, or Intel accelerators — only the driver changes.

Cuándo esperar: DRA needs a recent cluster (v1.35+), so an upgrade is a prerequisite — see our guía práctica de actualización de clústeres. Driver maturity varies; NVIDIA’s is the most battle-tested. And if you run a single GPU node with one workload, the device plugin still works fine — keep it, and migrate when the second node arrives. During migration both models can coexist, so move inference workloads first and compare utilization before you commit.

Un camino de adopción sensato: upgrade the cluster → install the driver with DRA enabled → define one DeviceClass → convert a single workload → watch kubectl get resourceslices and GPU utilization for a week → expand.

DRA is one of those rare infrastructure changes that simplifies rather than complicates. It replaces taints, labels, and vendor plugins with one declarative API — and for SMBs watching GPU bills grow, it’s the difference between guessing and knowing exactly what your cluster can run.

Not sure whether DRA is worth the migration for your cluster? We help SMBs make pragmatic Kubernetes and AI-infrastructure decisions — book a free 30-minute consultation and we’ll map out your path.