dra-driver-nvidia-gpu: letting a third party own GPU scheduling in Kubernetes

DRA moves device configuration out of the cluster core

Dynamic Resource Allocation is described in the project overview as a new concept in Kubernetes for flexibly requesting, configuring and sharing specialised devices such as GPUs. The point the driver makes about it is that DRA puts resource configuration and scheduling in the hands of third party vendors, which is exactly the gap this repository fills for NVIDIA hardware. The project is part of the Kubernetes SIGs and targets Kubernetes 1.32 or newer with DRA enabled, and it points readers at the Kubernetes documentation, the GKE documentation and a Kubernetes blog post on the 1.33 DRA updates for background. The architecture is a driver, not a scheduler: it implements the kubelet side of the DRA contract so the cluster can hand a claim to a piece of NVIDIA hardware, and it leaves the policy decisions to whoever installs it.

Two kubelet plugins, and only one of them is production shaped

The driver manages two kinds of resource, and each has its own kubelet plugin under cmd/: gpu-kubelet-plugin and compute-domain-kubelet-plugin. They can be enabled or disabled separately at install time, which is the first thing to understand about this project. The ComputeDomain plugin is the officially supported one. The GPU side is not: the overview states that while some GPU allocation features can be tried out, they are not yet officially supported, and that the GPU kubelet plugin is currently disabled by default in the Helm chart installation. The features being built on that side, dynamic allocation of MIG devices among them, are described in the project as enabling more capability, with the planned work tracked through the project releases. In practice this means an install gives you a working ComputeDomain path and a GPU path you have to switch on yourself.

ComputeDomain: isolation for multi-node NVLink

A ComputeDomain is an abstraction for multi-node NVLink, and the guarantee it makes is specific: every pod inside the domain can reach every other pod inside it over that fabric, and pods outside the domain are isolated from it. Placement and lifetime are treated differently, and both matter for how you write a workload. In terms of placement, a domain follows the workload, so the pods that need the link end up in the same domain wherever the scheduler puts them. In terms of lifetime, a domain is ephemeral and its lifetime is bound to the lifetime of the consuming workload, so there is no long-lived domain object to garbage collect. The project also notes that if you have heard of IMEX, this driver orchestrates IMEX primitives, namely daemons, domains and channels, under the hood.

Running the kind demo that shares one GPU between two containers

The demo section builds a local cluster and shows a single GPU shared by two containers in one pod, which is the quickest way to see the driver do something. The dependencies are kind, following its own installation documentation, and the NVIDIA Container Toolkit and Runtime. Clone the repository and step into it first.

git clone https://github.com/kubernetes-sigs/dra-driver-nvidia-gpu.git
cd dra-driver-nvidia-gpu

Then build the driver image and create the cluster.

export KIND_CLUSTER_NAME="kind-dra-1"
./demo/clusters/kind/build-dra-driver-gpu.sh
./demo/clusters/kind/create-cluster.sh

The Helm chart goes in after that.

./demo/clusters/kind/install-dra-driver-gpu.sh

Finally the workload is submitted from the quickstart specs.

kubectl apply -f ./demo/specs/quickstart/v1/gpu-test2.yaml

The overview shows what the container logs look like afterwards, with both containers reporting the same device.

$ kubectl logs pod -n gpu-test2 --all-containers --prefix
[pod/pod/ctr0] GPU 0: NVIDIA A100-SXM4-40GB (UUID: GPU-4404041a-04cf-1ccf-9e70-f139a9b1e23c)
[pod/pod/ctr1] GPU 0: NVIDIA A100-SXM4-40GB (UUID: GPU-4404041a-04cf-1ccf-9e70-f139a9b1e23c)

What the Go dependencies say about the implementation

The go.mod file lists the module as sigs.k8s.io/dra-driver-nvidia-gpu targeting go 1.26.0, and the dependency set is a fair map of what the driver talks to. On the NVIDIA side there is go-nvml for the management library, go-nvlib and go-nvfm as the newer libraries, and nvidia-container-toolkit at v1.20.1, which is the piece that injects the device into the container. On the Kubernetes side the driver depends on k8s.io/dynamic-resource-allocation, which is the DRA API itself, along with k8s.io/kubelet, k8s.io/component-base and k8s.io/kubernetes at v1.37.0, with the api, apimachinery, client-go and mount-utils libraries at the matching v0.37.0. Two other dependencies are worth noting because they shape the design: tags.cncf.io/container-device-interface at v1.1.1, the older device plugin interface that DRA grew out of, and gRPC for the kubelet plugin protocol. Metrics come from prometheus/client_golang and logging from logrus and klog.

Building from the Makefile rather than by hand

The repository ships a Makefile that includes common.mk and versions.mk, and it derives its command targets from the directories under cmd, so each kubelet plugin becomes a cmd- target without a hand-written rule per binary. The target list covers binaries, build, build-image, check, clean, fmt, lint-internal, test, examples, cmds, coverage, generate, vendor, check-modules, helm-lint, helm-test and helm-package, plus golangci-lint and check-generate as separate check targets. Every target also has a docker- prefixed variant, which is how the container image for the driver gets built. The build uses CGO with a linker flag that allows unresolved symbols in object files, and the architecture is derived from uname with aarch64 mapped to arm64, so the same Makefile covers Linux on x86_64 and arm64. The top level also carries a .golangci.yaml for the lint configuration and a cloudbuild.yaml for image builds.

Two installation paths, one documentation site

The overview does not carry the installation steps itself, it points to the project documentation site and to the source of the install page in the repository at site/content/docs/install.md. The same pattern holds for the code: the site directory is part of the repository, alongside a netlify.toml for serving it and a mkdocs-style layout, so the documentation is versioned with the code rather than living on a separate site. The repository also carries a helm-lint and helm-test target, which tells you the chart is validated as part of the build, and a deployments/ directory alongside templates/ for the chart sources. Because the GPU plugin is off by default in the chart, the install page is also where you would find out how to enable it, and that is the single most important page to read before touching this project in anger.

Licence, release cadence and how to report problems

The project is licensed under Apache-2.0, and contributions require a Developer Certificate of Origin, with the process spelled out in CONTRIBUTING.md. The repository follows the usual Kubernetes project layout, with an OWNERS file, a CODE_OF_CONDUCT.md, SECURITY_CONTACTS and an AGENTS.md, plus an api/ directory for the driver's own API types and a pkg/ and internal/ split for the implementation. The release history shows v0.5.1 on 2026-10-12, v0.5.0 on 2026-08-19 and v0.4.1 on 2026-06-30, with the last push to the repository on 2026-10-19. The version numbers themselves carry information: a driver that is still pre-1.0 with the GPU side marked experimental is telling you it expects its interfaces to move. For questions and problem reports the project asks you to open an issue on the GitHub project, and the README notes that the release pages are where the outlook and specific plans for improvements are written down.

Editorial conclusion

dra-driver-nvidia-gpu fits a cluster operator on Kubernetes 1.32 or newer who has DRA enabled and needs multi-node NVLink isolation between specific pods, since the ComputeDomain plugin is the officially supported half of this project and gives pods in a domain reachability guarantees plus isolation from pods outside it. It does not fit anyone expecting production GPU allocation, because the GPU kubelet plugin is disabled by default in the Helm chart and its features are described as not yet officially supported. Before you deploy, confirm your cluster has DRA enabled and your version is 1.32 or newer, read the install page in the project documentation site rather than the overview, and if you enable the experimental GPU plugin yourself, keep the demo quickstart directory in mind as the reference for what a working pod spec looks like.

Frequently asked questions

Official sources

1. kubernetes-sigs/dra-driver-nvidia-gpu on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases