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
KEDA lets Kubernetes workloads scale down to zero replicas and activate when an event source has work, then uses Kubernetes’ Horizontal Pod Autoscaler (HPA) to scale active workloads up or down. It is “serverless” in the scaling-experience sense: KEDA still runs inside a Kubernetes cluster, and the cluster and its operator remain your responsibility.
What KEDA does—and what “serverless” means here
KEDA, the Kubernetes Event-driven Autoscaler, connects a Kubernetes workload to an event source and makes event-related metrics available to Kubernetes autoscaling. It works with the HPA rather than replacing it. The KEDA project describes it as a “Kubernetes-based Event Driven Autoscaler” on its official homepage.
Scaling to zero can reduce the number of running workload pods while a queue or other event source is idle. It does not remove the cluster: KEDA must be installed in a running Kubernetes cluster, and that infrastructure still needs to be operated. Calling the experience serverless describes how the workload responds to demand, not a guarantee that no infrastructure management is required.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →How KEDA and the HPA divide scaling work
KEDA separates activation from ordinary scaling. Its operator watches KEDA resources and manages the HPA associated with a target. When a workload has zero replicas, KEDA evaluates its configured event source and can activate the workload. Once active, the HPA uses metrics exposed through KEDA’s metrics API server to adjust replicas above one. The KEDA concepts documentation and scaling documentation describe this as activation from zero to one (and back) followed by scaling between one and N replicas.
#1 Best Overall
- Zero to one: KEDA’s event-source evaluation provides the activation signal.
- One to N, or N to one: the HPA uses metrics to manage the active replica count.
“Event-driven” does not mean instantaneous. At zero, activation depends on the relevant KEDA polling or event evaluation cadence. Above zero, changes depend on HPA metric checks, the Kubernetes controller-manager’s HPA sync interval, and configured scaling behavior. When planning latency and capacity, account for source/API limits and how quickly a new pod can begin consuming work.
Which Kubernetes workloads KEDA can target
KEDA’s supported resource patterns cover common long-running workloads as well as batch jobs. A ScaledObject connects a target to triggers; a ScaledJob responds to external metrics by creating Kubernetes Jobs. Custom resources can also be targeted when they expose Kubernetes’ /scale subresource.
| Resource pattern | How KEDA applies it |
|---|---|
| Deployment or StatefulSet | A ScaledObject associates the workload with one or more triggers and coordinates HPA-based scaling. |
| Custom resource | Can be targeted when the resource implements Kubernetes’ /scale subresource. |
| Batch processing | A ScaledJob creates Kubernetes Jobs in response to external metrics. |
These patterns do not make application-level processing guarantees. For a queue consumer, the application and event source still determine retry handling, ordering, dead-lettering, checkpoints, idempotency, and how work is divided among replicas. KEDA changes replica decisions; it does not make a consumer safe or correctly partitioned by itself.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
What to configure in a ScaledObject
A ScaledObject specifies its target and trigger or triggers. It can also set polling and cooldown intervals, minimum and maximum replicas, fallback behavior, and HPA behavior. Those settings depend on the KEDA release and the workload, so sample values should not be treated as universal production recommendations.
In the KEDA v2.21 ScaledObject specification, the default polling interval is 30 seconds and the default maximum replica count is 100. These are documented defaults for that version, not recommended values for every service. The specification also describes fallback when a scaler is in an error state, subject to supported trigger types.
For HPA-backed scaling above one replica, choose bounds and scale-up and scale-down behavior that match the workload. KEDA passes HPA behavior settings through its ScaledObject configuration, subject to the Kubernetes version’s supported API. Version details can change: the v2.21 reference notes that configurable HPA tolerance is beta in Kubernetes v1.34 and specifiable by default there.
How to plan a KEDA deployment
- Establish a Kubernetes cluster. KEDA is a cluster component, not a replacement for the cluster. It can be used with Kubernetes generally; Amazon EKS is one possible platform, and AWS provides guidance for using KEDA on EKS.
- Install KEDA and configure kubectl. Follow the KEDA v2.21 setup guidance for your environment.
- Choose a scaler that matches the event source. Read that scaler’s prerequisites before deployment. Depending on the source, it may require particular credentials, identity configuration, metrics access, or other setup.
- Choose a ScaledObject or ScaledJob. Use a ScaledObject for supported scalable targets such as Deployments and StatefulSets; use a ScaledJob for event-driven job creation.
- Configure and apply the resource, then inspect it in the cluster. Verify that the trigger can be read, activation works at zero, and active scaling behaves as intended.
Not every integration is part of KEDA’s core installation. The setup documentation identifies some scalers as separate add-ons. It also describes an HTTP add-on for incoming HTTP traffic and labels it beta in the consulted v2.21 documentation; check the current documentation before relying on its availability or maturity.
Why CPU and memory alone cannot wake a zero-replica workload
CPU and memory scaling use Kubernetes Metrics Server and pod resource requests or limits. With no running pods, those resource metrics cannot independently signal that a workload should restart. KEDA’s CPU scaler documentation says CPU or memory can be combined with at least one additional non-CPU/non-memory scaler to provide activation when the minimum replica count is zero. If scale-from-zero is a requirement, configure an event-based activation signal rather than relying on CPU or memory alone.
When KEDA is a fit—and what to evaluate
KEDA is useful when a workload’s demand is represented by an event source or external metric, especially for workers that should be inactive when there is no work. Before adopting it, assess the actual signal and processing model, not just whether an integration exists.
- Can the event source indicate demand while the workload has no pods?
- How much backlog can build up before a new replica is ready, and how quickly can each replica consume work?
- What are the source’s API limits and the operational impact of polling?
- How should retries, ordering, dead-lettering, checkpoints, and duplicate delivery be handled?
- What replica bounds and HPA scale-up or scale-down behavior fit the workload?
For a workload that only needs conventional resource-based scaling while pods are already running, an ordinary HPA configuration may be sufficient. KEDA is most distinctive when scaling depends on event-source metrics or activation from zero.
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.
