KEDA Study Portal

How it works

The problem KEDA solves

The built-in HPA is the only autoscaler most teams reach for, and it has two hard limits baked in:

So for an I/O-bound worker draining a queue, CPU is a poor proxy for load, and for a low-traffic admin API the floor of 1 wastes memory on a constrained node. KEDA (Kubernetes Event-Driven Autoscaling) — a CNCF graduated project — adds exactly the two things HPA lacks: event/metric-driven scaling and scale-to-zero. It does not rip out HPA; it builds on top of it.

Step 1 — What gets installed

Installing KEDA adds a small set of components (total footprint ~50–100 Mi):

The split matters: the operator is what makes scale-to-zero possible (HPA can't), while the metrics-apiserver is what lets the ordinary HPA do the 1→N scaling on a non-CPU metric.

Step 2 — The two-phase scaling model (the central mental model)

This is the single most important thing to understand about KEDA. Scaling happens in two distinct phases owned by two different things:

   idle                                          load grows
   replicas = 0                                  ──────────────►
        │                                                 │
   ┌────▼─────────────────────┐              ┌────────────▼───────────────┐
   │  0 → 1  (ACTIVATION)      │              │  1 → N                     │
   │  owned by KEDA OPERATOR   │   hand-off   │  owned by a standard HPA   │
   │  uses the scaler's        │ ───────────► │  that KEDA CREATES         │
   │  ACTIVATION threshold     │              │  reads the metric via      │
   │  after cooldownPeriod     │              │  KEDA's metrics-apiserver  │
   │  idle → back to 0         │              │  scales 1..maxReplicaCount │
   └──────────────────────────┘              └────────────────────────────┘

• 0→1 (activation) is done by the KEDA operator itself, based on a scaler's activation threshold. After cooldownPeriod (default 300s) below that threshold, it scales back to 0. This is the part HPA cannot do.
• 1→N: once there is ≥1 replica, KEDA creates a standard HPA and hands off. The HPA reads metrics through KEDA's metrics-apiserver and scales between 1 and maxReplicaCount. KEDA wraps HPA; it does not replace it.

This is why each scaler has two numbers: an activation threshold (the 0→1 decision, owned by the operator) and a target value (the 1→N driver, owned by the HPA).

Step 3 — Scalers and the ScaledObject

KEDA ships 60+ scalers — adapters that know how to read a metric from a specific source:

You wire one up with a ScaledObject that ties a target Deployment to triggers:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: order-consumer
spec:
  scaleTargetRef:
    name: order-consumer          # the Deployment to scale
  minReplicaCount: 0              # 0 = scale-to-zero
  maxReplicaCount: 20
  cooldownPeriod: 300            # seconds idle before scaling back to 0
  pollingInterval: 15            # how often KEDA polls the scaler
  triggers:
    - type: rabbitmq
      metadata:
        queueName: orders
        queueLength: "20"        # TARGET: ~20 msgs per replica (drives 1→N)
        activationQueueLength: "1"  # ACTIVATION: ≥1 msg wakes it from 0
        host: amqp://guest:guest@rabbitmq:5672/

Key fields: minReplicaCount (0 enables scale-to-zero), maxReplicaCount (the 1→N ceiling), cooldownPeriod (idle time before returning to 0), pollingInterval (how often KEDA polls the scaler — the resolution of the 0→1 decision), and triggers[] with each scaler's metadata including its activation and target thresholds.

Step 4 — Why HTTP needs an add-on

Most scalers read a metric that exists whether or not the app is running: a RabbitMQ queue has a length even if zero consumers are up, and a Prometheus query can be evaluated against historical series. So KEDA can poll those at zero replicas and decide to wake the workload.

HTTP is fundamentally different: at 0 pods there is nothing to receive the request and therefore nothing to produce a metric. The request itself is the signal, and the thing that would emit the signal is asleep. You need something in the request path that is always up. That is the keda-http-add-on (footprint ~30–60 Mi):

1. an interceptor proxy that buffers the incoming request, signals KEDA to scale 0→1, waits for the pod's readiness probe, then forwards the buffered request — and counts pending requests as the 1→N metric;
2. an external scaler feeding those pending-request counts to KEDA;
3. the HTTPScaledObject CRD (host/path → Deployment, min/max replicas, target pending requests).

You integrate it by pointing the service's Ingress backend at the interceptor instead of directly at the app Service:

apiVersion: http.keda.sh/v1alpha1
kind: HTTPScaledObject
metadata:
  name: my-api
spec:
  hosts: ["my-api.example.com"]
  scaleTargetRef:
    name: my-api               # Deployment
    service: my-api            # the app's Service
    port: 8080
  replicas:
    min: 0
    max: 10
  scalingMetric:
    requestRate:
      targetValue: 100         # pending/req-rate target drives 1→N
# Ingress backend → the interceptor Service, NOT my-api directly

Step 5 — Cold start and cooldown

When a scaled-to-zero HTTP service gets its first request after being idle, that request pays the cold-start cost: KEDA must schedule the pod → the container starts → the readiness probe passes (~2–5s for a typical .NET app, less with ReadyToRun/AOT which trims JIT warm-up). The interceptor buffers that request within an activation timeout, so the caller experiences a slow 200, not a 502. Warm requests (a replica already up) pass straight through with no penalty.

On the way down: after cooldownPeriod below the activation threshold, KEDA scales back to 0. So cooldownPeriod is a trade-off — too short and a bursty-but-idle-in-gaps service flaps 0↔1 repeatedly (re-paying cold start each time); too long and you hold a replica's RAM longer than necessary.

Step 6 — KEDA vs HPA vs Knative (judgment)

These three are constantly confused; the distinctions are interview-grade:

The judgment call: on a small or memory-constrained node, Knative's control plane and per-pod queue-proxy sidecar can consume more memory than the idle services it puts to sleep would free — so KEDA's http-add-on is preferred there. Knative earns its weight when you want a full request-driven serverless platform (revisions, traffic splitting, automatic concurrency-based scaling) at scale, not when you're just trying to free RAM on one tight box.

Step 7 — The consumer nuance: can a queue consumer scale to zero?

A naive worry: "you must never scale a message-queue consumer to zero, because a sleeping consumer stops draining its queue and the backlog grows unbounded." That is *true only if you scale it on the wrong trigger* — e.g. a CPU or cron trigger unrelated to the queue. In that case the consumer at 0 has no way to know messages are piling up.

But KEDA's *idiomatic pattern is to scale the consumer on the queue itself — the rabbitmq queueLength scaler (or Kafka lag, SQS depth, etc.). Because KEDA polls the queue depth out-of-band even at 0 replicas, the consumer sleeps at 0 and wakes the instant a message arrives (activation threshold ≥ 1). So with the right scaler, a queue consumer absolutely can scale to zero — it scales 0→N on queue depth, draining proportionally to the backlog and sleeping when empty. The simplest conservative first pass* is still minReplicaCount: 1 (never sleep), but it is not a hard rule — it's the safe default before you trust the queue scaler.

What is a hard rule: stateful workloads — databases, brokers, caches — are never KEDA scale-to-zero targets. Their value is being continuously available with their state; sleeping them breaks the system, not just latency.

Step 8 — What it buys you (and the cost-honesty caveat)

The payoff: an idle workload drops to 0 replicas, which frees *0 RAM and 0 scheduling reservation — the pod stops consuming memory and stops reserving capacity the scheduler would otherwise hold against its requests. On a constrained node, scaling several idle long-tail services to zero is the density lever that lets other workloads schedule (this is exactly the strongest lever in the node-rightsizing module, where a constrained K3s box was OOM-killing pods because memory was 95% requested*).

The caveat to teach explicitly: scale-to-zero gives 0 RAM per idle container, not a $0 hardware bill. A self-hosted always-on node costs the same whether idle or full — the hardware is paid for regardless. Literal $0-at-idle only exists on per-request serverless (Cloud Run, AWS Lambda, Fly.io auto-stop), where you genuinely stop being billed when there's no traffic. So on self-hosted infra, scale-to-zero is a density/headroom play (free RAM for other workloads), not a billing play.

Step 9 — How KEDA connects to the right-sizing story

KEDA is the strongest, safest lever in the broader node-rightsizing playbook for a memory-constrained node. There, a single small K3s box (4 vCPU, 7.9 GB, no swap) was OOM-killing pods because memory was 95% requested, and long-running .NET services accumulated working set with uptime (a fresh content-api at 94 MB vs 284 MB aged). The validated levers were: lower the container memory limit, periodic restart, app-level reduction, and scale-to-zero with KEDA — which sidesteps accumulation entirely because a pod at 0 replicas accumulates nothing. KEDA is how you implement "idle = 0 RAM" without an app change.