We Tried "No-Restart Resizing," and the Pod Got Recreated Anyway
We switched VPA's (Vertical Pod Autoscaler) updateMode to InPlaceOrRecreate, expecting to adjust CPU and memory without restarting Pods. A few days later, checking the event log, we found several Pods had been Evicted and recreated anyway.
To be clear upfront: this isn't a bug. In-Place Pod Resize (In-Place Pod Vertical Scaling) only avoids restarting containers when certain conditions are met, and it silently falls back to recreating the Pod when those conditions aren't satisfied.
This article verifies the actual behavior of VPA's InPlaceOrRecreate mode and In-Place Pod Resize on K3s, with real configuration examples, commands, and how to read the resulting status (spoiler: on a managed K3s like Kubo where the cgroup prerequisites are already configured, you can skip most of this investigation).
The Basics of In-Place Pod Resize — Six Years from Alpha to GA
In-Place Pod Resize (built on Kubernetes' /resize subresource) started as alpha in v1.27 in 2023, graduated to beta in v1.33 in May 2025, and reached Stable (GA) in v1.35 in December 2025. According to the official blog post announcing the v1.33 beta, restart-free resource adjustment became enabled by default during this period.
Each container's resizePolicy supports two values:
NotRequired: the container is not restarted when the resource changes (default)RestartContainer: the container is restarted when the resource changes
The official Kubernetes documentation describes patching resources with kubectl patch pod <name> --subresource=resize, and checking the result via status.conditions: PodResizePending (reason Deferred or Infeasible) or PodResizeInProgress. Deferred means the resize is held back due to insufficient node capacity right now; Infeasible means the request exceeds the node's maximum capacity and cannot be scheduled at all. In April 2026, v1.36 also graduated in-place resize for Pod-level resources to beta, so the scope keeps expanding.
Why Does "InPlaceOrRecreate" Still Recreate the Pod?
The first thing to check is the QoS class. As the official Kubernetes documentation states, a Pod's QoS class (Guaranteed / Burstable / BestEffort) is fixed at creation time and cannot be changed by a resize. A change that would make a Burstable container's requests equal its limits for both CPU and memory — effectively turning it into Guaranteed — cannot be done in-place.
An easy detail to miss is whether initial values are set at all. According to a practical setup guide, if a container has no requests/limits configured at all, the Pod is treated as BestEffort, and the moment VPA tries to set resources on it, the QoS class changes — forcing a recreation. If you want to use InPlaceOrRecreate, setting at least minimal requests/limits from the start is a prerequisite.
VPA's own behavior matters too. According to an explainer on the InPlaceOrRecreate mode, VPA attempts to patch via the /resize subresource, and falls back to eviction (recreation) under these conditions:
- The kubelet reports the resize as infeasible or errors out
- The resize stays
Deferredfor more than 5 minutes PodResizeInProgressstays unresolved for more than 1 hour- The proposed resource change would alter the Pod's QoS class
The same article points out another easy-to-miss detail: a successful /resize does not call the Eviction API, so PodDisruptionBudget is never consulted for that patch. If you think your PDB is protecting you, a successful in-place resize bypasses that check entirely.
The K3s/Edge-Specific Trap — Things Get Complicated with cgroup Drivers
Running on K3s adds another layer of complexity: the cgroup version and driver. In-Place Pod Resize and Pod-Level Resources assume the node is running cgroup2 (devopscube.com's verification guide also lists this as the first thing to check).
Since a certain version, K3s defaults to the systemd cgroup driver instead of cgroupfs whenever systemd is detected. This change improves compatibility with cgroup v2, but on setups running K3s inside Docker, or on nodes with older OS images, there are reports of startup failures caused by the switch to the systemd driver, such as the "kubepods" root container not being found. On the edge-device side, there are also documented cases of K3s agents failing to start when stuck on cgroup v1.
Edge K3s nodes deployed in factories and stores often have their OS images updated infrequently and end up running cgroup v1 for a long time. Enabling In-Place Pod Resize or VPA's InPlaceOrRecreate on such nodes means any Pod-Level-Resources feature is effectively off the table from the start. If "the same YAML worked on the cloud cluster but not on the edge cluster," the cgroup version and driver should be the first thing you suspect.
With Kubo On-Premise, the K3s distribution itself is configured with the cgroup v2 + systemd driver combination as a prerequisite, removing the need to fix up individual edge nodes by hand. If you manage your own OS images, this mismatch is the single most common place things go wrong.
In Practice — Setting resizePolicy and Verifying with kubectl
Start by declaring resizePolicy explicitly on the container:
resources:
requests:
cpu: "250m"
memory: "256Mi"
limits:
cpu: "500m"
memory: "512Mi"
resizePolicy:
- resourceName: cpu
restartPolicy: NotRequired
- resourceName: memory
restartPolicy: RestartContainer
Letting CPU resize with NotRequired while keeping memory on RestartContainer lets applications like JVM-based services safely recompute heap sizing when needed. DevOpsCube's guide also recommends using RestartContainer for memory changes.
Verification is a matter of kubectl alone:
kubectl patch pod <pod-name> --subresource=resize -p \
'{"spec":{"containers":[{"name":"app","resources":{"requests":{"cpu":"400m"}}}]}}'
kubectl get pod <pod-name> -o jsonpath='{.status.conditions}'
PodResizeInProgress means the resize is in progress; PodResizePending with Deferred means the node is short on resources right now; Infeasible means the current node simply can't accommodate the request. For downsizing memory, if current usage exceeds the new limit, PodResizeInProgress can get stuck at Error — so it's safer to default to RestartContainer for any memory reduction.
Conclusion — Don't Design Around the Assumption of "No Restart"
In-Place Pod Resize did reach GA in v1.35, and VPA's InPlaceOrRecreate mode is now solid enough for production use. But it's a feature that skips the restart when conditions are met — not a guarantee that a restart will never happen. Fixed QoS classes, whether initial requests/limits are set, and the cgroup version and driver — get these three things wrong, and a Pod will get recreated exactly when you didn't expect it.
On a managed K3s environment, the cgroup v2 + systemd driver combination and other node-level prerequisites are already taken care of. Kubo, built on K3s, lets you try VPA and In-Place Pod Resize without worrying about these low-level prerequisites.
If you're reconsidering your VPA operational design altogether, Kubo Cloud's AI-Driven Deployment lets you start from a working configuration before getting into the weeds of resource settings and cgroup prerequisites in YAML. Compared to running the same verification on EKS or AKS, being able to try a full-spec Kubernetes starting at around ¥48,000/month is also worth factoring into the decision.
If you'd like to verify this behavior in a pre-configured environment before rolling a new feature into production, feel free to reach out via Contact Us.