What happened
Kubernetes 1.35, released 19 December 2025, graduated In-Place Pod Resize (in-place vertical scaling) to stable — more than six years after it was first proposed. A container's CPU and memory requests and limits are now mutable: you change them on a running Pod via a new `resize` subresource, 'often without requiring a container restart.' Previously, changing a container's resources required deleting and recreating the whole Pod, disrupting stateful, batch and latency-sensitive workloads. The GA release also permits memory-limit decreases and adds kubelet metrics and Pod events for resize operations. (Alpha in v1.27, beta in v1.33.)
Why it matters
Immutable pod resources forced a bad choice: over-provision for peak, or accept disruptive restarts to right-size. Making CPU and memory adjustable in place lets autoscalers and operators tune resources to real load without evicting workloads — better bin-packing and cost, without the churn.
This quietly changes capacity strategy. The Staff move is to revisit requests/limits and the Vertical Pod Autoscaler now that right-sizing no longer means a restart: use in-place resize for startup boosts, bursty workers, and stateful services you couldn't safely bounce. But 'often without a restart' is not 'always' — memory changes and container-runtime support have caveats, so adopt it as a per-workload tool to test, not a global default.
Kubernetes pod CPU/memory used to be immutable. What did that force teams to do, and how does in-place resize change your approach to requests, limits and autoscaling?
Probes resource management, autoscaling trade-offs, and stateful-workload handling.