KEDA Event-Driven Autoscaling Cheat Sheet

Updated 2026-05-22

Next Topic: Knative Serverless on Kubernetes Cheat Sheet

🧠Study flashcards on this topic106 cards · spaced repetition→

KEDA (Kubernetes Event-Driven Autoscaling) is a CNCF graduated project that extends Kubernetes with event-driven scaling capabilities, acting as both a Kubernetes Operator and a custom metrics adapter. While the built-in HPA can only scale on CPU and memory, KEDA connects workloads to 79+ external event sources — message queues, streaming platforms, databases, and custom metrics APIs — and uniquely enables scale-to-zero, making it indispensable for cloud-native architectures where idle resources carry cost. The crucial mental model is that KEDA controls the 0↔1 transition directly, then hands off 1↔N scaling to a managed HPA; understanding where each component takes responsibility explains virtually every behavior practitioners encounter.

What This Cheat Sheet Covers

This topic spans 16 focused tables and 152 indexed concepts, 106 flashcards. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.

Table 1: KEDA Architecture and Core ComponentsTable 2: ScaledObject Core Specification FieldsTable 3: ScaledJob Core Specification FieldsTable 4: Scale-to-Zero and Activation BehaviorTable 5: Scaler Catalog — Message Queues and StreamingTable 6: Scaler Catalog — Cloud, Observability, and DatabaseTable 7: TriggerAuthentication and Credential ManagementTable 8: Scaling Behavior Tuning — HPA and Advanced ConfigTable 9: Fallback Configuration and Failure ModesTable 10: Multi-Trigger Scenarios and Trigger CompositionTable 11: KEDA HTTP Add-on — HTTP Scale-to-ZeroTable 12: External and Custom Scalers (gRPC Interface)Table 13: Deployment, Operations, and ObservabilityTable 14: Key Scaler Parameters — Kafka, SQS, Cron Deep DiveTable 15: Common Pitfalls, Debugging, and Best PracticesTable 16: KEDA Integration Patterns — Karpenter, AI, and Multi-Tenant

Quick IndexSubscribe to unlock

A jump-to index of every table row in this cheat sheet.

Mind MapSubscribe to unlock

An interactive map of every table and concept in this topic.

Table 1: KEDA Architecture and Core Components

KEDA is composed of three distinct Kubernetes deployments plus a set of CRDs; each component has a clearly bounded responsibility. Understanding which process does what is the foundation for diagnosing any scaling issue.

Component	Example	Description
KEDA Operator	`kubectl get deploy -n keda keda-operator`	Watches ScaledObject/ScaledJob CRDs, activates/deactivates workloads (0↔1), and creates/manages the underlying HPA.
Metrics Server (Adapter)	`kubectl get deploy -n keda keda-metrics-apiserver`	• Implements the Kubernetes External Metrics API • serves scaler metric values to the HPA so HPA can drive 1↔N scaling
Admission Webhooks	`kubectl get deploy -n keda keda-admission-webhooks`	Validates ScaledObject/ScaledJob manifests at apply time to catch misconfigurations before they affect production.
ScaledObject CRD	`apiVersion: keda.sh/v1alpha1` `kind: ScaledObject`	Custom resource linking a Deployment/StatefulSet/Custom Resource to one or more event-source triggers with full scaling config.
ScaledJob CRD	`apiVersion: keda.sh/v1alpha1` `kind: ScaledJob`	Custom resource that spawns a new Kubernetes Job per event batch rather than scaling a long-running Deployment.
TriggerAuthentication CRD	`apiVersion: keda.sh/v1alpha1` `kind: TriggerAuthentication`	Namespace-scoped resource that holds credentials/pod-identity config, referenced from ScaledObject triggers via `authenticationRef`.
ClusterTriggerAuthentication CRD	`kind: ClusterTriggerAuthentication`	• Cluster-scoped variant of TriggerAuthentication • a single credential object shared across all namespaces
KEDA Operator (activation phase)	Scale: `0 → 1`	• KEDA owns this phase exclusively • it polls scalers at `pollingInterval` and calls `IsActive` to decide whether to activate from zero
HPA (scaling phase)	Scale: `1 → N`	Once KEDA activates a workload, the Kubernetes HPA (backed by KEDA's metrics adapter) drives all further replica adjustments.

Table 2: ScaledObject Core Specification Fields

The ScaledObject is the most commonly configured KEDA resource; every field has a precise default and behavioral effect. Getting these values wrong is the most frequent source of unexpected scaling behavior.

Field	Example	Description
scaleTargetRef	`scaleTargetRef:` `name: my-deployment`	• Reference to the workload KEDA manages • defaults to `kind: Deployment` in `apps/v1` • must be in the same namespace

The rest of this section is part of the full cheat sheet

Table 3: ScaledJob Core Specification Fields

ScaledJob creates a fresh Kubernetes Job for each event batch instead of scaling a long-running process, making it ideal for queue-draining and batch workloads. Several fields are ScaledJob-specific and have no ScaledObject equivalent.

Field	Example	Description
jobTargetRef	`jobTargetRef:` `template:` `spec:` `containers: [...]`	• The Kubernetes `JobSpec` template KEDA will create for each scaling event • `template` is mandatory

The rest of this section is part of the full cheat sheet

Table 4: Scale-to-Zero and Activation Behavior

Scale-to-zero is KEDA's most distinctive capability versus native HPA, but it involves two separate phases with separate controls. Misunderstanding which phase controls which transition causes most "won't scale up/down" bug reports.

Concept	Example	Description
Scale-to-zero	`minReplicaCount: 0`	• Set `minReplicaCount: 0` • KEDA scales the Deployment to 0 pods when no trigger is active and `cooldownPeriod` has elapsed

The rest of this section is part of the full cheat sheet

Table 1: KEDA Architecture and Core Components

Component	Example	Description
KEDA Operator	`kubectl get deploy -n keda keda-operator`	Watches ScaledObject/ScaledJob CRDs, activates/deactivates workloads (0↔1), and creates/manages the underlying HPA.
Metrics Server (Adapter)	`kubectl get deploy -n keda keda-metrics-apiserver`	• Implements the Kubernetes External Metrics API • serves scaler metric values to the HPA so HPA can drive 1↔N scaling
Admission Webhooks	`kubectl get deploy -n keda keda-admission-webhooks`	Validates ScaledObject/ScaledJob manifests at apply time to catch misconfigurations before they affect production.
ScaledObject CRD	`apiVersion: keda.sh/v1alpha1` `kind: ScaledObject`	Custom resource linking a Deployment/StatefulSet/Custom Resource to one or more event-source triggers with full scaling config.
ScaledJob CRD	`apiVersion: keda.sh/v1alpha1` `kind: ScaledJob`	Custom resource that spawns a new Kubernetes Job per event batch rather than scaling a long-running Deployment.
TriggerAuthentication CRD	`apiVersion: keda.sh/v1alpha1` `kind: TriggerAuthentication`	Namespace-scoped resource that holds credentials/pod-identity config, referenced from ScaledObject triggers via `authenticationRef`.
ClusterTriggerAuthentication CRD	`kind: ClusterTriggerAuthentication`	• Cluster-scoped variant of TriggerAuthentication • a single credential object shared across all namespaces
KEDA Operator (activation phase)	Scale: `0 → 1`	• KEDA owns this phase exclusively • it polls scalers at `pollingInterval` and calls `IsActive` to decide whether to activate from zero
HPA (scaling phase)	Scale: `1 → N`	Once KEDA activates a workload, the Kubernetes HPA (backed by KEDA's metrics adapter) drives all further replica adjustments.

Table 2: ScaledObject Core Specification Fields

Field	Example	Description
scaleTargetRef	`scaleTargetRef:` `name: my-deployment`	• Reference to the workload KEDA manages • defaults to `kind: Deployment` in `apps/v1` • must be in the same namespace

Table 3: ScaledJob Core Specification Fields

Field	Example	Description
jobTargetRef	`jobTargetRef:` `template:` `spec:` `containers: [...]`	• The Kubernetes `JobSpec` template KEDA will create for each scaling event • `template` is mandatory

Table 4: Scale-to-Zero and Activation Behavior

Concept	Example	Description
Scale-to-zero	`minReplicaCount: 0`	• Set `minReplicaCount: 0` • KEDA scales the Deployment to 0 pods when no trigger is active and `cooldownPeriod` has elapsed