Kubernetes can change a pod's size while it runs.
The component that decides where pods go still plans against the numbers those pods were born with.
In place pod resize reached general availability in Kubernetes v1.35, so CPU and memory requests on a running container are no longer fixed at startup.
When a resize asks for more than the node can currently give, the kubelet marks the request Deferred and parks the pod, waiting for capacity to appear.
Kubernetes v1.37, released on 26 August 2026, adds an alpha path where the scheduler itself can make room for that resize.
Resource requests stopped being a fact about the past and became a value that two components have to keep agreeing on.
Why a Kubernetes pod resize can stall
The scheduler places a pod once, using the requests it can see at that moment, and the kubelet enforces those numbers on the node afterwards.
Resize puts a second writer into that picture. A scale up that exceeds the node's allocatable headroom cannot be applied locally, so the kubelet defers it and the pod keeps running at its old size.
A deferred resize is not a failure, which is exactly why it goes unnoticed. Nothing crashes and nothing restarts, so the only clue sits on the pod itself.
Meanwhile the numbers your tooling reports are the ones the scheduler stored, so dashboards and alerts can run behind the reality on the node for as long as the resize sits there.
Horizontal autoscalers add a third opinion to the same argument, because their target calculation also reads requests that may no longer describe the container.
Some resizes are refused rather than deferred. A change that would move a pod between QoS classes cannot be applied in place, so the request comes back infeasible and waits for nothing.
That distinction is worth keeping straight during triage. Deferred means the node is full, while infeasible means the pod is being asked for something it cannot accept.
What the alpha path in v1.37 actually changes
The new behaviour is alpha and behind a feature gate, which in Kubernetes means you test it rather than plan your year around it.
What it buys is a way out of the parked state. Instead of waiting for a neighbour to shrink, the scheduler can evict a lower priority pod so the resize can be honoured.
Priority is what makes that decision possible, and preemption only exists between pods that carry different priority classes. A cluster where every workload sits at the default priority gives the scheduler nothing to take.
Preemption has a cost that is easy to miss, because the pod that loses is usually someone else's. A resize is now a scheduling event that can displace work, so it is worth deciding which workloads may never be evicted.
Test the alpha with production node sizes rather than a laptop cluster, because both the deferral and the preemption path depend on real headroom and a real spread of priorities.
Waiting is a legitimate strategy for a resize that cannot fit, as long as your monitoring can tell the difference between a request that is queued and one that is stuck.
Three things worth doing before you rely on it
- Measure committed requests, not declared ones. Add up what the scheduler believes is committed on a node and compare it with what the kubelet has applied, because deferred resizes are the gap between the two. A deferred count belongs in a capacity report, not in a support queue.
- Assign priority classes before you need preemption. Preemption cannot evict pods the scheduler considers equally important, and a PodDisruptionBudget does not shield a pod from it. A small, stable ordering your team can explain is enough to give the scheduler a candidate when a resize needs room.
- Alert on the resize, not on the patch. The API server can accept a resize that the node then defers, so watch the pod's own resize condition rather than the success message from your deployment tooling. A resize that stays pending longer than a normal deploy window is a capacity signal.
The scheduling model underneath all of this is testable knowledge rather than folklore, and it is worth knowing whether you can reason about Kubernetes the way the scheduler does.
Watching a pod's condition instead of an exit code is a monitoring problem, and monitoring and observability is the skill it exercises. Track three values per node: allocatable, the sum of applied requests, and the sum of requested changes that have not been applied yet.
If you are unsure where the headroom went, 5 signs your SaaS backend will not scale is a short checklist of the same failure showing up earlier.
What it changes for capacity planning
Pod level resource managers, also in this release, graduated to beta behind a feature gate that stays off by default, and they let the kubelet's CPU, memory and topology managers read pod level resources when they make placement decisions.
That addresses a familiar annoyance, because getting exclusive NUMA aligned cores used to require integer requests on every container in the pod, sidecars included.
Anyone who has sized a Java heap or a connection pool already knows the right number changes with the day, and the cluster is only now catching up to that.
Both changes point the same way. The unit of resource truth is drifting from the container to the pod, and from admission time to runtime.
What makes this worth watching is the direction of travel: as pods get more mutable while they run, more of the cluster's behaviour moves out of the admission path and into reconciliation, where it is harder to see.
The old assumption was that a scheduling decision is permanent and easy to audit.
The new reality is that a pod's resource profile is a live value with two owners, which puts reconciliation inside your capacity planning.
Where should a deferred resize surface first: the pod's own status, an alert, or a neighbour being evicted to make room for it?