KEDA Event-Driven Autoscaling: ScaledObjects, ScaledJobs, HPA, and Safe Scale-to-Zero
How KEDA turns queue and event metrics into pod or Job scaling, with authentication, timing controls, observability, backpressure, and production safeguards.
Kubernetes Event-driven Autoscaling (KEDA) connects external event sources to workload scaling. It does not replace the Horizontal Pod Autoscaler for every phase: for a ScaledObject, KEDA’s operator manages activation and creates an HPA, while the metrics API exposes external metrics used for scaling above one replica.
Architecture and resources
The operator reconciles KEDA custom resources. The metrics API server supplies metrics to Kubernetes. A ScaledObject targets a Deployment, StatefulSet, or supported scale subresource. A ScaledJob creates Kubernetes Jobs in response to pending work. Triggers describe sources such as Kafka, RabbitMQ, Amazon SQS, Azure Service Bus, or Google Cloud Pub/Sub; the exact scaler fields depend on the installed KEDA version.
Timing and replica controls
pollingInterval controls how often KEDA checks a trigger while activation logic applies. cooldownPeriod governs the return to zero for a ScaledObject; HPA behavior governs scaling between one and the maximum. Set minimum and maximum replicas from measured service capacity, not queue size alone. Aggressive scale-out can exhaust database connections or API quotas, while scale-in can interrupt in-flight work.
Authentication
TriggerAuthentication and ClusterTriggerAuthentication separate supported credentials or cloud identity configuration from scaling rules. Prefer workload identity and managed identities over literal secrets. Restrict cluster-scoped authentication carefully because its blast radius crosses namespaces.
Production correctness
Queue consumers need idempotency, bounded retries, dead-letter handling, graceful shutdown, and visibility-timeout or acknowledgement rules aligned with processing duration. Autoscaling cannot compensate for a poison message or downstream outage; backpressure must be designed end to end.
Observe and troubleshoot
Monitor trigger values, desired/current replicas, HPA conditions, operator and metrics-server health, pending work age, processing latency, failures, and cost. Confirm that the scaler sees the same queue semantics the application uses. Version-pin KEDA, read the scaler documentation for that release, and test scale-from-zero plus simultaneous bursts before production.
Sources: KEDA concepts, ScaledObject specification, ScaledJob specification