Free — no signup required

KEDA Architecture: The Metrics Proxy

2 min read

How It Fits In

KEDA does not replace the HPA — it extends it. This is a critical design decision: rather than building a parallel scaling system, KEDA plugs into Kubernetes' existing scaling machinery. It registers itself as a custom metrics API server, which means the standard HPA can query it just like it queries the built-in metrics server for CPU data.

KEDA consists of three main components:

1. The Operator (Agent)
A Kubernetes controller that watches for ScaledObject and ScaledJob custom resources. It is responsible for the "0 to 1" and "N to 0" transitions — the activation and deactivation of workloads. When a queue goes from empty to having messages, the Operator wakes the deployment up. When the queue drains, it puts it back to sleep.

2. The Metrics Adapter (Metrics Server)
This is the bridge between the HPA and the external world. The standard HPA asks, "What is the current metric value for this workload?" KEDA intercepts that call, translates it into a query against the external event source (e.g., "How many messages are in this SQS queue right now?"), and returns the answer in a format the HPA understands. The HPA then does the math and issues the scale command.

3. The Scalers
Built-in connectors for 60+ event sources. Each scaler knows how to authenticate with and query a specific system. Examples include Apache Kafka, RabbitMQ, AWS SQS, Azure Service Bus, Google Cloud Pub/Sub, PostgreSQL, Redis, Prometheus, and even a simple cron schedule.

The Flow End-to-End

When KEDA is managing a deployment, here is what happens on every reconciliation loop:

  1. KEDA's scaler polls the external source (e.g., SQS GetQueueAttributes).
  2. The result (e.g., ApproximateNumberOfMessages: 47) is stored and exposed via the custom metrics API.
  3. The HPA queries KEDA's metrics adapter for the current value.
  4. The HPA calculates the desired replica count: current_value / target_per_pod.
  5. The HPA issues a scale command to the Deployment.

The Operator handles the special cases: scaling from 0 to 1 (before the HPA can take over) and from 1 to 0 (after the HPA would otherwise stop at minReplicas: 1).

This is one of 18 chapters

Every chapter is free — Kubernetes, Terraform, SRE, distributed systems, and more — with fast daily review built in.

Sign up free