Don't Panic — KEDA

KEDA is the small translator stationed between an external sign of work and Kubernetes autoscaling. Kubernetes is already excellent at running Pods. It is less telepathic about a queue quietly filling up while the workers are idle. KEDA supplies the missing clue, then lets the Horizontal Pod Autoscaler, or HPA, do its familiar replica arithmetic.

The important shape is pleasantly short: event source, scaler, external metric, HPA, replicas. A scaler knows how to ask one kind of source what is happening. A trigger gives it the connection details and target. KEDA turns the reply into an external metric. The HPA uses that metric to change the number of Pods. This is not sorcery. It is a chain of controllers, which is fortunate because chains can be inspected when they get ideas.

The unusual part happens at zero. A ScaledObject connects a long-running workload to one or more triggers. KEDA handles the journey from zero to one replica and back again; the HPA handles the busier territory from one to many. That split explains why pollingInterval, cooldownPeriod, and HPA behavior are three different knobs wearing suspiciously similar hats. Polling asks whether work exists. Cool-down waits before returning to zero. HPA behavior governs positive replica counts.

Choose the signal as if it were a job description, because it is. Queue depth suits waiting messages. Consumer lag suits a stream processor. A Prometheus query can suit a request-driven service. CPU and memory cannot wake a workload from zero because a zero-Pod workload has no Pods left to report them. The metric has to remain visible while the application has vanished from the stage.

KEDA also offers ScaledJob for finite batch work. That is not a very energetic Deployment with a new name. A ScaledJob creates Kubernetes Jobs as demand arrives, while a ScaledObject changes replicas on a long-running target. Pick the model that matches the work before negotiating with settings that cannot change its nature.

There are boundaries. KEDA does not add nodes, repair unreachable sources, or make a poor metric wiser. It can choose a fallback replica count after repeated scaler errors, but that is a degraded posture, not a certificate of health. Keep credentials in a TriggerAuthentication resource where possible, keep the scope narrow, and make the whole route observable.

Read the Intro for the architecture and the division of responsibility. Use Slides for the control loop at a glance. Keep the Cheatsheet nearby when choosing fields and diagnosing a delay. Then use the Practice Reference and Exercise to make a queue wake a zero-replica worker, which is where the machinery stops being a diagram and starts being evidence.

Don't Panic — KEDA

Relevant careers