Blog post for DRA updates in 1.36 #54567

SergeyKanzhelev · 2026-03-26T21:31:28Z

it will be great to include some information on adoption and gaps still left comparing to Device Plugin. Maybe a couple of words on available DRA drivers. So end users may make sense of this blog post.

Added a little section about the availability of drivers. I'm a little worried that by mentioning some drivers here, we might be forgetting others that also should be included. But I can ask in the device management chat if someone knows about other drivers that should be included.

I need to think a bit more about the gaps vs Device Plugin.

I can't think of anything that can be done by a Device Plugin that cannot also be done with a DRA driver. Resource Health Status may have been the last remaining gap.

is there auto-tainting of "broken" devices? Yes, it seems like the health tracking is the last thing

lmktfy · 2026-04-14T08:44:46Z

Suggested change

Dynamic Resource Allocation (DRA) has fundamentally changed how we handle hardware

Dynamic Resource Allocation (DRA) has fundamentally changed how platform administrators can handle hardware

If "we" means "all the contributors to DRA" then it's best not to have it also mean "anyone using Kubernetes", within one article.

lmktfy · 2026-04-14T08:45:55Z

This link is stale, and the transfer happened before the v1.36 release. Let's update and switch to past tense.

pohly · 2026-04-07T09:48:22Z

Calling those out seems reasonable for a blog post because this is newsworthy.

We could link to https://github.com/kubernetes-sigs/wg-device-management/tree/main/device-ecosystem but I'll defer to SIG Docs about that.

You can link to https://www.kubernetes.dev/community/community-groups/wg/device-management/

If we want to publish something like https://github.com/kubernetes-sigs/wg-device-management/tree/main/device-ecosystem for end users, we can. Maybe a (separate)
blog article?

It's not a good fit for the official Kubernetes documentation; it has a bit too much about vendors and offerings. But a neutral blog article could be OK.

lmktfy · 2026-04-14T07:35:37Z

I would use an actual heading here; also, use sentence case, eg

### Prioritized list (stable) {#prioritized-list}

and similarly for other headings

lmktfy · 2026-04-14T07:36:40Z

Idiomatically, don't use title case for the names of features. Outside of a hyperlink we use italics; within a hyperlink they are optional.

lmktfy · 2026-04-14T08:47:46Z

Watch out for "now"; was this not possible in v1.35?

If it was, even behind a feature gate, we should reword.

harche · 2026-03-27T14:13:32Z

I want to include kubernetes/enhancements#4680 in the feature blog.

ref: docs PR is #54420

Suggested change

**Resource Health Status (Beta)**

Knowing when a device has failed or become unhealthy is critical for

workloads running on specialized hardware. With

[Resource Health Status](/docs/concepts/scheduling-eviction/dynamic-resource-allocation/#device-health-monitoring),

Kubernetes now exposes device health information directly in the Pod

Status through the `allocatedResourcesStatus` field. When a DRA driver

detects that an allocated device has become unhealthy, it reports this

back to the kubelet, which surfaces it in each container's status.

In 1.36, the feature graduates to beta (enabled by default) and adds

an optional `message` field providing human readable context about the

health status, such as error details or failure reasons. DRA drivers

can also configure per device health check timeouts, allowing different

hardware types to use appropriate timeout values based on their

health reporting characteristics. This gives users and controllers

crucial visibility to quickly identify and react to hardware failures.

So I've added your proposal for now, but do you think we can shorten it a bit and make it just one paragraph? There is a large number of features and we don't want the blog post to be too long. Focus just on the benefits of this feature and what it enables and leave the details to the DRA docs which we link to. Also, including that it is graduating to beta in 1.36 is already given from the context.

Sorry I forgot to add this in the first draft, it is of course something we should include in the blog.

@harche Could you take a look at this? Currently the description of this feature gets into quite a bit more detail than the other descriptions and I think some of it can be left to the documentation.

thanks @mortent , does this look better ?#54567 (comment)

lmktfy · 2026-04-14T08:48:47Z

Suggested change

Kubernetes now exposes device health information directly in the Pod Status through the

Kubernetes can expose device health information directly in the Pod `.status`, through an entry within the

?

lmktfy · 2026-04-14T08:49:45Z

Suggested change

`allocatedResourcesStatus` field. When a DRA driver detects that an allocated device

`.status.allocatedResourcesStatus` field.

When a compatible DRA driver detects that an allocated device

lmktfy · 2026-04-14T08:12:18Z

(for this article, only a nit)

Remember that this is a post release blog:

Suggested change

In 1.36, the feature graduates to beta (enabled by default) and adds an optional `message`

In 1.36, the feature has graduated to beta (and is now enabled by default). There was

a small change from alpha, adding an optional `message`

harche · 2026-04-13T18:26:53Z

Suggested change

**Resource Health Status (Beta)**

Knowing when a device has failed or become unhealthy is critical for workloads running on

specialized hardware. With

[Resource Health Status](/docs/concepts/scheduling-eviction/dynamic-resource-allocation/#device-health-monitoring),

Kubernetes now exposes device health information directly in the Pod Status through the

`allocatedResourcesStatus` field. When a DRA driver detects that an allocated device

has become unhealthy, it reports this back to the kubelet, which surfaces it in each

container's status.

In 1.36, the feature graduates to beta (enabled by default) and adds an optional `message`

field providing human readable context about the health status, such as error details or

failure reasons. DRA drivers can also configure per device health check timeouts,

allowing different hardware types to use appropriate timeout values based on their

health reporting characteristics. This gives users and controllers crucial visibility

to quickly identify and react to hardware failures.

**Resource Health Status (Beta)**

Knowing when a device has failed or become unhealthy is critical for workloads running on

specialized hardware. With

[Resource Health Status](/docs/concepts/scheduling-eviction/dynamic-resource-allocation/#device-health-monitoring),

Kubernetes now exposes device health information directly in Pod Status, giving users and

controllers crucial visibility to quickly identify and react to hardware failures. In 1.36,

the feature graduates to beta (enabled by default) and adds support for human readable

health status messages, making it easier to diagnose issues without diving into driver logs.

I recommend writing the graduation as if it was in the past (which it will be). Also, watch out for implying that beta → enabled by default. Some things go to beta as initially opt-in.

alaypatel07 · 2026-04-10T13:35:49Z

kubernetes/enhancements#5304

This enhancement was add in 1.36, I wonder if this section should contain a sub-section for it.

cc @pohly

Let's add it. Can you suggest something?

Sure, added a suggestion here: https://github.com/kubernetes/website/pull/54567/changes#r3076822230

lmktfy · 2026-04-14T08:22:27Z

Try to describe what is possible (rather than summarizing the enhancement).

eg

People using Kubernetes in their platform may have large AI/ML workloads and rely on strict _topological scheduling_ (matching Pods to run across multiple nodes with firm constraints, such as making an entire rack of compute available along with interconnects). DRA provides an [integration](/docs/concepts/scheduling-eviction/dynamic-resource-allocation/#workload-resourceclaims) with the Workload API, so that you can get near seamless management of infrastructure resources, even across very large sets of Pods. By associating ResourceClaims or ResourceClaimTemplates with the PodGroup API (also new in Kubernetes v1.35), this integration eliminates previous scaling bottlenecks, such as the limit on the number of Pods that can share a claim, and removes the burden of custom or manual claim management from specialized orchestrators.

Notice how I didn't mention the feature other than by hyperlinking to its docs. I would consider also mentioning the feature gate on this one.

lmktfy · 2026-04-14T08:23:15Z

Suggested change

iteration of using the DRA API to manage Kubernetes native resources (like CPU and

iteration of using the DRA APIs to manage

_node allocatable_ infrastructure resources (such as CPU and

"Infrastructure resource" to disambiguate from HTTP resources, BTW.

pohly · 2026-04-07T09:51:12Z

Should this be called "Node Allocatable Resources" instead of "Native Resources"?

cc @pravk03

I think I used the name from the KEP, but I see that #54598 uses the term node allocatable resources. @pravk03 I assume node allocatable resources is the preferred name here? And do we spell that with a hyphen or not (the docs seems inconsistent on this)?

Yes, we have renamed this to node allocatable resources.

Following the convention in the Node Allocatable and Resource Management documentation, we can omit the hyphen. I’ll update the the KEP and docs to keep it consistent.

lmktfy · 2026-04-14T08:33:02Z

I recommend: talk about what Kubernetes does more than what the feature does.

Something like:

In v1.36, ResourceClaim constraint evaluation has changed (behind a feature gate) to work better with scalar and list values: `matchAttribute` now checks for a non-empty intersection, and `distinctAttribute` checks for pairwise disjoint values. Kubernetes v1.36 also introduces an `includes()` function in CEL, that lets device selectors keep working more easily when an attribute changes between scalar and list representations. (The `includes()` function is only available in DRA contexts for expression evaluation).

I avoided "naturally". People reading this probably won't have a sense of the natural way for ResourceClaim evaluation to work; that's different from how people use "naturally" outside of a more jargon-y context.

lmktfy · 2026-04-14T08:33:44Z

Just call this deterministic device selection; it's snappier.

everpeace · 2026-03-26T21:45:46Z

I want to include kubernetes/enhancements#5491 if it's worth putting in the feature blog.

ref: docs PR is #54561

Suggested change

**List Types for Attributes**

With

[List Types for Attributes](/docs/concepts/scheduling-eviction/dynamic-resource-allocation/#list-type-attributes),

DRA can represent device attributes as typed lists (int, bool, string, and

version), not just scalar values. This helps model real hardware topology, such

as devices that belong to multiple PCIe roots or NUMA domains.

This feature also extends `ResourceClaim` constraint behavior to work naturally

with both scalar and list values: `matchAttribute` now checks for a non-empty

intersection, and `distinctAttribute` checks for pairwise disjoint values.

It also introduces `includes()` function in DRA CEL, which lets device selectors keep working

more easily when an attribute changes between scalar and list representations.

Sorry I forgot this one, it is definitely worth including. Added your suggestion.

Similar to my comment on #54567 (comment), do you think we could make it a bit more focused on just the benefits of the feature and leave some of the details to the DRA documentation? And see if we can keep it to a single paragraph?

@everpeace Could you take a look at updating the description to align a bit more with the other features, ref my previous comment?

It's in now, right?

SergeyKanzhelev · 2026-04-07T18:13:06Z

should we say that the big priority is to migrate community to DRA? And also make it a call to action?

Good point. I've added a small section for this.

alaypatel07 · 2026-04-14T02:32:49Z

Suggested change

## What’s next?

**Discoverable Device Metadata in Containers**

Workloads running on with DRA devices often need to discover details about

their allocated devices, such as PCI bus addresses or network

interface configuration, without querying the Kubernetes API. With

[DRA Device Metadata](/docs/concepts/scheduling-eviction/dynamic-resource-allocation/#device-metadata),

Kubernetes defines a standard protocol for how DRA drivers expose device

attributes to containers as versioned JSON files at well-known paths. Drivers

built with the

[DRA kubelet plugin library](https://pkg.go.dev/k8s.io/dynamic-resource-allocation/kubeletplugin)

get this behavior transparently; they just provide the metadata and the

library handles file layout, CDI bind-mounts, versioning, and lifecycle. This

gives applications a consistent, driver-independent way to discover and

consume device metadata, eliminating the need for custom controllers or

looking up the of ResourceSlice objects to get metadata via attributes.

## What’s next?

lmktfy · 2026-04-14T08:35:02Z

I would call it a release, not a cycle: we're writing for the public.

lmktfy · 2026-04-14T08:36:04Z

I might write:

Suggested change

integration with Workload-Aware and Topology-Aware Scheduling.

integration with _workload-aware scheduling_ and with _topology-aware scheduling_.

lmktfy · 2026-04-14T08:38:20Z

This seems far fetched. Do we mean that we want everyone using accelerators to use DRA, or do we mean that behind even simple workloads, CPU and memory resources become allocated to nodes and Pods dynamically?

Without being prescriptive, let's try to help readers guess what we really mean.

lmktfy · 2026-04-14T08:41:20Z

Rather than those two links, consider linking to WG Device Management.

Those existing links aren't useful to the public reading the article.

lmktfy · 2026-04-14T08:43:06Z

You might mean Americas rather than "US", and "EMEA" rather than EU. We like to look inclusive.

Blog post for DRA updates in 1.36 #54567

Are you sure you want to change the base?

Blog post for DRA updates in 1.36 #54567

Uh oh!

Uh oh!

Diff view

Diff view

There are no files selected for viewing

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

everpeace Mar 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

everpeace Mar 26, 2026 •

edited

Loading

alaypatel07 Apr 14, 2026 •

edited

Loading