KEDA vs. Kubernetes HPA: Event-Driven Autoscaling im Vergleich 2026

Kubernetes skaliert Workloads standardmäßig über den Horizontal Pod Autoscaler (HPA) — basierend auf CPU- und Memory-Metriken. Für moderne, Event-Driven-Architekturen reicht das oft nicht aus. KEDA (Kubernetes Event-Driven Autoscaling) füllt diese Lücke mit über 50 eingebauten Skalierungstriggern für Message Queues, Datenbanken, HTTP und mehr.

Der native Kubernetes HPA

Der HPA ist seit Kubernetes 1.2 Teil des Kerns und skaliert Deployments, StatefulSets und andere Workloads anhand von Metriken. Er fragt den Metrics Server ab (CPU, Memory) oder nutzt Custom Metrics via dem Prometheus Adapter.

HPA-Konfiguration (CPU-basiert):

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

Stärken des HPA:

  • Kein zusätzliches Tool nötig — Teil von Kubernetes
  • Gut dokumentiert, stabile API
  • Unterstützt Custom Metrics via Prometheus Adapter
  • Einfach zu verstehen und zu debuggen

Schwächen des HPA:

  • Reagiert auf aktuelle Last, nicht auf bevorstehende Last
  • Skaliert auf 0 nicht möglich (mind. 1 Replica)
  • Kein direktes Event-Driven-Scaling ohne Custom Metrics-Setup

Was ist KEDA?

KEDA ist ein Kubernetes-Operator, der als Custom Controller im Cluster läuft und eigene Custom Resource Definitions (CRDs) mitbringt. Es installiert sich als Helm Chart und erweitert den HPA, anstatt ihn zu ersetzen.

helm repo add kedacore https://kedacore.github.io/charts
helm install keda kedacore/keda --namespace keda --create-namespace

KEDA bringt zwei eigene Ressourcentypen mit:

  • ScaledObject: skaliert Deployments/StatefulSets
  • ScaledJob: erstellt Kubernetes Jobs pro Event (für Batch-Processing)

KEDA in der Praxis: Kafka-basiertes Scaling

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: kafka-consumer-scaler
spec:
  scaleTargetRef:
    name: kafka-consumer
  minReplicaCount: 0
  maxReplicaCount: 20
  triggers:
    - type: kafka
      metadata:
        bootstrapServers: kafka:9092
        consumerGroup: my-group
        topic: events
        lagThreshold: "100"

Dieses ScaledObject skaliert den Kafka-Consumer basierend auf dem Consumer-Lag. Bei 0 Nachrichten in der Queue: 0 Pods. Bei 2000 Nachrichten: automatisch auf 20 Pods. Der HPA allein könnte das nicht — er weiß nichts vom Kafka-Lag.

KEDA ScaledJob für Batch-Processing

apiVersion: keda.sh/v1alpha1
kind: ScaledJob
metadata:
  name: image-processor
spec:
  jobTargetRef:
    template:
      spec:
        containers:
          - name: processor
            image: my-image-processor:latest
  triggers:
    - type: rabbitmq
      metadata:
        host: amqp://rabbitmq:5672/
        queueName: image-jobs
        queueLength: "1"

Für jeden Job in der RabbitMQ-Queue wird ein Kubernetes Job erstellt. Ideal für Bildverarbeitung, Report-Generierung oder andere Batch-Workloads.

KEDA Scaler im Überblick

KEDA 2.x unterstützt über 50 eingebaute Scaler:

Kategorie Scaler
Message Queues Kafka, RabbitMQ, NATS, Azure Service Bus, AWS SQS
Datenbanken PostgreSQL, MySQL, Redis, MongoDB
HTTP HTTP Requests (via http-add-on), Prometheus
Cloud AWS CloudWatch, GCP Pub/Sub, Azure Event Hubs
K8s intern CPU, Memory (wie HPA), Cron-basiert

Scale-to-Zero: Der entscheidende Unterschied

Der wichtigste Vorteil von KEDA: Scale-to-Zero. Ein Deployment kann auf 0 Replicas skaliert werden, wenn keine Events vorliegen. Der HPA erlaubt mindestens 1 Replica.

Für Self-Hoster mit begrenzten Ressourcen ist das besonders wertvoll: Batch-Worker laufen nur, wenn es Arbeit gibt. In einem Homelab-Cluster mit 3 Nodes spart das signifikant CPU und RAM.

Vergleich: HPA vs. KEDA

Kriterium HPA KEDA
Installation Im Kern vorhanden Helm Chart nötig
Trigger CPU, Memory, Custom Metrics 50+ Scaler inkl. alle HPA-Trigger
Scale-to-Zero ❌ ✅
Batch-Jobs ❌ ✅ (ScaledJob)
Kafka/Queue-Scaling Indirekt via Prometheus Nativ
Lernkurve Niedrig Mittel
Produktionsreife Sehr hoch Hoch (CNCF Graduated)

Wann HPA, wann KEDA?

Bleib beim HPA, wenn:

  • CPU/Memory-basiertes Scaling ausreicht
  • Du kein zusätzliches Tool im Cluster willst
  • Einfache, zustandslose Services ohne Queue-Backend

Nutze KEDA, wenn:

  • Du Message Queues oder Event Streams verarbeitest
  • Scale-to-Zero für Batch-Worker wichtig ist
  • Du Cron-basiertes Scaling brauchst
  • Prometheus-Metriken als Scaling-Trigger

KEDA ersetzt den HPA nicht — es ergänzt ihn. Hinter den Kulissen erstellt KEDA selbst HPA-Objekte und sorgt für die Metrik-Brücke.

Fazit

Für Standard-Workloads ist der native HPA völlig ausreichend und wartungsärmer. Sobald du Event-Driven-Architekturen mit Kafka, RabbitMQ oder HTTP-basierten Triggern betreibst, ist KEDA die richtige Wahl. Als CNCF-Graduated-Projekt ist es produktionsreif und in vielen großen Kubernetes-Clustern im Einsatz.

Weiterführende Artikel

Verwandte Technologien im Techradar