Learn KEDA - Core Concepts & Main Architecture

#Introduction

In episode 1 we understood why KEDA exists: to scale workloads based on events, not CPU, and to scale replicas down to zero when there's no work. The natural next question is: how does it do it?

Episode 2 opens the hood. We'll look at the three components running in the keda namespace after installation, understand each one's role, and then get acquainted with the Custom Resource (CRD) objects you'll be writing over and over for the rest of this series.

#The Three-Component Architecture

When you install KEDA via Helm, three Deployments appear: keda-operator, keda-metrics-server, and keda-admission-webhooks. Each has a very different role.

#Operator: Managing ScaledObject and ScaledJob

The operator is KEDA's brain. It runs the reconciliation loop typical of the Kubernetes operator pattern: continuously comparing the real state with what's declared in the CRDs. When you create a ScaledObject or ScaledJob, the operator is responsible for two important things:

1. Creating and managing the matching HPA automatically.
2. Making sure that HPA stays in sync with the CRD configuration — for example, when maxReplicaCount changes.

A simple ScaledObject example

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: order-worker-scaledobject
spec:
  scaleTargetRef:
    name: order-worker
  minReplicaCount: 0
  maxReplicaCount: 10
  triggers:
    - type: rabbitmq
      metadata:
        queueName: orders

Note: you never create an HPA manually for this workload. The HPA is created and managed by the operator, and the following commands will show it:

Viewing the HPA created automatically by KEDA

kubectl get hpa
kubectl get scaledobject
kubectl describe scaledobject order-worker-scaledobject

#Metrics Server: The Bridge to HPA

The second component is keda-metrics-server. It implements the Kubernetes External Metrics API. When the HPA (created by the operator) needs a number, it asks keda-metrics-server, which contacts the appropriate scaler to fetch the actual value — for example, RabbitMQ queue length — and returns it in a form HPA understands.

This is why KEDA "melts into" the Kubernetes ecosystem without extra plugins: HPA doesn't know or care that its data comes from Kafka or SQS. All it sees is an external metric with a specific name.

#Admission Webhooks: The Validation Gatekeeper

The third component is keda-admission-webhooks. As the name suggests, it provides webhook endpoints that Kubernetes calls every time a KEDA object is created or modified. Its job is validation: is maxReplicaCount greater than minReplicaCount? Is the scaler name being used actually registered? If not, the object is rejected before it can damage the cluster state.

#The Metric Request Flow, Step by Step

To understand how neat KEDA's design is, follow one metric request cycle from start to finish:

1. The operator detects a new ScaledObject and creates an HPA targeting your deployment.
2. According to pollingInterval, the HPA requests the external metric value from keda-metrics-server.
3. The metrics server determines the appropriate scaler (e.g. RabbitMQ) and calls the broker API to fetch the actual queue depth.
4. The actual value is compared against the trigger's threshold.
5. The HPA calculates the required replica count and scales your deployment.

Data flow from event to replica

RabbitMQ --> keda-metrics-server --> External Metrics API --> HPA --> Deployment

The key to this entire flow: HPA remains the only final decision maker. KEDA merely provides more relevant data. That's why replica scaling behavior can still be tuned through HPA mechanisms like behavior for scaleUp and scaleDown — which we'll cover in episode 11.

#The Main Components as CRDs

All KEDA configuration happens through four Custom Resources. Mastering all four means mastering 80 percent of KEDA.

#ScaledObject

ScaledObject (with scaledobjects.keda.sh) manages autoscaling for continuous workloads like Deployment, StatefulSet, or ReplicaSet. Its main fields are scaleTargetRef (points at the workload), pollingInterval, cooldownPeriod, minReplicaCount, maxReplicaCount, and triggers. Episode 4 covers it in full.

#ScaledJob

ScaledJob manages Job autoscaling (Kubernetes Jobs for batch workloads). The fundamental difference from ScaledObject: instead of adding/removing replicas of an already-running pod, KEDA creates a new Job whenever there's an event — behavior better suited to tasks that have a beginning and an end.

#TriggerAuthentication and ClusterTriggerAuthentication

Most scalers need credentials to access the event source — for example, SQS secrets or Kafka certificates. Those credentials are defined in TriggerAuthentication (scoped to one namespace) or ClusterTriggerAuthentication (scoped across namespaces), then referenced from triggers in the ScaledObject. We'll dig into the details in episode 6.

#70+ Scalers

The part that makes KEDA so compelling: the collection of ready-made scalers. Each scaler is an implementation for one specific metric source:

Two triggers in one ScaledObject

spec:
  triggers:
    - type: prometheus
      metadata:
        serverAddress: http://prometheus.monitoring:9090
        query: sum(rate(worker_processed_total[2m]))
        threshold: "10"
    - type: cron
      metadata:
        timezone: Asia/Jakarta
        start: "0 8 * * *"
        end: "0 18 * * *"

As of 2026, the collection already has more than 70 scalers, and they can be grouped by category:

The full official list can always be checked in the keda.sh documentation. Those three architecture components plus these four CRDs are the package you'll use in every following episode.

#Conclusion

Episode 2 gives you the map of KEDA's architecture. Here's what you must bring along:

• The operator manages ScaledObject/ScaledJob and automatically creates HPAs.
• The metrics server feeds external metrics to HPA via the External Metrics API.
• Admission webhooks validate configuration before it's applied.
• Four main CRDs: ScaledObject, ScaledJob, TriggerAuthentication, and ClusterTriggerAuthentication, backed by 70+ scalers.

In episode 3 we'll get hands-on: installing KEDA from scratch with Helm, configuration options via --set, and a manifest-based installation alternative for GitOps flows.