Recommended Free Tools
Kubernetes HPA can now scale workloads to zero—the old blanket claim that it cannot is out of date. In Kubernetes v1.37, scale-to-zero is a Beta feature enabled by default, provided the HPA has an object or external metric that remains available when the workload has no Pods. For queue consumers, compare native HPA with KEDA; for HTTP services that must wake on incoming requests, consider Knative Serving with KPA or the KEDA HTTP Add-on.
Choose by how demand reaches a zero-Pod workload
Scale-to-zero is not one interchangeable feature across these options. The key question is whether demand can be detected while the application has no Pods, and whether work can wait while a Pod starts.
As an Amazon Associate I earn from qualifying purchases.
| Option | Good starting point | How it detects or handles demand at zero | Key requirement or limitation |
|---|---|---|---|
| Native HPA on Kubernetes v1.37 or later | Queue consumers and other workloads with an independent object or external metric | The HPA continues to evaluate the object or external metric and can scale from zero. | CPU and memory resource metrics alone cannot wake a zero-Pod workload. Scale-to-zero is Beta in v1.37. |
| KEDA | Event-driven workers using a KEDA-supported or custom event-source trigger | A ScaledObject defines triggers and scaling behavior, working with Kubernetes autoscaling machinery. | Requires KEDA and suitable trigger configuration; verify the chosen scaler’s metric, authentication, and fallback behavior. |
| Knative Serving with KPA | HTTP-serving workloads that fit Knative’s serving and revision model | KPA scales based on traffic, with Knative Serving’s activation path supporting scale-to-zero. | Requires Knative Serving and KPA. Knative’s optional Kubernetes HPA mode does not support scale-to-zero. |
| KEDA HTTP Add-on | HTTP backends that need requests to activate a zero-scaled service | The add-on’s interceptor holds requests while KEDA scales the backend up. | Validate topology, request deadlines, cold-start tolerance, and add-on behavior in your setup. |
For durable queue or event work, start by checking whether native HPA’s metric path is already available; use KEDA when its trigger model fits better. For HTTP demand, evaluate whether Knative’s serving model or the KEDA HTTP Add-on fits your request path. This is a workload-pattern guide, not a benchmarked ranking: the projects address different demand paths, and the right choice depends on your metric availability, waiting tolerance, activation needs, and appetite for additional components.
What native HPA needs to scale from zero
Use a signal that survives the absence of Pods
With spec.minReplicas: 0, an HPA needs at least one object or external metric. CPU and memory resource metrics depend on running Pods, so they cannot, by themselves, tell the HPA to bring a zero-Pod workload back. Queue depth is a useful example of an independent signal: the queue can still contain work while its consumers are stopped.
#1 Best Overall
For an external metric, make the entire path work before relying on it: the metric source, adapter, and Kubernetes External Metrics API must expose the value the HPA queries. The Kubernetes v1.37 guide demonstrates exposing a Prometheus queue metric through a metrics adapter and advises checking the metric query before creating the HPA. A configured metric name is not enough if the API cannot discover or return its value while Pods are absent.
Start the workload through the HPA, not by treating zero as a pause
For the v1.37 flow, start the Deployment with at least one replica and let the HPA manage subsequent scaling. Manually setting the target to zero has historically meant “pause,” not “let the HPA resume it.” The controller identifies HPA-managed scale-to-zero using the ScaledToZero condition; inspect that condition when diagnosing why a zero-replica target is not being managed as expected.
Account for feature support and downscale timing
Kubernetes v1.37 marks HPAScaleToZero Beta and enables it by default. During a control-plane upgrade with version skew, both the API server and controller manager must support and enable the feature before creating HPAs with a zero minimum. If disabling it or downgrading, first raise the minimums and restore any workloads at zero replicas.
The Kubernetes v1.37 HPA guide documents a five-minute default downscale stabilization window. That is a controller setting, not a promise that a workload will reach zero five minutes after becoming idle; tune it to the workload and queue behavior rather than assuming scale-down is immediate.
When KEDA is a better fit than configuring HPA directly
KEDA centers configuration on event-source triggers. A ScaledObject can define triggers and scaling behavior for Deployments, StatefulSets, and custom-resource targets. In the current KEDA specification, minReplicaCount defaults to zero, so inspect the actual trigger and metric behavior rather than assuming every workload can wake reliably from zero.
Check the selected scaler’s supported source, authentication requirements, and behavior when the source or metrics are unavailable. KEDA documents fallback settings for supported triggers, but its described fallback does not cover CPU and memory triggers. Do not assume fallback applies to every scaler or failure mode.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.When HTTP traffic must wake the service
Knative Serving with KPA
Knative Serving’s default autoscaler is KPA, which supports scale-to-zero. The optional Knative mode that uses Kubernetes HPA does not. Knative’s scale-to-zero setting is global and requires KPA; current Knative documentation lists it as enabled by default.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitchesKnative also documents a 30-second default scale-to-zero grace period and a zero-second default last-pod retention period. These are configuration defaults, not estimates or guarantees for application startup time or request latency. The documented scale bounds default to a minimum of zero when scale-to-zero is enabled with KPA, and one otherwise; retention can be adjusted to reduce exposure to cold starts.
Best Value
KEDA HTTP Add-on
The KEDA HTTP Add-on provides an interceptor that holds requests while KEDA scales the backend. This gives the request path a way to accommodate an inactive backend; it is not a guarantee that every request will finish within its deadline. Validate how the interceptor is deployed in your topology, how long callers will wait, and what happens when startup takes longer than the request budget.
Why a Kubernetes Service alone is not an activation layer
The Kubernetes v1.37 announcement warns that Services do not buffer requests while no Pods are ready. It says request-driven workloads need a separate buffering layer. Knative’s documented autoscaling design includes an activator path, while the KEDA HTTP Add-on describes its request-holding interceptor. If clients send requests directly through a path with no ready backend and no buffering or activation component, those requests should not be assumed to wait safely for a Pod to start.
Make cold-start tolerance part of the decision
Scale-to-zero trades idle capacity for time spent detecting demand, scheduling a Pod, and starting the application. As Johannes Würbach explains in the Kubernetes v1.37 announcement, “The trade-off is cold-start time: the HPA must observe the metric, schedule a Pod, and start the application.” That is generally easier to accommodate when work is already waiting in a durable queue than when a live HTTP caller is waiting for a response.
- Queue or event consumer: establish how long jobs may wait, whether the queue is durable, and whether processing can recover cleanly after an idle period.
- HTTP-serving workload: decide which component activates the backend or holds requests, and set request deadlines with startup delay in mind.
- Any approach: validate that the demand signal is observable at zero replicas, that the metric or trigger path is healthy, and that downscale timing matches the workload.
- Operational ownership: compare the metric adapter and HPA configuration, KEDA and its scaler setup, or Knative Serving and its global autoscaling configuration against the components your team can operate.
There is no established cross-project benchmark here that makes one option universally faster, cheaper, or more efficient. Choose based on the demand signal, activation path, failure behavior, and waiting tolerance you can verify for your workload.
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.
