Dynamic Resource Allocation (DRA) in Kubernetes 2026: Redefining GPU Scheduling

Dynamic Resource Allocation (DRA) has been stable since Kubernetes 1.34/1.35 – and solves a problem that has been troubling GPU cluster operators for years: The old device plugin architecture treats GPUs as countable black boxes, without taking into account properties such as model, memory, or MIG profile. DRA fundamentally changes this. The following article shows how the new API works, why it is particularly relevant for AI workloads, and what initial production deployments look like.

What DRA does differently

The old device plugin framework only allows nvidia.com/gpu: 1 – a simple number. Which GPU type, with which memory or which compute architecture actually reaches the pod remains hidden from the scheduler. Teams work around this with nodeSelector, Taints and Tolerations, which quickly leads to unmaintainable configurations.

DRA, on the other hand, introduces a full-fledged API model reminiscent of the PersistentVolume system. Four new objects form the backbone:

• DeviceClass – defines a category of devices (e.g., gpu.nvidia.com or mig.nvidia.com).
• ResourceSlice – lists all available devices on a node with their attributes.
• ResourceClaim – a “ticket” for a specific device that a pod references.
• ResourceClaimTemplate – a template that automatically creates a separate claim per pod.

The decisive advancement: The scheduler itself now evaluates CEL (Common Expression Language) expressions against the attributes in the ResourceSlices. A pod can say: “I need a MIG instance with profile 1g.5gb” – and Kubernetes finds the matching node without the developer needing to know node labels.

Why DRA is relevant right now

The API was promoted to Stable status with Kubernetes v1.34 and is enabled by default from v1.35. Red Hat elevated DRA to GA with OpenShift 4.21 (Kubernetes 1.34) and emphasizes that the new architecture “fundamentally” overcomes the limitations of the device plugin model. NVIDIA has moved the driver dra-driver-nvidia-gpu into the Kubernetes SIGs – a clear sign that the standard is gaining industry-wide traction.

The CNCF survey from January 2026 shows that 66% of organizations run generative AI models on Kubernetes. GPU capacity has become a bottleneck: On average, only 5% of GPU resources in production clusters are actually utilized, as the Cast AI study on Kubernetes optimization 2026 determined. DRA addresses precisely this inefficiency by enabling fine-grained allocation and sharing mechanisms.

Concrete Use Cases

1. Attribute-based GPU Selection

Instead of guessing a node with the correct GPU via labelSelector, the developer specifies the required device attributes directly. A ResourceClaim for a specific MIG instance looks like this in practice:

apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
metadata:
  name: mig-1g5gb-claim
spec:
  spec:
    devices:
      requests:
        - name: mig
          exactly:
            deviceClassName: mig.nvidia.com
            selectors:
              - cel:
                  expression: "device.attributes['gpu.nvidia.com'].profile == '1g.5gb'"

The scheduler automatically assigns the pod to a node that provides a matching MIG partition – without nodeSelector, without Tolerations.

2. Device Sharing Between Containers

Two containers in the same pod can reference the same ResourceClaim and thus share a GPU device. This was not possible with the old device plugin. This is particularly beneficial for sidecar patterns in inference workloads.

3. Time Slicing at the GPU Level

DRA enables GPU Time Slicing directly via the API, without manual configuration of the number of slices. The NVIDIA DRA Driver handles the partitioning transparently.

What this means for everyday cluster operations

DRA eliminates the fragmentation that was previously unavoidable: GPUs of different generations (e.g., A100 and H100) in the same cluster are now cleanly addressable via attributes. Mixed hardware becomes an advantage instead of a problem.

Furthermore, Device Health Reporting is being added from Kubernetes v1.36. If a GPU fails, the administrator can see in the ResourceSlice whether the error originated from the device or the application – without manual node inspection. This saves considerable time in troubleshooting in larger clusters.

Another advantage: The DRA architecture is compatible with the Cluster Autoscaler. In the future, GPU node pools could be automatically expanded when demand for specific DeviceClasses increases.

Conclusion

Dynamic Resource Allocation is more than just a new API – it corrects one of the oldest blind spots in Kubernetes. Where nodeSelector chains and individual webhooks for each GPU configuration were previously necessary, a single CEL expression in the ResourceClaim suffices today. For teams running or planning AI workloads on Kubernetes, DRA is the decisive step towards an efficient, maintainable GPU infrastructure.

The initial production experiences with OpenShift 4.21 and the NVIDIA DRA drivers show: The technology is ready for deployment. Those migrating now will save themselves the later switch from a deprecated device plugin model.

Sources

• Understanding dynamic resource allocation in Kubernetes – CNCF Blog, Juli 2026
• Dynamic resource allocation goes GA in Red Hat OpenShift 4.21 – Red Hat Developer, März 2026
• Kubernetes AI Infrastructure in 2026: GPU Scheduling & Production Realities – CloudOptimo, Mai 2026
• Introduction to Dynamic Resource Allocation (DRA) in Kubernetes – Rafay, August 2025