News › ai-infrastructure
By The Linux Camp News, October 25, 2026
The demonstration separates tenant control planes and tests fractional-GPU scheduling with mock devices. It validates integration paths, not GPU performance or runtime isolation.
Anish Bista published a CNCF-hosted integration demonstration for multi-tenant GPU Kubernetes on October 23, 2026. This is a lab report, not a software release: it addresses the combination of separate Kubernetes clusters for teams and GPU allocation that otherwise reserves whole cards. 1
Bista reports two tenant clusters running on one machine without physical GPUs, with all eight tests passing. Kamaji hosts both tenant control planes in one kind management cluster, while each tenant gets a separate worker container running HAMi. The important boundary is that tenants do not share a worker or API server. This is not a demonstration of two tenants sharing one physical GPU. 1
The critical integration path crosses that management-to-tenant boundary. HAMi’s webhook, a service the API server calls during GPU pod creation, lives on tenant workers rather than beside the hosted API server. Consequently, pod creation depends on the API server reaching those workers through Kamaji’s Konnectivity tunnel. Bista reports that this path worked on the first try; checking only that the control-plane pods start would miss this dependency. 1 2
Within each tenant, HAMi lets pods request GPU memory in MB and compute as a percentage, allowing several pods to fit on one card. The mock plugin substitutes declared capacity for hardware discovery. Its documentation, retrieved October 25, 2026, explains that fake-card annotation entries determine card count, memory and compute totals. A separate positive GPU-count resource is only a health gate. Increasing that count alone therefore does not create more simulated memory or compute capacity. 1 2
For engineers evaluating scheduling policies without accelerators, the useful result is capacity rejection rather than GPU execution. Bista reports that a fourth pod requesting 30% compute would take demand to 120% of one card and remained Pending. That tests whether HAMi refuses an oversized placement, not whether a running workload receives its promised compute share. 1
A useful inventory check is to compare workers, pods and advertised GPU capacity through each tenant’s own API server. Bista reports that these queries returned only the respective tenant’s resources despite the shared management cluster. Treat that as evidence of API visibility separation, not a comprehensive tenant-security assessment: those queries establish what the APIs returned, not every possible isolation boundary. 1
Reproducing the mock workflow also requires accounting for allocation bookkeeping. HAMi locks a node while binding a pod; on real hardware its device plugin finishes allocation and releases that lock. In Bista’s lab the mock did not, leaving subsequent pods waiting for a five-minute expiry. He manually marked allocation successful and removed the lock. That was a lab workaround, not an instruction to bypass allocation handling on real-device installations. 1
The hardware boundary remains untested. HAMi-core enforces limits through the NVIDIA driver, which the simulated cards cannot exercise. No CUDA workloads ran, so the report supplies no throughput measurements or evidence about interference between competing workloads. The supported interpretation is narrower: the lab demonstrates integration wiring and scheduling decisions, not runtime GPU isolation. 1