KEDA Introduction

Welcome to this lesson on Kubernetes Event-Driven Autoscaling (KEDA). This guide explains what KEDA is, how it works, and why it’s a strong choice for modern applications that must scale quickly and efficiently in response to external events. First, a quick recap of the autoscaling landscape so you can see where KEDA fits. We have several ways to autoscale in Kubernetes:

• Horizontal Pod Autoscaling (HPA): adjusts the number of pod replicas for a Deployment based on CPU, memory, custom metrics, or external metrics.
• Vertical Pod Autoscaling (VPA): adjusts CPU/memory requests and limits for existing pods.
• Cluster Proportional Autoscaling (CPA): adjusts system-component replicas (e.g., DNS, proxies) proportionally to cluster size (nodes or cores).

Below is a focused review of each autoscaling option — strengths, limitations, and the scenarios where they shine — so you can see why KEDA is often the best fit for event-driven workloads.

​

Horizontal Pod Autoscaler (HPA)

HPA automatically adjusts the number of pod replicas in a workload based on metrics such as CPU, memory, custom metrics, or external metrics exposed to Kubernetes. Advantages:

• Native Kubernetes feature and simple to enable for CPU/memory scaling.
• Smooth replica adjustments with minimal disruption.
• Extendable to custom or external metrics via adapters.

Limitations:

• Built-in triggers are limited — event-driven triggers (queue depth, webhook events) need additional adapters or custom metrics pipelines.
• Uses periodic polling (controller sync intervals), so it reacts on a timer rather than directly to events.
• Requires predefined thresholds and at least one running pod; HPA cannot scale workloads to zero.

​

Vertical Pod Autoscaler (VPA)

VPA adjusts CPU and memory requests/limits for existing pods; it does not change replica counts. Advantages:

• Automatically right-sizes container CPU/memory requests and limits based on actual usage.
• Reduces the need for manual resource estimation and tuning.
• Ideal for workloads where changing pod resources is preferable to horizontal scaling.

Limitations:

• Resource adjustments often require pod restarts, which can cause brief downtime — risky for stateful or latency-sensitive services.
• VPA does not provide horizontal scaling; combining VPA and HPA needs careful coordination to avoid controller conflicts.
• May react slower to sudden spikes because of restart/re-provision cycles.

​

Cluster Proportional Autoscaler (CPA)

CPA scales system components (e.g., CoreDNS, kube-proxy) proportionally to cluster size (nodes or cores), not based on application workload. Notes:

• Keeps cluster-level infrastructure components aligned with cluster growth or shrink.
• Useful alongside DaemonSets when you need different proportional ratios for system pods.
• Not driven by application workload, so it doesn’t help scale application replicas in response to user traffic.

Limitations:

• Infrastructure-focused and does not react to per-application demand.
• Less precise for workload tuning compared with HPA or KEDA.

​

Quick comparison

​

Why KEDA?

Imagine an HTTP public API that sees sudden bursts of traffic followed by long idle periods. Requirements might include:

• Rapid scale-up based on request volume or a request counter metric.
• Scale-down-to-zero when idle to save cost.
• Minimal complexity without custom adapters or heavy configuration.

HPA may not be ideal here (cannot scale to zero and may lag on CPU-based signals). VPA changes pod sizing and can cause restarts. CPA does not observe HTTP load. KEDA fills this gap with event-driven autoscaling that integrates with Kubernetes and supports many external scalers:

• Scales workloads based on event sources or external metrics: message queues, HTTP counters, Prometheus metrics, cloud provider metrics, and more.
• Ships many built-in scalers (Kafka, Azure Service Bus, AWS SQS, Prometheus, HTTP, and others).
• Reacts quickly to metric changes and supports scaling down to zero when demand is zero.
• Uses Kubernetes CRDs like ScaledObject and ScaledJob to define scaling behavior with minimal extra infrastructure.

​

KEDA architecture and components

KEDA is composed of several cooperating components that enable event-driven autoscaling in Kubernetes:

• KEDA Operator (control plane): Reconciles CRDs (ScaledObjects and ScaledJobs), watches event sources, and requests scaling actions from the Kubernetes API.
• Metrics adapter / Metrics server: Exposes external metrics to Kubernetes’ External Metrics API so the HPA or other controllers can consume them.
• Admission Webhook: Validates and optionally mutates KEDA resources at admission time to ensure correct configurations.
• TriggerAuthentication: A CRD to securely store credentials for external systems so secrets are not embedded in ScaledObjects.
• Scaler: Component-specific implementations that fetch metrics or observe events from external sources and determine scale-up/scale-down decisions.
• ScaledObject / ScaledJob: CRDs that link a Deployment or Job to a scaler and define scaling behavior (thresholds, min/max replicas, cooldowns).

​

Component details

Operator

• Acts as KEDA’s control plane: watches ScaledObjects and ScaledJobs, reconciles their desired state, and requests scaling changes via the Kubernetes API.

Metrics adapter

• Aggregates external metrics and exposes them through the External Metrics API. This lets Kubernetes-native controllers (like HPA when configured) consume event-based metrics seamlessly. See Kubernetes HPA metrics support: https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-metrics-apis

Admission Webhook

• Validates and mutates KEDA-related resources during admission to the API server. This prevents invalid or insecure configurations from being persisted.

TriggerAuthentication

• Stores credentials and secrets that scalers need to access external systems (for example, cloud queues or APIs) so you avoid embedding secrets directly in ScaledObject definitions.

Scaler

• Implements the platform-specific logic to fetch metrics or observe events (e.g., from Prometheus, cloud provider APIs, or messaging systems). A scaler interprets thresholds and signals when the operator should scale a target workload, and it supplies metrics to the metrics adapter.

ScaledObject (and ScaledJob)

• The ScaledObject CRD attaches to a Deployment (or other supported workload) and defines:
  • Which scaler to use (the event source or metric source).
  • Metric queries, thresholds, and behavior parameters.
  • Scaling policy: min/max replicas, cooldown periods, polling intervals.
• ScaledJob is the equivalent for Jobs: it triggers Kubernetes Jobs based on event messages or metrics.

​

Putting it together

KEDA’s pieces work together to provide flexible, efficient event-driven scaling:

• ScaledObjects define the scaler, thresholds, and min/max bounds.
• TriggerAuthentication keeps secrets out of ScaledObjects.
• Scalers fetch metrics and interpret when to scale.
• The Operator reconciles desired state and issues scaling requests.
• The metrics adapter surfaces metrics to Kubernetes APIs.
• The admission webhook validates configurations on create/update.

This architecture makes KEDA an excellent choice when you need:

• Fast reaction to event-driven workloads (message queues, HTTP counters, webhooks).
• Fine-grained control over scaling thresholds and behavior.
• The ability to scale to zero to save cost during idle periods.
• Native Kubernetes integration while supporting many external sources and cloud providers.

​

Additional resources

• KEDA project: https://keda.sh/
• Kubernetes HPA documentation: https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/
• Prometheus: https://prometheus.io/
• Cluster Autoscaler (useful when autoscaling nodes): https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler

Thanks for reading this lesson.