# Kubernetes community works to unify scheduler and autoscaler for AI workloads

> **Key takeaway:** The Kubernetes community is actively designing integration APIs to make the autoscaler scheduler-aware, addressing failures where GPU pods stay pending despite available cluster capacity.

**Published:** 2026-10-19T11:00:00+00:00 
**Source:** Cloud Native Computing Foundation (CNCF) 
**Category:** cloud-native 
**Canonical URL:** https://fosswire.org/news/kubernetes-community-works-to-unify-scheduler-and-autoscaler.html 

## Summary
AI workloads running on accelerators have exposed a fundamental tension in Kubernetes architecture: the scheduler and autoscaler operate as independent control loops that do not share decisions. This causes pods to remain unschedulable even when capacity exists, because the autoscaler provisions nodes the scheduler cannot use. The CNCF blog post, authored by AWS engineers, details how Dynamic Resource Allocation now gives both components a shared vocabulary for topology and device sharing, and how SIG-Autoscaling is developing integration APIs for direct coordination. Gang scheduling remains partially unsolved, with workload-aware scheduling beta in the scheduler but the autoscaler still reasoning pod-by-pod.

## How DRA and new APIs bridge the scheduler-autoscaler gap
- **Dynamic Resource Allocation (DRA)** replaces bare accelerator counts with structured claims that specify device relationships, such as an accelerator paired with its feeding network interface
- **Topology awareness**: DRA-aware autoscalers can now account for NUMA domains, PCIe paths, and high-bandwidth interconnects when simulating capacity, though implementation support varies
- **Device sharing**: Partitionable devices and consumable capacity allow fractional accelerator allocation; DRA-aware autoscalers are starting to use this model for node sizing
- **Gang scheduling gap**: Workload-aware scheduling (beta, disabled by default) lets the scheduler hold pod groups for atomic placement, but the autoscaler still scales pod-by-pod, risking stranded capacity
- **Provisioning requests**: Current bridge mechanism lets workloads request group capacity atomically via Kueue, but remains provider-dependent and bolt-on rather than native integration
- **Future work**: SIG-Autoscaling has a public proposal for integration APIs that would let the scheduler see provisionable capacity and let the two components share placement reasoning directly

## Why it matters
For organizations running AI training or inference on Kubernetes, the scheduler-autoscaler mismatch translates directly to wasted accelerator spending and failed job starts. The convergence work described, if adopted upstream, would reduce the operational burden currently addressed through provider-specific workarounds and manual capacity management.