Kubernetes VPA Update Management

Kubernetes VPA Update Management is the operational discipline of controlling how and when the Vertical Pod Autoscaler's Updater component actually applies resource changes to running pods, covering eviction thresholds, disruption coordination, and the newer in-place resize capability that reduces or eliminates the need for pod recreation entirely.

How the Updater Decides to Act

Deviation Threshold for Eviction

The Updater does not evict a pod for every minor difference between current resources and the latest recommendation; it acts only when the deviation exceeds a configured threshold (a percentage difference in requested CPU or memory), avoiding constant, low-value churn in response to small recommendation fluctuations.

--updater-min-cpu-usage-quality-threshold=0.5

Respecting Minimum Replica Availability

The Updater evicts at most one pod from a workload at a time by default and coordinates with PodDisruptionBudget constraints, ensuring vertical resizing does not violate the same availability guarantees that protect against voluntary disruption during node maintenance or cluster scaling.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: batch-worker-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: batch-worker

In-Place Pod Resize

Avoiding Eviction Entirely

Newer Kubernetes versions support resizing a running pod's resource requests and limits in place, without requiring the pod to be evicted and recreated, provided the container runtime and kubelet support it and the resize does not require moving the pod to a different node (for instance, when the increase would exceed the current node's remaining allocatable capacity).

kubectl patch pod api-service-7d4f9 --subresource resize \
  --patch '{"spec":{"containers":[{"name":"app","resources":{"requests":{"memory":"512Mi"}}}]}}'

VPA Support for In-Place Updates

VPA's updatePolicy can be configured to prefer in-place resizing when supported, falling back to the traditional evict-and-recreate approach when an in-place resize is not possible (a resource decrease that would violate a QoS class boundary, for instance, or a resize that requires more capacity than the current node can provide).

spec:
  updatePolicy:
    updateMode: "Auto"

Managing Disruption From VPA-Driven Updates

Scheduling Updates During Low-Traffic Windows

For workloads where any disruption carries real cost, configuring update behavior to align with known low-traffic periods (through external scheduling of Auto mode activation, or by using Initial mode combined with planned rolling restarts) reduces the practical impact of VPA-driven changes compared to allowing the Updater to act at arbitrary times.

Coordinating With Rolling Deployments

Because a rolling deployment already recreates pods, VPA recommendations are naturally applied during the deployment's own pod creation without needing a separate eviction; workloads deployed frequently through normal release cadence often see VPA's Initial mode alone keep resources reasonably current without the additional disruption Auto mode introduces.

Monitoring Update Activity

Tracking Eviction Frequency and Cause

Reviewing events and Updater logs for how often and why pods are evicted for resizing reveals whether the current threshold and mode configuration produces an acceptable level of disruption for a given workload's tolerance, and highlights any container whose usage remains volatile enough to trigger frequent resizing.

kubectl get events --field-selector reason=EvictedByVPA -n analytics

Confirming In-Place Resize Success

When in-place resizing is expected, confirming through kubectl describe pod that a resize was actually applied without pod recreation (versus a fallback to eviction) verifies the feature is functioning as configured rather than silently reverting to the disruptive path for all updates.

kubectl get pod api-service-7d4f9 -o jsonpath='{.status.resize}'

Choosing the Right Update Strategy

Weighing Responsiveness Against Disruption

Auto mode with in-place resizing available offers the closest approximation to continuous, low-disruption right-sizing; without in-place resize support, Auto mode's eviction-based updates should be weighed against the workload's actual sensitivity to restarts, with Initial mode as a lower-disruption alternative when frequent recreation is undesirable.