Kubernetes 1.37 DRA Explained: 6 Changes That Retire the GPU Device Plugin in 2026

For nine years, the way Kubernetes knew you had a GPU was that a DaemonSet told the kubelet a number. That number — nvidia.com/gpu: 8 — was an opaque integer with no structure, no attributes, and no way for the scheduler to tell an H100 from a decade-old inference card in the same pool. Kubernetes 1.37 DRA finishes dismantling that model. With DRA Extended Resource support graduating to GA and device taints and tolerations reaching Stable, the device plugin is no longer the thing that stands between your workload and your accelerator. It is now a compatibility shim you can delete on your own schedule. This post walks through the six changes that actually matter, what breaks when you cut over, and whether you should do it this quarter.

What this covers: the scheduling control plane underneath your GPU fleet, the six 1.37 changes in mechanical detail, an extended-resource migration path that spares your manifests, the failure modes nobody warns you about, and an honest verdict on timing.

Context and Background: How Device Plugins Got Us Here

The device plugin API was a pragmatic hack that outlived its assumptions. It landed in the Kubernetes 1.8 era and graduated to GA in Kubernetes 1.26, and its contract is deliberately thin: a vendor DaemonSet registers with the kubelet over a Unix socket, advertises a count of some named extended resource, and when a pod lands on the node, the kubelet asks the plugin to allocate a specific device and hand back the environment variables, device nodes, and mounts the container needs.

That contract has one structural flaw, and everything else follows from it. The scheduler never sees a device. It sees an integer of allocatable capacity on a node. Placement is a bin-packing decision over anonymous units.

The consequences were felt by anyone running a heterogeneous accelerator fleet. You cannot ask for “a GPU with at least 40 GB of memory and NVLink to its neighbour” — you can only ask for one unit of a resource name, and then encode everything else into node labels and affinity rules that the platform team maintains by hand. You cannot share one device between two pods without a vendor-specific trick. You cannot express that two claims must land on devices connected by the same interconnect. And you cannot take one flaky card out of service without cordoning the entire node, which strands the seven healthy GPUs sitting next to it.

Dynamic Resource Allocation was designed to fix the representational problem, not just the ergonomics. It reached GA in Kubernetes v1.34 and has been locked on since 1.35. Prioritized device lists went stable in 1.36, with partitionable devices and consumable capacity following into beta. The 1.37 release, named Garhwal and shipped on 26 August 2026 with 67 enhancements across 16 stable, 23 beta and 27 alpha graduations plus one removal, is the point at which the migration story stops being aspirational.

This matters for a cluster you already run because it changes the layer at which GPU decisions are made. If you have read our walkthrough of GPU sharing with MIG, time-slicing and MPS, that post is about partitioning a device. This one is about the control plane that decides which partition a pod gets — and that control plane just changed underneath it.

The Scheduling Control Plane Underneath Your GPU Fleet

Direct answer: DRA replaces the device plugin’s node-local, integer-counting allocation model with a cluster-level, API-driven one. Drivers publish structured device inventory as ResourceSlice objects, administrators define categories of device as DeviceClass objects with CEL selectors, workloads express needs as ResourceClaim objects, and the scheduler — not the kubelet — decides which specific device each pod gets.

That one sentence contains the whole architectural shift, and it is worth unpacking each half.

Figure 1: The device plugin path versus the Kubernetes 1.37 DRA path for a pod requesting a GPU.

In the upper path, the kubelet advertises an integer, the scheduler filters nodes on allocatable capacity, and the kubelet makes the actual device selection after binding. The scheduler’s decision and the device’s identity are decoupled — which is precisely why topology-aware placement was never reliably expressible. In the lower path, the DRA driver publishes a per-node ResourceSlice describing every device it manages, the scheduler evaluates CEL expressions against those device attributes during filtering, and writes the concrete allocation into the ResourceClaim status before binding. The kubelet then calls NodePrepareResources on the driver and the container receives its device nodes through the Container Device Interface, exactly as before.

The container-facing end of the pipeline is deliberately unchanged. CDI is the same injection mechanism both models use. That is the single most important fact for anyone planning a migration: the workload’s runtime experience of the device does not change, only the decision about which device it gets.

What a ResourceClaim Actually Replaces

A ResourceClaim replaces three things at once, which is why the mental model takes a moment to settle.

First, it replaces the resource request line in the pod spec. Instead of limits: {nvidia.com/gpu: 1}, the pod references a claim by name and the claim carries a structured device request.

Second, it replaces the node-label-plus-affinity scaffolding you built to steer workloads at specific hardware. The selector logic moves into the claim itself, as a CEL expression evaluated against device attributes that the driver publishes. An expression like device.capacity['gpu.example.com'].memory.compareTo(quantity('40Gi')) >= 0 does the work that a node.kubernetes.io/instance-type affinity rule used to do badly.

Third — and this is the part teams underestimate — it replaces the implicit lifecycle of device ownership. A ResourceClaim is a first-class API object with its own status, its own reservations, and its own garbage collection. ResourceClaimTemplate generates a per-pod claim that Kubernetes deletes when the pod terminates, which is the right default for most workloads. A standalone ResourceClaim persists and can be shared, which is what you want for a multi-pod training job that needs the same set of devices across restarts.

The Four Objects, and Who Owns Each

The full API surface lives in the resource.k8s.io/v1 group and divides cleanly along organisational lines.

ResourceSlice is owned by the driver. Nobody on the platform team writes one by hand. The driver discovers devices on the node, enumerates their attributes and capacities, and keeps the slice current as hardware state changes. If your inventory looks wrong, the bug is in the driver or its device discovery, not in your manifests.

DeviceClass is owned by the cluster administrator. It is the policy object: a named category with CEL selectors that define which devices qualify, plus optional configuration and — new in 1.37 — an extended resource name. This is where a platform team encodes “what we mean by a training GPU” once, so that application teams do not each write their own selector.

ResourceClaim and ResourceClaimTemplate are owned by the workload. They reference a DeviceClass and narrow it further if needed.

The division matters operationally because it determines who gets paged. Under the device plugin model, a GPU scheduling problem was almost always a node problem. Under DRA it might be a driver problem, a DeviceClass policy problem, or a claim problem, and the three have different owners and different diagnostic paths.

Why This Is a Control-Plane Change, Not a Driver Change

It is tempting to read DRA as “a better device plugin,” and that reading will cost you during migration. The device plugin is a node-level component whose failure mode is local: if it crashes, that node stops advertising GPUs and the scheduler routes around it.

DRA moves the allocation decision into the scheduler and the API server. The failure modes are correspondingly cluster-level. ResourceClaim objects are written and updated on the hot path of scheduling, which means GPU scheduling now contributes write load to etcd. The Kubernetes documentation is explicit that the scheduler and ResourceClaim controller need more API calls, memory and CPU than non-DRA scheduling, and that large clusters with heavy DRA use require the control plane to be sized for it.

This is also why the interaction with node autoscaling changes. Cluster Autoscaler and Karpenter both simulate scheduling to decide whether a new node would help a pending pod. That simulation must now understand ResourceSlice inventory that does not yet exist, because the node does not yet exist. Our comparison of Karpenter and Cluster Autoscaler for GPU nodes covers the node-provisioning side; what 1.37 changes is the accuracy of the simulation feeding it.

The Six Changes in Kubernetes 1.37

Five of these are API or behaviour changes you can point at in a release note. The sixth is a performance fix that will matter more than the others combined if you run a large cluster.

1. DRA Extended Resource Support Reached GA — the Migration Escape Hatch

This is the change that makes everything else practical, and it graduated to GA in 1.37 after three consecutive releases of development.

The mechanism: a cluster administrator sets extendedResourceName on a DeviceClass. Pods that request that extended resource name through the classic resources.limits syntax are then satisfied by DRA, with no device plugin registered on the node and no ResourceClaim written in the workload manifest. The scheduler constructs the claim internally.

apiVersion: resource.k8s.io/v1
kind: DeviceClass
metadata:
  name: gpu.example.com
spec:
  selectors:
    - cel:
        expression: |
          device.driver == 'gpu.example.com' &&
          device.attributes['gpu.example.com'].type == 'gpu'
  extendedResourceName: example.com/gpu

A pod asking for example.com/gpu: 2 can now be scheduled onto any node with two or more devices matching that class. The workload manifest is byte-for-byte unchanged.

There is a second, lighter-weight form that needs no extendedResourceName at all. Requesting the special resource name deviceclass.resource.kubernetes.io/<DeviceClass-name> works against any DeviceClass and produces a claim requesting an exact count of devices from it. That is useful for ad-hoc testing and for classes you do not want to expose under a legacy name.

Figure 2: How an unchanged extended-resource request resolves through a DeviceClass into a DRA allocation.

The diagram traces the compatibility path. The pod spec is legacy. The scheduler’s DRA plugin sees no device plugin advertising that resource on the node, finds a DeviceClass carrying the matching extendedResourceName, synthesises a ResourceClaim, matches it against published ResourceSlices, and records the allocation. The kubelet then prepares the device through CDI. Nothing downstream of the allocation knows the difference.

Strategically, this is the single most important thing in the release. It decouples installing DRA from rewriting every manifest in the fleet — which were previously the same project, and which is why so many teams deferred DRA entirely. Now they are two projects, and you can complete the first without starting the second.

2. Device Taints and Tolerations Reached Stable — Fleet Maintenance Without Cordoning

Under the device plugin model, a single degraded GPU forced a node-level decision. You cordoned and drained a machine with seven healthy accelerators to service one bad one. On an eight-GPU node at current instance prices, that is an expensive way to handle a fan fault.

Device taints fix this at the right granularity. Two mechanisms produce them. A DRA driver can taint a device directly in the ResourceSlice it publishes — the natural path for health-driven taints, because the driver is the component that knows the device is throwing ECC errors. Separately, an administrator or a controller can create a DeviceTaintRule, which applies a taint to every device matching a selector without requiring any cooperation from the driver. The selector can match on DeviceClass, driver, pool, and device name; an empty selector matches everything, and an absent selector matches nothing.

apiVersion: resource.k8s.io/v1
kind: DeviceTaintRule
metadata:
  name: firmware-rollout-rack-7
spec:
  deviceSelector:
    driver: gpu.example.com
    pool: node-7
  taint:
    key: maintenance.example.com/firmware
    value: "2026-09"
    effect: NoSchedule

The three effects mirror node taints with one addition. NoSchedule keeps new claims off the device. NoExecute implies NoSchedule and additionally evicts pods already using the device, unless their ResourceClaim carries a matching toleration. None is ignored by both the scheduler and the eviction controller, and exists so drivers can communicate a device condition — degraded health, reduced clocks, a pending recall — to administrators and controllers without changing scheduling behaviour at all.

Figure 3: The device taint lifecycle for a degraded accelerator, from driver report through eviction to clearing.

The None effect deserves more attention than it gets. It turns the taint mechanism into a general-purpose device condition channel that an external controller can subscribe to. You can build a policy where an ECC error rate above a threshold raises a None-effect taint, a monitoring controller notices it, correlates against job SLOs, and only then escalates to NoSchedule — draining the device gracefully at the next checkpoint boundary rather than mid-step.

3. Shared ResourceClaims for Workloads and PodGroups Reached Beta

Gang-scheduled training jobs hit a hard ceiling in earlier DRA releases: a ResourceClaim could be reserved by at most 256 pods. For a large distributed training job that is a real limit, not a theoretical one.

In 1.37, ResourceClaim support for workloads graduates to Beta behind the DRAWorkloadResourceClaims feature gate, alongside the core Workload and PodGroup APIs. A Workload or PodGroup can reference a ResourceClaim directly, so a single claim covers an entire group of pods instead of being capped by the per-pod reservation list.

The scheduling semantics matter as much as the cap. When the group owns the claim, the allocation decision is made once for the group rather than negotiated pod-by-pod, which is the right shape for gang scheduling — you want all-or-nothing placement of a topology-sensitive set of devices, not a partial allocation that deadlocks waiting for the rest.

If you run multi-node training, this is the change that makes DRA viable for your largest jobs. It is Beta, so treat the API as likely to shift before GA, but the capability gap it closes was the main reason batch platforms stayed on device plugins.

4. Fractional Capacity Ranges Reached Beta

The DRAFractionalCapacityRange feature gate, in Beta as of 1.37, allows more precise capacity requests and allocation for devices that expose fractional resources.

This is the API-level counterpart to the partitioning story. Consumable capacity — the ability for multiple claims to draw from one device’s divisible resources — has been maturing since 1.34. Fractional capacity ranges let a claim express a range rather than a point value, which is what you need for inference workloads that can run in 4 GB of GPU memory but would prefer 12 GB if it is free.

For anyone doing serious inference cost optimisation, the range form is the more useful primitive. A fixed request forces you to pick between low utilisation and frequent OOM; a range lets the scheduler pack opportunistically and hand back the headroom when the device is contended.

5. Standardised Per-Device Status in ResourceClaim

DRA drivers can now report per-device status in the status.devices field of a ResourceClaim. For network devices, that includes the interface name, MAC address, and assigned IP addresses.

This sounds narrow. It is not. Before this field existed, if a pod requested a network device through DRA, no other component in the cluster could learn what IP address that device ended up with — which meant DRA could allocate a secondary network interface but nothing downstream could use it. The field closes that gap and makes DRA fully usable for attaching secondary interfaces to pods, a job that until now belonged to Multus and a pile of CNI-adjacent glue.

This one landed directly as Stable, because it is a naming and registration change with no feature gate and no in-tree behaviour change. Why it belongs in a GPU post: it is the clearest signal that DRA is becoming the general device-attachment plane for Kubernetes, not a GPU-specific mechanism. The same object that hands your pod an accelerator will hand it an RDMA NIC, and the scheduler can reason about both in one allocation decision. For RDMA-backed training that is not a nicety — co-locating the GPU and the NIC on the same PCIe root complex is the difference between a job that scales and one that does not.

6. The Scheduler Requeue Path Went From Quadratic to Constant

The least publicised change is the one most likely to show up in your dashboards.

Every ResourceClaim event used to trigger a full scan of every unschedulable pod in the cluster. During a large scale-up — exactly the moment a GPU cluster is under the most pressure — that is O(N²) work: N claim events each walking a queue of N pending pods. The DRA scheduler plugin now maintains a pod informer index so that a claim event only wakes the pods actually affected by it, reducing the requeue path to O(1). Upstream reports roughly double the scheduling throughput in early benchmarks.

Treat “roughly double” as an upstream-reported figure from early benchmarking, not a number you should put in a capacity plan. The shape of the improvement is more reliable than its magnitude: the worst case moves from quadratic to linear in the number of claim events, so the benefit grows with cluster size. A 50-node cluster will barely notice. A 2,000-node cluster spinning up a large training job will notice a great deal.

Three more changes are worth knowing about even though they are earlier-stage. Device binding conditions, gated by DRADeviceBindingConditions, let a claim list condition types that must be True in .status.conditions before the pod can bind — readiness signals like DeviceAttached or DeviceInitialized, which matter for devices that need out-of-band attachment before they are usable. The DRA Device Attributes Downward API, in Alpha, lets drivers populate a metadata field that the framework writes as a JSON file mounted into the container via CDI; it targets device injection into KubeVirt VMs. And list types for attributes entered a second Alpha, letting a device attribute hold multiple values rather than a single scalar.

Migrating Without Rewriting Every Manifest

The extended-resource compatibility path turns migration from a big-bang rewrite into a sequence of independently reversible steps. Here is a staged plan that has survived contact with real clusters.

Figure 4: A staged cutover from the GPU device plugin to Kubernetes 1.37 DRA, one reversible step at a time.

Stage 0 — inventory. Find every workload requesting a device-plugin extended resource, every node label your affinity rules depend on, every ResourceQuota counting those resources, and every admission policy that inspects them. The last two are where surprises live. A quota that limits requests.nvidia.com/gpu behaves differently once those requests are satisfied by DRA, and any Kyverno or ValidatingAdmissionPolicy rule that reads spec.containers[*].resources will not see a ResourceClaim at all.

Stage 1 — install the DRA driver alongside the device plugin. Both can coexist; they manage different views of the same hardware. Do not point them at the same devices simultaneously in production. Use a dedicated node pool for the first pass.

Stage 2 — verify inventory before trusting it. kubectl get resourceslices -o yaml and read what the driver actually published. Confirm device counts, attributes and capacities match physical reality. Discovery bugs surface here or they surface at 3am.

Stage 3 — map a DeviceClass onto your existing extended resource name. Set extendedResourceName: nvidia.com/gpu (or whatever your fleet uses) on the class. Your existing manifests now resolve through DRA on nodes where the device plugin is absent. This is the step that makes the rest optional.

Stage 4 — drain one node pool and remove the device plugin from it. Watch scheduling latency, claim allocation errors, and etcd write rate. If anything is wrong, reinstall the device plugin and you are back where you started.

Stage 5 — adopt native ResourceClaims for new workloads only. Do not backfill. New jobs get the expressive API and the CEL selectors; old jobs keep working on the compatibility path indefinitely. Backfilling is where migrations stall, because it converts a platform project into an application-team negotiation.

Stage 6 — turn on device taints for fleet maintenance. This is where the operational payoff arrives, and it is worth doing before full cutover because the benefit is immediate and independent.

Stage 7 — retire the device plugin cluster-wide once every pool has run clean for a full maintenance cycle.

The order is deliberate. Every stage up to 4 is additive and reversible. Stage 4 is the first one with a blast radius, and it is scoped to one pool. By the time you reach stage 7, the thing you are deleting has not been load-bearing for weeks.

Trade-offs, Gotchas, and What Goes Wrong

Admission policy goes blind. This is the most common self-inflicted wound. Policies that enforce “every GPU pod must set a node selector” or “no pod may request more than 4 GPUs” almost always work by reading container resource requests. A pod using a ResourceClaim has no GPU line in resources. Your policy passes it, silently. Audit every policy that mentions a device resource name before you let native claims into the cluster, and write the DRA-aware equivalent first.

Quota semantics shift. Devices requested through resource claims and through extended resources are both counted toward quota, so the accounting exists — but the object being counted changes. If your chargeback pipeline scrapes pod specs rather than quota status, it will undercount DRA workloads to zero. Fix the pipeline before the cutover, not after the first surprising invoice. This matters for the same teams doing GPU rightsizing and cost work, where the input data is exactly what breaks.

Autoscaler simulation fidelity. A node that does not exist has no ResourceSlice. The autoscaler must therefore model what inventory a hypothetical node of a given type would publish. If that model is wrong or absent, you get one of two bad outcomes: pending pods that never trigger a scale-up because the simulator cannot prove the new node would help, or a scale-up that provisions a node whose devices do not match the claim, leaving the pod pending and the node idle. Test scale-from-zero explicitly on a scratch cluster, with the exact DeviceClass and claim shapes you intend to ship.

Driver maturity is uneven. Not every vendor DRA driver implements every feature at the same pace, and a driver that does not publish rich attributes gives you a DRA-shaped device plugin with none of the selection power. Read the driver’s ResourceSlice output before you design selectors against attributes you assume exist.

Control-plane load is real. GPU scheduling now writes to etcd on the hot path. On a large cluster with high pod churn, size the API server and scheduler accordingly and watch apiserver_request_duration_seconds for the resourceclaims resource specifically. This is a genuine new cost, not a rounding error.

Mixed-mode ambiguity. Running the device plugin and a DRA driver against the same physical devices on the same node invites double allocation. The extended-resource path is designed for nodes where the device plugin is absent. Treat “device plugin present” and “DRA driver present” as mutually exclusive per node pool, and enforce it with node labels rather than convention.

Debugging is less obvious. Under the device plugin, kubectl describe node told you almost everything. Under DRA, a pending pod requires you to check the ResourceClaim status, the relevant ResourceSlices, any device taints, and the scheduler’s events — four places instead of one. Build the runbook before you need it.

Practical Recommendations

Start with the compatibility path, always. Installing a DRA driver and mapping a DeviceClass onto your existing extended resource name gets you the scheduler improvements, device taints, and a working DRA control plane without touching a single workload manifest. That is most of the value for a fraction of the risk.

Prioritise device taints over native claims. Taints deliver an operational win — per-device maintenance instead of per-node cordoning — that pays back immediately and does not require application teams to change anything. Native claims deliver expressiveness, which is valuable but only to workloads that need it.

Treat the admission and quota audit as a blocking prerequisite, not a follow-up. It is the one class of failure that is silent, and silent policy bypass on GPU resources is the kind of thing that is discovered by an auditor rather than an alert.

Checklist before you cut over a pool:

• [ ] Kubernetes control plane and nodes on 1.37 or later, with the relevant feature gates confirmed enabled.
• [ ] Vendor DRA driver installed, and ResourceSlice output manually verified against physical inventory.
• [ ] Every admission policy touching device resource names rewritten to understand ResourceClaim.
• [ ] Quota and chargeback pipelines reading claim-aware sources.
• [ ] Autoscaler scale-from-zero tested with the exact DeviceClass and claim shapes you will ship.
• [ ] DeviceTaintRule RBAC scoped — this object can evict running workloads fleet-wide.
• [ ] Rollback tested: device plugin reinstalled on a drained pool and verified working.
• [ ] Runbook written for the four-place debugging path.

Should You Migrate Yet? An Honest Verdict

If you run a homogeneous GPU fleet with one card type and simple whole-device allocation: not urgent. The device plugin works, your manifests work, and the 1.37 improvements buy you device taints and a faster scheduler. Install the DRA driver on the compatibility path this quarter to de-risk the eventual move, but do not prioritise native claims.

If you run a heterogeneous fleet — multiple GPU generations, mixed memory sizes, mixed interconnect: migrate now. This is the case DRA was built for, and every month you spend maintaining node-label-and-affinity scaffolding is a month of accruing operational debt against a mechanism that is on its way out.

If you run large distributed training: wait for the workload APIs to stabilise, but start the compatibility migration today. Shared ResourceClaims for PodGroups is the feature you need and it is Beta, which means it will move before GA. Get the driver and DeviceClass groundwork done now so that adopting the workload API later is a small change rather than a project.

If you are building a new cluster in 2026: skip the device plugin entirely. There is no reason to install a mechanism you will remove, and the vendor ecosystem has committed to DRA-native drivers on a timeline measured in releases rather than years, as the CNCF analysis of DRA’s ecosystem impact sets out.

The honest summary: Kubernetes 1.37 DRA is the release where the device plugin stopped being the default and became the legacy option. It is not yet the release where keeping the device plugin is negligent. That release is coming, and the cheapest time to prepare is while the compatibility path is holding your manifests steady.

Frequently Asked Questions

Is the Kubernetes device plugin API deprecated in 1.37?

No. The device plugin API is not formally deprecated in Kubernetes 1.37 and continues to work. What changed is that DRA can now fully replace it for GPU scheduling, including satisfying classic extended-resource requests without any device plugin present. Major accelerator vendors have committed to DRA-native drivers, so the practical deprecation is being driven by the ecosystem rather than by an upstream removal date. Plan for eventual removal; do not expect it imminently.

Do I have to rewrite my pod manifests to use DRA?

Not for the initial migration. DRA Extended Resource support went GA in 1.37, letting an administrator set extendedResourceName on a DeviceClass so that existing requests like nvidia.com/gpu: 2 are satisfied through DRA with no device plugin and no ResourceClaim in the manifest. Rewriting to native ResourceClaims is optional and only worth doing for workloads that need attribute-based selection, device sharing, or topology-aware placement.

What do device taints give me that node taints do not?

Granularity. A node taint takes an entire machine out of service; on an eight-GPU node, servicing one bad card strands seven healthy ones. Device taints act on individual devices, so you can quarantine a single degraded accelerator while the rest of the node keeps serving. The NoExecute effect evicts pods already using the device unless their claim tolerates the taint, and the None effect lets drivers signal device conditions without changing scheduling at all.

Does DRA replace MIG or time-slicing?

No — they operate at different layers. MIG and time-slicing partition a physical GPU into smaller usable units. DRA is the control plane that decides which unit a given pod receives and records that decision. The two compose: a driver publishes MIG partitions as distinct devices in a ResourceSlice, and DRA allocates them with full attribute awareness, which is considerably better than the device plugin’s opaque integer count of partitions.

Will DRA slow down my scheduler?

It adds control-plane cost, because ResourceClaim objects are written on the scheduling hot path and increase API server and etcd load. Kubernetes 1.37 offsets much of this: the DRA plugin now uses a pod informer index so a claim event only wakes affected pods, cutting the requeue path from quadratic to constant and roughly doubling scheduling throughput in upstream early benchmarks. Net effect on a large cluster is usually positive; size the control plane deliberately either way.

Can I run the device plugin and a DRA driver at the same time?

Across different node pools, yes, and that is the recommended migration pattern. On the same devices on the same node, no — you risk double allocation, because neither mechanism knows about the other’s reservations. The extended-resource compatibility path is specifically designed for nodes where no device plugin advertises the resource. Enforce the separation with node labels rather than relying on deployment convention.

Further Reading

• Kubernetes GPU sharing with MIG, time-slicing and MPS — the device-partitioning layer that DRA now schedules on top of.
• Karpenter vs Cluster Autoscaler for GPU nodes — the node-provisioning layer whose scheduling simulation DRA changes.
• AI inference cost optimization in 2026 — where fractional capacity and device sharing show up on the invoice.
• Kubernetes cost optimization and GPU rightsizing — the chargeback pipelines that need to become claim-aware.
• Kubernetes v1.37: DRA Updates — the upstream release post covering every DRA graduation in 1.37.
• Device Taints and Tolerations — the official reference for DeviceTaintRule semantics and effects.

By Riju — about