Kubernetes 1.34 stabilizes the core device allocation APIs

A request for a device can mean more than a count. A workload may need a particular class of accelerator, or a device whose attributes satisfy a constraint. Allocating that device also needs to agree with the node chosen for the Pod. These are related decisions, and treating the device as an opaque quantity leaves little room to express the relationship.

The Kubernetes 1.34 announcement graduates the core Dynamic Resource Allocation APIs to stable. ResourceClaim, DeviceClass, ResourceClaimTemplate and ResourceSlice are available under resource.k8s.io/v1 by default. Pods refer to claims through their resourceClaims field, connecting workload placement to an explicit request for devices.

I consider this a significant use of the Kubernetes API machinery. Device allocation becomes a set of objects with declared ownership and observed state. The scheduler receives information it can evaluate, while drivers retain responsibility for the devices and their implementation-specific configuration.

Inventory and demand are separate objects

The versioned 1.34 API definitions make the roles concrete. ResourceSlice publishes resources managed by a common driver in a pool. A pool can span multiple slices, and the driver determines how many slices represent it. The resource types currently represented are devices with attributes and capacities.

A device's identity includes its driver, pool and device name. The API explicitly allows a device to move between ResourceSlices over time without changing that identity. A consumer therefore cannot treat the name of the slice containing a device as the identity of the device itself.

ResourceClaim records demand for devices. DeviceClass provides a named selection and configuration policy that claims can reference. ResourceClaimTemplate provides the template used when a workload needs claims created for its Pods. Those objects distinguish an inventory published by a driver from a request made by a workload.

That distinction supports independent changes. A driver can update the inventory as devices become available. A workload can express the devices it needs without listing the object names through which the driver happens to publish them. Scheduling then has a common representation in which to reconcile the request with available capacity.

The release announcement notes that the structured-parameter design has been the basis for DRA since 1.30. Its graduation should therefore be read as stabilizing that design, not as the first appearance of all device allocation work in Kubernetes. The history matters because the API reaching stability is the result of changes in the approach itself.

A complete inventory needs a consistency rule

Publishing a pool through multiple objects introduces a subtle problem. A consumer may observe some updated slices before others. Without a rule for distinguishing an incomplete update from a complete inventory, it could allocate using a mixture of old and new information.

The ResourceSlice definition includes a pool generation and a count of slices. When a driver updates a pool, it increments the generation and publishes the corresponding slices. Consumers use the highest generation and ignore older ones. The count lets them determine whether they have a complete view before making decisions that require one.

This is especially relevant when a request means all matching devices or when the allocator evaluates alternatives. A partial inventory can make a valid choice look impossible, or make an incomplete set look complete. The API gives consumers the information needed to wait for a consistent view of that pool.

Device accessibility also affects placement. A slice can identify a node or describe which nodes have access to the resources. The API does not assume that every resource is local to exactly one node. That permits the inventory to describe a placement constraint instead of forcing a client to infer it from a device name.

These details explain why DRA needs more than a richer quantity field in a Pod. Inventory publication has its own consistency and identity rules. Claims then depend on that inventory, and Pods depend on claims. Each relationship needs a representation that controllers and the scheduler can observe.

Stable API versions still contain gated capabilities

Core API stability does not mean every field or allocation policy has the same maturity. The 1.34 announcement lists DRA capabilities in its beta section separately from the stable core. That distinction is particularly important when describing sharing or privileged device access.

Administrative access reaches beta through the adminAccess field. The announcement describes it as access for monitoring or diagnostics to devices already allocated to others. This access is restricted through namespaces carrying the resource.k8s.io/admin-access label set to true. It is a privileged operating mode, not a general indication that arbitrary workloads can share any device safely.

Prioritized alternatives also reach beta. The firstAvailable field allows a claim to describe ordered ways of satisfying the request. A workload might accept one stronger device or a larger set of less capable devices. The ordering communicates a preference without requiring the application to submit a different Pod after each failed allocation attempt.

The versioned API comments place a further limit on that interpretation. DRA does not yet implement scoring, and selection of the first satisfiable device set does not guarantee a globally optimal choice. Other scheduling features determine the node when requirements can be satisfied in several places. An ordered alternative is therefore a request policy, not proof of cluster-wide optimal allocation.

Consumable capacity has its own feature gate in the API definitions. It should not be conflated with the core API's general ability to represent capacities. Describing a device capacity and supporting multiple concurrent allocations against portions of it are different commitments.

I prefer the narrower description of this release. A stable set of core objects is useful even while individual policies evolve. Operators need the maturity of the specific behavior they intend to use, including the driver's support for that behavior.

A claim can express a concrete device count

The stable API represents an exact request through the exactly field of a named device request. The deviceClassName is required there. ExactCount is the default allocation mode, with a count of one when the mode is ExactCount and count is omitted.

This example makes those choices explicit. It assumes a DeviceClass named example-accelerator already exists and that a driver publishes matching devices. Creating the claim alone does not install a driver or create hardware.

apiVersion: resource.k8s.io/v1
kind: ResourceClaim
metadata:
  name: accelerator
spec:
  devices:
    requests:
      - name: compute
        exactly:
          deviceClassName: example-accelerator
          allocationMode: ExactCount
          count: 1

Selectors can further restrict the devices considered for an exact request. The API says all selectors must be satisfied. DeviceClass can also supply selectors and additional configuration, which means the class name represents a policy input rather than merely a convenient display label.

The API supports an All allocation mode as well, with conditions on matching devices and existing allocations. That illustrates why a count example cannot stand in for every allocation policy. Different modes require different decisions about completeness and availability, including the inventory consistency rules described above.

The versioned definition also tells clients to refuse requests with allocation modes they do not understand. That preserves a meaningful boundary as new policies are added. Silently interpreting an unfamiliar mode as an exact count would accept a request while changing its meaning, which is particularly undesirable for an allocation that controls access to scarce hardware.

Drivers remain part of the operating contract

The core API gives Kubernetes a supported vocabulary for device inventory and allocation. It does not make every accelerator behave identically or remove the vendor-specific work of preparing a device for use. The announcement describes DRA as supporting GPUs, TPUs, NICs and other devices, which are different hardware classes with different operating requirements.

Driver-published attributes allow selection to account for those differences. Implementation-specific configuration still needs an appropriate driver. A cluster serving the stable API without a suitable inventory does not have the devices a claim requests, just as accepting a storage claim does not by itself supply a particular storage backend.

The release also stabilizes scheduler QueueingHint support, which lets plugins make more accurate decisions about retrying previously unschedulable Pods. The announcement specifically identifies dynamically allocated resources as a beneficiary. More informative inventory helps allocation, while more selective requeueing helps the scheduler respond when that inventory changes.

Together these changes improve how specialized devices participate in declared workload state. The stable core defines the objects through which a driver reports supply and a workload requests it. The policy details still need to be read at their own maturity level, particularly when the intended use involves privileged access, ordered alternatives or concurrent consumption of device capacity.