INFRA Signal 152
Kubernetes v1.37: Scheduler Preemption for In-Place Pod Resize (Alpha)
↗
Illustration only Photo by Paul .T on Unsplash
Kubernetes v1.37 introduces an Alpha feature behind the InPlacePodVerticalScalingSchedulerPreemption gate that lets the kube-scheduler preempt lower-priority workloads when a running Pod's in-place resource resize is stuck in Deferred status due to insufficient node capacity.
Previously, in-place resize requests that exceeded node headroom were blocked indefinitely, forcing operators to manually evict pods or rely on disruptive cluster autoscaling that violated the no-restart promise of in-place scaling. This feature lets you bin-pack nodes with lower-priority batch workloads without risking that critical applications cannot scale up when needed.
Written by elseif from the cluster below · every claim links back to a sourceThe three things worth knowing
The InPlacePodVerticalScalingSchedulerPreemption feature gate enables the kube-scheduler to track running Pods with Deferred resize status and act on them.
The scheduler can now evict lower-priority workloads to free node capacity for higher-priority in-place resizes, preserving the no-restart value proposition.
Operators can maintain high cluster utilization with lower-priority bin-packing without degrading critical workloads' ability to scale up during traffic surges or memory spikes.
THE READ
What the cluster adds up to.
In-place Pod resize reached General Availability in Kubernetes v1.35, allowing CPU and memory allocations of running containers to change without restarts. But a scheduling gap remained: when a running Pod requested a scale-up that exceeded the node's allocatable headroom, the Kubelet set the container's resizeStatus to Deferred. Unlike an Infeasible request, which is immediately rejected for exceeding physical limits, namespace limit ranges, or admission quotas, a Deferred request was valid but stuck, waiting indefinitely for node capacity to free up naturally.
Before v1.37, the kube-scheduler was unaware of deferred resizes on running Pods and could not use standard priority-based preemption to help. Operators facing a Deferred critical workload had three poor options: manually evict lower-priority Pods, rely on the cluster autoscaler to spin up a larger node and reschedule the Pod (disruptive and violating the no-restart promise), or build a custom autoscaling solution. Even an in-memory database facing an imminent OOM crash could not get its resize fulfilled if the node was fully utilized.
Kubernetes v1.37 addresses this with scheduler preemption for in-place Pod resize, introduced as an Alpha feature behind the InPlacePodVerticalScalingSchedulerPreemption feature gate. The kube-scheduler now monitors the cluster for running Pods with a Deferred resize status condition and can actively preempt lower-priority workloads to clear headroom for the higher-priority running Pod's resource growth. This integrates directly into the core scheduling cycle.
The operational impact is significant for clusters that bin-pack unused capacity with lower-priority workloads such as batch jobs or background data processing. Without this feature, that strategy created a dilemma: lower-priority workloads consuming remaining headroom could block higher-priority applications from scaling up during sudden traffic surges or memory spikes. With preemption, operators can confidently maintain high utilization without sacrificing the responsiveness of critical services, since the scheduler will automatically evict lower-priority Pods when a high-priority resize demands it.
Written by elseif from the cluster below · checked for specifics the sources never containedTHE CLUSTER