Recommended Free Tools
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Choose HPA when adding or removing equivalent pods can meet changing demand, KEDA when event backlog or scale-to-zero activation is central, and VPA when the resources assigned to each pod need adjustment. KEDA commonly uses HPA for scaling from one replica upward; VPA changes a different variable—pod resource requests and, depending on configuration, limits. There is no documented universal performance or cost winner: measure each candidate against the same workload and service constraints.
What changes when each autoscaler acts?
The key distinction is whether the workload needs more copies, event-driven activation, or better-sized pods. These mechanisms can affect one another, but they do not solve the same problem.
| Tool | Primary control | Useful when |
|---|---|---|
| Horizontal Pod Autoscaler (HPA) | Number of replicas for a supported scalable target | Work can be divided among equivalent pods and a metric signals demand or saturation. |
| Kubernetes Event Driven Autoscaler (KEDA) | Event-aware activation and scaling metrics; typically HPA manages one-to-many replica scaling | An event source such as a queue or stream best represents pending work, especially when idle replicas can be removed. |
| Vertical Pod Autoscaler (VPA) | CPU and memory resource requests and, depending on policy, limits assigned to pods | Per-pod resource sizing is the issue, or the workload does not benefit meaningfully from more replicas. |
Kubernetes describes horizontal scaling as deploying more pods in response to increased load, and vertical scaling as assigning more resources to pods already running. HPA is part of Kubernetes; VPA is a separately installed add-on. KEDA supplies event-driven integration rather than replacing HPA in every scaling phase.
How HPA responds to demand
HPA is a periodic control loop, not an instantaneous reaction. Kubernetes documentation lists a default controller sync period of 15 seconds; operators can change it with --horizontal-pod-autoscaler-sync-period. That interval is not a promise that adequate capacity will be ready in 15 seconds: metric collection, scheduling, image startup, and application readiness also affect the result.
#1 Best Overall
HPA can use resource metrics such as CPU, custom metrics, or external metrics. CPU utilization is interpreted relative to pod resource requests, so missing or unsuitable requests can make that signal unavailable or misleading. With multiple metrics, HPA calculates recommendations and uses the largest desired replica count. If a metric cannot be evaluated, that can prevent a scale-down when another metric recommends fewer replicas.
HPA defaults that affect a test
| Setting | Documented default | Effect to account for |
|---|---|---|
| Controller sync period | 15 seconds, per Kubernetes documentation accessed in 2026 | Sets the default cadence for evaluating scaling; it does not include pod startup or readiness time. |
| Scale tolerance | 0.1 (10%), per Kubernetes documentation accessed in 2026 | HPA skips scaling when the observed metric ratio is sufficiently close to the target. |
| Downscale stabilization window | 5 minutes, per Kubernetes documentation accessed in 2026 | The controller uses recent recommendations and selects the highest within the window to smooth scale-down. |
These are documented defaults, not universal values: configuration and cluster version matter. HPA also supports configurable scale-up and scale-down policies and stabilization behavior. When evaluating reaction time, record when demand changes, when the metric reflects it, when replicas change, and when the new pods become ready.
When KEDA is a better fit for event-driven work
For a queue-backed worker, queue depth or message arrival can describe unmet work more directly than CPU utilization. KEDA monitors configured event sources and exposes metrics for Kubernetes scaling. A common pattern is to allow the worker to fall to zero when there is no work, have KEDA activate it when an event appears, and use HPA for scaling from one replica to many.
That division matters: KEDA handles event-source integration and zero-to-one activation; HPA provides the one-to-many replica control in this pattern. The exact polling interval, activation threshold, scaler support, and event semantics depend on the selected KEDA scaler and its configuration. A metrics-cache option can reduce load on scalers, but KEDA documentation says it is not supported by CPU, memory, or cron scalers.
Rank #3
Measure whether the event signal predicts actual work, how long activation takes, the age and size of the backlog, processing throughput, and idle capacity. Scale-to-zero can save idle replicas, but it also means a new event may wait for activation and startup. Decide whether that wait fits the workload’s latency or completion objective rather than assuming zero replicas are always preferable.
When VPA is the right control
VPA’s recommender uses historical resource use, cluster availability, and runtime events such as out-of-memory conditions to recommend CPU and memory sizing. A metrics source such as Metrics Server must be available. Kubernetes documentation identifies VPA as stable since Kubernetes v1.25, but that does not mean it is bundled with every cluster or configured automatically.
VPA update modes and their operational impact
| Mode | Behavior | Operational consideration |
|---|---|---|
| Off | Records recommendations without applying them. | Useful for comparing recommendations with observed requests before allowing automated changes. |
| Recreate | Applies changes by evicting pods so the owning workload can create replacements. | Consider availability, disruption budgets, restart effects, and whether replacements can be scheduled. |
| InPlaceOrRecreate | Tries to resize in place and falls back to eviction when needed. | Behavior depends on Kubernetes capabilities, VPA version, and configuration. |
| InPlace | Documented as alpha in VPA 1.7.0, requiring Kubernetes 1.33 or later and specific feature gates. | Do not assume it is available or suitable without checking the target cluster’s version and gates. |
VPA documentation says the Auto update mode has been deprecated since VPA 1.4.0 and currently aliases Recreate. Treat that as a versioned behavior, and check the installed VPA release before relying on it.
Kubernetes identifies in-place pod vertical scaling as stable since Kubernetes v1.35, but its documentation also states that VPA does not support resizing pods in place as of Kubernetes v1.37. The Kubernetes platform feature and VPA’s integration with that feature are distinct; platform support alone does not establish that VPA will apply in-place changes.
Best Value
Choose by workload shape and the signal for unmet work
| Workload condition | Starting point | What to measure |
|---|---|---|
| Equivalent replicas can process work in parallel; demand varies with CPU, memory, request rate, or an application metric. | HPA | Metric-to-saturation relationship, target error, SLO violations, replica changes, and time until added capacity is ready. |
| Queue, stream, or other event backlog best describes pending work, and idle replicas can be removed. | KEDA with HPA for one-to-many scaling | Backlog depth and age, activation delay, processing throughput, idle capacity, and work completion delay. |
| The workload is not usefully parallelizable, or per-pod resource requests are poorly sized. | VPA, initially in recommendation-only mode when disruption is a concern | Recommended versus observed requests, scheduling outcomes, resource use, and any eviction impact. |
| More pods are requested than the available nodes can schedule. | Pod autoscaling plus a separate node-capacity mechanism | Pending-pod duration, node provisioning time, and whether new nodes make pods schedulable. |
Pod autoscaling and node autoscaling are separate capacity layers. Microsoft’s AKS guidance describes Cluster Autoscaler as adjusting node count in response to pending-pod demand and commonly pairing it with HPA. A pod autoscaler cannot by itself create node capacity when the cluster has nowhere to place new pods.
Can HPA and VPA run together?
They can be combined, but avoid competing control loops. Microsoft’s AKS guidance advises against applying HPA and VPA to the same CPU or memory metrics. Its suggested approaches include using VPA in recommendation-only mode or using distinct custom metrics for horizontal scaling. This is provider guidance; verify the interaction for the Kubernetes distribution, versions, metrics, and policies in the target cluster.
KEDA and HPA are commonly complementary rather than alternatives: KEDA supplies event-aware activation and metrics, while HPA handles the replica-count control for the one-to-many phase. VPA addresses per-pod sizing. Combining controllers still requires checking that their inputs and effects do not undermine one another.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsHow to compare autoscaling strategies quantitatively
The official documentation describes mechanisms and configuration, not an apples-to-apples benchmark showing that one option is universally faster, cheaper, or more efficient. To select a strategy for a particular service, run candidates against the same workload trace and constraints. The following are evaluation measures, not published results.
- Define the workload and objective. Use the same demand trace, event or request mix, starting state, SLO, and availability requirements for each candidate. Include both demand increases and decreases, plus idle periods if scale-to-zero matters.
- Record the environment. Document Kubernetes and autoscaler versions, metric sources, configuration, pod resource requests, node capacity, workload readiness time, and any feature gates. If calculating cost, state the pricing model, region, and accounting window.
- Choose the signal before testing. For HPA, select the resource, custom, or external metric that tracks saturation or unmet demand. For KEDA, identify the event source and the meaning of its backlog metric. For VPA, capture the current requests and the recommendations or applied values being evaluated.
- Measure service outcomes. Track latency or SLO violation rate, time from a demand change to adequate ready capacity, backlog depth and age, and time to complete work. Use the same observation windows for each candidate.
- Measure resource and operational effects. Record CPU and memory requested and used, replica and resource changes, scheduling failures, evictions, restarts, and other disruption. Calculate cost only from a disclosed pricing model and the same accounting period.
- Repeat representative scenarios. Include steady load, bursts, gradual ramps, and scale-down conditions where relevant. Report the configuration and results for each scenario; a single load shape cannot establish a universal winner.
A useful decision is the strategy that meets the workload’s SLO and availability constraints with acceptable response time, resource use, and operational disruption under the tested conditions. Keep the measured conclusion scoped to that workload, configuration, and environment.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
