Kubernetes 1.36 makes GPUs a shareable resource with DRA going GA

Kubernetes 1.36, shipping on 22 April 2026, closes a decade-old gap. Since 2017, scheduling a GPU on Kubernetes meant writing nvidia.com/gpu: 1 — an opaque integer, blind to model, memory, or topology. Dynamic Resource Allocation (DRA), introduced as alpha in 1.26 and redesigned in 1.31, graduates to general availability. GPUs join CPU and memory as first-class, attribute-aware cluster resources.

For teams running AI/ML clusters where 60% of VRAM sits idle because native partitioning never existed, 1.36 is the pivot: the NVIDIA device plugin era is over. DRA takes over.

Before DRA: one GPU, one integer

The legacy model was brutally simple. The device plugin advertises GPUs as an integer count per node. A Pod requests nvidia.com/gpu: 1, the scheduler checks a box, and the Pod lands — with no awareness of whether it got an A100 40GB or an H100 80GB, no visibility into NVLink peer topology, no way to reserve a fraction of a GPU.

What this costs in production:

• No topology awareness. A multi-GPU training job that needs NVLink across its 8 GPUs gets placed by affinity heuristics, not scheduler logic.
• No native partitioning. Serving a 7B model on an H100 80GB wastes 70GB of VRAM. MIG (Multi-Instance GPU) exists at the hardware level, but the device plugin treats each partition as a separate opaque device — manual configuration, dedicated node pools, operational overhead.
• No preemption. A low-priority batch job holding a GPU blocks urgent inference workloads until it finishes.
• No gang scheduling. A distributed training job with 8 pods can leave 7 GPUs idle while 1 pod stays Pending — resources locked with no work to do.

The device plugin served its purpose for nearly a decade. The 2025–2026 AI workload explosion made it structurally obsolete.

How DRA works

DRA introduces three native Kubernetes resources. A ResourceClaim declares what a Pod needs — using attributes, not integers. A ResourceSlice advertises what is available on a node. A DeviceClass defines the hardware category and the driver handling allocation.

The scheduler evaluates CEL (Common Expression Language) constraints directly against structured attributes published by the driver. No more hand-labeled nodes.

# ResourceClaim — Request 2 GPUs with at least 40GB VRAM
apiVersion: resource.k8s.io/v1
kind: ResourceClaim
metadata:
  name: gpu-claim
  namespace: ml-training
spec:
  devices:
    requests:
    - name: gpu
      deviceClassName: nvidia-gpu
      count: 2
      selectors:
      - cel:
          expression: "device.attributes['gpu.nvidia.com'].memory.isGreaterThan(quantity('40Gi'))"

# DeviceClass — NVIDIA GPU class with time-slicing
apiVersion: resource.k8s.io/v1
kind: DeviceClass
metadata:
  name: nvidia-gpu
spec:
  selectors:
  - cel:
      expression: "device.driver == 'gpu.nvidia.com'"
  config:
  - opaque:
      driver: gpu.nvidia.com
      parameters:
        apiVersion: gpu.nvidia.com/v1
        kind: GpuConfig
        sharing:
          strategy: TimeSlicing
          timeSlicingConfig:
            replicas: 4

# LLM inference Pod using DRA
apiVersion: v1
kind: Pod
metadata:
  name: llm-inference
spec:
  containers:
  - name: inference
    image: vllm/vllm-openai:latest
    resources:
      claims:
      - name: gpu
        request: gpu
  resourceClaims:
  - name: gpu
    resourceClaimName: gpu-claim

The difference from nvidia.com/gpu: 1 is fundamental. The Kubernetes scheduler now understands that a Pod needs an H100 with 80GB VRAM and an NVLink peer link to its neighbours — and it places accordingly.

GPU sharing: MIG, time-slicing, and partitionable devices

The most anticipated capability is native GPU partitioning. 1.36 promotes Partitionable Devices to beta — carving a physical accelerator into logical instances becomes a DRA primitive.

Three strategies, one API:

• Native MIG. The NVIDIA DRA driver automatically allocates a MIG partition matching the requested profile (1g.10gb, 2g.20gb, etc.) — no manual node configuration. A Pod declares its profile requirement; the driver provisions it.
• Time-slicing. Multiple Pods share one GPU through temporal multiplexing, configured declaratively in the DeviceClass (replicas: 4 = 4 time slices).
• Prioritized List. A Pod expresses a ranked fallback: “H100 first, A100 if none available.” The scheduler evaluates in order, boosting cluster utilisation.

# ResourceClaim with prioritized fallback
spec:
  devices:
    requests:
    - name: gpu
      deviceClassName: nvidia-gpu
      firstAvailable:
      - count: 2
        selectors:
        - cel:
            expression: "device.attributes['gpu.nvidia.com'].productName.startsWith('H100')"
      - count: 2
        selectors:
        - cel:
            expression: "device.attributes['gpu.nvidia.com'].productName.startsWith('A100')"

Device Taints (beta in 1.36) complete the picture: an administrator can taint a faulty GPU to pull it from the allocation pool, or reserve a subset of GPUs for a specific team — the device-level mirror of node taints.

NVIDIA donates its DRA driver to the CNCF

At KubeCon Europe 2026, NVIDIA made a structural move: donating its GPU DRA driver to the CNCF. The driver was already open-source; neutral governance signals to AMD, Intel, and every other silicon vendor that DRA is the standard, not a proprietary extension.

The driver handles three responsibilities. It discovers GPU hardware on each node and publishes structured attributes (memory, compute capability, NVLink topology, MIG profiles) into the Kubernetes API. It processes ResourceClaims by binding each claim to a specific physical GPU. It automatically configures MIG partitions and the Fabric Manager when a claim requires it.

What changes for operators: no more ad-hoc labelling scripts, no more GPU-model-specific node pools, no more manual MIG configuration. The scheduler sees the hardware as it actually is.

The bottom line: less waste, higher density

Moving from binary to attribute-based allocation has a direct cost impact. A cluster of 32 H100 80GB GPUs running at 40% VRAM utilisation because 7B model workloads hog full GPUs can double its workload density with time-slicing and native MIG — without buying a single additional GPU.

Gang scheduling through KAI Scheduler (NVIDIA’s open-source batch scheduler, complementary to DRA) eliminates the partially-stuck distributed job problem: all pods in a job start together, or none start. The 7 GPUs that were waiting for the eighth pod go back to the pool.

Resource Health Status (beta in 1.36) exposes device health directly in Pod status — no more digging through driver logs to find out whether a GPU failed.

The adoption checklist

1. Audit current usage. kubectl describe nodes | grep nvidia.com/gpu — every Pod still using nvidia.com/gpu is a migration candidate.
2. Install the DRA driver. The NVIDIA nvidia-dra-driver Helm chart deploys into the nvidia-dra namespace. It runs alongside the legacy device plugin — incremental migration is possible.
3. Define DeviceClasses. One class per sharing strategy (time-slicing, MIG, passthrough). Pods select their class via deviceClassName in the ResourceClaim.
4. Migrate workload by workload. Start with inference (immediate sharing benefit), then training jobs (topology benefit).
5. Add a batch scheduler if needed. KAI Scheduler for gang scheduling and fair-share queues; DRA alone is sufficient for low-contention clusters.

The verdict

Kubernetes 1.36 is not a footnote release — it is the release that brings GPUs into the cloud-native resource model alongside CPU and memory.

DRA going GA means the scheduler finally understands what a GPU is. The NVIDIA device plugin had a solid decade-long run; it is time to retire it. If you operate GPU clusters in production, the question is not whether to migrate — it is when. Every month spent on nvidia.com/gpu: 1 is a month of VRAM paid for and unused.

Start with inference workloads, deploy the DRA driver in parallel, and target a full migration before 1.38. Shareable GPUs are no longer a promise — they are a Kubernetes primitive.

References

• Kubernetes v1.36: More Drivers, New Features, and the Next Era of DRA, Kubernetes Blog, 7 May 2026.
• Complete Guide to Kubernetes 1.36: DRA GA, DEV Community, April 2026.
• Kubernetes GPU Orchestration in 2026: DRA, KAI Scheduler, and Grove, Spheron Blog, 2026.
• Dynamic Resource Allocation, Kubernetes documentation.
• NVIDIA DRA Driver for GPU, GitHub.
• KAI Scheduler, GitHub.