Autoscaling

Skyhook supports three complementary autoscaling strategies for your services, all configurable per environment from the same settings page:

• Horizontal Pod Autoscaler (HPA) — scale the number of pod replicas up and down based on CPU or memory usage
• Vertical Pod Autoscaler (VPA) — automatically adjust the CPU and memory requests of individual pods to match real usage
• KEDA — event-driven autoscaling that scales on queue depth, message rate, or any metric HPA can’t target, including scale-to-zero

Open any service and navigate to Settings → Scaling to see all three sections in one place. Each section has its own per-environment configuration — you can run HPA in production and leave it off in dev, or enable VPA only on a specific customer environment.

​

Horizontal Pod Autoscaling (HPA)

HPA adjusts the number of pod replicas in response to CPU and memory load. Use it when:

• Your workload can safely scale horizontally (stateless or shared-state via cache/db)
• Traffic varies predictably or spikily over time
• You want to trade cost for capacity — more pods when busy, fewer pods when idle

​

Fields

​

Vertical Pod Autoscaling (VPA)

VPA watches real CPU and memory usage of your pods and automatically adjusts their requests (and optionally limits) to match. Use it when:

• You don’t know what resource requests to set and want data-driven recommendations
• Your workload has variable per-pod cost but a stable replica count
• You want to fix over-provisioning (paying for reserved capacity you never use) or under-provisioning (OOMKills, CPU throttling)

​

Update Modes

VPA has several update modes that control how aggressively it applies its recommendations: The older Auto mode is deprecated and now aliases to Recreate.

​

Per-container resource policies

VPA can be scoped per container — useful for multi-container pods where you want to control the main app but leave sidecars alone. For each container you can set:

• Minimum CPU and memory — lower bounds VPA won’t go below
• Maximum CPU and memory — upper bounds VPA won’t exceed
• Controlled resources — whether VPA manages CPU only, memory only, or both

​

VPA + HPA together

HPA and VPA can both be enabled on the same workload, but not on the same resource. The supported pattern is:

• HPA on CPU — HPA scales the replica count based on CPU utilization
• VPA on memory — VPA adjusts memory requests based on observed usage

Having both target CPU creates a feedback loop where VPA shrinks requests and HPA scales in, then traffic grows and both fight.

​

KEDA Event-Driven Autoscaling

KEDA scales on external signals: queue depth, message rate, cron schedules, Prometheus metrics, database row counts — anything KEDA has a scaler for. Use it when HPA’s CPU/memory signals don’t describe what you actually care about. KEDA also supports scale-to-zero — you can set minimum replicas to 0 and the workload will spin down completely when idle, then spin back up when the first event arrives.

​

Fields

​

Best practices

​

Start with HPA

If you’re unsure which to use, start with HPA on CPU or memory — it’s the simplest, most battle-tested option, and most workloads scale fine on resource utilization alone.

​

Use VPA for right-sizing, not autoscaling

VPA’s real value is finding the right resource requests. Run it in Off or Initial mode for a few weeks, look at the recommendations via the FinOps Efficiency page, and apply the right numbers manually or via Recreate mode once you’re confident.

​

KEDA for queue-based workloads

If your service processes messages from a queue, KEDA scaling on queue depth is almost always better than HPA on CPU — CPU usage lags behind queue growth, but queue depth is a leading indicator.

​

Test with load

After enabling any autoscaler, generate realistic load (not a simple ramp) and verify that scale-up and scale-down happen when you expect. Tune the target utilization or minimum replicas based on what you see.

​

Troubleshooting