Kubernetes 1.33 in-place pod resize:
the end of the 3 AM restart window.

On March 19, 2026, Kubernetes 1.33.10 dropped with a feature that's been eight years in the making: in-place pod vertical resize went to beta. If you run stateful workloads — databases, message brokers, caches, search indexes, anything with warm state — this is the biggest capacity-planning improvement since the cluster autoscaler.

Here's why it matters, how it works under the hood, the four-state machine you need to understand before you rely on it, and a safe rollout plan for existing clusters.

1. The problem it solves

Every Kubernetes operator has told this story. A Postgres pod is running with 8GB of memory. Traffic grows. It needs 16GB. The "correct" Kubernetes way is to update spec.containers[].resources.limits.memory and let the pod restart.

Except that means:

• The Postgres instance loses its warm buffer cache — potentially tens of GB of hot data.
• Active connections get dropped.
• Replication state has to re-sync.
• You're taking an intentional, planned outage to increase capacity.

So in practice, teams pick one of three bad options: (a) over-provision from day one (expensive), (b) schedule memory resizes at 3 AM (still an outage), or (c) build complex blue/green resize workflows (pure operational overhead).

In-place resize kills all three paths. You update the spec. The kubelet changes the cgroup limits. No restart, no eviction.

2. How it actually works

The in-place flow is actually very simple:

1. You update pod.spec.containers[*].resources (via a resize subresource in 1.33).
2. The kubelet on that node sees the update and validates that the resize is feasible.
3. The kubelet writes new cgroup limits — memory.max and cpu.max under cgroup v2.
4. pod.status.resources updates to reflect the new values.

Under the hood this leverages the Linux cgroup v2 API, which has allowed live modification of memory and CPU ceilings for years — Kubernetes just finally plumbed it through. The container runtime sees a new cgroup limit, the kernel enforces it on the next allocation, and your running process sees its budget grow mid-life.

3. The resize state machine

Not every resize succeeds. The kubelet can be in one of four states after a request:

• Proposed — kubelet has seen the request and hasn't decided yet.
• InProgress — resize is being applied; cgroups are being updated.
• Deferred — resize can't happen right now, usually because shrinking memory would overcommit the pod's current working set. The kubelet retries automatically.
• Infeasible — resize can never happen on this node (e.g., requesting more CPU than the node has allocatable). You'll need to reschedule.

The important subtlety: memory cannot be shrunk below current usage. If your pod is using 12GB and you set the limit to 10GB, Kubernetes says "Deferred" and waits for the pod's RSS to drop below 10GB. It will not kill the process to make it fit — that would defeat the entire point.

4. A safe rollout plan

Here's how we recommend teams adopt in-place resize in production:

Step 1: Enable the feature gate. In 1.33 this is beta but not on by default in every distribution. Set --feature-gates=InPlacePodVerticalScaling=true on kube-apiserver and kubelet. EKS, GKE, and AKS all expose this as a cluster setting from 1.33+.

Step 2: Start with a single non-critical workload. Pick a cache, a worker pool, or a staging database. Run kubectl patch to adjust resources and watch kubectl get pod -o yaml for the resize conditions.

Step 3: Instrument what changed. The Prometheus metric kube_pod_container_resource_limits will reflect the new values, but you also want container_memory_usage_bytes to confirm the process actually started using the new room.

Step 4: Integrate with VPA. Vertical Pod Autoscaler's InPlaceOrRecreate mode (still alpha in 1.33, beta targeted for 1.34) is the long-term destination. It uses in-place resize where possible and falls back to recreate where necessary.

Step 5: Don't trust memory shrink. Ever. Build your automation around "grow in-place, shrink on deploy." Memory is sticky, and Deferred states can last hours.

5. What it still doesn't fix

A realistic list of things in-place resize does not solve:

• Changing storage (PVC) sizes — that's volume expansion, a separate feature.
• Adding or removing containers in a pod — still requires a restart.
• Changing node affinity, tolerations, or nodeSelector — still requires reschedule.
• QoS class transitions (Guaranteed ↔ Burstable) — the kubelet will refuse.
• Init container resizes — ignored.

And the old-school caveat: if your process doesn't actually observe cgroup changes — some older JVMs, some CPython builds, Go binaries compiled before 1.18 — you'll grow the box but the application will still act like it has the old budget. Test this per runtime, not per cluster.

The takeaway

In-place resize is one of those features where "yeah, we finally have it" is the entire review. It removes a long-standing Kubernetes tax on stateful workloads and makes VPA viable for a new class of services that couldn't tolerate the restart.

If you run Postgres, Kafka, Redis, Elasticsearch, or anything with warm state on Kubernetes and you haven't mapped out how in-place resize changes your capacity planning — that's a 30-minute conversation worth having in your next architecture review.

Planning a 1.33 upgrade and want a second set of eyes? Book a free 30-minute Kubernetes review — we'll look at your stateful workloads and tell you where in-place resize changes the plan.

Related: DevOps Engineering services · Site Reliability Engineering · Three Kubernetes migration mistakes