Does Kubernetes DRA Replace HAMi?

Projects that want to share a GPU on Kubernetes have to work around an API instead of with it. The device plugin interface could count devices, and that was the whole vocabulary: nvidia. It meant one whole card, take it or leave it. HAMi , which the CNCF Technical Oversight Committee (TOC) accepted as an incubating project on July 15, 2026 , built its entire pipeline (mutating webhook, scheduler extender, annotations, in-container enforcement) to express what that vocabulary couldn’t: “give this pod 8,000 MiB and 10% of a GPU, and make the limit stick. ” Then, the vocabulary changed.

Dynamic Resource Allocation (DRA) reached general availability in Kubernetes v1. 34 and is enabled by default since v1. With the consumable capacity feature , a pod can now ask the scheduler itself for a slice of a device’s memory, natively, with no annotations involved. So the question I keep seeing in the HAMi communication channels is: does DRA make HAMi obsolete? The short answer is no, but the complete answer depends on which of HAMi’s jobs you’re talking about. One of them, encoding fractional requests where the scheduler can see them, is exactly what DRA absorbs.

The other, enforcing those fractions inside the container at CUDA-call granularity, is a job DRA was never designed to do. HAMi’s response has been to split accordingly: keep the enforcement, and rebuild the encoding on top of DRA across 3 repositories. Let’s walk through both halves, then look at what running the DRA stack takes today. To see what DRA changes, it helps to be precise about the machinery it replaces: which parts of HAMi’s pipeline exist only because the device plugin API was too narrow. None of these mean anything to the default scheduler.

Extended resources are opaque integers to Kubernetes: it can subtract them from a node total, and that’s all. It doesn’t know that gpumem and gpucores must land on the same physical card, or that 2 pods with 8,000 MiB each fit on a 24 GiB card while a third asking for 12,000 MiB doesn’t (HAMi’s scheduler rejects that third pod at filter time with a CardInsufficientMemory event). So HAMi routes the pod through a mutating webhook to its own scheduler extender, which filters nodes, scores cards, picks a specific device UUID, and records the decision where the API has room for it: an annotation.