Skip to content

Commit 0bec122

Browse files
k8s-ci-robotk8s-ci-robot
authored
Merge pull request kubernetes#54567 from mortent/DRABlog136
Blog post for DRA updates in 1.36
2 parents de1fc72 + 5cdaca3 commit 0bec122

1 file changed

Lines changed: 183 additions & 0 deletions

File tree

‎content/en/blog/_posts/2026/dra-136-update.md‎

Lines changed: 183 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,183 @@
1+
---
2+
layout: blog
3+
title: "Kubernetes v1.36: More Drivers, New Features, and the Next Era of DRA"
4+
slug: dra-136-updates
5+
draft: true
6+
date: 2026-04-27
7+
author: >
8+
The DRA team
9+
---
10+
11+
Dynamic Resource Allocation (DRA) has fundamentally changed how platform administrators handle hardware
12+
accelerators and specialized resources in Kubernetes. In the v1.36 release, DRA
13+
continues to mature, bringing a wave of feature graduations, critical usability
14+
improvements, and new capabilities that extend the flexibility of DRA to native
15+
resources like memory and CPU, and support for ResourceClaims in PodGroups.
16+
17+
Driver availability continues to expand. Beyond specialized compute accelerators,
18+
the ecosystem includes support for networking and other hardware types,
19+
reflecting a move toward a more robust, hardware-agnostic infrastructure.
20+
21+
Whether you are managing massive fleets of GPUs, need better handling of failures,
22+
or simply looking for better ways to define resource fallback options, the upgrades
23+
to DRA in 1.36 have something for you. Let's dive into the new features and graduations!
24+
25+
## Feature graduations
26+
27+
The community has been hard at work stabilizing core DRA concepts. In Kubernetes 1.36,
28+
several highly anticipated features have graduated to Beta and Stable.
29+
30+
### Prioritized list (stable) {#prioritized-list}
31+
32+
Hardware heterogeneity is a reality in most clusters. With the
33+
[Prioritized list](/docs/concepts/scheduling-eviction/dynamic-resource-allocation/#prioritized-list)
34+
feature, you can confidently define fallback preferences when requesting
35+
devices. Instead of hardcoding a request for a specific device model, you can specify an
36+
ordered list of preferences (e.g., "Give me an H100, but if none are available, fall back
37+
to an A100"). The scheduler will evaluate these requests in order, drastically improving
38+
scheduling flexibility and cluster utilization.
39+
40+
### Extended resource support (beta) {#extended-resource}
41+
42+
As DRA becomes the standard for resource allocation, bridging the gap with legacy systems
43+
is crucial. The DRA
44+
[Extended resource](/docs/concepts/scheduling-eviction/dynamic-resource-allocation/#extended-resource)
45+
feature allows users to request resources via traditional extended resources on a Pod.
46+
This allows for a gradual transition to DRA, meaning cluster operators can migrate clusters
47+
to DRA but let application developers adopt the ResourceClaim API on their own schedule.
48+
49+
### Partitionable devices (beta) {#partitionable-devices}
50+
51+
Hardware accelerators are powerful, and sometimes a single workload doesn't need an
52+
entire device. The
53+
[Partitionable devices](/docs/concepts/scheduling-eviction/dynamic-resource-allocation/#partitionable-devices)
54+
feature, provides native DRA support for dynamically carving physical hardware into smaller,
55+
logical instances (such as Multi-Instance GPUs) based on workload demands. This allows
56+
administrators to safely and efficiently share expensive accelerators across multiple Pods.
57+
58+
### Device taints (beta) {#device-taints}
59+
60+
Just as you can taint a Kubernetes Node, you can apply taints directly to specific DRA
61+
devices.
62+
[Device taints and tolerations](/docs/concepts/scheduling-eviction/dynamic-resource-allocation/#device-taints-and-tolerations)
63+
empower cluster administrators to manage hardware more effectively. You can taint faulty
64+
devices to prevent them from being allocated to standard claims, or reserve specific hardware
65+
for dedicated teams, specialized workloads, and experiments. Ultimately, only Pods with
66+
matching tolerations are permitted to claim these tainted devices.
67+
68+
### Device binding conditions (beta) {#device-binding-conditions}
69+
70+
To improve scheduling reliability, the Kubernetes scheduler can use the
71+
[Binding conditions](/docs/concepts/scheduling-eviction/dynamic-resource-allocation/#device-binding-conditions)
72+
feature to delay committing a Pod to a Node until its required external resources—such as attachable
73+
devices or FPGAs—are fully prepared. By explicitly modeling resource readiness, this
74+
prevents premature assignments that can lead to Pod failures, ensuring a much more robust
75+
and predictable deployment process.
76+
77+
### Resource health status (beta) {#device-health-monitoring}
78+
79+
Knowing when a device has failed or become unhealthy is critical for workloads running on
80+
specialized hardware. With
81+
[Resource health status](/docs/concepts/scheduling-eviction/dynamic-resource-allocation/#device-health-monitoring),
82+
Kubernetes expose device health information directly in the Pod status, giving users and
83+
controllers crucial visibility to quickly identify and react to hardware failures. The
84+
feature includes support for human-readable health status messages, making it
85+
significantly easier to diagnose issues without the need to dive into complex driver logs.
86+
87+
## New Features
88+
89+
Beyond stabilizing existing capabilities, v1.36 introduces foundational new features
90+
that expand what DRA can do. These are alpha features, so they are behind feature gates
91+
that are disabled by default.
92+
93+
### ResourceClaim support for workloads {#workload-resourceclaims}
94+
95+
To optimize large-scale AI/ML workloads that rely on strict topological scheduling, the
96+
[ResourceClaim support for workloads](/docs/concepts/scheduling-eviction/dynamic-resource-allocation/#workload-resourceclaims)
97+
feature enables Kubernetes to seamlessly manage shared resources across massive sets
98+
of Pods. By associating ResourceClaims or ResourceClaimTemplates with PodGroups,
99+
this feature eliminates previous scaling bottlenecks, such as the limit on the
100+
number of pods that can share a claim, and removes the burden of manual claim
101+
management from specialized orchestrators.
102+
103+
### Node allocatable resources {#node-allocatable-resources}
104+
105+
Why should DRA only be for external accelerators? In v1.36, we are introducing the first
106+
iteration of using the DRA APIs to manage _node allocatable_ infrastructure resources (like CPU and
107+
memory). By bringing CPU and memory allocation under the DRA umbrella with the DRA
108+
[Node allocatable resources](/docs/concepts/scheduling-eviction/dynamic-resource-allocation/#node-allocatable-resources)
109+
feature, users can leverage DRA's advanced placement, NUMA-awareness, and prioritization
110+
semantics for standard compute resources, paving the way for incredibly fine-grained
111+
performance tuning.
112+
113+
### DRA resource availability visibility {#resource-pool-status}
114+
115+
One of the most requested features from cluster administrators has been better visibility
116+
into hardware capacity. The new
117+
[Resource pool status](/docs/concepts/scheduling-eviction/dynamic-resource-allocation/#resource-pool-status)
118+
feature allows you to query the availability of devices in DRA resource pools. By creating a
119+
`ResourcePoolStatusRequest` object, you get a point-in-time snapshot of device counts
120+
— total, allocated, available, and unavailable — for each pool managed by a given
121+
driver. This enables better integration with dashboards and capacity planning tools.
122+
123+
### List types for attributes {#list-type-attributes}
124+
125+
ResourceClaim constraint evaluation has changed to work better with scalar
126+
and list values:
127+
`matchAttribute` now checks for a non-empty intersection, and
128+
`distinctAttribute` checks for pairwise disjoint values.
129+
130+
An `includes()` function in CEL has also been introduced,
131+
that lets device selectors keep working more easily when an attribute
132+
changes between scalar and list representations.
133+
(The `includes()` function is only available in DRA
134+
contexts for expression evaluation).
135+
136+
### Deterministic device selection {#deterministic-device-selection}
137+
138+
The Kubernetes scheduler has been updated to evaluate devices using lexicographical
139+
ordering based on resource pool and ResourceSlice names. This change empowers drivers
140+
to proactively influence the scheduling process, leading to improved throughput and
141+
more optimal scheduling decisions. The ResourceSlice controller toolkit automatically
142+
generates names that reflect the exact device ordering specified by the driver author.
143+
144+
### Discoverable device metadata in containers {#device-metadata}
145+
146+
Workloads running on nodes with DRA devices often need to discover details about
147+
their allocated devices, such as PCI bus addresses or network
148+
interface configuration, without querying the Kubernetes API. With
149+
[Device metadata](/docs/concepts/scheduling-eviction/dynamic-resource-allocation/#device-metadata),
150+
Kubernetes defines a standard protocol for how DRA drivers expose device
151+
attributes to containers as versioned JSON files at well-known paths. Drivers
152+
built with the
153+
[DRA kubelet plugin library](https://pkg.go.dev/k8s.io/dynamic-resource-allocation/kubeletplugin)
154+
get this behavior transparently; they just provide the metadata and the
155+
library handles file layout, CDI bind-mounts, versioning, and lifecycle. This
156+
gives applications a consistent, driver-independent way to discover and
157+
consume device metadata, eliminating the need for custom controllers or
158+
looking up ResourceSlice objects to get metadata via attributes.
159+
160+
## What’s next?
161+
162+
This release introduced a wealth of new Dynamic Resource Allocation (DRA) features,
163+
and the momentum is only building. As we look ahead, our roadmap focuses on maturing
164+
existing features toward beta and stable releases while hardening DRA’s performance,
165+
scalability, and reliability. A key priority over the coming cycles will be deep
166+
integration with _workload aware_ and _topology aware scheduling_.
167+
168+
A big goal for us is to migrate users from Device Plugin to DRA, and we want
169+
you involved. Whether you are currently maintaining a driver or are just beginning
170+
to explore the possibilities, your input is vital. Partner with us to shape the next
171+
generation of resource management. Reach out today to collaborate on development,
172+
share feedback, or start building your first DRA driver.
173+
174+
175+
## Getting involved
176+
177+
A good starting point is joining the WG Device Management
178+
[Slack channel](https://kubernetes.slack.com/archives/C0409NGC1TK) and
179+
[meetings](https://docs.google.com/document/d/1qxI87VqGtgN7EAJlqVfxx86HGKEAc2A3SKru8nJHNkQ/edit?tab=t.0#heading=h.tgg8gganowxq),
180+
which happen at Americas/EMEA and EMEA/APAC friendly time slots.
181+
182+
Not all enhancement ideas are tracked as issues yet, so come talk to us if you want to help or have some ideas yourself!
183+
We have work to do at all levels, from difficult core changes to usability enhancements in kubectl, which could be picked up by newcomers.

0 commit comments

Comments
 (0)