Kubernetes 1.35: Gang Scheduling is here

Kubernetes 1.35 just shipped something the community's been asking for: workload aware scheduling.

Here's the thing. Scheduling a single Pod? Easy. Scheduling an entire ML training job where all workers need to land on the same rack? That's chaos without the right tools.

For years, people built custom schedulers to handle this. But with AI workloads exploding, Kubernetes decided to stop treating workloads like second-class citizens.

Three big moves in 1.35:

1. Workload API — A new resource that describes how a group of Pods should be scheduled. It's structured, machine-readable, and sits in the scheduling.k8s.io/v1alpha1 API group.

2. Gang Scheduling — All-or-nothing placement. Your Pods don't start until the entire group can run. No more partial schedules consuming resources and causing deadlocks. The scheduler holds them at a Permit gate until there's room for everyone.

3. Opportunistic Batching — A Beta feature that speeds up scheduling for identical Pods. The scheduler reuses feasibility calculations across the queue. Most users get this automatically, no opt-in needed.

The vision goes deeper. Future work includes workload-level preemption, multi-node DRAM awareness, better autoscaling integration, and lifecycle management. This is just the first wave.

To get started: Enable GenericWorkload on kube-apiserver and kube-scheduler for the Workload API. Enable GangScheduling on kube-scheduler for gang scheduling. Opportunistic batching is on by default in 1.35.

Try it in your test clusters and send feedback to the Kubernetes team via Slack (#sig-scheduling) or GitHub issues. The future of Kubernetes scheduling is being written right now.