AI
SIG Scheduling: What the Group Maintains
SIG Scheduling owns the components that decide where pods run. The kube-scheduler is the main piece: it filters nodes that lack capacity, scores remaining candidates, and binds pods. Plugins implement each step at named extension points. The scheduling cycle runs synchronously to pick a node; the binding cycle runs asynchronously to apply the decision. Three sub-projects round out the SIG: Kueue for job-level queuing and quota management, descheduler for rescheduling already-placed pods, and kube-scheduler-simulator for testing at scale without real nodes.
Gang Scheduling and the Deadlock Problem in 1.35
In 1.35, gang scheduling used a Workload API where a workload specified gangMinCount: 4, meaning all four pods had to schedule together. Each pod passed through the scheduling cycle and hit the permit extension point, which held pods until the full gang was ready. If one pod was unschedulable, it never reached permit. The other pods stayed reserved at that point, waiting. When multiple gangs each partially reserved nodes this way, they deadlocked each other.
The API Split: Workload Policy and PodGroup Instances
Kubernetes 1.36 splits the single Workload object into two. Workload now holds static scheduling policy and pod templates. The controller uses those templates to create PodGroup objects at runtime. Each replica or scheduling unit gets its own PodGroup. Pods reference a specific PodGroup by name. PodGroup tracks scheduling state, letting the scheduler and DRA perform lifecycle management after infeasible placements. The scheduler now cares only about PodGroups, not the parent Workload.
Atomic Scheduling Decisions and Workload Preemption
The new PodGroup scheduling cycle takes the entire group, snapshots cluster state once, and runs feasibility for all pods together. If the group is feasible, pods proceed to binding. If not, the whole group returns to the scheduling queue without touching the cluster, eliminating partial-reservation deadlocks. Workload preemption follows the same logic: one preemption phase covers the entire group rather than running per pod. A priorityClassName field and a disruption mode field in the PodGroup API control which group gets evicted.
Topology-Aware Scheduling, Kueue, and the Descheduler
Topology-aware scheduling (TAS) adds a topology key field: all pods in a group must land on nodes sharing the same label value. The scheduler generates candidate placements, such as racks or zones, runs PodGroup feasibility against each, and scores the feasible options. Kueue picked up balanced placement across domains, simultaneous TAS and provisioning request support, and cross-cluster authentication via the profile API. The descheduler added a default evictor plugin and a pod lifetime plugin to fix zone spread imbalances after scale-down events.
Notable Quotes
all or nothing Kensei Nakada · ▶ 07:20
deadlock each other. Kensei Nakada · ▶ 09:05
decision of the scheduleuler to do that. Maciej Skoczeń · ▶ 13:17
Key Takeaways
- PodGroup scheduling in 1.36 makes gang scheduling decisions atomically, eliminating deadlocks from partial resource reservation.
- The Workload API now separates static policy from runtime PodGroup instances, giving the scheduler per-instance state.
- Topology-aware scheduling generates candidate placements (racks, zones) and runs feasibility across each before scoring.
About the Speakers
Kensei Nakada is a software engineer at a stealth startup. In the community, he serves as SIG Scheduling Chair and Tech Lead, and maintains the kube-scheduler-simulator and kube-scheduler-wasm-extension projects.
Maciej Skoczeń is a Software Engineer at Google and SIG Scheduling Chair. His contributions focus on making kube-scheduler workload-aware and on community development.