In-Place Pod Resize: VPA Without the Restart

The article on VPA explains that its Auto mode always restarts a pod to apply a new requests recommendation. That behavior, historically true, changes with in-place pod resize: a feature letting you modify a running container’s requests and limits without ever recreating it.

What in-place resize actually changes

Before this feature, modifying a pod’s requests or limits required its full recreation: Kubernetes simply didn’t allow changing these fields on a pod already scheduled and running. In-place resize introduces a resize subresource that accepts this change directly, without going through pod deletion and recreation.

# Modifies a running container's requests/limits,
# without ever recreating the pod
kubectl patch pod my-app --subresource resize --patch \
  '{"spec":{"containers":[{"name":"app","resources":{"requests":{"cpu":"200m"}}}]}}'

What can resize without interruption, and what can’t

A CPU increase or decrease generally applies with no container restart, CPU being a compressible resource the kernel can readjust on the fly via cgroups. Memory is more constrained: an increase often works without a restart, but a decrease may require restarting the container depending on the defined resize policy, since already-allocated memory can’t be forcibly reclaimed without risking killing the process.

# The resize policy decides, resource by resource,
# whether a restart is required or not
resizePolicy:
  - resourceName: cpu
    restartPolicy: NotRequired
  - resourceName: memory
    restartPolicy: RestartContainer

What this changes for VPA

VPA can now leverage this capability via an InPlaceOrRecreate mode (in addition to Off, Initial, Auto already covered), which first attempts an in-place resize and only recreates the pod if the resize policy requires it (typically a memory decrease) or if the node technically can’t accommodate the change in place.

spec:
  updatePolicy:
    updateMode: "InPlaceOrRecreate"

This mode significantly reduces interruptions compared to the classic Auto mode, without eliminating them entirely: there remains a category of changes (memory decreases in particular) that still trigger a restart, depending on the defined policy.

What this doesn’t change

In-place resize never modifies the container image, nor any pod field beyond CPU/memory resources: an application code change still requires a classic deployment with pod recreation, via a normal rolling update. This feature stays strictly limited to sizing adjustments, not version updates.

Takeaway

In-place pod resize lets you modify a running container’s requests and limits without ever recreating it, an evolution that fixes VPA’s historical Auto mode limitation (systematic restart). A CPU increase generally applies with no interruption, a memory decrease can still require a restart depending on the per-resource resize policy. VPA’s InPlaceOrRecreate mode leverages this capability to reduce interruptions, without eliminating them entirely, a recent evolution worth knowing before sizing a vertical autoscaling strategy for a recent Kubernetes migration.