HPA vs VPA: Why You Can’t Have Both (Without ScaleOps)

The Problem: You’re Already Late

It’s 9 AM on a Tuesday. Your taxi booking service sees the morning commute spike—same time every day, same shape, same traffic volume. Predictable as a clock.

But your Kubernetes cluster doesn’t know that.

Your users experience a 90-second latency bump. Some requests timeout. A few frustrated riders close the app and use a competitor. By the time your horizontal pod autoscaler (HPA) notices the spike and spins up new pods, the damage is done.

Here’s the thing: you know the spike is coming. Your ops team can predict it to the minute. Your historical metrics prove it. But HPA can’t.

Why? Because HPA has no memory.

How HPA Works (And Why It Fails)

Kubernetes’ Horizontal Pod Autoscaler uses a deceptively simple formula:

desiredReplicas = ceil(currentReplicas × (current metric / target metric))

The controller evaluates that formula every 15 seconds by default (via --horizontal-pod-autoscaler-sync-period in kube-controller-manager). That’s it. Pure math. No history. No pattern recognition. No prediction.

Here’s what happens in practice:

During those 90 seconds, your existing pods are drowning. Requests queue up. Latency explodes. Users see errors.

And that’s just the latency cost.

Prerequisite: HPA pulls CPU and memory metrics from the Kubernetes Metrics API, so Metrics Server (or an equivalent adapter) must be running. Without it, the control loop never sees utilization and pods never scale.

The VPA/HPA Death Spiral

Now imagine you’re also running Vertical Pod Autoscaler (VPA). VPA right-sizes CPU and memory requests based on actual usage. That sounds good—and it is. But when combined with HPA, it creates a documented anti-pattern that Kubernetes warns against.

Here’s why:

In vanilla Kubernetes, you have to pick one: right-sizing OR autoscaling. Not both.

This is why most teams either:

It’s a broken system.

The Opportunity: Predictable Traffic Has Patterns

But here’s what most ops teams miss: your traffic IS predictable.

Daily cycles. Morning commute spike. Lunch hour rush. Evening peak. Then overnight quiet. Week after week, the same shape repeats.

Weekly patterns. Weekdays differ from weekends.

Seasonal patterns. Holiday traffic looks different from regular traffic.

These patterns exist in your historical metrics right now. They’re just hidden in the noise.

What if your autoscaler could see them?

What if it could act 20 minutes before the spike, not 90 seconds after?

Predictive Scaling: Pattern Learning in Action

Here’s how predictive scaling works:

Day 1: Your cluster sees morning traffic spike at 9 AM, noon lunch peak, 6 PM evening rush. Same volume. Same shape.

Day 2: Your predictive autoscaler has learned the pattern. Less than 24 hours.

9:40 AM (20 minutes before the spike): No traffic yet. No metric trigger. But your autoscaler knows what’s coming. It patches minReplicas on your HPA. New pods spin up.

9:45 AM: 6 pods running, all ready, all correctly sized (no more “broken pods” with stale resource requests).

10:00 AM (the spike): Traffic arrives. Nothing changes. Latency stays flat. Your pods can handle it because capacity was already there.

Compare to vanilla HPA:

It’s not magic. It’s signal processing. Your autoscaler learns your traffic patterns and acts before spikes hit.

Real Impact: Numbers From the Demo

We tested this on a real workload—a taxi prediction model trained on 70 million NYC taxi trips. Real traffic. Real spikes. Real problems.

The pods are already there. They’re already sized right. When traffic arrives, your cluster handles it without breaking a sweat.

KEDA: Leading vs Lagging Metrics

If you’re using KEDA (event-driven autoscaling), here’s something important:

HPA’s default metrics—CPU and memory—are lagging indicators. By the time CPU spikes, your users are already waiting.

Leading indicators—queue depth, Kafka lag, orders pending—tell you work is coming before it hits your cluster. Much better signals.

KEDA makes it easy to scale on leading metrics. But KEDA is still reactive. Events land in the queue, KEDA notices, then pods spin up.

With predictive scaling, KEDA gets smarter:

Leading metrics, predictive timing, right-sized pods. That’s the full picture.

The Real Cost of Being 90 Seconds Late

Over a month, how many spikes miss those 90 seconds? If each one costs you even a tiny percentage of users (or microseconds of latency that compound), the cumulative impact is real.