Kubernetes 1.37 DRA: A Practical Migration Guide for GPU Workloads

Kubernetes Dynamic Resource Allocation (DRA) gives device scheduling the flexibility that dynamic provisioning brought to storage. Kubernetes 1.37 makes adoption easier because DRA-backed devices can now satisfy traditional extended-resource requests through a stable API.

For platform teams, that means an existing workload can continue requesting example.com/gpu while the cluster moves device allocation behind the scenes from a device plugin to DRA.

What DRA Changes

Traditional device plugins advertise a count on each node. DRA adds richer objects:

• ResourceSlice publishes available devices and attributes.
• DeviceClass defines a reusable category and selection rules.
• ResourceClaim or ResourceClaimTemplate requests devices for a workload.
• A DRA-compatible driver prepares the allocated device for the container.

Selectors can use CEL to match device attributes, and classes let the platform expose intent such as “cost optimized” or “high performance” instead of vendor-specific details.

Stable Extended-Resource Compatibility

In Kubernetes 1.37, a DeviceClass can declare an extended resource name:

apiVersion: resource.k8s.io/v1
kind: DeviceClass
metadata:
  name: gpu.example.com
spec:
  selectors:
    - cel:
        expression: device.driver == 'gpu.example.com'
  extendedResourceName: example.com/gpu

An existing Pod can keep its familiar request:

resources:
  limits:
    example.com/gpu: 1

The scheduler can match that request to DRA devices without requiring the workload author to create a separate claim. This compatibility path is valuable when hundreds of manifests already use extended resources.

Other Kubernetes 1.37 Improvements

Device taints and tolerations are stable. A driver can mark an unhealthy or unsuitable device so new Pods avoid it, and an administrator can apply a DeviceTaintRule without reconfiguring the driver.

ResourceClaim status can also expose standardized device information. Network devices may report interface name, MAC address, and IP addresses, giving controllers visibility after allocation.

Kubernetes 1.37 additionally standardizes a NUMA node attribute so schedulers and drivers can reason about device locality consistently across vendors.

Migrate Gradually

1. Confirm the vendor driver supports the Kubernetes 1.37 DRA APIs.
2. Inventory current extended-resource names and workload quantities.
3. Create a DeviceClass with a unique extendedResourceName.
4. Add a canary node pool using the DRA driver.
5. Run representative training, inference, and restart tests.
6. Inspect allocation and device status.
7. Expand only after failure and cleanup behavior is proven.

Avoid defining the same extended resource on multiple DeviceClasses. The API documents selection behavior, but duplicate ownership makes operations harder to reason about.

Understand the Scheduling Limitation

The Kubernetes scheduler does not preempt an existing Pod merely to free a DRA device for a higher-priority Pod. A high-priority Pod can remain Pending until the current device user exits or is removed.

Capacity planning, queueing, quotas, and workload admission still matter. DRA improves allocation expressiveness; it does not create accelerators or guarantee immediate priority-based access.

Secure DRA Controllers

DRA status updates use fine-grained authorization. Grant drivers and controllers only the resource and synthetic-subresource permissions they require. Do not copy broad cluster-admin examples into production.

Audit who can create or change DeviceClasses because those objects influence which physical devices a workload receives and how the driver configures them.

Bottom Line

Kubernetes 1.37 provides a realistic bridge from device-plugin-era manifests to richer DRA allocation. Start with extended-resource compatibility, isolate the first node pool, validate cleanup and failure behavior, and introduce explicit claims only where workloads need DRA’s advanced selection or sharing features.

Review the broader Kubernetes 1.37 upgrade guide before enabling new device behavior.

Sources

• Kubernetes Blog: Kubernetes v1.37 DRA updates
• Kubernetes Docs: Dynamic Resource Allocation
• Kubernetes Docs: DRA hardening guide