ReviseAlgo Logo

Autoscaling & Resource Management

Vertical Pod Autoscaler (VPA) — Right-Sizing Pods

Tuning resource allocation automatically over time.

Last Updated: June 15, 2026 • 15 min read

Introduction

While the Horizontal Pod Autoscaler (HPA) scales by adding more Pod replicas, the Vertical Pod Autoscaler (VPA) right-sizes pods by dynamically adjusting their CPU and Memory requests and limits.

VPA analyzes the actual resource consumption of your containers over time and automatically adjusts their allocations, ensuring applications have exactly what they need without wasting cluster compute.

Why It Matters

Configuring requests and limits manually is often guesswork. Developers regularly over-provision resources (requesting 2 cores when a container uses 0.1 cores) to avoid crashes, which leads to high cloud bills. Conversely, under-provisioning leads to Out-Of-Memory (OOM) kills. VPA eliminates this dilemma.

Real-World Analogy

Think of VPA like tailoring clothes for a growing child. Instead of buying a massive adult-sized coat that they will trip over (over-provisioning) or forcing them to wear a tight coat that will rip open (OOM killed), you measure them periodically and adjust their clothing sizes as they grow (vertical scaling).

How It Works

VPA operates in four distinct update modes:

  • Off: VPA only calculates recommendations and saves them in the VPA resource status. It does not apply changes. Safe for production auditing.
  • Initial: VPA assigns resource requests/limits only during pod creation, and does not alter running pods.
  • Recreate: VPA evicts running pods if their recommended resources are significantly different, and recreates them, applying the recommendations at startup.
  • Auto: Currently equivalent to Recreate. VPA restarts running pods to apply changes. In the future, it may support in-place resource updates.

Internal Architecture

VPA consists of three micro-services working together inside the cluster:

  • Recommender: Monitors historical and real-time resource utilization (via Prometheus or Metrics Server) and calculates recommended resources using an exponential decay algorithm that favors recent usage peaks.
  • Updater: Scans active pods and evicts those whose current requests are out of sync with recommendations, respecting PodDisruptionBudgets (PDBs).
  • Admission Controller (Mutating Webhook): Intercepts pod creation requests. If a VPA matches the pod, the controller replaces the resource requests and limits in the pod manifest with the recommended values.

Visual Explanation

Loading diagram…

Practical Example

Here is a Vertical Pod Autoscaler configuration running in Auto mode targeting a deployment named data-indexer:

Common Mistakes

  • HPA-VPA Conflict: Deploying HPA (scaling on CPU/Memory utilization) and VPA (Auto mode) on the same workload. The VPA will see high CPU, increase requests; HPA will see utilization fall, scale down replica counts; VPA will then scale requests down. They enter a feedback loop. Use them together only if HPA is scaling on custom metrics (like HTTP queue length).
  • Single Replica Disruption: Setting updateMode: "Auto" for workloads with only 1 replica. The pod will be terminated to apply modifications, causing downtime.
  • No Maximum Resource Cap: Omitting the maxAllowed parameter. If the application has a memory leak, VPA will continually increase memory allocation recommendations, eventually consuming all cluster resources.

Quick Quiz

Q1: Which VPA component is responsible for terminating pods that are running with outdated resource configurations?

A) Recommender

B) Updater

C) Admission Controller

D) Kube-Scheduler

Answer: B — The VPA Updater identifies pods that need resource adjustment and evicts them to trigger a recreation cycle.

Q2: How does VPA apply the new resource requests and limits to a pod if it is set to "Auto" mode?

A) It updates the resource settings live in-place without restarting the pod.

B) It intercepts the pod recreation flow via a mutating admission webhook to write the values.

C) It directly modifies the worker node's Docker configuration file.

D) It updates the master deployment manifest stored in git.

Answer: B — When the Updater evicts the pod, the controller manager recreates it. During creation, the VPA Mutating Admission Webhook intercepts the request and injects the new resource limits/requests.

Scenario-Based Challenge

Production Scenario:

You run an analytics service that experiences high CPU spikes during monthly reports generation. You want to use VPA to right-size it, but you cannot afford any eviction-induced restarts during office hours. How do you configure VPA?

View Solution

To achieve this, configure the VPA in Initial mode or Off mode:

1. If you configure updateMode: "Initial", VPA calculates the recommended resources over time and only applies them when the pods are created/restarted for other reasons (e.g. CI/CD deployments). It will never evict a running pod.
2. Alternatively, set updateMode: "Off", which serves as a monitoring-only tool. You can then run a weekly cronjob to inspect the VPA recommendations and apply them manually during scheduled maintenance windows.

Debugging Exercise

Broken Configuration:

You configured HPA and VPA to manage the same deployment. Both are scaling on CPU utilization. Your pods are oscillating between scale-out (many small pods) and scale-up (few large pods), causing cluster instability:

View Debugging Steps & Fix

The Problem: When CPU load spikes, VPA responds by increasing the container requests. This decreases the percentage CPU utilization (since request size is larger), which fools the HPA into scaling down the replica count. This in turn spikes CPU load per pod, leading to a loop of restarts and capacity adjustments.

The Fix: Restructure the configuration to partition responsibilities. Either:
1. Use VPA for Memory recommendations and HPA for CPU scaling:


2. Or configure HPA to scale on custom application metrics (e.g. active HTTP connections) instead of CPU/Memory resource metrics.

Interview Questions

1. Conceptual: What are the main differences between HPA and VPA, and when should you choose one over the other?

HPA scales pods horizontally by adjusting the replica count (adding/removing pods), which is ideal for stateless applications that scale out easily under user-traffic fluctuations. VPA scales pods vertically by adjusting their resources (CPU/Memory limits and requests), which is ideal for stateful workloads (like databases) or singletons that cannot be scaled horizontally, or to run as a development auditing tool to determine initial resource configurations.

2. Technical: Explain the step-by-step lifecycle of a Pod replacement when VPA is set to updateMode: "Auto".

The flow is:
1. VPA Recommender records resource usage metrics and calculates recommendations.
2. VPA Updater notices a pod is running with resources that deviate from the recommendation.
3. The Updater evicts the pod by sending a delete command.
4. The parent controller (e.g. Deployment) notices a replica is missing and submits a request to the API Server to create a new pod.
5. The VPA Mutating Admission Webhook intercepts this creation request, reads the VPA recommendations, overrides the CPU/Memory spec, and returns the modified pod manifest.
6. Kube-scheduler routes the updated pod definition to a node with sufficient capacity to accommodate the new request.

Production Considerations

In production, run VPA in Off or Initial mode first to analyze recommendations safely before enabling Auto mode. Ensure all workloads targeted by VPA are backed by multiple replicas and have PodDisruptionBudgets (PDBs) configured to protect against cascading outages when VPA evicts pods to resize them.