Event-Driven Scaling mit KEDA: Wenn die Message Queue den Cluster steuert

Der klassische Horizontal Pod Autoscaler (HPA) von Kubernetes ist wie ein Thermostat: Wenn es im Zimmer zu warm wird (CPU > 80 %), geht die Klimaanlage an. Das funktioniert für Standard-Web-Apps gut, versagt aber in modernen, ereignisgesteuerten Architekturen.

Was ist, wenn Ihre CPU-Last niedrig ist, aber in Ihrer Kafka-Queue 10.000 unbearbeitete Aufträge liegen? Oder wenn Ihr System auf einen plötzlichen Spike von Webhooks reagieren muss? Hier stößt das Standard-Scaling an seine Grenzen. Die Lösung für 2026 heißt KEDA (Kubernetes Event-driven Autoscaling).

Das Problem: Warum CPU und RAM oft die falschen Metriken sind

Standard-Scaling ist reaktiv. Es wartet, bis die Hardware “schwitzt”. In datenintensiven Szenarien führt das zu Problemen:

• Der “Quiet Killer” (Kafka Lag): Ihre Worker-Pods verbrauchen kaum CPU, weil sie auf I/O warten, aber die Schlange der unbearbeiteten Nachrichten wächst. Der HPA sieht keinen Grund zu skalieren, während Ihre Kunden auf ihre Bestätigungs-E-Mails warten.
• Scale-to-Zero: Der Standard-HPA kann eine Applikation nicht auf null Pods herunterfahren. Sie zahlen also auch nachts für Ressourcen, die nichts tun.

KEDA: Die Brücke zwischen Events und Infrastruktur

KEDA ist ein leichtgewichtiger Operator, der den HPA nicht ersetzt, sondern ihm “Augen und Ohren” für die Außenwelt gibt. KEDA beobachtet externe Quellen (Scalers) und sagt dem HPA genau, wie viele Instanzen benötigt werden.

Die drei mächtigsten Scaling-Szenarien mit KEDA:

1. Kafka- & RabbitMQ-Lags: KEDA misst nicht die Auslastung der Worker, sondern die Länge der Warteschlange. Wenn der “Lag” (die Differenz zwischen produzierten und konsumierten Nachrichten) einen Schwellenwert überschreitet, fährt KEDA die Flotte sofort hoch.
2. Datenbank-Zustände: Skalieren Sie basierend auf dem Ergebnis einer SQL-Abfrage. Wenn beispielsweise mehr als 50 “Pending Orders” in Ihrer PostgreSQL-Datenbank stehen, werden zusätzliche Processing-Worker gestartet.
3. HTTP-Traffic mit dem Add-on: Während der Standard-Ingress oft träge reagiert, kann KEDA den Traffic direkt am Ingress-Level abgreifen und proaktiv skalieren, bevor die Antwortzeiten steigen.

Vergleich: HPA vs. KEDA

In Google Sheets exportieren

Kosten-Effizienz durch “Scale-to-Zero”

Für den Mittelstand ist das Potenzial von KEDA bei den Cloud-Kosten enorm. Viele Hintergrundprozesse (Cron-Jobs, Import-Worker, PDF-Generatoren) werden nur sporadisch benötigt. Mit KEDA verbrauchen diese Services exakt null Ressourcen, solange keine Arbeit in der Queue liegt. Sobald eine Nachricht eintrifft, “weckt” KEDA den Service auf. Das ist Serverless-Feeling auf Ihrer eigenen Kubernetes Infrastruktur.

[Image showing a scaling graph: CPU-based scaling (delayed, staircase) vs. Event-based scaling with KEDA (aligned with message peaks)]

Fazit: Atmen im Rhythmus des Business

Echtes Autoscaling sollte sich nach Ihrem Geschäftserfolg richten, nicht nach der Temperatur Ihrer Prozessoren. KEDA macht Ihre Infrastruktur intelligent und reaktionsschnell. Wer 2026 moderne Backend-Architekturen betreibt, kommt an event-gesteuertem Scaling nicht mehr vorbei.

Technical FAQ: Autoscaling Deep-Dive

Ist KEDA ein Ersatz für den Cluster Autoscaler? Nein. KEDA skaliert die Pods. Wenn der Platz auf den physischen Nodes nicht mehr reicht, muss weiterhin der Cluster Autoscaler (oder Karpenter) neue Nodes hinzufügen. KEDA sorgt lediglich dafür, dass der Bedarf schneller und präziser gemeldet wird.

Kann KEDA auch mit Prometheus-Metriken skalieren? Ja, das ist einer der mächtigsten Scaler. Sie können jede beliebige Metrik, die Sie bereits in Prometheus sammeln (z.B. Fehlerraten oder Business-KPIs), als Trigger für das Scaling Ihrer Pods nutzen.

Gibt es eine Verzögerung beim Aufwachen aus der Null-Skalierung? Ja, der sogenannte “Cold Start”. Da der Pod erst gestartet werden muss, wenn die erste Nachricht eintrifft, entsteht eine kurze Latenz. Für Echtzeit-User-Interfaces ist Scale-to-Zero daher oft nicht ideal, für asynchrone Worker jedoch perfekt.