KEDA — Kubernetes Event-Driven Autoscaling

What it is

KEDA (Kubernetes Event-Driven Autoscaling) is a CNCF-graduated project that extends the native Kubernetes Horizontal Pod Autoscaler (HPA) with event-driven triggers. Instead of scaling only on CPU or memory, KEDA lets you scale workloads based on queue depth, stream lag, cron schedules, database row counts, or metrics from 70+ sources.

KEDA is built for platform engineers, DevOps teams, and backend developers who run event-driven microservices on Kubernetes. If your workloads are bursty or idle most of the time, KEDA can scale them to zero when there is no work and spin them up within seconds when events arrive.

How it saves time or tokens

KEDA eliminates the need to write custom autoscaling controllers. Without KEDA, scaling a Kafka consumer based on consumer group lag requires a custom metrics adapter, a Prometheus query, and an HPA configuration. KEDA wraps all of that into a single ScaledObject YAML manifest. The result is fewer moving parts, less custom code to maintain, and faster iteration on scaling policies.

For cost optimization, KEDA's scale-to-zero capability means idle workloads consume no compute resources. In a multi-tenant cluster running dozens of event consumers, this can reduce node count significantly during off-peak hours.

How to use

1. Install KEDA via Helm into your cluster:

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

1. Define a ScaledObject that targets your Deployment and specifies triggers:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: kafka-scaler
spec:
  scaleTargetRef:
    name: consumer
  minReplicaCount: 0
  maxReplicaCount: 50
  triggers:
  - type: kafka
    metadata:
      bootstrapServers: kafka:9092
      consumerGroup: my-group
      topic: orders
      lagThreshold: '10'

1. Apply the manifest and KEDA handles the rest -- it creates an HPA under the hood, polls the trigger source, and adjusts replica count accordingly.

Example

Scale an AWS SQS consumer to zero when the queue is empty:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: sqs-scaler
spec:
  scaleTargetRef:
    name: sqs-worker
  minReplicaCount: 0
  maxReplicaCount: 20
  triggers:
  - type: aws-sqs-queue
    metadata:
      queueURL: https://sqs.us-east-1.amazonaws.com/123456/orders
      queueLength: '5'
    authenticationRef:
      name: aws-credentials

When queueLength exceeds 5 messages per pod, KEDA adds replicas. When the queue drains, pods scale to zero.

Related on TokRepo

• DevOps AI tools -- more tools for infrastructure automation and CI/CD
• Automation tools -- event-driven and workflow automation resources

Common pitfalls

• Setting minReplicaCount: 0 means cold starts. If your workload cannot tolerate startup latency, set the minimum to 1.
• KEDA polls trigger sources at a configurable interval (default 30s). For sub-second scaling, you need to tune pollingInterval and accept higher API call volume.
• Mixing KEDA ScaledObjects with manually created HPAs on the same Deployment causes conflicts. Let KEDA own the HPA entirely.