Autoscaling from the signal that actually matters
Kubernetes Horizontal Pod Autoscaler is good at reacting to CPU and memory, but a worker can be idle while ten thousand messages wait in a queue. KEDA closes that gap. A ScaledObject connects a Deployment, StatefulSet, or compatible custom resource to an event source. KEDA asks that source for activity and metrics, starts the workload from zero when work appears, and feeds the resulting metric to the normal HPA for scaling above one replica.
The architecture is conservative in the right way. KEDA does not replace the HPA. Its operator owns zero-to-one and one-to-zero transitions and manages the HPA resource. A metrics API server exposes external metrics through the Kubernetes API. Admission webhooks reject several dangerous configurations, including two autoscalers targeting the same workload. The standard ReplicaSet still creates the pods. Teams can inspect familiar Kubernetes resources instead of trusting an entirely separate scheduler.
Coverage is the standout strength. The version 2.20 documentation contains 78 built-in scaler pages across queues, Kafka, cloud services, databases, Prometheus-compatible systems, CI runners, and other event sources. Authentication resources keep credentials out of each scaling rule and support Kubernetes secrets, environment variables, cloud workload identities, and external secret stores. If a source is missing, an external gRPC service can implement the scaler contract.
Two scaling models, with different responsibilities
ScaledObject is best for a long-running consumer that can process multiple events. When Kafka or RabbitMQ becomes active, KEDA wakes the deployment, and each replica pulls work according to the application's normal delivery semantics. Polling defaults to 30 seconds while the workload is at zero. Above one replica, the HPA also queries metrics on its own interval. The default five-minute cooldown only governs the return to zero; normal scale-down among running replicas belongs to the HPA.
ScaledJob is for long-running or isolated tasks where one Kubernetes Job should handle one detected event and exit. KEDA can cap job creation, retain histories, and choose among scaling strategies that account for running work. This is useful, but it does not create exactly-once delivery. The worker and event source still own acknowledgement, retry, timeout, poison-message, and idempotency behavior. A burst can also create many Jobs quickly, so cluster capacity and job startup cost need explicit limits.
KEDA offers useful guardrails for metric failures. A ScaledObject can fall back to a chosen replica count after repeated scaler errors, and version 2.20 adds a mode that lets a scaling formula route around failed triggers. Fallback does not support CPU or memory triggers and is unavailable for ScaledJobs. The idleReplicaCount setting effectively supports only zero because of HPA limitations. These details belong in design reviews, not just Helm values.
Installation is short, operation is a platform task
The Helm start is easy: add the KEDA chart repository and install into its own namespace. Operator Hub and released YAML manifests are also supported. KEDA has no outside database, but it adds three in-cluster components, custom resource definitions, aggregated external metrics, certificates, RBAC, and optional admission webhooks. Kubernetes control-plane networking must reach KEDA on the documented port, with a Google Cloud-specific path using another port.
Version compatibility needs discipline. The 2.20 deployment page requires Kubernetes 1.30 or newer, while the operations matrix lists 1.33 through 1.35 as the tested window for that line. Treat the tested matrix as the safe purchasing guide. Release 2.20 also moved event recording to events.k8s.io; custom restricted roles needed new permissions before upgrade. Several scaler settings were removed. Read the major-minor upgrade notes instead of letting an automated chart bump discover those changes.
The default permission model deserves special attention. KEDA watches every namespace and its cluster role can get, list, and watch secrets across the cluster. The operations guide documents WATCH_NAMESPACE and KEDA_RESTRICT_SECRET_ACCESS for reducing that scope. Use them where teams are separated, prefer workload identity over copied cloud keys, and decide carefully when a ClusterTriggerAuthentication is justified. Autoscaling needs credentials to query event sources, but it should not become an effortless route to unrelated secrets.
High availability is also qualified. Multiple operator replicas use leader election, so only one is active; standby replicas reduce failover time but do not increase throughput. The metrics service can have multiple pods, yet Kubernetes permits only one active external metrics provider of this kind in a cluster, and API-server aggregator routing is recommended for balancing. KEDA is mature, but upstream control-plane constraints remain.
Scalers must be tested like application code
A scaling formula can be syntactically valid and still represent the wrong backlog. Open issue #7936 reports that the Kafka scaler, with an earliest offset policy and no committed offset, can count messages already deleted by retention. The result is an idle deployment scaled out for work that no consumer can fetch. This affects a specific configuration, but it illustrates the larger rule: record real broker state beside KEDA's reported metric during acceptance tests.
Issue #7998 reports that active ScaledObject resources on 2.20.2 update lastActiveTime and patch status on every poll even when replicas and conditions do not change. At scale, that creates avoidable API and etcd churn. Platform teams with hundreds of scaling objects should monitor API writes, operator latency, metric errors, and source request rates, then tune polling and controller concurrency rather than accepting defaults blindly.
Health and the final choice
KEDA was pushed on August 14, 2026, and v2.20.2 shipped on July 31. GitHub showed 228 open issues and pull requests combined; separate searches found 190 issues and 38 pull requests. New scaler reports, release work, testing improvements, and dependency updates were active in August. Combined with CNCF graduated status, versioned documentation, governance, public meetings, and listed adopters, the evidence supports a healthy production project.
KEDA should be the first trial for Kubernetes event workers. Its abstractions are clear and its integration with HPA is sound. The winning rollout is incremental: one broker, one workload class, measured failure behavior, restricted permissions, then expansion after the reported metric matches reality.