Cloud and platform
Kubernetes specialized resources beyond CPU and memory
What Dynamic Resource Allocation brings to GPUs, accelerators and devices on cloud-native platforms.
The central idea
DRA expresses device requirements more precisely. Availability still depends on inventory, drivers and the deployed version.
AI and specialized workloads need to select, share and configure devices that do not fit the traditional extended-resource model. Dynamic Resource Allocation adds a more expressive API.
Kubernetes 1.34 promoted the core of DRA to stable, separating resource claims, device capabilities and driver logic for GPUs, TPUs, NICs and accelerators.
Dynamic device allocation
Capacity planning still needs resource classes, quotas, observability, isolation and priority policies that reflect cost and workload criticality.
An internal platform can expose DRA as self-service: developers request an approved profile while the platform resolves provider, node and configuration.
Move beyond extended-resource counters
CPU and memory are fungible; devices have models, capabilities, topology and sharing modes. DRA separates workload intent from inventory detail. Applications can express richer requirements without hardcoding node names or providers into every manifest.
Understand Claims, Classes and drivers
The ResourceClaim represents the request and may live beside a Pod or be reused depending on the case. Classes expose approved profiles. The driver publishes devices and prepares access. This separation lets the platform define options while application teams choose a stable capability.
Plan capacity and scheduling
DRA improves expression, but it does not create GPUs. Quotas, priority, topology awareness and observability remain essential. Metrics should expose inventory, pending allocations, utilization, driver failures and cost. An impossible request needs an error that helps correct class, region or size.
Offer profiles as a platform product
A team can request standard inference or intensive training while the platform maps that intent to provider and device. Profiles include limits, security and cost. The contract decouples applications from hardware changes and makes it easier to move workloads across clusters with equivalent capabilities.
Teaching case
Pending inference despite free GPUs
A cluster has idle GPUs, but only some meet the requested capability. Free device counts miss attributes, driver compatibility, topology and allocation constraints. Compare the request with the inventory Kubernetes actually sees.
The platform can offer profiles through DeviceClass and requests through ResourceClaim. Drivers publish inventory through ResourceSlice and prepare assigned devices. This separates application needs from hardware details without guaranteeing every cluster can satisfy a profile.
Core DRA became stable in Kubernetes 1.34; additional features have separate maturity levels. Sharing and partitioning vary by version and driver. Document compatibility, isolation and node-failure behavior before publishing a profile.
Choices and their tradeoffs
| Situation | Choice | Tradeoff |
|---|---|---|
| Pending request | Compare requirements, inventory and events. | Free capacity may be incompatible. |
| Shared platform profile | Define DeviceClass and usage conditions. | Isolation depends on driver capabilities. |
| Moving between clusters | Validate destination API and driver. | Matching profile names do not prove equivalent hardware. |
Scroll the table to compare all three columns.
Put it into practice
Validate the resource lifecycle
- Submit compatible and impossible requests.
- Observe allocation, preparation and workload use.
- Check claim retention or deletion before expecting capacity release.
What to verify: You can explain pending requests and demonstrate capacity recovery after claim release.
Abstract without hiding capacity
DRA creates a cleaner interface for specialized resources. The abstraction works when the platform exposes availability, cost and limits; hiding them entirely only moves the surprise to the scheduler.
Continue reading
Cloud and platform
The internal platform now serves teams and agents
Golden paths, self-service and policies for organizations where people and agents consume the same platform.
Cloud and platform
FinOps on Azure: from monthly cost to product value
An operating cycle to allocate spend, detect waste and make technical decisions with business context.