KEDA Tutorial: Event-Driven Autoscaling on Kubernetes

What is KEDA?

KEDA (Kubernetes Event-Driven Autoscaling) is a CNCF project that scales your Kubernetes workloads based on the events that actually drive load - the number of messages in a queue, consumer lag on a Kafka topic, the result of a Prometheus query, or even the time of day - rather than only CPU and memory.

Crucially, KEDA can scale to zero: when there is no work to do, your deployment drops to zero replicas and costs you nothing, then spins back up the moment events arrive.

How KEDA works

KEDA does not replace the Horizontal Pod Autoscaler - it drives one. You install KEDA into your cluster, then describe what to scale on with a ScaledObject:

• A scaler connects to an event source (Kafka, SQS, Prometheus, etc.) and reports a metric.
• KEDA creates and manages an HPA behind the scenes, feeding it that metric.
• When the metric crosses your threshold, the HPA adds replicas. When it drops to zero, KEDA removes the last replica too.

Installing KEDA

The simplest path is the official Helm chart:

helm repo add kedacore https://kedacore.github.io/charts
helm repo update
helm install keda kedacore/keda --namespace keda --create-namespace

Verify the operator is running:

kubectl get pods -n keda

Scaling a deployment on queue depth

Here is a ScaledObject that scales a worker deployment based on the number of messages in a RabbitMQ queue - one replica per 20 messages, up to 30 replicas:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: worker-scaler
spec:
  scaleTargetRef:
    name: worker
  minReplicaCount: 0
  maxReplicaCount: 30
  triggers:
    - type: rabbitmq
      metadata:
        host: amqp://guest:guest@rabbitmq.default.svc:5672/
        queueName: jobs
        mode: QueueLength
        value: "20"

Apply it and KEDA takes over scaling:

kubectl apply -f worker-scaler.yaml
kubectl get scaledobject

Scaling to zero

Because minReplicaCount is 0, when the jobs queue empties KEDA scales worker down to zero pods. The instant a message lands, KEDA activates the deployment back to one replica, and the HPA takes it from there based on queue depth. This is the headline feature: idle workloads cost nothing.

When to use KEDA

KEDA shines for event-driven and bursty workloads:

• Queue/stream consumers (RabbitMQ, Kafka, SQS) that should scale with backlog
• Jobs that only run on a schedule (use the cron scaler)
• Services where you want true scale-to-zero between traffic spikes

For steady, CPU-bound web services, the plain HPA is often enough - reach for KEDA when load is driven by an external signal the HPA cannot measure.