Kubernetes Vertical Pod Autoscaler Management

Kubernetes Vertical Pod Autoscaler Management is the operational practice of deploying, configuring, and maintaining VPA objects across a cluster's workloads to keep resource requests and limits aligned with actual observed consumption, addressing the common problem of manually specified resource values that drift out of sync with a workload's real usage as it evolves.

VPA Components

Recommender, Updater, and Admission Controller

VPA consists of three cooperating components: the Recommender observes historical resource usage and computes suggested requests and limits, the Updater identifies pods whose current resources differ significantly from the recommendation and evicts them for recreation, and the VPA admission webhook applies the recommendation to pods at creation time so evicted pods come back with updated values.

kubectl get pods -n kube-system -l app=vpa-recommender
kubectl get pods -n kube-system -l app=vpa-updater
kubectl get pods -n kube-system -l app=vpa-admission-controller

The VerticalPodAutoscaler Object

A VerticalPodAutoscaler object ties these components to a specific target, similarly to how an HPA references its scale target, but drives resource sizing rather than replica count.

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: batch-worker-vpa
  namespace: analytics
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: batch-worker
  updatePolicy:
    updateMode: "Auto"

Update Modes

Off: Recommendations Only

updateMode: "Off" runs the Recommender continuously but never applies its output automatically, letting operators review suggested values and adjust manifests manually — the lowest-risk mode, useful for initially understanding a workload's actual resource profile before granting VPA any automatic control.

kubectl describe vpa batch-worker-vpa
# Recommendation: Target: cpu: 350m, memory: 420Mi

Initial: Apply Only at Pod Creation

updateMode: "Initial" applies the current recommendation only when a pod is first created, never modifying already-running pods, which avoids mid-lifecycle disruption while still ensuring new pods (from a rolling update or scale event) start with reasonably accurate resource values.

Auto: Continuous Automatic Resizing

updateMode: "Auto" continuously applies updated recommendations, evicting and recreating pods whose current resource allocation deviates meaningfully from the latest recommendation — the most hands-off mode, but one that introduces periodic, VPA-driven pod restarts as an ongoing operational characteristic of the workload.

Configuring Resource Policies

Bounding Recommendations Per Container

resourcePolicy.containerPolicies lets specific containers be excluded from VPA management, or bounded with minAllowed/maxAllowed values, preventing the Recommender's suggestions from pushing a container's resources outside an organizationally acceptable range regardless of observed usage.

spec:
  resourcePolicy:
    containerPolicies:
    - containerName: sidecar-proxy
      mode: "Off"
    - containerName: app
      minAllowed:
        cpu: 100m
        memory: 128Mi
      maxAllowed:
        cpu: 4
        memory: 8Gi

Coordinating With Other Autoscaling Mechanisms

Avoiding Conflict With HPA on the Same Dimension

Running VPA in Auto mode against CPU on the same workload an HPA scales based on CPU utilization creates a feedback loop, since VPA changing the CPU request alters the denominator of the HPA's utilization calculation; a common resolution scopes VPA to memory management only, leaving CPU-based replica scaling to the HPA exclusively.

Interaction With Cluster Autoscaler

Because VPA-driven resource increases can push a node's aggregate requests beyond its allocatable capacity, triggering Cluster Autoscaler activity, VPA management should account for the downstream node-provisioning implications of its recommendations, particularly for workloads with many replicas where even a modest per-pod increase compounds significantly.

Operational Practices

Starting in Off Mode Before Enabling Auto

Deploying a new VPA in Off mode first, observing its recommendations against actual workload behavior over a representative period, and only then switching to Auto avoids an initial recommendation based on limited historical data causing an unexpectedly disruptive resize immediately upon enabling automatic mode.

Monitoring Eviction Frequency

Tracking how often the VPA Updater evicts pods for a given workload reveals whether Auto mode is producing an acceptable level of disruption or whether the workload's usage pattern is too volatile for continuous automatic resizing, in which case Initial mode may be a better fit.

kubectl get events --field-selector reason=EvictedByVPA