Kubernetes VPA Recommendation Flow

Kubernetes VPA Recommendation Flow is the internal pipeline by which the Vertical Pod Autoscaler's Recommender component transforms historical resource usage observations into the specific request and limit values reported in a VerticalPodAutoscaler object's status, and, depending on update mode, ultimately applied to running or newly created pods. Understanding this flow clarifies why VPA recommendations behave the way they do, and how much historical data influences a given suggestion.

Collecting Usage History

The Recommender's Data Source

The Recommender continuously ingests container resource usage metrics, sourced either from the metrics-server (recent, short-term data) or from a configured history provider that can read further back — commonly Prometheus, when the Recommender is configured to use it for a longer usage history than the metrics-server alone retains.

--recommender.history-length=8d
--storage=prometheus
--prometheus-address=http://prometheus.monitoring:9090

Sampling and Aggregation

Usage samples are aggregated over time into a statistical model per container, rather than reacting to the single most recent data point, which smooths out short-term noise and produces a recommendation representative of sustained usage patterns rather than momentary spikes or dips.

Computing the Recommendation

Percentile-Based Target Selection

The Recommender computes its target recommendation using a high percentile (commonly around the 90th percentile) of observed usage rather than the average, ensuring the recommended request comfortably covers typical peak usage rather than only the median case, which would leave many observed periods under-provisioned.

Separate Requests for CPU and Memory

CPU and memory are modeled independently, since their usage patterns typically behave very differently — CPU usage often fluctuates significantly with request volume, while memory tends to grow more gradually and plateau, and the Recommender's statistical model for each resource type accounts for these distinct characteristics separately.

Multiple Recommendation Bounds

The Recommender produces not just a single target value but a lowerBound, target, and upperBound for each resource, reflecting a confidence range around the estimate; the target value is what gets applied under Auto or Initial modes, while the bounds provide context on how much the estimate might reasonably vary.

kubectl get vpa batch-worker-vpa -o jsonpath='{.status.recommendation.containerRecommendations}'

status:
  recommendation:
    containerRecommendations:
    - containerName: app
      lowerBound:
        cpu: 150m
        memory: 256Mi
      target:
        cpu: 300m
        memory: 384Mi
      upperBound:
        cpu: 600m
        memory: 512Mi

Applying Recommendations

Admission-Time Application

When a pod matching a VPA's target is created (or recreated by the Updater), the VPA admission webhook intercepts the request and mutates the pod's resource requests and limits to match the current recommendation, meaning the actual application point of a recommendation is always at pod creation, never a live in-place patch of an already-running pod's spec (except where in-place resize support is available).

The Updater's Role in Triggering Reapplication

For Auto mode, the Updater periodically compares each running pod's current resources against the latest recommendation and, if the deviation exceeds a configured threshold, evicts the pod so it is recreated — passing back through the admission webhook — with the updated values applied.

Recommendation Stability Over Time

Convergence With Accumulated History

Immediately after a workload starts (or after the Recommender itself restarts, since it does not necessarily persist its statistical model across restarts unless using a checkpoint mechanism), recommendations are based on limited data and may shift noticeably as more usage history accumulates; recommendations become more stable as the observation window fills out.

Checkpointing to Preserve History

VPA supports checkpointing its accumulated statistical model to VerticalPodAutoscalerCheckpoint objects, allowing the Recommender to resume from prior history after a restart rather than starting its estimation from scratch, which would otherwise temporarily degrade recommendation quality following any Recommender downtime.

kubectl get verticalpodautoscalercheckpoints -n analytics

Practical Implications

Allowing Sufficient Observation Time Before Trusting Recommendations

Because recommendation quality depends on accumulated usage history, reviewing recommendations against a workload's actual, representative traffic pattern over a full cycle (including any periodic peaks such as daily or weekly patterns) before switching to Auto mode avoids acting on a recommendation formed from an unrepresentative, short observation window.