KEDA

What it is

KEDA (Kubernetes Event-Driven Autoscaling) extends the Kubernetes Horizontal Pod Autoscaler to scale workloads based on external event sources instead of just CPU/memory. It watches things like Kafka consumer lag, SQS queue depth, Azure Service Bus, Prometheus query results, cron schedules, and 60+ other "scalers," then feeds that data into HPA as custom metrics. The headline feature most teams actually want: scale-to-zero for event-driven workloads that don't need to run when there's nothing to process.

It runs as an operator (KEDA operator + metrics adapter) inside your cluster, doesn't replace HPA, and doesn't require you to rewrite your deployment manifests beyond adding a ScaledObject or ScaledJob CRD.

Who builds it and why

CNCF graduated project, originally started by Microsoft and Red Hat engineers to solve serverless-style autoscaling on plain Kubernetes without vendor lock-in to something like Azure Functions or AWS Lambda. It's now maintained by a broad contributor base (494 contributors) with no single vendor controlling the roadmap — governance sits with CNCF, and maintainers come from multiple companies including Microsoft, Red Hat, and independent contributors who run it in production.

The motivation is straightforward: Kubernetes HPA only understands resource utilization out of the box, and most real workloads (queue consumers, stream processors, batch jobs) scale on backlog, not CPU. KEDA fills that gap without forcing you into a proprietary autoscaler.

Production readiness signal

Strong. CNCF graduated status alone means it's cleared a bar for governance, security process, and adoption diversity. The GitHub signal backs it up: 10,331 stars, 494 contributors, and a commit as recent as July 2026 — this is actively maintained, not coasting. License is Apache-2.0, no ambiguity there. Current release v2.20.1 indicates a mature, iterating codebase rather than a project still finding its API.

It's used widely enough in production that most major managed Kubernetes offerings (AKS, EKS via add-ons, GKE) either bundle it or officially support installing it. If you're running Kafka, RabbitMQ, or cloud queue-based workloads on Kubernetes, there's a good chance KEDA is already running somewhere in your organization whether you know it or not.

Who should use this

• Teams running event-driven or queue-based workloads (Kafka consumers, RabbitMQ workers, SQS/Service Bus processors) who need to scale on backlog, not CPU.
• Anyone wanting scale-to-zero for cost savings on bursty or intermittent workloads without going full serverless.
• Platform teams standardizing autoscaling across many custom metric sources without writing bespoke metrics adapters for each one.
• Organizations already invested in Prometheus who want to scale on arbitrary PromQL queries.

Who should NOT use this

• If your workloads only ever need CPU/memory-based scaling, standard HPA is simpler — don't add KEDA's operational overhead for no reason.
• Teams with zero tolerance for extra cluster components: KEDA adds an operator, a metrics server, and CRDs that need upgrading and monitoring like anything else.
• Shops needing sub-second scaling reactions — KEDA's polling-based model (default intervals) isn't built for that latency; you'll want something closer to the event source itself.
• If you're deep in a single cloud and already happy with that provider's native event-driven autoscaling (e.g., Lambda, Azure Functions Consumption plan) and don't need Kubernetes portability, KEDA is extra complexity for no clear win.

Alternatives

• Kubernetes HPA (native) — fine for CPU/memory-only scaling, no external event source support.
• Knative — broader serverless platform with its own autoscaling, more opinionated and heavier to adopt than KEDA alone.
• Cloud-native autoscalers (AWS Application Auto Scaling, Azure Functions scaling) — tightly integrated with their ecosystem but lock you into that cloud.

Pricing

Fully open source, Apache-2.0. No paid tier, no enterprise edition gating features. Cost is purely your own operational overhead of running and maintaining it.