Skip to main content
bex.co
419
Blog

Kubernetes 1.36 Didn't Put DRA in GA — Here's What Shipped, and How to Run GPU-Aware Scheduling on Your Own Hetzner Fleet

8 min readDora NodaDora Noda
Kubernetes
Self-Hosting
PaaS
Infrastructure
Share
On this page

If you've read a headline claiming "Dynamic Resource Allocation went GA in Kubernetes 1.36," it's wrong by two releases. DRA's core API — the one that lets a Pod ask for a GPU by attribute instead of by opaque integer count — graduated to stable in Kubernetes 1.34, back in September 2025. What 1.36 "Haru" (released April 22, 2026) actually shipped is narrower and, for anyone trying to run GPU-aware scheduling on their own hardware, more interesting than the misquoted headline: one more DRA feature reached stable, three more shipped at beta enabled by default, and NVIDIA handed governance of its GPU driver to the community.

That distinction matters if you're trying to figure out what you can actually build today. This post untangles the real DRA timeline, shows what "GPU-aware scheduling" concretely buys you over the old Device Plugin API, and — because Bex.co runs tenant workloads on Cluster API fleets on owned Hetzner hardware rather than a hyperscaler's rented GPU instances — walks through what it takes to get a real, DRA-scheduled GPU node into a self-hosted fleet right now.

The Real DRA Timeline (and What "Haru" Actually Shipped)​

DRA didn't arrive in one release. It's been graduating feature-by-feature since Kubernetes 1.26, and conflating "the umbrella feature has a GA milestone" with "everything under it is GA" is exactly the mistake the misquoted headline makes:

VersionDateWhat happened
1.26Dec 2022DRA lands as alpha
1.31Aug 2024Core API redesigned around "structured parameters"
1.32Dec 2024Structured parameters reach beta (v1beta1)
1.33Apr 2025API bumped to v1beta2
1.34Sep 2025Core DRA graduates to GA/stable
1.36 "Haru"Apr 22, 2026Prioritized List → stable. Partitionable Devices, Consumable Capacity, Device Taints → beta, on by default

Kubernetes 1.36 shipped 70 enhancements total — 18 graduated to stable, 25 to beta, 25 landed as alpha. Exactly one of those stable graduations touches DRA directly: Prioritized List, which lets a ResourceClaim express an ordered fallback ("give me an H100, but an A100 will do") instead of a single hard requirement. The features that actually make DRA useful for GPU partitioning — Partitionable Devices (native MIG-style slicing), Consumable Capacity (fractional sharing without hard partitions), and Device Taints (cordoning a bad or reserved accelerator) — are all still beta in 1.36, just shipped enabled by default rather than behind an opt-in flag.

So the accurate claim is: DRA-the-framework has been GA for three releases; DRA-for-GPU-partitioning is beta-by-default as of this release. Both of those are true and useful. Neither is "DRA went GA in 1.36."

What GPU-Aware Scheduling Concretely Buys You​

The reason this distinction is worth a whole section, and not just a correction, is that the old API this replaces was genuinely primitive. The Device Plugin API treats every accelerator as an opaque integer:

yaml
resources:
  limits:
    nvidia.com/gpu: 2

That request can't say which two GPUs, whether they're NVLink-connected, whether a fraction of one will do, or what to do if none are free. It's a count, not a description.

A DRA ResourceClaim targeting a driver that implements Partitionable Devices can instead express something like "a 10GB MIG slice with at least 1/7 of the GPU's compute," and — with Prioritized List — "an H100 partition, falling back to an A100 if none is free." The scheduler evaluates the claim against structured attributes (memory, compute class, MIG topology, NVLink adjacency) that the driver publishes, rather than matching a bare count. That's the entire practical difference between the Device Plugin API and DRA: attribute matching instead of counting, with fallback semantics on top.

One more change worth knowing about if you're building on this: at KubeCon EU in Amsterdam on March 24, 2026, NVIDIA donated its GPU DRA driver to the CNCF. It's no longer a single-vendor plugin you depend on at NVIDIA's pleasure — it's a community-governed component under the same project as the scheduler it plugs into. For a platform betting on owned hardware over a hyperscaler's managed GPU tier, that's a meaningfully lower-risk dependency than a vendor-controlled binary.

Getting a Real GPU Node Into a Self-Hosted Cluster API Fleet​

Here's where the theory has to meet Bex.co's actual infrastructure: a Cluster API fleet on Hetzner. And here's the part most "self-host your GPUs" posts skip — Hetzner Cloud, the VM product, has no GPU instances at all. There's no hcloud server create --type gpu-anything. The cloud API simply doesn't offer one.

GPUs on Hetzner exist exactly one way: as dedicated servers, provisioned through the Robot API/portal, not the Cloud API. As of this writing the lineup is two SKUs — the GEX44 (RTX 4000 SFF Ada, 20GB), frequently unavailable, and the GEX131 (RTX PRO 6000 Blackwell Max-Q, 96GB GDDR7 ECC, 24-core Xeon Gold 5412U, 256GB DDR5 ECC) at €889/month, no setup fee, launched December 2025. These are monthly-contract bare metal, not autoscaled, metered cloud VMs — provisioning can take days, and both SKUs carry waitlists during demand spikes.

That €889/month is worth sitting next to a hyperscaler rental price, with one caveat up front: the GEX131's RTX PRO 6000 Blackwell Max-Q isn't the same GPU class as an H100, so this isn't an apples-to-apples benchmark — it's an order-of-magnitude sanity check. AWS's on-demand P5 (H100) list price runs roughly $6.88 per GPU-hour, which is about $5,000/month left running continuously. A single GEX131, at roughly a sixth of that monthly cost, buys a fixed 96GB card you own outright instead of a metered hourly rental — the tradeoff being that "outright" also means no autoscaling, no hourly billing, and a provisioning wait if the SKU is on a waitlist. DRA's job is to make that one owned card behave like a shared pool across tenants; it can't manufacture more physical GPUs when Hetzner's waitlist is the bottleneck.

That reality shapes the whole approach. Cluster API Provider Hetzner (CAPH) supports two distinct node paths: HCloud VMs (fast, autoscaled, no GPUs) and Hetzner dedicated/bare-metal servers via HetznerBareMetalHost (slower to provision, but the only path to a GPU). Getting a DRA-scheduled GPU node into a fleet means using the bare-metal path specifically:

  1. Provision a GEX131 through Hetzner Robot (or pre-order — check the waitlist first) and register it as a HetznerBareMetalHost in CAPH, the same way you'd onboard any other bare-metal worker.
  2. Install the NVIDIA GPU Operator on that node to handle driver installation, and deploy the community-governed GPU DRA driver (post-CNCF-donation) instead of the legacy device plugin.
  3. Enable the 1.36 beta feature gates you need — DRAPartitionableDevices and DRAConsumableCapacity — on the API server and scheduler if you want MIG-style slicing rather than whole-GPU allocation. They ship on by default in 1.36, but confirm your distribution hasn't disabled them.
  4. Author ResourceClaims with Prioritized List fallbacks so a tenant workload degrades gracefully to a smaller partition instead of failing to schedule when the one GEX131 in the fleet is fully claimed — a real constraint when your GPU capacity is one bare-metal box, not an autoscaling pool.

That last point is worth sitting with. On a hyperscaler, "not enough GPU capacity" usually means "raise the autoscaling ceiling." On owned Hetzner hardware, it means "wait for the next dedicated server to provision" or "partition harder." DRA's fallback and partitioning primitives aren't cosmetic here — they're what makes a single expensive, slow-to-provision GPU box behave like a shared resource pool instead of a single point of contention.

What's Still Missing​

Two honest caveats, so this doesn't oversell where DRA is today. First, Consumable Capacity and device health-status reporting are still beta — expect rough edges if you lean on fractional sharing in production. Second, there is still no path to an autoscaled, on-demand GPU cloud instance on Hetzner; every GPU node in a self-hosted fleet is a manually provisioned, monthly-billed dedicated server with a waitlist risk. DRA solves the scheduling half of GPU-aware infrastructure. It does nothing to solve Hetzner's GPU supply constraint — that remains a capacity-planning problem, not a Kubernetes API problem.

Neither caveat erases the core shift: as of Kubernetes 1.36, a self-hosted platform can express real GPU topology and fallback semantics through a community-governed driver, on hardware it owns outright — it just has to plan around bare-metal provisioning timelines instead of pretending they're autoscaled cloud instances.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with the same Cluster API fleet model this post's GPU node-onboarding steps apply to. Star the repo on GitHub or deploy your first app today.

Sources​

Related articles

Run this on infrastructure you own

bex is the open-source, AI-native Render alternative — push a git repo and get a running HTTPS service on your own machines.

Get started with bex
Back to all posts