Kubernetes v1.37: DRA Updates – New GA Features and What's Next

In Kubernetes 1.37 the Dynamic Resource Allocation (DRA) “Extended Resource” mechanism reached General Availability. This feature lets a DRA driver satisfy a request that appears in a pod spec through the classic extended‑resource name (for example example.com/gpu) without the cluster also running a legacy device plugin for the same hardware.

When an ExtendedResource name is declared on a DeviceClass, the scheduler treats a pod that references that name exactly as it did with the older device‑plugin model. The difference is that the allocation decision is delegated to the DRA driver, which can perform richer checks (NUMA affinity, capacity ranges, custom CEL rules) before returning a ResourceClaim that contains a devices field in its .status. Because the pod does not need to create a ResourceClaim explicitly, existing manifests remain unchanged.

Key operational effects

• Zero‑code migration path: workloads that already request example.com/gpu continue to run without modification; the backend allocation logic simply switches from the device‑plugin to the DRA driver.
• Unified visibility: the driver populates per‑device status (e.g., interface name, MAC address, IP) in ResourceClaim.status.devices, giving operators the same observability that was previously only available after a pod started.
• Consistent scheduling semantics: device taints and tolerations, now stable, work with extended resources, allowing administrators to mark a specific GPU offline while other pods continue to schedule on remaining devices.

Practical example

apiVersion: v1
kind: Pod
metadata:
  name: gpu‑worker
spec:
  containers:
  - name: app
    image: my‑app:latest
    resources:
      limits:
        example.com/gpu: "1"

In a 1.37 cluster that has a DRA driver registered for example.com/gpu, the scheduler matches the pod to a suitable GPU device via the driver. The driver returns a claim whose .status.devices entry might contain:

status:
  devices:
  - name: gpu‑0
    attributes:
      interface: eth0
      mac: "aa:bb:cc:dd:ee:ff"
      ip: "10.2.3.4"

Because the pod never referenced a ResourceClaim object, the manifest stays identical to the pre‑DRA version, yet the operator gains detailed device information for monitoring or for downstream services such as network‑attached storage that need the reported IP address.

Adoption checklist

• Verify that the desired extended‑resource name is defined on a DeviceClass.
• Deploy the corresponding DRA driver; remove the legacy device plugin if no longer needed.
• Confirm that DeviceTaintRule and taint‑toleration policies are configured for maintenance workflows.
• Monitor ResourceClaim.status.devices to ensure visibility into allocated devices.

The Kubernetes 1.37 release promotes three DRA capabilities to stable, giving cluster operators deterministic control over device lifecycle, topology awareness, and visibility into network‑attached resources.

Device taints and tolerations (DeviceTaintRule)

Device taints work like node taints: a driver can label a device with a key=value:effect pair, and the scheduler will exclude that device from new allocations unless a pod’s ResourceClaim explicitly tolerates the taint. The DeviceTaintRule API object lets administrators apply the same taint across all devices of a particular class without modifying each driver.

• Use case: Mark a NIC that requires firmware upgrade as maintenance=true:NoSchedule. New pods that request the NIC are blocked, while existing pods continue to run until they are evicted or the claim adds a matching toleration.
• Implementation pattern:

  apiVersion: device.k8s.io/v1alpha1
  kind: DeviceTaintRule
  metadata:
    name: nic-maintenance
  spec:
    taint:
      key: maintenance
      value: "true"
      effect: NoSchedule

• Pod toleration example:

  apiVersion: v1
  kind: Pod
  spec:
    resourceClaims:
    - name: my-nic
    tolerations:
    - key: maintenance
      operator: Equal
      value: "true"
      effect: NoSchedule

Standardized NUMA node attribute

The attribute resource.kubernetes.io/numaNode is now the canonical name for exposing a device’s NUMA locality. Because every driver registers this attribute under the same key, the scheduler can co‑locate devices (e.g., GPU and NIC) on the same NUMA node without vendor‑specific translation.

• Define the attribute in a DeviceClass:

  attributes:
        resource.kubernetes.io/numaNode: "2"

• Scheduler can filter with a selector such as resource.kubernetes.io/numaNode=2 to enforce locality constraints.

ResourceClaim.status.devices field

ResourceClaims now include a devices array in their status. For network devices, drivers populate the interface name, MAC address, and assigned IP addresses. This information is observable by controllers and users without inspecting the pod’s network namespace.

• Sample status snippet:

  status:
    devices:
    - name: eth0
      attributes:
        mac: "aa:bb:cc:dd:ee:ff"
        ips:
        - "10.1.2.3"
        - "fd00::1"

• Controllers can build higher‑level services (e.g., load balancers) by reading the reported IPs directly from the claim.

By combining device taints, a unified NUMA attribute, and enriched claim status, engineers gain fine‑grained operational control, predictable topology placement, and transparent network device state—key requirements for large‑scale, performance‑sensitive workloads.

The Kubernetes 1.37 release introduces significant advancements to Dynamic Resource Allocation (DRA), enhancing how orchestrators manage specialized hardware. These updates focus on improving workload-to-resource mapping, virtual machine integration, and scheduler consistency.

Workload-Level ResourceClaims
The promotion of ResourceClaim support for workloads to Beta—guarded by the DRAWorkloadResourceClaims feature gate—allows for more efficient resource sharing. Unlike legacy mechanisms that constrained claims to a per-pod reservation limit of 256, this update enables Workload and PodGroup objects to reference ResourceClaims directly. This architecture permits a single claim to be shared across an entire group of pods, facilitating complex orchestration for high-performance computing or distributed training jobs that require uniform access to a shared resource pool.

DRA Device Attributes Downward API
Targeting KubeVirt virtual machine injection, the new alpha-stage Device Attributes Downward API simplifies how guest operating systems gain visibility into host-side hardware. When a driver prepares a ResourceClaim, it can populate specific Metadata fields. The framework subsequently writes this information into a JSON file, which is mounted into the container via the Container Device Interface (CDI). This eliminates the need for sidecar containers or custom controllers to watch ResourceClaims and ResourceSlices, allowing KubeVirt VMs to natively read attributes such as PCI bus addresses and MAC addresses.

Node Allocatable Resource Requests
Node allocatable resource requests have advanced to Alpha 2. This functionality bridges the gap between DRA-managed resources—such as specialized CPU or memory pools—and standard Kubernetes scheduling. By aligning DRA requests with traditional resource management, the scheduler and kubelet can evaluate node capacity holistically. This ensures that nodes are not oversubscribed and allows engineers to define resource requirements in a single location, rather than duplicating configurations between the ResourceClaim and the pod specification. This alignment reduces the risk of scheduling conflicts and simplifies the management of nodes that mix heterogeneous resource types.

The PreQueueingHint extension point (alpha) changes how the scheduler reacts to ResourceClaim events. Previously each claim triggered a full scan of every unschedulable pod, an O(N²) operation that could dominate scheduling latency during large scale‑ups. By indexing pods with a dedicated informer, the DRA plugin now requeues only the pods whose predicates are directly affected, reducing the path to O(1) and roughly doubling throughput in early benchmarks. This improvement is gated by SchedulerPreQueueingHints and must be enabled explicitly.

Fractional capacity support is introduced in CapacityRequestPolicyRange (beta). Devices that expose sub‑unit resources—such as GPUs that can be sliced into 0.25 or 0.5 portions—can now be requested with decimal values. The scheduler treats these values as consumable capacity, allowing workloads to express fine‑grained needs without over‑provisioning.

Example of a fractional request in a pod spec:

apiVersion: v1
kind: Pod
metadata:
  name: fractional-gpu
spec:
  containers:
  - name: app
    image: myapp:latest
    resources:
      claims:
      - name: gpu-claim
  resourceClaims:
  - name: gpu-claim
    source:
      resourceClaimName: gpu-claim
    capacityRequestPolicy:
      range:
        min: "0.5"
        max: "1.0"

DRA Device Compatibility Groups (alpha) let drivers tag logical partitions of a physical device—such as NVIDIA MIG slices or vGPU profiles—with a compatibility identifier. The scheduler then rejects pod combinations that belong to different groups, preventing the driver from encountering a preparation failure after scheduling.

• Define a compatibility group in the driver’s DeviceClass manifest.
• Assign the group label to each partition (e.g., compatibilityGroup: mig-A or compatibilityGroup: vgpu‑standard).
• Enable the DRADeviceCompatibilityGroups feature gate.
• Pods requesting devices from incompatible groups will be filtered out during scheduling.

Practical guidance for engineers:

1. Enable the required feature gates (SchedulerPreQueueingHints, DRAFractionalCapacityRange, DRADeviceCompatibilityGroups) in the API server and scheduler configuration.
2. Update driver manifests to expose fractional capacity ranges and compatibility group tags.
3. Validate pod specifications with kubectl explain to ensure the correct claim syntax and capacity values.
4. Monitor scheduling latency and allocation failures after rollout; the reduced requeue path should manifest as lower scheduler_attempts_total for DRA‑related pods.

By combining these three alpha/beta features, clusters can achieve higher scheduling throughput, finer resource granularity, and safer placement of heterogeneous device partitions, all while keeping the existing extended‑resource workflow unchanged.

The progression of Dynamic Resource Allocation (DRA) remains a primary focus for the Kubernetes community, with the upcoming v1.38 release intended to continue the maturation of current alpha and beta capabilities. Following the stabilization of Extended Resource support and device taints in v1.37, the roadmap emphasizes improving the framework's performance, scalability, and driver-level reliability.

Engineers looking to influence the direction of DRA or contribute to core development should engage directly with the Working Group (WG) Device Management. Participation allows contributors to shape features that address complex hardware integration challenges, such as the evolution of node-allocatable resource requests and refined scheduling mechanisms like the PreQueueingHint extension point.

To participate effectively, consider the following engagement channels:

• WG Device Management Slack: The primary hub for real-time discussion regarding KEPs, driver implementation queries, and technical architectural debates.
• Working Group Meetings: Regularly scheduled meetings accommodate multiple global time zones (US/EU and EU/APAC), providing a forum for reviewing enhancement ideas that may not yet be documented as formal GitHub issues.
• Development Contributions: Opportunities exist across the full stack, ranging from low-level core Kubernetes scheduler optimizations to user-facing usability enhancements in kubectl.

In anticipation of v1.38, the community is focused on progressing existing experimental features. For instance, the transition of DRAWorkloadResourceClaims from its current beta state and the refinement of alpha-stage features—such as derived attributes using CEL expressions and multi-value list types—represent significant areas where community feedback and testing are critical. As DRA continues to integrate more deeply with Kubernetes scheduling and node lifecycle management, the focus remains on reducing the complexity of device injection and ensuring that resource allocation remains consistent, whether for standard containerized workloads or KubeVirt-based virtual machines.