Kubernetes 1.37 adds an Alpha‑level scheduler capability that can preempt lower‑priority Pods to satisfy Deferred in‑place pod resize requests, eliminating the need for manual eviction or disruptive node scaling. Practitioners care because it restores the promise of dynamic resource adjustments while preserving high node utilization and cost efficiency.
In‑place pod resize preemption – what changed
The new feature is gated behind InPlacePodVerticalScalingSchedulerPreemption. When a running Pod’s container requests a larger CPU or memory limit, the Kubelet checks the node’s allocatable headroom. If insufficient, it marks the request as Deferred instead of rejecting it outright. The scheduler now watches for Pods with a Deferred resize condition and, if the node is fully utilized, it can select lower‑priority Pods for preemption. The preempted Pods are evicted, freeing the necessary resources so the original high‑priority Pod can complete its in‑place resize without a restart.
Operational impact
Before this change, operators faced three main options: manually evict low‑priority workloads, rely on the cluster autoscaler to provision a larger node (which defeats the no‑restart benefit), or build custom autoscaling logic. With in‑place pod resize preemption, the scheduler automates the first option, allowing teams to continue bin‑packing workloads aggressively. The result is higher overall cluster utilization, reduced idle buffer capacity, and fewer manual interventions during traffic spikes or memory pressure events. Because the resize happens on the same node, application downtime remains zero, preserving service‑level objectives for critical workloads.
Architectural and security considerations
Enabling preemption introduces a new control surface: priority classes now directly influence which workloads may be evicted to make room for a resize. Practitioners should audit existing PriorityClass definitions to ensure that non‑critical batch jobs are appropriately ranked below services that may need rapid scaling. Misconfiguration could lead to unintended eviction of workloads that are themselves critical, effectively creating a denial‑of‑service scenario for those Pods. Monitoring preemption events via the scheduler’s audit logs is advisable to detect unexpected patterns. Additionally, because the feature operates at the scheduler level, it does not alter pod security policies or RBAC; however, any automation that reacts to preemption (e.g., restart controllers) should be reviewed for privilege escalation risks.
Related CloudNinjas coverage: Kubernetes.
What This Means For Practitioners
To adopt the new behavior, enable the InPlacePodVerticalScalingSchedulerPreemption feature gate in the kube‑scheduler configuration and verify that your cluster runs version 1.37 or later. Test the flow in a staging environment with a mix of priority classes to confirm that high‑priority Pods successfully complete Deferred resizes while lower‑priority Pods are evicted as expected. Update operational runbooks to include preemption monitoring and adjust alert thresholds for eviction events. Finally, revisit capacity‑planning models to account for the reduced need for static buffer capacity, but retain safeguards for workloads that should never be preempted.