There is a number that has defined Kubernetes AI deployments for the past three years: the integer GPU count. A workload requests nvidia.com/gpu: 1. The scheduler finds a node with an available GPU unit and assigns it. The workload starts. The scheduler has no idea which GPU, what memory bandwidth it provides, what its interconnect topology is relative to other GPUs on the node, or whether its capabilities match what the workload actually needs. It assigned a GPU. One GPU. That's all the API could express.
Dynamic Resource Allocation reaching General Availability in Kubernetes 1.35 changes this. DRA is not an improvement to GPU scheduling. It is a replacement of the mental model entirely — from "count of available resource" to "structured claim against a resource with specific capabilities." That is an architectural shift, not a feature addition. And combined with the NVIDIA DRA driver transitioning to Kubernetes SIGs, it marks the moment Kubernetes became an AI operating system in a meaningful technical sense rather than just a marketing claim.
What DRA Actually Does
The pre-DRA resource model in Kubernetes treated devices as interchangeable counters. A GPU was a GPU. You had some or you didn't. The scheduler's job was to find a node with enough of the counted resource and assign the workload to it. This model works adequately for CPU and memory, where the resources are genuinely more interchangeable than the device-centric model suggests. For GPUs, it was always a lie. GPUs are not interchangeable. A 40GB A100 with NVLink is not the same resource as a 16GB L4 connected over PCIe, and a workload that needs the former will perform catastrophically on the latter.
DRA introduces structured resource claims. Instead of nvidia.com/gpu: 1, a workload can express: "I need a GPU with at least 40GB of VRAM, NVLink interconnect capability, and NUMA locality to CPU socket 0." The DRA framework — implemented by device plugins that understand the actual hardware — matches this claim against available hardware and either satisfies it or reports that no suitable hardware exists. No more silent substitution of inadequate hardware for what was actually requested.
Fractional allocation is now a first-class primitive. Before DRA, fractional GPU allocation required third-party tools with varying levels of production maturity. DRA makes fractional allocation expressible in the standard Kubernetes resource model. A workload can claim 30% of a GPU's compute with 8GB of its VRAM, and the DRA framework enforces that allocation. This is the foundation that HAMi's CNCF Incubating project — which I covered separately — builds on.
Topology-aware placement is schedulable, not configurable. Previously, topology-aware GPU placement required manual node affinity rules, custom schedulers, and extensive engineering effort to get right. With DRA, topology requirements are part of the resource claim. The scheduler understands them natively and respects them when making placement decisions. For multi-GPU inference jobs and distributed training, this changes the operational complexity calculus significantly.
The NVIDIA DRA Driver Moving to SIGs
The governance dimension of this release is as important as the technical one.
When NVIDIA moves their DRA driver from a private engineering project to a Kubernetes Special Interest Group, they are making a commitment. SIG membership means the driver is developed in the open, with community governance, with the expectation that it will become upstream infrastructure rather than a vendor extension that enterprises adopt at their own risk. It means NVIDIA is betting that the Kubernetes community model — open development, broad testing, transparent governance — produces better infrastructure than a proprietary path.
For enterprise teams making infrastructure decisions, this matters. A GPU scheduling driver maintained in a Kubernetes SIG has a governance model, a security disclosure process, a stable API contract, and a community of contributors who are invested in its quality. A vendor extension does not have these things by default. The SIG transition moves the NVIDIA DRA driver from "vendor-supported" to "community-infrastructure."
The AMD ROCM community is watching this closely, and AMD's growing engagement with Kubernetes GPU scheduling infrastructure follows the same trajectory. For the Sovereign Stack running AMD hardware, the DRA framework and its extension model are the path to first-class AMD GPU and NPU scheduling in standard Kubernetes — without requiring AMD-specific forks or patches.
What "AI Operating System" Actually Means
The phrase "Kubernetes as the AI operating system" has been used in marketing for at least two years. Before DRA GA, it was aspirational. After DRA GA, it is descriptive.
An operating system manages hardware resources on behalf of applications. It abstracts the hardware, presents a stable interface to applications, schedules access to shared resources, and enforces isolation between applications sharing the same hardware. The quality of an operating system is determined by how well it manages the resources that the applications actually depend on.
Before DRA, Kubernetes managed CPUs and memory well, but GPUs poorly. The GPU management model was a count, not an abstraction. Applications that depended on specific GPU characteristics had to implement their own hardware awareness, bypassing the scheduler's resource management. The operating system was incomplete.
With DRA GA and the NVIDIA driver in SIGs, Kubernetes now manages the full hardware stack that AI workloads depend on — with the same structured, policy-based, topology-aware approach it applies to CPUs and memory. That is what completion looks like. That is an operating system.
What This Means for Kaigents and the Sovereign Stack
I run a bare-metal Kubernetes cluster on AMD Ryzen AI hardware. The workloads include GPT-OSS 20B and Qwen3 Coder 30B inference via Lemonade Server, agent execution workloads via Kaigents, and data processing jobs that use the NPU for accelerated operations. Before DRA, workload placement was a combination of manual node affinity rules, label selectors, and operational judgment about which workload should run where.
DRA changes this. Workloads can now express their hardware requirements — NPU affinity, VRAM requirements, NUMA locality — in the standard Kubernetes resource model. The scheduler can make principled placement decisions rather than relying on my manual configuration. For a cluster running mixed workloads across heterogeneous hardware, this is a meaningful operational improvement.
The broader implication for the Sovereign Stack community is that AMD's DRA driver integration — which is following the same trajectory as NVIDIA's — will eventually give AMD NPU and GPU resources the same first-class scheduler treatment that NVIDIA resources now receive. The hardware choice for sovereign inference is a preference question. The scheduling infrastructure is converging toward a common, hardware-agnostic model.
The Question for Your Team
If you are running AI inference workloads on Kubernetes and your workload definitions still use the pre-DRA integer resource model, you have a follow-up task. DRA GA does not automatically upgrade your workloads. You need to evaluate which workloads would benefit from structured resource claims, update their definitions, and verify that your cluster's device plugins support the DRA model for your hardware.
This is engineering work, not emergency work. But it is work worth doing, because the performance and utilization improvements from topology-aware, capability-matched placement are real. The integer count model got you here. The structured claim model gets you to production-grade AI infrastructure.
The operating system is ready. The question is whether your workloads are ready to use it properly.