Custom Opaque CPUSet Allocation Overrides

Migrate from individual mode

To keep scheduler-controlled selection of exact CPUs that the deprecated Individual mode enabled, use grouped mode with the external allocator. Note that also NUMA-node or Socket grouping supports external allocator like the Machine grouping. All grouping modes publish the external-allocator attributes, but the NUMA-node or Socket grouping also retain a useful topology boundary:

driverConfig:
  cpuDeviceMode: grouped
  groupBy: numanode # or socket
  allocator: external

The external allocator reads the selected grouped device’s external-allocator attributes, selects CPUs from that group, and writes the cpuset in the opaque configuration described below. The driver validates and enforces the selection. groupBy: machine is also supported, but is less preferred because it removes that topology boundary; use it only when the allocator must select from the entire node.

When using the external allocator with grouped mode (numanode, socket, or machine), the DRA driver does not perform automatic topology-aware CPU allocation. Instead, an explicit core assignment must be provided via the cpuset field in the claim’s opaque configuration parameters. With numanode or socket, the cpuset must belong to the group selected for the request.

The Kubelet driver parses this configuration at prepare time from the claim’s allocation status (status.allocation.devices.config). The control plane (typically scheduling plugin) is responsible for injecting this configuration block into the allocation result when binding the claim.

Opaque Parameters Schema (v1alpha1)

The opaque.parameters field must conform to the following schema:

Example of a Fully Allocated ResourceClaim with Opaque Configuration

apiVersion: resource.k8s.io/v1
kind: ResourceClaim
metadata:
  name: exclusive-cores-claim
  namespace: default
  uid: claim-uid-123456
spec:
  devices:
    requests:
    - name: cpu-request-1
      exactly:
        deviceClassName: dra.cpu
        capacity:
          requests:
            dra.cpu/cpu: "4"
status:
  allocation:
    devices:
      results:
      - request: cpu-request-1
        driver: dra.cpu
        pool: test-node
        device: cpudevnuma000
        consumedCapacity:
          dra.cpu/cpu: "4"
      config:  # Added by external scheduler
      - source: FromClaim
        requests:
        - cpu-request-1
        opaque:
          driver: dra.cpu
          parameters:
            apiVersion: v1alpha1
            cpuConfig:
              cpuset: "2-5"

The driver allocates the specified cores directly (after validating that they are allocatable and not reserved). If it is omitted, resource preparation will fail and pod startup will be rejected.