Kubernetes 1.37: DRA Slices One GPU Into Many Pods

Kubernetes 1.37 drops August 26. For most teams, that is a routine version bump with the usual round of deprecation warnings and graduated features. For anyone running GPU workloads, it is not: pod-level resources hit stable, DRA device taints reach GA, and the GPU partitioning story that has been building for two years takes another decisive step forward. If you have been running nvidia.com/gpu: 1 and wondering when you can do better, the answer is arriving this month.

The GPU Scheduling Problem Worth Solving

Cast AI measured average GPU utilization across tens of thousands of production Kubernetes clusters in 2026 and found 5%. Not 50%. Five. A quantized LLM running on an 80GB A100 typically consumes about 12GB of memory, leaving 68GB idle while the meter runs at roughly $6–15 per GPU-hour depending on cloud and instance type.

The old Device Plugin Framework is the culprit. It treated GPUs like parking spots — request one, get one, the scheduler decrements a counter. It had no concept of which GPU you got, how much memory it had, or whether there was room for anyone else. Sharing required ugly workarounds: manual MIG configuration before scheduling, time-slicing with no isolation guarantees, or just buying more hardware.

Dynamic Resource Allocation is the architectural fix. Instead of counting devices, it describes them. A pod declares a ResourceClaim — “give me a device where memory exceeds 40GB and the architecture is Hopper” — and the scheduler evaluates actual hardware attributes to find a match. It is the same conceptual shift that PersistentVolumeClaims brought to storage: from “give me 100GB” to “give me fast SSD in us-east-1a.”

What Kubernetes 1.37 Actually Ships

Sixteen enhancements graduate to stable in 1.37. The ones AI and infrastructure teams care about most:

Pod-level resources → Stable. You can now set CPU, memory, and hugepage requests and limits at the pod level instead of per container. Multi-container GPU workloads — a model server plus a sidecar, a prefill pod alongside a decode pod — no longer require duplicating resource declarations across every container spec. Both the v1 and v1beta1 APIs keep working, so existing manifests are fine.

DRA device taints and tolerations → GA. This mirrors the node taint model down to individual GPU devices. A thermal-throttling H100 can be cordoned without taking down the entire node. A GPU under maintenance gets tainted; pods without the matching toleration avoid it automatically. For clusters with dozens of GPUs across many nodes, this is the operational primitive that was missing.

The API server itself also gets a significant boost: internal type conversions have been eliminated, producing up to 5.7x faster response times and 3.3x lower memory usage. Large clusters with heavy custom resource traffic will notice this immediately.

GPU Partitioning: How It Works Now

The old model was a single line that told the scheduler nothing useful:

resources:
  limits:
    nvidia.com/gpu: 1

The new model, using a DRA ResourceClaimTemplate to request a specific H100:

apiVersion: resource.k8s.io/v1beta2
kind: ResourceClaimTemplate
metadata:
  name: h100-gpu-claim
spec:
  spec:
    devices:
      requests:
      - name: gpu
        deviceClassName: gpu.nvidia.com
        selectors:
        - cel:
            expression: >
              device.attributes["gpu.nvidia.com"].productName.startsWith("H100")
              && device.attributes["gpu.nvidia.com"].memory >= 80737418240

MIG (Multi-Instance GPU) partitioning becomes a first-class operation. Previously, enabling MIG on an H100 required manual driver configuration before Kubernetes scheduled anything. With the NVIDIA DRA driver — donated to the Kubernetes community as a reference implementation in March 2026 — you simply request a MIG profile and the driver handles the rest:

devices:
  requests:
    - name: mig-slice
      exactly:
        deviceClassName: mig.nvidia.com
        selectors:
          - cel:
              expression: |
                device.attributes["gpu.nvidia.com"].profile == "1g.10gb"

An H100 supports up to seven MIG instances. Seven pods, one GPU, full hardware isolation between them. This is not time-slicing — each instance gets dedicated compute, memory bandwidth, and L2 cache. The utilization case for this is overwhelming: production teams running DRA with MIG have reported going from 13% GPU utilization to 37%, with some reaching 80%.

The Cost Case

An H100 on a major cloud runs around $6.88 per hour. Split across four experiment pods using MIG, that is $1.72 per pod-hour. Enable Spot pricing and the cost drops to roughly $0.69 per pod-hour. Teams running hundreds of GPUs and improving utilization by even 20 percentage points are looking at 50–70% infrastructure cost reductions. That is not a rounding error in a budget — it is the difference between a team scaling its model experiments and hitting a wall.

The math is not subtle. If your team spends $15,000 per month on GPU compute at 10% average utilization, you are paying $13,500 for idle hardware every month. DRA and MIG are not a nice-to-have — they are a cost audit you should have run already.

What Is Still Alpha

KEP-4815 (partitionable devices) continues progressing. This covers on-demand partitioning — GPUs that are not pre-sliced but can be split at allocation time based on workload requirements. It is the right abstraction for heterogeneous clusters where different jobs need different slice sizes without pre-configuring every possible partition on every node.

Standard NUMA node attributes land in alpha, giving multi-GPU workloads a vendor-neutral topology view. Placement decisions will work across NVIDIA, AMD, and Intel hardware without driver-specific logic — a meaningful step for multi-vendor clusters.

DRA derived attributes (also alpha) let you write CEL expressions that synthesize virtual attributes across device types — pairing a GPU with a specific NIC for RDMA workloads, for example, without encoding vendor-specific attribute names in every manifest.

What to Fix Before You Upgrade

• nftables is the default in 1.40. Kubernetes 1.37 starts logging IPVS deprecation warnings. You have three releases to migrate. Do not wait until 1.40 forces the issue.
• cgroup v2 is required. failCgroupV1 defaults to true since 1.35. Any node still running cgroup v1 will fail kubelet initialization. Upgrade nodes now.
• Static pods lost API access. A bug that allowed static pods to reference Secrets or ConfigMaps via configMapRef and secretRef is now fixed and enforced. Audit your static pod manifests before upgrading.
• kubectl run -f is deprecated. Switch to kubectl apply for file-based pod creation.

The Practical Upgrade Path

For AI infrastructure teams, the DRA driver installation is straightforward. You need Kubernetes 1.33 or later for the v1beta2 API, NVIDIA drivers 565 or later, and Container Toolkit with CDI support enabled. Deploy the DRA driver via Helm:

helm repo add nvidia https://helm.ngc.nvidia.com/nvidia
helm install nvidia-dra-driver nvidia/nvidia-dra-driver   --namespace nvidia-dra   --create-namespace   --version 0.2.0

From there, define ResourceClaimTemplates instead of device plugin limits. The fallback to the old integer model stays available if you need a gradual migration path.

The broader ecosystem is coalescing around this. Google contributed a DRA driver for TPUs alongside NVIDIA’s reference implementation. The CNCF AI Conformance Program now mandates DRA APIs. Kubernetes 1.37 is a good release to start moving with it — pod-level resources and device taints in stable give you a real operational foundation, and the cost savings are immediate.