How KEDA Scales on Events
How KEDA Scales on Events
KEDA (Kubernetes Event Driven Autoscaling) installs CRDs and two components: the keda-operator, which reconciles ScaledObject resources, and the keda-metrics-adapter, which serves metrics HPA can consume. For each ScaledObject the operator creates a companion HorizontalPodAutoscaler pointing at its own adapter.
The adapter queries the external system — Kafka consumer lag, SQS queue depth, cron schedules, Prometheus — on spec.pollingInterval (default 30s). When queue depth exceeds the threshold KEDA scales up; after spec.cooldownPeriod (default 300s) with no traffic it scales the workload down, possibly to minReplicaCount: 0.
Writing a ScaledObject
Writing a ScaledObject
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata: { name: orders-worker }
spec:
scaleTargetRef: { name: orders-worker }
pollingInterval: 15
cooldownPeriod: 120
minReplicaCount: 0
maxReplicaCount: 20
triggers:
- type: aws-sqs-queue
metadata:
queueURL: https://sqs.eu-west-1.amazonaws.com/123456789012/orders
queueLength: "5"
awsRegion: eu-west-1
authenticationRef: { name: sqs-trigger-auth }
TriggerAuthentication (namespaced) or ClusterTriggerAuthentication pulls secrets/keys from a Secret or environment so credentials never live in the ScaledObject. Per-trigger activation values set the queue depth at which scaling starts.
Pitfalls and Interview Angles
Pitfalls and Interview Angles
Cold-start latency. Scale-from-zero is bounded by polling interval plus pod scheduling, image pull, and app warm-up — set pollingInterval low for latency-sensitive workers and keep images node-cached.
Premature scale-to-zero. The default 300s cooldown kills workers between bursts; raise it or set minReplicaCount: 1 for stateful consumers holding partitions.
Conflicting HPAs. KEDA owns an HPA for the target — do not create another HPA on the same Deployment.
Interview angle: walk the chain ScaledObject → operator → companion HPA → metrics adapter → external scaler, name a trigger you have used, and explain how scale-to-zero still drains work safely.
Quiz
1. What does the keda-operator create for each ScaledObject?
2. A worker keeps getting killed between SQS bursts. Which field do you raise?
3. Where should SQS credentials for a trigger live?
Flashcards
Question
ScaledObject
Click to reveal answer
Answer
KEDA CRD binding a workload (scaleTargetRef) to external triggers; operator creates and manages an HPA for it.
Question
TriggerAuthentication
Click to reveal answer
Answer
Namespaced (or ClusterTriggerAuthentication) object providing trigger credentials from Secrets, not inline.
Question
pollingInterval vs cooldownPeriod
Click to reveal answer
Answer
Poll how often the external metric is checked (default 30s); cooldown is idle seconds before scaling toward zero (default 300s).
Question
activation threshold
Click to reveal answer
Answer
Per-trigger value defining the metric level (e.g. queue length) below which replicas stay at zero.
Question
ScaledJob
Click to reveal answer
Answer
KEDA CRD that creates Jobs per event instead of scaling a Deployment — for batch-style workloads.
Revision Notes
Key Takeaways
- 1. KEDA = operator + metrics adapter that let HPA consume external event metrics
- 2. Scale-to-zero is governed by pollingInterval, activation, and cooldownPeriod — tune all three
- 3. One KEDA ScaledObject owns its HPA; do not create a second HPA on the same target
Interview Tips
- • Describe the full object chain: ScaledObject → operator → HPA → keda-metrics-adapter → external source
- • Discuss cold start honestly: polling lag plus scheduling, image pull, and warm-up determine real latency
Cheat Sheet
KEDA: ScaledObject → operator → HPA + metrics adapter. Creds via TriggerAuthentication. pollingInterval 30s, cooldown 300s gates zero-scaling. No second HPA on the same target.