Kubernetes has traditionally used device plugins to make GPUs and other specialized hardware available to workloads. Kubernetes 1.37 gives cluster operators another option: Dynamic Resource Allocation, or DRA.
DRA Extended Resource support is now Stable in Kubernetes 1.37. A DRA driver can satisfy traditional extended resource requests such as example.com/gpu without requiring a separate device plugin.
That makes migration easier because existing workloads can continue requesting GPUs through the familiar resource model while the device allocation is handled by DRA.
DRA also provides a richer model for describing devices, selecting hardware based on attributes, creating reusable resource claims, and handling device-specific scheduling requirements.
What Is Dynamic Resource Allocation?
DRA is a Kubernetes resource-management mechanism designed for resources that cannot be described well by ordinary CPU and memory requests.
GPUs are a common example.
A traditional Pod might request a GPU like this:
resources:
limits:
example.com/gpu: 1
The application does not need to know which physical GPU it receives.
The scheduler and device-management system handle that decision.
With DRA, the resource model becomes more expressive:
Pod
|
v
ResourceClaim
|
v
DeviceClass
|
v
DRA driver
|
v
Physical GPU
A workload can request a device based on properties such as:
This is useful when "one GPU" is not specific enough.
Why DRA Matters for GPUs
Device plugins work well when the resource can be represented as a simple count.
For example:
4 GPUs available
A workload requests:
2 GPUs
But AI and accelerator workloads often have more specific requirements.
A workload might need:
GPU
with
80 GiB memory
specific accelerator family
specific device attributes
Or it may need a particular combination of devices.
DRA allows the request to describe those requirements rather than reducing everything to a numeric resource count.
DRA Architecture
The main DRA objects are:
DeviceClass
|
v
ResourceSlice
|
v
ResourceClaim
|
v
Pod
The DRA driver publishes information about available devices through ResourceSlice objects.
A DeviceClass defines a category of devices and can contain selectors describing which devices belong to that class.
A ResourceClaim describes what a workload wants.
The scheduler uses this information when deciding where the Pod can run.
The DRA driver then prepares the allocated device for the workload.
DeviceClass
A DeviceClass represents a category of devices.
A simplified example looks like this:
apiVersion: resource.k8s.io/v1
kind: DeviceClass
metadata:
name: gpu.example.com
spec:
selectors:
- cel:
expression: |
device.driver == 'gpu.example.com' &&
device.attributes['gpu.example.com'].type == 'gpu'
The selector uses CEL to describe the devices that belong to the class.
This becomes more useful when a cluster contains different GPU types.
For example, a cluster might have:
gpu.example.com
|
+-- accelerator-a
+-- accelerator-b
`-- accelerator-c
The workload can select the class and then apply additional requirements.
ResourceClaim
A ResourceClaim represents a request for one or more devices.
For example:
apiVersion: resource.k8s.io/v1
kind: ResourceClaim
metadata:
name: gpu-claim
spec:
devices:
requests:
- name: gpu
exactly:
deviceClassName: gpu.example.com
A Pod can then reference the claim.
apiVersion: v1
kind: Pod
metadata:
name: gpu-worker
spec:
resourceClaims:
- name: accelerator
resourceClaimName: gpu-claim
containers:
- name: worker
image: example/gpu-worker
The claim represents the hardware requirement separately from the application container definition.
That separation becomes useful when the resource request is more complicated than "give me one GPU."
Selecting a GPU by Attributes
DRA can use device attributes to make more precise selections.
For example:
apiVersion: resource.k8s.io/v1
kind: ResourceClaim
metadata:
name: high-memory-gpu
spec:
devices:
requests:
- name: gpu
exactly:
deviceClassName: gpu.example.com
selectors:
- cel:
expression: |
device.attributes['gpu.example.com'].type == 'gpu' &&
device.capacity['gpu.example.com'].memory >= quantity('64Gi')
The exact attributes depend on the DRA driver.
This is an important difference from traditional extended resources.
With a simple GPU resource:
example.com/gpu: 1
the scheduler primarily knows that one GPU is needed.
With DRA, the request can describe what kind of GPU is acceptable.
Kubernetes 1.37 and Extended Resources
This is one of the most practical changes in Kubernetes 1.37.
DRA Extended Resource support is now Stable.
A DRA DeviceClass can specify an extended resource name.
For example:
apiVersion: resource.k8s.io/v1
kind: DeviceClass
metadata:
name: gpu.example.com
spec:
extendedResourceName: example.com/gpu
selectors:
- cel:
expression: |
device.driver == 'gpu.example.com'
A Pod can continue using the familiar resource request:
apiVersion: v1
kind: Pod
metadata:
name: gpu-app
spec:
containers:
- name: app
image: example/gpu-app
resources:
limits:
example.com/gpu: 1
The workload does not need to create a ResourceClaim for this particular allocation path.
The DRA driver handles the device allocation behind the extended-resource request.
This is useful for teams that already have GPU workloads using the device-plugin resource model.
DRA vs Device Plugins
The biggest difference is how much information the scheduler can work with.
Area | Device Plugin | DRA |
|---|
Basic GPU count | Yes | Yes |
Device attributes | Limited | Yes |
Attribute-based selection | Limited | Yes |
ResourceClaim | No | Yes |
DeviceClass | No | Yes |
CEL selectors | No | Yes |
Traditional extended resources | Yes | Yes in Kubernetes 1.37 |
Complex hardware allocation | Limited | Better suited |
Migration from existing GPU workloads | Existing model | Can use extended resources |
This does not mean device plugins suddenly stop working.
Existing device-plugin-based workloads can continue to operate.
DRA provides another allocation model and, with extended resource support, can allow organizations to move toward DRA without changing every workload at once.
What the DRA Driver Does
The DRA driver is responsible for publishing and managing device information.
A simplified flow is:
Physical GPUs
|
v
DRA Driver
|
+-- DeviceClass
|
+-- ResourceSlices
|
v
Kubernetes Scheduler
|
v
ResourceClaim
|
v
Kubelet
|
v
GPU available to container
The driver can describe devices and their attributes.
When a claim is allocated, the driver can prepare the device before the container starts.
This allows device-specific setup to happen at the node level without putting all of that logic into the application workload.
ResourceSlices Describe Available Devices
ResourceSlice objects contain information about devices managed by DRA drivers.
A simplified example could look like:
apiVersion: resource.k8s.io/v1
kind: ResourceSlice
metadata:
name: gpu-pool-1
spec:
driver: gpu.example.com
nodeSelector:
nodeSelectorTerms:
- matchExpressions:
- key: accelerator-type
operator: In
values:
- high-performance
pool:
name: gpu-pool
generation: 1
resourceSliceCount: 1
devices:
- name: gpu-1
attributes:
vendor:
string: example
model:
string: accelerator-x
The scheduler can use this information when determining where a Pod can run.
For GPU clusters, this provides a much richer description than simply advertising a number such as:
example.com/gpu: 4
Workload Scheduling
The scheduler needs to know which nodes can satisfy a resource request.
With DRA, that decision can include device-level requirements.
Consider a cluster with:
Node A
GPU 0: 24 GiB
GPU 1: 24 GiB
Node B
GPU 0: 80 GiB
GPU 1: 80 GiB
A workload requiring one GPU with at least 64 GiB cannot run on Node A.
A DRA request can express that requirement.
The scheduler can therefore eliminate Node A before the Pod is placed.
This matters for AI workloads where GPU memory, accelerator type, or device topology can determine whether an application can run successfully.
Device Taints and Tolerations
Kubernetes 1.37 also makes DRA device taints and tolerations Stable.
This allows individual devices to be taken out of service without necessarily taking the entire node out of service.
For example, an administrator may need to mark a problematic GPU:
GPU 0
status: degraded
A device taint can prevent new workloads from being allocated to it.
This is similar to node taints, but the scope is the device rather than the entire node.
A useful operational model is:
Node
|
+-- GPU 0
| status: healthy
|
+-- GPU 1
| status: degraded
|
`-- GPU 2
status: healthy
The node can continue serving workloads through GPU 0 and GPU 2 while GPU 1 is investigated or repaired.
Device Metadata
Kubernetes 1.37 also adds Beta support for exposing DRA device metadata to containers.
This allows a DRA driver to provide information about the allocated device to the workload.
Examples can include:
The metadata is exposed as JSON inside the container.
A workload can then inspect its allocated device without needing a custom controller to query Kubernetes and translate the ResourceClaim into application-specific information.
This can be useful for virtualization and specialized accelerator workloads.
Observing GPU Allocation
DRA introduces several ways to understand what happened to an allocated resource.
Start with the ResourceClaim:
kubectl get resourceclaims
Then inspect it:
kubectl get resourceclaim gpu-claim -o yaml
The status can contain information about the allocated device.
Kubelet device metrics and the Pod Resources API can also provide information about devices currently in use.
For production clusters, this observability matters because GPU allocation problems are often difficult to diagnose from Pod status alone.
Common Mistakes
Assuming DRA Automatically Installs a GPU Driver
DRA does not replace the operating-system or vendor-specific GPU driver.
The physical GPU still needs to be available to the node.
DRA manages resource allocation and device preparation. It does not eliminate the underlying hardware requirements.
Treating DRA Like a Drop-In Replacement for Every Device Plugin
DRA and device plugins have different APIs and operational models.
A migration should be tested with the specific GPU driver and workload.
Using Extended Resources Without Understanding the DRA Backend
An existing request such as:
resources:
limits:
example.com/gpu: 1
can continue to work through DRA in Kubernetes 1.37 when the corresponding DeviceClass is configured.
But the allocation behavior now depends on the DRA configuration.
Operators should understand which DRA driver and DeviceClass satisfy that resource.
Ignoring Device Health
A node may be healthy while one GPU is not.
Device-level health and tainting should therefore be part of the operational design for large accelerator clusters.
Making Every Workload Create a ResourceClaim
ResourceClaims are powerful, but they are not required for every DRA scenario.
Kubernetes 1.37's stable extended-resource integration allows existing resource requests to use DRA without changing the workload specification to explicitly reference a claim.
Use the model that matches the workload requirements.
Troubleshooting DRA GPU Allocation
Pod Remains Pending
Inspect the Pod events:
kubectl describe pod gpu-worker
Look for scheduling messages related to:
Resource availability
Device selectors
ResourceClaims
Node selection
Device allocation
ResourceClaim Is Not Allocated
Check:
kubectl get resourceclaim gpu-claim -o yaml
Look at the allocation status and any conditions reported by the driver.
GPU Is Available but the Application Cannot Use It
Check the DRA driver and kubelet integration.
The scheduler successfully allocating a device does not necessarily mean the application container is correctly configured to access it.
Device Is Being Skipped
Check whether the device has a taint.
A device marked with a NoSchedule taint will not be selected unless the ResourceClaim tolerates it.
Attribute Selector Does Not Match
Inspect the attributes published by the DRA driver.
For example, a selector expecting:
type == gpu
will not match a device if the driver publishes the attribute under a different name or value.
Best Practices
Start With Extended Resource Compatibility
If you already use device-plugin-based GPU workloads, stable DRA extended-resource support provides a practical migration path.
You can keep the application resource request familiar while moving allocation logic toward DRA.
Use ResourceClaims for More Complex Requirements
When a workload needs specific device characteristics, use ResourceClaims and selectors instead of trying to encode everything into a simple resource count.
Keep Device Classes Consistent
Define clear DeviceClasses for different accelerator categories.
For example:
gpu-general
gpu-high-memory
gpu-inference
gpu-virtualized
The names should reflect actual scheduling requirements rather than hardware marketing names.
Monitor Device-Level Health
A node-level health check is not enough for GPU-heavy clusters.
Track which devices are allocated, healthy, degraded, or unavailable.
Test Scheduling Before Production
Create test workloads that cover:
This exposes problems before AI workloads depend on the configuration.
Advantages and Disadvantages
Advantages
Supports richer hardware allocation than simple resource counts.
Allows device selection using attributes.
Separates resource requests from Pod definitions through ResourceClaims.
Stable extended-resource support provides a migration path from device plugins.
Device-level taints help isolate unhealthy hardware.
Device metadata can expose useful hardware information to workloads.
Provides a common Kubernetes model for GPUs and other specialized resources.
Disadvantages
Requires DRA-aware device drivers.
Adds more Kubernetes objects and configuration.
ResourceClaims and DeviceClasses require operators to understand a new resource model.
Debugging can involve the scheduler, kubelet, ResourceClaim, and DRA driver.
Existing device-plugin environments may not benefit immediately from migration.
Advanced DRA capabilities can require feature gates and additional testing.
A Practical Migration Strategy
For an existing GPU cluster, do not replace all device plugins at once.
A safer approach is:
Inventory existing GPU workloads.
Identify which workloads only need a GPU count.
Install and test the appropriate DRA driver.
Create DeviceClasses for the supported accelerator types.
Test DRA extended-resource allocation.
Validate scheduling and device access.
Move workloads with more complex requirements to ResourceClaims.
Monitor device allocation and failures.
Keep a rollback path while the migration is being evaluated.
This allows teams to introduce DRA without forcing every workload to change on the first day.
Final Checklist
Before using DRA for GPUs in Kubernetes 1.37, verify:
Check | What to confirm |
|---|
Kubernetes version | Cluster is running a compatible release |
DRA driver | Driver supports the required DRA APIs |
DeviceClass | Correct accelerator category is defined |
ResourceSlices | Devices are correctly published |
ResourceClaim | Requests match the intended hardware |
Extended resources | DeviceClass is configured correctly if using them |
Scheduling | Pods are placed on eligible nodes |
Device access | Application can actually use the allocated GPU |
Device health | Failed devices can be isolated |
Observability | Allocation and device status can be inspected |
Security | Driver and RBAC permissions are appropriately restricted |
Conclusion
Kubernetes 1.37 makes DRA a much more practical option for GPU management.
The biggest change for existing clusters is stable extended-resource support. A workload can continue requesting a resource such as example.com/gpu while a DRA driver handles the underlying device allocation.
For more advanced workloads, ResourceClaims and DeviceClasses provide a better way to describe hardware requirements such as GPU memory, device attributes, and specific accelerator types.
DRA does not make device plugins obsolete overnight. The useful approach is to introduce it where its richer allocation model solves a real problem, then expand the deployment as drivers, workloads, monitoring, and operational processes are ready.
Kubernetes has traditionally used device plugins to make GPUs and other specialized hardware available to workloads. Kubernetes 1.37 gives cluster operators another option: Dynamic Resource Allocation, or DRA.
DRA Extended Resource support is now Stable in Kubernetes 1.37. A DRA driver can satisfy traditional extended resource requests such as example.com/gpu without requiring a separate device plugin.
That makes migration easier because existing workloads can continue requesting GPUs through the familiar resource model while the device allocation is handled by DRA.
DRA also provides a richer model for describing devices, selecting hardware based on attributes, creating reusable resource claims, and handling device-specific scheduling requirements.
What Is Dynamic Resource Allocation?
DRA is a Kubernetes resource-management mechanism designed for resources that cannot be described well by ordinary CPU and memory requests.
GPUs are a common example.
A traditional Pod might request a GPU like this:
resources:
limits:
example.com/gpu: 1
The application does not need to know which physical GPU it receives.
The scheduler and device-management system handle that decision.
With DRA, the resource model becomes more expressive:
Pod
|
v
ResourceClaim
|
v
DeviceClass
|
v
DRA driver
|
v
Physical GPU
A workload can request a device based on properties such as:
This is useful when "one GPU" is not specific enough.
Why DRA Matters for GPUs
Device plugins work well when the resource can be represented as a simple count.
For example:
4 GPUs available
A workload requests:
2 GPUs
But AI and accelerator workloads often have more specific requirements.
A workload might need:
GPU
with
80 GiB memory
specific accelerator family
specific device attributes
Or it may need a particular combination of devices.
DRA allows the request to describe those requirements rather than reducing everything to a numeric resource count.
DRA Architecture
The main DRA objects are:
DeviceClass
|
v
ResourceSlice
|
v
ResourceClaim
|
v
Pod
The DRA driver publishes information about available devices through ResourceSlice objects.
A DeviceClass defines a category of devices and can contain selectors describing which devices belong to that class.
A ResourceClaim describes what a workload wants.
The scheduler uses this information when deciding where the Pod can run.
The DRA driver then prepares the allocated device for the workload.
DeviceClass
A DeviceClass represents a category of devices.
A simplified example looks like this:
apiVersion: resource.k8s.io/v1
kind: DeviceClass
metadata:
name: gpu.example.com
spec:
selectors:
- cel:
expression: |
device.driver == 'gpu.example.com' &&
device.attributes['gpu.example.com'].type == 'gpu'
The selector uses CEL to describe the devices that belong to the class.
This becomes more useful when a cluster contains different GPU types.
For example, a cluster might have:
gpu.example.com
|
+-- accelerator-a
+-- accelerator-b
`-- accelerator-c
The workload can select the class and then apply additional requirements.
ResourceClaim
A ResourceClaim represents a request for one or more devices.
For example:
apiVersion: resource.k8s.io/v1
kind: ResourceClaim
metadata:
name: gpu-claim
spec:
devices:
requests:
- name: gpu
exactly:
deviceClassName: gpu.example.com
A Pod can then reference the claim.
apiVersion: v1
kind: Pod
metadata:
name: gpu-worker
spec:
resourceClaims:
- name: accelerator
resourceClaimName: gpu-claim
containers:
- name: worker
image: example/gpu-worker
The claim represents the hardware requirement separately from the application container definition.
That separation becomes useful when the resource request is more complicated than "give me one GPU."
Selecting a GPU by Attributes
DRA can use device attributes to make more precise selections.
For example:
apiVersion: resource.k8s.io/v1
kind: ResourceClaim
metadata:
name: high-memory-gpu
spec:
devices:
requests:
- name: gpu
exactly:
deviceClassName: gpu.example.com
selectors:
- cel:
expression: |
device.attributes['gpu.example.com'].type == 'gpu' &&
device.capacity['gpu.example.com'].memory >= quantity('64Gi')
The exact attributes depend on the DRA driver.
This is an important difference from traditional extended resources.
With a simple GPU resource:
example.com/gpu: 1
the scheduler primarily knows that one GPU is needed.
With DRA, the request can describe what kind of GPU is acceptable.
Kubernetes 1.37 and Extended Resources
This is one of the most practical changes in Kubernetes 1.37.
DRA Extended Resource support is now Stable.
A DRA DeviceClass can specify an extended resource name.
For example:
apiVersion: resource.k8s.io/v1
kind: DeviceClass
metadata:
name: gpu.example.com
spec:
extendedResourceName: example.com/gpu
selectors:
- cel:
expression: |
device.driver == 'gpu.example.com'
A Pod can continue using the familiar resource request:
apiVersion: v1
kind: Pod
metadata:
name: gpu-app
spec:
containers:
- name: app
image: example/gpu-app
resources:
limits:
example.com/gpu: 1
The workload does not need to create a ResourceClaim for this particular allocation path.
The DRA driver handles the device allocation behind the extended-resource request.
This is useful for teams that already have GPU workloads using the device-plugin resource model.
DRA vs Device Plugins
The biggest difference is how much information the scheduler can work with.
Area | Device Plugin | DRA |
|---|
Basic GPU count | Yes | Yes |
Device attributes | Limited | Yes |
Attribute-based selection | Limited | Yes |
ResourceClaim | No | Yes |
DeviceClass | No | Yes |
CEL selectors | No | Yes |
Traditional extended resources | Yes | Yes in Kubernetes 1.37 |
Complex hardware allocation | Limited | Better suited |
Migration from existing GPU workloads | Existing model | Can use extended resources |
This does not mean device plugins suddenly stop working.
Existing device-plugin-based workloads can continue to operate.
DRA provides another allocation model and, with extended resource support, can allow organizations to move toward DRA without changing every workload at once.
What the DRA Driver Does
The DRA driver is responsible for publishing and managing device information.
A simplified flow is:
Physical GPUs
|
v
DRA Driver
|
+-- DeviceClass
|
+-- ResourceSlices
|
v
Kubernetes Scheduler
|
v
ResourceClaim
|
v
Kubelet
|
v
GPU available to container
The driver can describe devices and their attributes.
When a claim is allocated, the driver can prepare the device before the container starts.
This allows device-specific setup to happen at the node level without putting all of that logic into the application workload.
ResourceSlices Describe Available Devices
ResourceSlice objects contain information about devices managed by DRA drivers.
A simplified example could look like:
apiVersion: resource.k8s.io/v1
kind: ResourceSlice
metadata:
name: gpu-pool-1
spec:
driver: gpu.example.com
nodeSelector:
nodeSelectorTerms:
- matchExpressions:
- key: accelerator-type
operator: In
values:
- high-performance
pool:
name: gpu-pool
generation: 1
resourceSliceCount: 1
devices:
- name: gpu-1
attributes:
vendor:
string: example
model:
string: accelerator-x
The scheduler can use this information when determining where a Pod can run.
For GPU clusters, this provides a much richer description than simply advertising a number such as:
example.com/gpu: 4
Workload Scheduling
The scheduler needs to know which nodes can satisfy a resource request.
With DRA, that decision can include device-level requirements.
Consider a cluster with:
Node A
GPU 0: 24 GiB
GPU 1: 24 GiB
Node B
GPU 0: 80 GiB
GPU 1: 80 GiB
A workload requiring one GPU with at least 64 GiB cannot run on Node A.
A DRA request can express that requirement.
The scheduler can therefore eliminate Node A before the Pod is placed.
This matters for AI workloads where GPU memory, accelerator type, or device topology can determine whether an application can run successfully.
Device Taints and Tolerations
Kubernetes 1.37 also makes DRA device taints and tolerations Stable.
This allows individual devices to be taken out of service without necessarily taking the entire node out of service.
For example, an administrator may need to mark a problematic GPU:
GPU 0
status: degraded
A device taint can prevent new workloads from being allocated to it.
This is similar to node taints, but the scope is the device rather than the entire node.
A useful operational model is:
Node
|
+-- GPU 0
| status: healthy
|
+-- GPU 1
| status: degraded
|
`-- GPU 2
status: healthy
The node can continue serving workloads through GPU 0 and GPU 2 while GPU 1 is investigated or repaired.
Device Metadata
Kubernetes 1.37 also adds Beta support for exposing DRA device metadata to containers.
This allows a DRA driver to provide information about the allocated device to the workload.
Examples can include:
The metadata is exposed as JSON inside the container.
A workload can then inspect its allocated device without needing a custom controller to query Kubernetes and translate the ResourceClaim into application-specific information.
This can be useful for virtualization and specialized accelerator workloads.
Observing GPU Allocation
DRA introduces several ways to understand what happened to an allocated resource.
Start with the ResourceClaim:
kubectl get resourceclaims
Then inspect it:
kubectl get resourceclaim gpu-claim -o yaml
The status can contain information about the allocated device.
Kubelet device metrics and the Pod Resources API can also provide information about devices currently in use.
For production clusters, this observability matters because GPU allocation problems are often difficult to diagnose from Pod status alone.
Common Mistakes
Assuming DRA Automatically Installs a GPU Driver
DRA does not replace the operating-system or vendor-specific GPU driver.
The physical GPU still needs to be available to the node.
DRA manages resource allocation and device preparation. It does not eliminate the underlying hardware requirements.
Treating DRA Like a Drop-In Replacement for Every Device Plugin
DRA and device plugins have different APIs and operational models.
A migration should be tested with the specific GPU driver and workload.
Using Extended Resources Without Understanding the DRA Backend
An existing request such as:
resources:
limits:
example.com/gpu: 1
can continue to work through DRA in Kubernetes 1.37 when the corresponding DeviceClass is configured.
But the allocation behavior now depends on the DRA configuration.
Operators should understand which DRA driver and DeviceClass satisfy that resource.
Ignoring Device Health
A node may be healthy while one GPU is not.
Device-level health and tainting should therefore be part of the operational design for large accelerator clusters.
Making Every Workload Create a ResourceClaim
ResourceClaims are powerful, but they are not required for every DRA scenario.
Kubernetes 1.37's stable extended-resource integration allows existing resource requests to use DRA without changing the workload specification to explicitly reference a claim.
Use the model that matches the workload requirements.
Troubleshooting DRA GPU Allocation
Pod Remains Pending
Inspect the Pod events:
kubectl describe pod gpu-worker
Look for scheduling messages related to:
Resource availability
Device selectors
ResourceClaims
Node selection
Device allocation
ResourceClaim Is Not Allocated
Check:
kubectl get resourceclaim gpu-claim -o yaml
Look at the allocation status and any conditions reported by the driver.
GPU Is Available but the Application Cannot Use It
Check the DRA driver and kubelet integration.
The scheduler successfully allocating a device does not necessarily mean the application container is correctly configured to access it.
Device Is Being Skipped
Check whether the device has a taint.
A device marked with a NoSchedule taint will not be selected unless the ResourceClaim tolerates it.
Attribute Selector Does Not Match
Inspect the attributes published by the DRA driver.
For example, a selector expecting:
type == gpu
will not match a device if the driver publishes the attribute under a different name or value.
Best Practices
Start With Extended Resource Compatibility
If you already use device-plugin-based GPU workloads, stable DRA extended-resource support provides a practical migration path.
You can keep the application resource request familiar while moving allocation logic toward DRA.
Use ResourceClaims for More Complex Requirements
When a workload needs specific device characteristics, use ResourceClaims and selectors instead of trying to encode everything into a simple resource count.
Keep Device Classes Consistent
Define clear DeviceClasses for different accelerator categories.
For example:
gpu-general
gpu-high-memory
gpu-inference
gpu-virtualized
The names should reflect actual scheduling requirements rather than hardware marketing names.
Monitor Device-Level Health
A node-level health check is not enough for GPU-heavy clusters.
Track which devices are allocated, healthy, degraded, or unavailable.
Test Scheduling Before Production
Create test workloads that cover:
This exposes problems before AI workloads depend on the configuration.
Advantages and Disadvantages
Advantages
Supports richer hardware allocation than simple resource counts.
Allows device selection using attributes.
Separates resource requests from Pod definitions through ResourceClaims.
Stable extended-resource support provides a migration path from device plugins.
Device-level taints help isolate unhealthy hardware.
Device metadata can expose useful hardware information to workloads.
Provides a common Kubernetes model for GPUs and other specialized resources.
Disadvantages
Requires DRA-aware device drivers.
Adds more Kubernetes objects and configuration.
ResourceClaims and DeviceClasses require operators to understand a new resource model.
Debugging can involve the scheduler, kubelet, ResourceClaim, and DRA driver.
Existing device-plugin environments may not benefit immediately from migration.
Advanced DRA capabilities can require feature gates and additional testing.
A Practical Migration Strategy
For an existing GPU cluster, do not replace all device plugins at once.
A safer approach is:
Inventory existing GPU workloads.
Identify which workloads only need a GPU count.
Install and test the appropriate DRA driver.
Create DeviceClasses for the supported accelerator types.
Test DRA extended-resource allocation.
Validate scheduling and device access.
Move workloads with more complex requirements to ResourceClaims.
Monitor device allocation and failures.
Keep a rollback path while the migration is being evaluated.
This allows teams to introduce DRA without forcing every workload to change on the first day.
Final Checklist
Before using DRA for GPUs in Kubernetes 1.37, verify:
Check | What to confirm |
|---|
Kubernetes version | Cluster is running a compatible release |
DRA driver | Driver supports the required DRA APIs |
DeviceClass | Correct accelerator category is defined |
ResourceSlices | Devices are correctly published |
ResourceClaim | Requests match the intended hardware |
Extended resources | DeviceClass is configured correctly if using them |
Scheduling | Pods are placed on eligible nodes |
Device access | Application can actually use the allocated GPU |
Device health | Failed devices can be isolated |
Observability | Allocation and device status can be inspected |
Security | Driver and RBAC permissions are appropriately restricted |
Conclusion
Kubernetes 1.37 makes DRA a much more practical option for GPU management.
The biggest change for existing clusters is stable extended-resource support. A workload can continue requesting a resource such as example.com/gpu while a DRA driver handles the underlying device allocation.
For more advanced workloads, ResourceClaims and DeviceClasses provide a better way to describe hardware requirements such as GPU memory, device attributes, and specific accelerator types.
DRA does not make device plugins obsolete overnight. The useful approach is to introduce it where its richer allocation model solves a real problem, then expand the deployment as drivers, workloads, monitoring, and operational processes are ready.
Join the conversation! Your thoughts help the community grow.