The Magic of "Scale to Zero

Serverless Behavior on Your Own Cluster

Standard Kubernetes HPA has a hard constraint: minReplicas must be at least 1. You are always paying for at least one idle pod, even if no work arrives for days. For batch workloads, nightly jobs, or low-traffic internal tools, this is pure waste.

KEDA removes this constraint by introducing a two-phase lifecycle:

Phase 1 — Activation (0 → 1):
KEDA's Operator continuously polls the event source. When the queue transitions from 0 messages to 1 or more, the Operator directly patches the Deployment's replica count from 0 to 1. At this point, no HPA exists yet — KEDA handles this transition itself.

Phase 2 — Scaling (1 → N):
Once at least one pod is running, KEDA creates a standard HorizontalPodAutoscaler resource and hands off control. The HPA uses KEDA's metrics adapter to scale from 1 up to maxReplicaCount based on the event source metric.

Phase 3 — Deactivation (N → 0):
When the event source reports zero events and the cooldown period has elapsed (configurable via cooldownPeriod), KEDA deletes the HPA it created and patches the Deployment back to 0 replicas.

Queue depth:  0 ──────► 1 ──────────────────────────────► 0
Replicas:     0 ──────► 1 ──────────────────────────────► 0
                         └──► HPA created ──► HPA deleted ┘
                              (scales 1→N)

This gives you true serverless behavior — pay only for what you use — while keeping your workload inside your own cluster with full access to your VPC, secrets, and internal services.

The Activation Threshold

There is a subtle but important configuration option: activationThreshold. By default, any non-zero queue depth triggers activation. But you can set this higher — for example, activationThreshold: "5" means KEDA will only wake the deployment when there are more than 5 messages. This prevents thrashing when a single stray message arrives and you don't want to spin up pods for it.