Kubernetes DRA for NVIDIA GPUs: ResourceClaims, MIG slices and the GPU Operator 26.7

What DRA changes for GPU pods

Dynamic Resource Allocation (DRA) replaces the counted resource nvidia.com/gpu with claims: a pod asks for a device of a DeviceClass, filtered by its attributes, and the scheduler picks a matching GPU or MIG slice from what each node publishes. NVIDIA's DRA Driver for GPUs provides those devices, and since release v26.7.0 the GPU Operator installs and manages it. Full GPUs and MIG instances that already exist are generally available; most other features are still alpha, so the question for a platform team is which workloads need them today.

With the device plugin, a pod asks for "one GPU" and gets whichever card the node offers. A claim can say "one GPU with more than 100 GiB of memory", "a 1g.24gb MIG slice" or "two slices from the same physical card", and the scheduler checks this before it places the pod. That matters on clusters with mixed hardware, for example RTX PRO 6000 Server Edition nodes for inference beside H200 NVL nodes for fine-tuning.

NVIDIA GPU Operator 26.7 documentation, "DRA Driver for NVIDIA GPUs", last updated 14 October 2026, read on 24 October 2026; status per feature gate of driver v0.5.1.

ComputeDomains serve Grace Blackwell racks with multi-node NVLink, such as GB200 NVL72; a PCIe server with RTX PRO or H200 NVL cards does not use them. Our guide to GPU sharing in Kubernetes explains MIG, time-slicing and MPS under the device plugin; this article covers the same cards under DRA.

Requirements before you switch

NVIDIA's prerequisites for GPU allocation through DRA, for driver v0.5.1 and GPU Operator 26.7.2, are short but strict.

NVIDIA DRA driver prerequisites page (driver v0.5.1, modified 23 July 2026) and GPU Operator 26.7 DRA page (14 October 2026), read on 24 October 2026.

The Kubernetes version deserves a second look. Kubernetes 1.34 has its end of life on 27 October 2026, and upstream then maintains 1.35 to 1.37, as our private LLM platform on Kubernetes notes; the GPU Operator's platform page lists 1.33 to 1.37. Several DRA features also become simpler from 1.36: NVIDIA's pages state that the gates DRAExtendedResource, DRAConsumableCapacity and DRAPartitionableDevices are on by default from v1.36, while on 1.34 and 1.35 they must be enabled by hand. By our reading, a new DRA cluster in late 2026 starts on 1.36 or 1.37.

On the driver side, both production branches qualify: R580, supported to June 2028, and R595, to March 2027, as our guide to NVIDIA driver branches and CUDA versions explains. For the RTX PRO 6000 Server Edition, the Operator's support list asks for 575.57.08 or later in any case.

Installing the DRA driver with the GPU Operator

Under the Operator, DRA has its own top-level resource. GPUCluster replaces ClusterPolicy, and the driver comes either from an NVIDIADriver resource that the Operator manages or from the host. NVIDIA documents two Helm installs of chart v26.7.2 into the namespace gpu-operator, both with clusterPolicy.deployCR=false and gpuCluster.deployCR=true: with an Operator-managed driver add driver.nvidiaDriverCRD.enabled=true, with a driver already on the host add driver.enabled=false. NVIDIA adds a warning not to install a separate dra-driver-nvidia-gpu Helm release next to it.

For a cluster of PCIe GPU servers, draDriver.computeDomains.enabled=false leaves out the ComputeDomain parts, which only Grace Blackwell systems with multi-node NVLink use. After the install, kubectl get gpucluster gpu-cluster should report ready, according to NVIDIA typically after about three minutes, and kubectl get deviceclass lists what the driver offers:

• gpu.nvidia.com for whole GPUs;
• mig.nvidia.com for MIG devices;
• vfio.gpu.nvidia.com for passthrough to virtual machines, alpha;
• two ComputeDomain classes, only when that support is on.

kubectl get resourceslice then shows one entry per device on each node. The driver itself now lives in a Kubernetes project: release v0.5.1 of 12 October 2026, a patch release with fixes for ComputeDomains and MIG profile creation, ships its image from registry.k8s.io, and its documentation sits on a sigs.k8s.io site.

Our AI servers come with the operating system, drivers, CUDA and a container runtime installed on request, so a new DRA cluster can start from nodes on the driver branch you choose. Tell us your Kubernetes version and driver branch, and we prepare the nodes to match.

A claim for one RTX PRO 6000 Server Edition

A pod does not write a ResourceClaim itself in the common case. It names a ResourceClaimTemplate, and Kubernetes creates one claim per pod when it is scheduled and deletes it with the pod. NVIDIA's examples use the API resource.k8s.io/v1. A template for one whole GPU contains four things.

NVIDIA DRA driver guide "Request full GPUs" (modified 23 July 2026), read on 24 October 2026.

In the pod spec, resourceClaims links a name to the template, and each container lists that name under resources.claims. Two containers that list the same claim share one GPU; two claims from the same template give two GPUs. For two GPUs that must be allocated together, one request can carry a count.

The selectors are where DRA earns its keep. Every GPU device in a ResourceSlice carries attributes such as productName, architecture, uuid, cudaComputeCapability, driverVersion and the PCI bus ID, and a capacity called memory. In CEL, the attributes sit under device.attributes['gpu.nvidia.com'] and the memory under device.capacity['gpu.nvidia.com'].memory. These selectors separate the cards we supply:

Selector forms from NVIDIA's DRA guide and ResourceSlice attribute reference, read on 24 October 2026. Thresholds are ours: the RTX PRO 6000 reports 95.6 GiB, the H200 NVL 140.4 GiB to the driver. Read the exact productName and memory values with kubectl get resourceslice -o yaml.

NVIDIA's attribute reference calls its example values illustrative, so a selector on productName should be written against the string your own ResourceSlices show. A memory threshold well clear of both cards, as above, survives small differences in how the capacity is rounded.

MIG slices as claims: 1g.24gb on the RTX PRO 6000

MIG devices have their own DeviceClass, mig.nvidia.com, and their own attributes: profile, parentUUID, the inherited productName and capacities for memory and multiprocessors. A template that asks for a quarter of an RTX PRO 6000 uses the selector profile == '1g.24gb'; the smallest H200 NVL instance is 1g.18gb. Two requests in one claim with a matchAttribute constraint on gpu.nvidia.com/parentUUID place two slices on the same physical card, for example an embedding model and a reranker that should share a card.

Profiles from NVIDIA's MIG user guide (13 October 2026), as in our MIG profile guides; device counts are our multiplication per server.

Static MIG is the generally available path: the partitions are created on the node before the DRA driver starts, and partitions added later are not discovered until the GPU kubelet plugin restarts. The DRA guide does not say which tool creates them; our MIG runbook for RTX PRO Blackwell shows the steps with nvidia-smi. Dynamic MIG, the alpha gate DynamicMIG, creates a slice for each claim, but NVIDIA warns that the driver then destroys MIG partitions it did not create when the plugin starts, that nvidia-smi mig and mig-parted must not run beside it, and that it does not work in vGPU guests. On 1.34 and 1.35 it also needs DRAPartitionableDevices on the API server and scheduler.

Two limits carry over from MIG itself. NCCL is not supported with MIG, so a model split over several GPUs needs whole cards. And NVIDIA's DRA prerequisites name MIG-capable data-centre GPUs from the Ampere architecture on; its examples use the A100. The RTX PRO 6000 Server Edition is on the GPU Operator's support list and in NVIDIA's MIG guide, but we found no DRA example for it, so try a claim on one node before a whole cluster depends on it. Our page on RTX PRO 6000 MIG profiles shows what fits in each slice.

Sharing without MIG: time-slicing, shares and MPS

Under DRA, time-slicing is a setting on the claim. The claim's config section passes opaque parameters to the driver: apiVersion resource.nvidia.com/v1beta1, kind GpuConfig, sharing strategy TimeSlicing and an interval of Default, Short, Medium or Long. Containers that reference the same request in one pod then share the card. Choosing an interval other than the default needs the alpha gate TimeSlicingSettings. NVIDIA's caveats match the device plugin's: "All containers sharing a GPU access the same GPU memory", and the sharing is best-effort, with no fixed share of throughput. Time-slicing has no effect on MIG slices.

Consumable shares, the alpha gate ConsumableShares, let the scheduler account for shares of one GPU or MIG device, by memory or by a fixed number; on 1.34 and 1.35 they need DRAConsumableCapacity. MPS is alpha too, cannot be combined with consumable shares or dynamic MIG, and cannot run on the same GPU as time-slicing at the same time, because the two need different compute modes. For production endpoints on the cards we supply, whole GPUs or static MIG remain the configurations NVIDIA lists as generally available.

Moving from the device plugin

NVIDIA's documentation is direct: in-place migration from ClusterPolicy to GPUCluster is not supported, and the procedure assumes a new cluster. The same applies to moving a standalone DRA driver release under the Operator. A move therefore looks like a cluster rebuild:

1. Build a new cluster on Kubernetes 1.36 or 1.37 with GPU nodes on the driver branch of the old cluster.
2. Install the GPU Operator v26.7.2 or later with GPUCluster, and ComputeDomains off on PCIe servers.
3. Create the MIG layouts on the nodes that need them before the DRA plugin starts.
4. Translate each GPU request into a ResourceClaimTemplate, starting with gpu.nvidia.com and no selectors.
5. Move workloads service by service, then add selectors where hardware differs.

For workloads that cannot be rewritten at once, Kubernetes can map an extended resource to a DeviceClass. With the gate DRAExtendedResource, on by default from v1.36, a pod can keep a resource limit and request the resource name deviceclass.resource.kubernetes.io/gpu.nvidia.com. The managed DeviceClass does not set the old name nvidia.com/gpu; keeping that name needs a separate DeviceClass with spec.extendedResourceName, according to NVIDIA.

Check the serving layer before you commit. KServe 0.21.0 added resourceClaims support for DRA in the ServingRuntime (pull request 5828). NVIDIA's NIM Operator 3.1.2 documents DRA for NIMService as a Technology Preview, "not suitable for deployment in production". NVIDIA also notes that Kubernetes does not support preemption for DRA resources, so a priority scheme that evicts low-priority GPU pods for high-priority ones does not carry over.

When the device plugin is still the better choice

Stay on the device plugin, or keep a device-plugin cluster beside the new one, in three cases: the cluster gives whole cards to a few services and needs nothing a selector adds; the sharing you rely on, MPS or time-slicing with a set interval, is alpha under DRA; or the platform on top expects a ClusterPolicy, as Red Hat's OpenShift AI guide does when it enables NVIDIA GPUs, described in our OpenShift AI on GPU servers guide.

Move to DRA when the cluster mixes card types or MIG layouts and pods should land on the right one by attribute, when several slices must come from the same card, or when you build a new cluster anyway. Whole-GPU claims on RTX PRO 6000 Server Edition and H200 NVL nodes, plus static MIG slices for small models, use only generally available features today.

What we supply

We build AI servers to order as Kubernetes GPU nodes: an entry server with two RTX PRO 6000 Server Edition cards, an inference node with four, and a training node with eight H200 NVL, each with two AMD EPYC processors, assembled and tested before delivery and delivered across the EU on one contract and invoice. On request they arrive with the operating system, the driver branch your cluster runs, CUDA and a container runtime with CDI. Send us your node count and the MIG layouts you plan, and our team replies with a configuration within one business day. For the operating system choice, see our comparison of Linux for GPU servers.

FAQ