Kubernetes VPA Setup: Vertical Pod Autoscaler Configuration

Kubernetes Vertical Pod Autoscaler (VPA) Setup: Optimize Resource Allocation

Your application steadily consumes more memory than allocated in requests? Or you overprovision resources with a 2x buffer and overspend on cloud? VPA (Vertical Pod Autoscaler) solves this: it automatically adjusts container requests/limits based on actual utilization, without manual manifest edits. Unlike HPA, which increases pod count, VPA changes the size of a single pod. This is critical for monoliths, stateful workloads, and batch jobs where horizontal scaling is impossible or inefficient. According to official VPA documentation, proper configuration reduces manual adjustments by 80% and cuts cloud resource costs by 30–40%.

We help configure VPA for your production environment to eliminate manual resource tuning and overspending. We assess current consumption, install components, and set boundaries for safe autoscaling.

The Primary Pain of VPA: Pod Restarts

In Auto or Recreate mode, VPA changes container resources by restarting the pod. Kubernetes cannot modify resources of a running container. Thus, each vertical scaling event causes a pod to terminate and restart with new requests/limits. For a single-replica production service, this means 5–10 seconds of downtime.

For workloads with multiple replicas (where restarting one pod is non-critical) or batch Jobs, Auto mode is safe. Off mode is the safest way to start: VPA only recommends, never applies. Review recommendations via kubectl describe vpa app-vpa, compare with manifests, adjust manually. Within 7–14 days, VPA collects histograms and provides accurate recommendations.

How to Install VPA in a Cluster?

VPA is not included in standard Kubernetes—it must be installed separately. Two main approaches:

Both options have been proven over years of practice—our experience shows Helm is more convenient for repeatable installations and automation via GitOps (e.g., ArgoCD or Flux). VPA deploys three components: recommender (analyzes metrics), updater (restarts pods), admission-controller (injects resources on pod creation).

VPA Modes: Off, Auto, Recreate

We recommend Auto mode for production only after collecting data in Off mode and verifying boundaries.

Configuring a VPA Object: Essential Fields

---
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: app-vpa
  namespace: production
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: app
  updatePolicy:
    updateMode: "Auto"
  resourcePolicy:
    containerPolicies:
      - containerName: app
        minAllowed:
          cpu: 100m
          memory: 128Mi
        maxAllowed:
          cpu: "4"
          memory: 4Gi
        controlledResources: ["cpu", "memory"]

minAllowed and maxAllowed are mandatory bounds for the recommender. Without them, VPA might suggest cpu: 50m (too low for JVM warmup) or memory: 8Gi (too high). Bounds are always necessary to avoid unrealistic values.

What to Do When VPA and HPA Conflict?

You cannot use VPA in Auto mode and HPA based on CPU/Memory on the same deployment simultaneously. They will fight: VPA changes requests, HPA calculates utilization relative to requests—result unpredictable. The correct combination: VPA on requests/limits, HPA on custom metrics (RPS, queue depth)—then they do not compete. Alternatively, VPA in Off mode as advisor + manual manifest adjustments. In any case, we configure both to work harmoniously.

Consider an example: using HPA based on RPS and VPA in Auto mode on the same deployment, VPA reduces requests under low load, the scheduler places more pods on a node, and HPA increases replicas when RPS rises. They work synergistically.

How to Configure VPA for a Java Application?

In our practice, we encountered a Java application started with requests.memory: 512Mi, but JVM after warmup consistently consumed 1.2GB. The container was not killed (limit higher), but the node experienced memory pressure due to incorrect requests—the scheduler thought the pod needed 512MB, but actual usage was 1.2GB.

VPA in Off mode collected consumption histograms over a week and recommended requests.memory: 1280Mi. After manual application, the scheduler correctly accounted for the pod when placing on nodes. Memory pressure disappeared, cluster stabilized. Result: 30% reduction in pod redistributions and 25% increase in placement density.

General recommendations: for Java, set minAllowed no less than 512MB memory (JVM warmup), maxAllowed with 20% headroom above expected peak. Enable Prometheus metrics to track consumption.

What Our VPA Setup Service Includes

• Audit of current resource consumption and workload specifics.
• VPA installation in your cluster (bare-metal, cloud, on-prem).
• Creation of VPA objects for target workloads with correct bounds.
• Configuration of Off mode for data collection or Auto for automatic application.
• Resolving conflicts with HPA if present.
• Documentation on operation and recommendations for regular monitoring.
• Training your team: how to analyze VPA recommendations and apply changes.

Timelines and Pricing

Estimated timelines:

• VPA installation and object setup in Off mode for audit: from 1 day.
• Full configuration with Auto mode, bounds, staging testing, and documentation: from 1 to 3 days.

Pricing is determined individually after work scope analysis. We provide a project assessment—just reach out to us, and we'll find the optimal solution. We guarantee quality and offer post-deployment support.

Why Trust Professionals with VPA Setup?

We have 5+ years of production Kubernetes administration experience, with dozens of successful deployments. Our engineers hold certifications (CKA, CKAD). We don't just install VPA; we integrate it with observability (Prometheus, Grafana) and GitOps workflows so you have a transparent view of consumption and can quickly respond to changes.

Get a consultation on VPA setup—we'll assess your cluster. Contact us to discuss details.