Kubernetes Autoscaling 2026: HPA, VPA, KEDA und Karpenter im Zusammenspiel

In Produktionsclustern reicht der klassische Horizontal Pod Autoscaler (HPA) längst nicht mehr aus. Moderne Kubernetes-Umgebungen verlangen nach einem fein abgestimmten Zusammenspiel mehrerer Autoscaler: HPA für CPU-basierte Replikaskalierung, VPA für das vertikale Right-Sizing von Pod-Ressourcen, KEDA für ereignisgesteuerte Workloads und Karpenter für die dynamische Node-Bereitstellung. Dieser Artikel gibt eine Orientierung, welches Werkzeug für welchen Anwendungsfall geeignet ist – und wie die Tools gefahrlos kombiniert werden können.

Die drei Skalierungsebenen im Kubernetes-Cluster

Autoscaling in Kubernetes bewegt sich auf drei unabhängigen Ebenen. HPA und KEDA skalieren die Anzahl der Pod-Replicas (Anwendungsebene), VPA passt die CPU- und Memory-Requests pro Pod an (Pod-Größe), während Cluster Autoscaler oder Karpenter die Anzahl der Cluster-Nodes verändern (Infrastrukturebene). Der häufige Fehler liegt darin, ein Tool für die falsche Ebene einzusetzen: Ein HPA kann die Replikazahl erhöhen, aber keine neuen Nodes bereitstellen – sind die vorhandenen Nodes ausgelastet, bleiben zusätzliche Pods im Pending-Status. Ebenso kann KEDA eine Queue-Tiefe erkennen, aber keine falsch gesetzten Resource Requests korrigieren. Die klare Trennung der Verantwortlichkeiten ist der erste Schritt zu einem robusten Autoscaling-Design.

HPA: bewährt, aber mit Fallstricken

Der Horizontal Pod Autoscaler ist das Standardwerkzeug für CPU- und Memory-basierte Skalierung. In der Version autoscaling/v2 unterstützt er neben Resource Metrics auch Custom Metrics wie Requests pro Sekunde oder Warteschlangenlängen, sofern ein Metrics-Adapter (etwa Prometheus Adapter) im Cluster installiert ist.

Ein häufig unterschätzter Parameter ist das Stabilization Window: Standardmäßig skaliert HPA aggressiv hoch, aber auch schnell wieder herunter, was zu Flapping führen kann. Empfohlen wird ein stabilizationWindowSeconds von 300 Sekunden für Scale-Down bei maximal 10 % Pod-Reduktion pro Minute, während Scale-Up ohne Verzögerung erfolgen sollte. Diese Konfiguration verhindert, dass kurze Lastspitzen zu unnötigen Auf- und Abbewegungen führen.

KEDA: Ereignisgesteuertes Scalen auf ein neues Level

KEDA (Kubernetes Event-Driven Autoscaling) erweitert das HPA-Konzept um über 60 native Scaler – von Kafka Consumer Lag über RabbitMQ-Queue-Tiefe bis hin zu AWS SQS oder Redis-Listenlänge. Anders als der klassische HPA kann KEDA Pods auf null herunterskalieren, wenn keine Events anstehen, und bei Bedarf wieder hochfahren. Das ist besonders wertvoll für Batch-Jobs, Hintergrundverarbeiter und saisonale Workloads.

Seit Version 2.16 (September 2026) unterstützt KEDA dateibasierte Authentifizierung für ClusterTriggerAuthentication und bringt neue Kubernetes-Ressourcen-Scaler. Die nächste geplante Version ist für Januar 2027 angesetzt. Für HTTP-basierte Workloads steht das KEDA HTTP Add-on zur Verfügung, das eingehende Requests puffert und bei Bedarf Pods aus dem Standby holt – eine echte Alternative zu traditionell immer laufenden API-Gateway-Instanzen.

VPA 2026: In-Place Resizing beendet die Ära der Pod-Neustarts

Der Vertical Pod Autoscaler hat 2025/2026 einen entscheidenden Sprung gemacht: Seit Kubernetes 1.35 (Dezember 2025) ist In-Place Pod Resizing GA, und VPA 1.2+ bietet den Modus InPlaceOrRecreate. Damit können Pods live in ihren Ressourcenanforderungen angepasst werden, ohne zwangsweise neuzustarten – das größte Hindernis für den VPA-Einsatz in der Produktion ist damit gefallen.

Gleichwohl bleiben Risiken: Die bekannte VPA/HPA-Todesspirale entsteht, wenn beide Tools auf dieselben CPU-/Memory-Metriken zugreifen. VPA senkt die Requests auf Basis historischer Daten, HPA interpretiert die gleiche absolute Auslastung als höheren Prozentsatz (da der Request-Nenner kleiner wurde) und skaliert horizontal nach. Die Abhilfe ist einfach: HPA auf Custom Metrics (RPS, Queue Depth) setzen, VPA nur für CPU/Memory verwenden – oder VPA im Off-Modus betreiben, um nur Empfehlungen zu sammeln, ohne automatisch einzugreifen.

Karpenter: Node-Autoscaling der nächsten Generation

Auf der Cluster-Ebene hat Karpenter in AWS-Umgebungen den Cluster Autoscaler vielerorts abgelöst. Statt auf vordefinierte Node Groups angewiesen zu sein, provisioniert Karpenter Nodes direkt über die Cloud-API und wählt automatisch den kosteneffizientesten Instanzentyp für ausstehende Pods aus. Die Konsolidierung unterausgelasteter Nodes erfolgt aggressiv – laut Herstellerangaben mit 40–60 % besserer Node-Auslastung im Vergleich zum klassischen Cluster Autoscaler. Für GKE-Nutzer bleibt der Cluster Autoscaler vorerst die Standardwahl, da ein produktionsreifer Karpenter-Provider für Google Cloud noch nicht verfügbar ist.

Architektur-Empfehlungen nach Workload-Typ

Für eine Web-API (stateless, latenzsensitiv) empfiehlt sich HPA auf CPU + RPS-Custom-Metric, VPA im Off-Modus (Empfehlungen sammeln) und Karpenter mit einer Mischung aus Spot- und On-Demand-Instanzen. Background Worker, die auf Queues hören, profitieren von KEDA mit Scale-to-Zero in Verbindung mit Spot-Instanzen – Ausfälle einzelner Pods sind durch Job-Retry-Mechanismen abgedeckt. ML-Inferenz-Workloads mit GPUs skalieren am besten über KEDA (HTTP oder benutzerdefinierte Prometheus-Metriken) mit längerem Cooldown, da GPU-Nodes teuer im Hochfahren sind.

Fazit

Kubernetes-Autoscaling ist 2026 kein Entweder-oder mehr. Die entscheidende Frage lautet nicht „Welcher Autoscaler ist der beste?“, sondern „Welches Signal skaliert welches Objekt?“. HPA, VPA, KEDA und Karpenter adressieren unterschiedliche Ebenen und Signale und entfalten ihre Stärke erst im intelligenten Zusammenspiel. Der häufigste Fehler bleibt, für jeden Workload zum HPA zu greifen – wer stattdessen das Skalierungssignal analysiert und das passende Werkzeug wählt, fährt kosteneffizienter und stabiler.