INFRA Signal 483
Does Kubernetes DRA Replace HAMi?
Kubernetes now provides a native way to request fractional GPU resources through a claims-based API, removing the need for HAMi’s encoding layer while leaving its enforcement role unchanged.
Engineers can define GPU slices using standard Kubernetes objects, which simplifies pod specifications and lets the scheduler make placement decisions based on actual device attributes. However, because the new API does not enforce those limits inside containers, teams must still rely on HAMi or similar tools to guarantee isolation, so operational work shifts rather than disappears.
Written by elseif from the cluster below · every claim links back to a sourceThe three things worth knowing
The claims model introduces ResourceSlice, DeviceClass, ResourceClaim and ResourceClaimTemplate objects that let the scheduler see GPU memory and compute as allocatable quantities.
HAMi’s mutating webhook, scheduler extender and annotation mechanism existed solely to translate fractional requests into a form the old device plugin could understand.
Enforcing the allocated fractions inside the container still requires HAMi’s libvgpu.so (or an equivalent), which the new API does not provide.
THE READ
What the cluster adds up to.
The new resource claims API replaces integer counting with structured objects that describe each GPU’s model, memory and architecture, allowing the scheduler to allocate specific slices of memory and compute. DeviceClass lets administrators group similar devices using CEL expressions, while ResourceClaim captures a workload’s request for a slice of a class. The scheduler binds a concrete device to a claim before pod creation, storing the result in the claim’s status as a typed API object. This eliminates the need for custom annotations to convey which card and how much of it a pod should receive.
Adopting the claims model requires rewriting pod specifications to use ResourceClaimTemplate instead of the nvidia.com/gpu, nvidia.com/gpumem and nvidia.com/gpucores extended resources. Cluster operators must ensure their GPU drivers publish ResourceSlice objects and grant appropriate RBAC permissions for the new API groups. Testing must verify that the scheduler’s placement decisions match the intended device UUID and that the claim status is correctly propagated to the kubelet. Migration effort includes updating monitoring and alerting rules that previously relied on the old annotation format.
The claims API stops at the point of allocation; it does not intervene inside the container to enforce memory or compute limits. If a container attempts to use more GPU memory or compute than its claim allows, the excess will not be prevented by the scheduler or kubelet. Isolation therefore depends on an in-container enforcement mechanism such as HAMi’s libvgpu.so, which reads the allocation annotation and sets CUDA environment variables. Without such a layer, workloads could overrun their allocated slice and affect other pods on the same GPU.
By moving the encoding of fractional requests into the scheduler, DRA reduces runtime failures caused by over-subscription, because the scheduler can reject pods that cannot be satisfied. Administrators still need to run the enforcement component to guarantee that the limits set at allocation time are respected inside the container. The overall operational cost shifts from maintaining complex webhook and annotation pipelines to managing the new claims objects and the enforcement side-car. In practice, teams keep HAMi for its enforcement role and retire the parts that duplicated the scheduler’s function.
Written by elseif from the cluster below · checked for specifics the sources never containedTHE CLUSTER
↗