Wiki · Concept · Last reviewed June 25, 2026

Kubernetes Dynamic Resource Allocation

Kubernetes Dynamic Resource Allocation lets workloads claim attached devices through structured Kubernetes resources rather than simple integer hardware requests.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: Kubernetes, DRA, ResourceClaims, GPUs, AI infrastructure

Definition

Kubernetes Dynamic Resource Allocation, usually shortened to DRA, is a Kubernetes feature for requesting and sharing resources among pods. The Kubernetes documentation describes the main use case as attached devices such as hardware accelerators, and marks DRA as stable in Kubernetes v1.35 with the feature enabled by default.

DRA changes how specialized hardware can be described to the scheduler. Instead of a pod only asking for an integer resource such as one named GPU, DRA introduces API objects that let cluster administrators and drivers publish device categories, device attributes, capacity, and claims. The goal is not to make a model safer by itself. It is to make hardware allocation more declarative and auditable.

How It Works

DRA uses Kubernetes API resources in the resource.k8s.io/v1 group. A DeviceClass defines a class of devices and how workloads may select among their attributes. A ResourceSlice represents resources attached to nodes, and is created and maintained by a DRA driver. A ResourceClaim describes a request for access to devices. A ResourceClaimTemplate lets Kubernetes generate per-pod claims from a template, which is useful when replicas need separate but similar devices.

The scheduler uses the ResourceSlices and the claim requirements to allocate matching devices, then places the pod on a node that can access the allocated devices. Workload operators can use Common Expression Language selectors to ask for device properties, such as a device type or capacity exposed by the driver. Kubernetes' workload guide says a pod requests DRA devices by listing claims in the pod's resourceClaims field and by referencing a specific claim from a container's resources.claims.

DRA is related to, but distinct from, Kubernetes Device Plugins. The official DRA concept page says DRA improves the workflow when compared with device plugins by supporting expression-based filtering, device sharing through claims, centralized device categories, and simplified pod requests. The older device-plugin model remains important, but DRA makes device selection a richer scheduling object.

Agent Context

AI systems often need scarce, heterogeneous resources: GPUs with different memory sizes, accelerators reserved for inference, devices with locality constraints, or network devices used by distributed training. DRA gives platform teams a way to describe those resources without making every workload author encode node labels, vendor strings, and topology assumptions directly into pod specs.

For agent infrastructure, this matters because accelerator access can shape cost, latency, isolation, and reproducibility. An evaluation worker, retrieval indexer, model-serving replica, simulation job, or fine-tuning run may need a specific device class. DRA can make that request visible as a claim that can be logged, authorized, inspected, and connected to scheduling events.

Governance Use

A governance record for DRA should capture DeviceClasses, driver owners, ResourceSlice producers, ResourceClaims, ResourceClaimTemplates, namespaces, workload owners, selectors, constraints, sharing decisions, allocated devices, scheduler events, and status updates. For AI services, it should also record whether the claim supports production serving, research training, batch evaluation, sandboxed agents, or privileged infrastructure.

Kubernetes' cluster-admin guidance says DRA uses several APIs and recommends separating permissions by role. DeviceClasses and ResourceSlices are generally admin or driver surfaces. ResourceClaims and ResourceClaimTemplates are namespace-scoped workload surfaces. The hardening guide focuses on least-privilege authorization for ResourceClaim status updates, because DRA components participate directly in allocation state.

Limits

DRA does not replace security, cost governance, model evaluation, or incident response. It allocates devices. It does not decide whether a workload should exist, whether a model output is valid, whether a prompt is safe, whether a tenant is trusted, or whether a generated artifact should be deployed.

DRA also depends on drivers and administrative configuration. If a driver reports misleading attributes, if RBAC is too broad, if ResourceSlices are stale, or if status permissions are careless, the claim object can become false confidence. It should sit beside admission policy, quotas, workload identity, node hardening, runtime isolation, observability, and audit trails.

Source Discipline

Claims about DRA should cite Kubernetes' DRA concept page, the workload guide for allocating devices with DRA, the cluster-administration guidance, and the hardening guide. Claims about a particular vendor driver or cloud implementation require that vendor or cloud source, not generic Kubernetes documentation.

The evidence to keep is operational: ResourceClaims, ResourceClaimTemplates, DeviceClasses, ResourceSlices, scheduler events, DRA driver logs, status updates, RBAC bindings, and the device metadata observed inside the workload.

Spiralist Reading

Spiralism reads DRA as a grammar for scarce machine capability.

Compute power enters the institution as a claim, a class, a selector, a status field, and a permission boundary. The allocation is technical, but the social question is older: who can ask for power, who names it, who sees the grant, and who can contest the record?

Sources

Return to Wiki