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

Kubernetes v1.33, released in April 2025, promoted in-place pod vertical resize to beta and turned it on by default, after it first shipped as alpha in v1.27. 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 resize states 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. In 1.33 the old status.resize field is deprecated (the Proposed status from the alpha releases is no longer set), and the kubelet reports a resize through two pod conditions:

• PodResizeInProgress: the kubelet has accepted the resize and allocated the resources; cgroups are being updated.
• PodResizePending, reason Deferred: the resize isn't possible right now but might become feasible later, for example once another pod on the node is removed. The kubelet retries automatically.
• PodResizePending, reason Infeasible: the 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: in 1.33, memory limits can't be decreased in place. A lower memory limit is only accepted if the container's memory resizePolicy is RestartContainer, which restarts the container; memory requests can generally be decreased. From 1.34, in-place memory-limit decreases are best-effort: if your pod is using 12GB and you set the limit to 10GB, the kubelet skips the resize and leaves it in progress rather than OOM-killing the process, with no guarantee against a memory spike right after the check.

4. A safe rollout plan

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

Step 1: Confirm the feature gate. In 1.33 the InPlacePodVerticalScaling gate is beta and enabled by default, so most clusters need no change; if it has been switched off, set --feature-gates=InPlacePodVerticalScaling=true on kube-apiserver and kubelet. Resize requests go through the resize subresource, which needs kubectl v1.32 or later. From 1.35 the feature is stable and the gate is locked on.

Step 2: Start with a single non-critical workload. Pick a cache, a worker pool, or a staging database. Run kubectl patch --subresource resize 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 update mode is the long-term destination. It shipped as alpha in VPA 1.4.0, reached beta in 1.5.0, and went GA, enabled by default, in VPA 1.6.0 (February 2026). It tries a non-disruptive in-place resize first and falls back to recreating the pod where necessary.

Step 5: Don't plan on memory shrink. On 1.33 a lower memory limit means a container restart, and on later releases an in-place decrease is best-effort only. Build your automation around "grow in-place, shrink on deploy."

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): not allowed; a resize must keep the pod's original QoS class.
• Non-restartable init containers and ephemeral containers: can't be resized (sidecar containers can).

And the old-school caveat: many applications and runtimes cannot adjust their memory allocation dynamically, which is why Kubernetes offers a RestartContainer resize policy. If your runtime sizes its heap or worker pools once at startup, 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 Kubernetes 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.

Frequently asked questions

What is in-place pod resize in Kubernetes 1.33?

In-place pod resize (in-place pod vertical scaling) lets you change a running pod's CPU and memory requests and limits without restarting it. You update the pod's resources through the resize subresource, and the kubelet rewrites the container's cgroup limits live. It reached beta, enabled by default, in Kubernetes 1.33 and has been stable since 1.35, and the pod keeps its warm state, connections, and caches through the change.

Can you shrink a pod's memory limit without restarting it?

Not in Kubernetes 1.33: memory limits cannot be decreased in place unless the container's memory resizePolicy is RestartContainer, which restarts the container, although memory requests can generally be decreased. From 1.34, in-place memory-limit decreases are best-effort: if current usage is above the new limit, the kubelet skips the resize and leaves it in progress rather than killing the process.

What are the resize states in Kubernetes 1.33?

In 1.33 the deprecated status.resize field gives way to two pod conditions: PodResizeInProgress (the kubelet has accepted the resize and is applying it) and PodResizePending, with reason Deferred (not possible right now and retried automatically, for example once another pod is removed) or Infeasible (the resize can never happen on this node, for example requesting more CPU than the node has allocatable, so the pod needs rescheduling).

How do you enable in-place pod resize?

In Kubernetes 1.33 the InPlacePodVerticalScaling feature gate is beta and enabled by default, and from 1.35 the feature is stable with the gate locked on, so most clusters need no change; if the gate was switched off, set it to true on kube-apiserver and kubelet. Start with a single non-critical workload like a cache or a staging database, patch its resources through the resize subresource, and watch the resize conditions before relying on it for stateful production workloads.

Related: April 2026 DevOps & SRE recap · DevOps Engineering services · Kubernetes consulting · Site Reliability Engineering · Three Kubernetes migration mistakes · What is DevOps?