Vertical Pod Autoscaling VPA 2025 Updates

This lesson explains the Kubernetes Vertical Pod Autoscaler (VPA), how it automates vertical scaling of Pod resources, and how it compares to the Horizontal Pod Autoscaler (HPA). You’ll find best practices, example manifests and commands, and guidance for when to use VPA, HPA, or both.

Manual vertical scaling (what you do today)

When you scale a workload vertically by hand, you update the Deployment’s Pod template to change container resource requests/limits. Typical steps:

Inspect the Deployment manifest to view current requests/limits.
Monitor real resource usage using the Metrics API (requires metrics-server).
Edit the Deployment; saving the change causes the Deployment controller to replace Pods with new ones using updated resource values.

Example commands:

# View pod resource usage (requires metrics-server)
kubectl top pod my-app-pod

# Edit the Deployment to change resource requests/limits
kubectl edit deployment my-app

Ensure the metrics-server is installed and healthy in the cluster. VPA and other resource-aware controllers rely on metrics from the Kubernetes Metrics API.

Note: Editing the Deployment’s Pod template will terminate existing Pods; the Deployment controller creates new Pods with the updated resources.

What VPA does

The Vertical Pod Autoscaler continuously observes container resource usage, computes recommended CPU and memory requests, and can apply those recommendations depending on configuration. VPA helps reduce over-provisioning by aligning Pod resource requests to actual usage.

A slide titled "Vertical Pod Autoscaler (VPA)" showing a small VPA box with dashed arrows to a blue "Observes metrics" box and a faded "Adds pod resources" box. It visually represents VPA observing metrics and adjusting pod resources.

Deploying VPA

VPA is not part of the core Kubernetes distribution. Install it from the autoscaler project manifests and confirm the VPA pods appear in the kube-system namespace. Install:

kubectl apply -f https://github.com/kubernetes/autoscaler/releases/latest/download/vertical-pod-autoscaler.yaml

Confirm components:

kubectl get pods -n kube-system | grep vpa
# Expected output:
# vpa-admission-controller-xxxx    Running
# vpa-recommender-xxxx            Running
# vpa-updater-xxxx                Running

VPA components and roles

You can think of the VPA as three cooperating parts. The table summarizes responsibilities:

Component	Role
Recommender	Collects historical and real-time usage metrics from the Metrics API and computes recommended CPU/memory requests.
Updater	Identifies Pods with suboptimal resource requests and evicts them (when configured) so the controller recreates Pods with updated requests.
Admission controller	Mutates Pod specs at creation time, applying recommender-suggested resource requests to newly created Pods.

Creating a VPA resource

VPA is a Kubernetes Custom Resource. Create it by applying a YAML manifest (there is no kubectl autoscale equivalent for VPA). Example VPA manifest:

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: my-app-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  updatePolicy:
    updateMode: "Auto"
  resourcePolicy:
    containerPolicies:
      - containerName: "my-app"
        minAllowed:
          cpu: "250m"
        maxAllowed:
          cpu: "2"
        controlledResources: ["cpu"]

Apply it:

kubectl apply -f my-app-vpa.yaml

VPA update modes (how recommendations are applied)

VPA has multiple update modes to control whether and how recommendations are enforced:

Off
- Only the recommender runs and records recommendations. The updater and admission controller do not apply changes. Use when you want visibility into recommended values without impacting running Pods.
Initial
- Admission controller applies recommended requests only at Pod creation time. Existing Pods are not evicted by the updater.
Recreate
- Updater evicts running Pods considered suboptimal; higher-level controllers recreate them with new requests. Admission controller also applies recommendations to new Pods.
Auto
- Current behavior is the same as Recreate (evicts & recreates). Intention is to support in-place resource adjustments in the future when the Kubernetes runtime and workloads support safe in-place resizing.

Using Recreate or Auto can cause Pod evictions and restarts. Ensure your controllers and Pod disruption budgets are configured to maintain availability during updates. Test in a non-production cluster first.

Inspecting VPA recommendations

View recommendations and policy details with kubectl describe:

kubectl describe vpa my-app-vpa

Sample (illustrative) excerpt:

Recommendations:
  Container: my-app
    Target: cpu: 1500m
    Uncapped target: cpu: 1.5
    Lower bound: cpu: 250m
    Upper bound: cpu: 2

VPA vs HPA — quick decision guide

Use this table to decide between VPA and HPA or when to combine them:

Concern	VPA (vertical)	HPA (horizontal)
Scaling action	Adjusts per-Pod resource requests/limits	Changes the number of Pod replicas
Best for	Stateful or resource-intensive apps (databases, JVMs)	Stateless services, web frontends, APIs
Reaction to spikes	Slower (Pod restarts or resizing needed)	Fast (adds replicas quickly)
Availability impact	May restart Pods to apply changes	Adds/removes Pods without restarting existing ones
Cost/efficiency	Reduces over-provisioning by matching resources to usage	Avoids idle resources by scaling out/in
Common strategy	Use to right-size each Pod	Use to handle load spikes

When combining: use VPA to recommend sane requests for Pods and HPA to scale the replica count. Test combinations and tune update modes and Pod Disruption Budgets to avoid conflict.

Summary and next steps

VPA automates vertical tuning of Pod resource requests; HPA changes the replica count.
Choose VPA for workloads that need tuned per-Pod resource allocation; choose HPA for fast horizontal scaling.
Combining both is powerful but requires careful configuration to avoid conflicting behavior.

Recommended resources:

Vertical Pod Autoscaler (autoscaler repo): https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler
Kubernetes HorizontalPodAutoscaler docs: https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/
Kubernetes Metrics Server: https://github.com/kubernetes-sigs/metrics-server

All set — try these steps in a test cluster to get hands-on experience with VPA and HPA.

Introduction

Core Concepts

Scheduling

Logging & Monitoring

Application Lifecycle Management

Cluster Maintenance

Security

Storage

Networking

Design and Install a Kubernetes Cluster

Install "Kubernetes the kubeadm way"

Troubleshooting

Helm Basics (2025 Updates)

Kustomize Basics (2025 Updates)

Other Topics

Mock Exams

Vertical Pod Autoscaling VPA 2025 Updates

Manual vertical scaling (what you do today)

What VPA does

Deploying VPA

VPA components and roles

Creating a VPA resource

VPA update modes (how recommendations are applied)

Inspecting VPA recommendations

VPA vs HPA — quick decision guide

Summary and next steps

Watch Video

Practice Lab

​Manual vertical scaling (what you do today)

​What VPA does

​Deploying VPA

​VPA components and roles

​Creating a VPA resource

​VPA update modes (how recommendations are applied)

​Inspecting VPA recommendations

​VPA vs HPA — quick decision guide

​Summary and next steps

Watch Video

Practice Lab

Manual vertical scaling (what you do today)

What VPA does

Deploying VPA

VPA components and roles

Creating a VPA resource

VPA update modes (how recommendations are applied)

Inspecting VPA recommendations

VPA vs HPA — quick decision guide

Summary and next steps