Kubernetes-Autoscaling-Kosten entstehen nicht beim Pod-Autoscaler selbst, sondern bei den Nodes, die seine Entscheidungen nach sich ziehen: Der Horizontal Pod Autoscaler (HPA) ändert die Zahl der Replikas, der Vertical Pod Autoscaler (VPA) ihre Requests, KEDA skaliert bis auf null, und jede dieser Änderungen verschiebt die Summe der Requests, nach der der Node-Autoscaler Nodes anlegt und abbaut. Die Rechnung folgt also mit Verzögerung und nur so weit, wie Nodes tatsächlich verschwinden. Diese Seite beschreibt, wie die drei Pod-Autoscaler die Node-Nachfrage ändern, was der Empfehlungsmodus des VPA kostenlos liefert, was Scale-to-Zero in einem Cluster mit Nodes wirklich spart, und was passiert, wenn ein HPA skaliert und kein Node Platz hat. Die Mechanik der Node-Autoscaler steht unter Cluster Autoscaler, Karpenter und Node-Provisioning, der anbieterübergreifende Überblick über Zeitpläne und Auto-Scaling im Kapitel zur Optimierung.

So funktioniert es

Der HPA gehört zum Kern von Kubernetes und rechnet in jedem Durchlauf (Standard alle 15 Sekunden) die gewünschte Replikazahl aus dem Verhältnis von gemessener zu gewünschter Metrik: Die neue Zahl ist die aktuelle Zahl mal dem Quotienten aus aktuellem und Zielwert, aufgerundet. Eine CPU-Zielauslastung ist ein Prozentsatz des Requests; fehlt einem Container der CPU-Request, ist die Auslastung des Pods undefiniert und der HPA tut für diese Metrik nichts. Auf DaemonSets wirkt er nicht, weil sie nicht skalierbar sind. Jede zusätzliche Replika bringt ihre Requests mit: Sie belegt Platz auf einem Node oder erzwingt einen neuen.

Der VPA ist ein Add-on und muss separat installiert werden. Er leitet aus der beobachteten Nutzung Requests ab und wendet sie je nach Modus an: Off schreibt die Empfehlung nur in den Status des VPA-Objekts, Initial setzt sie beim Anlegen eines Pods, Recreate verdrängt Pods, deren Requests von der Empfehlung abweichen, InPlaceOrRecreate ändert sie im laufenden Pod, wo das möglich ist. Für die Kosten ist die Richtung entscheidend: Senkt der VPA Requests, passen mehr Pods auf einen Node, und der Node-Autoscaler kann Nodes abbauen; hebt er sie an, weil die Nutzung höher war als gedacht, braucht der Cluster Nodes, die er vorher nicht bezahlt hat. Off liefert diese Zahlen, ohne einen Pod anzufassen, und ist deshalb der Modus, mit dem die Messung beginnt (Rightsizing).

KEDA ergänzt den HPA um Ereignisquellen (Warteschlangen, Topics, Cron, Metriken) und um die Null: Standardmäßig skaliert ein ScaledObject auf null Replikas, wenn kein Trigger aktiv ist, und KEDA selbst übernimmt den Schritt zwischen null und eins; ab einer Replika entscheidet der HPA, den KEDA dafür anlegt. Die cooldownPeriod (Standard 300 Sekunden) wartet nach dem letzten aktiven Trigger, bevor auf null skaliert wird; pollingInterval (Standard 30 Sekunden) bestimmt, wie oft der Trigger geprüft wird; idleReplicaCount erlaubt eine Ruhegröße unterhalb des Minimums.

Alle drei wirken auf die Rechnung nur über die Nodes. In einem Cluster mit Nodes ist eine Replika weniger erst dann billiger, wenn ein Node entbehrlich wird und der Node-Autoscaler ihn entfernt, was Mindestgrößen, Wartezeiten und blockierende Pods verhindern können. In einem Modell, das nach Pods abrechnet, wie GKE Autopilot oder AWS Fargate, ist jede Replika und jeder Request sofort eine Position: Dort spart Scale-to-Zero in der Sekunde, in der der Pod verschwindet, und ein VPA-Eingriff ändert den Preis, ohne dass ein Node sich bewegt.

nach Nodesnach Pods: Autopilot,FargateHPA, VPA oder KEDA ändertRepliken oder RequestsWie wird der Clusterabgerechnet?Eine Replik weniger ist erst günstiger,wenn ein Node entbehrlich wird undder Node-Autoscaler ihn entferntVerhindert durch Mindestgrößen,Wartezeiten und blockierende PodsJede Replik und jeder Request sofortein Posten: Scale-to-Zero spart in derSekunde, in der der Pod verschwindet
Pod-Autoscaler erreichen die Rechnung in einem Cluster mit Nodes nur über die Nodes, und sofort, wo der Pod selbst abgerechnet wird

Was es für Ihre Kosten bedeutet

Pod-Autoscaling ist die Nachfrageseite des Clusters, Node-Autoscaling die Angebotsseite, und die Rechnung entsteht auf der Angebotsseite. Drei Konsequenzen folgen daraus. Erstens braucht ein HPA Node-Headroom oder einen schnellen Node-Autoscaler: Ohne freie Kapazität bleiben neue Replikas Pending, bis ein Node bereitsteht, und die Kapazität, die das abfängt, ist bezahlter Leerlauf (Kapazitätsplanung und Headroom). Zweitens ist die Wirkung des VPA auf die Rechnung die Wirkung auf die Node-Zahl; eine Empfehlung, die zehn Prozent Requests spart, spart nichts, wenn danach dieselben Nodes laufen. Drittens hängt der Wert von Scale-to-Zero vom Abrechnungsmodell ab: direkt bei Autopilot und Fargate, bei Nodes nur zusammen mit Konsolidierung oder einem Pool, der auf null darf.

HPA und VPA auf denselben CPU- und Speichermetriken arbeiten gegeneinander: Der VPA senkt den Request, der HPA misst die Auslastung am Request und startet bei gleicher Last mehr Replikas. Kombiniert werden sie deshalb mit getrennten Metriken, etwa HPA auf Anfragen je Sekunde und VPA auf Arbeitsspeicher. Welche Einsparung ein Autoscaler erzielt hat, zeigt sich erst in den Instanzstunden der Nodes oder den abgerechneten Pod-Ressourcen (von der geschätzten zur belegten Einsparung); die Zahl der Replikas ist kein Beleg.

Der VPA senkt den RequestDer HPA misst die Auslastunggegen den RequestMehr Repliken bei gleicher LastStattdessen getrennte Metriken: HPA aufAnfragen je Sekunde, VPA auf SpeicherDer Beleg: die Instanzstunden der Nodesoder die abgerechneten Pod-Ressourcen,nie die Replikenzahl
HPA und VPA auf derselben Metrik arbeiten gegeneinander, deshalb bekommen sie getrennte Metriken, und die Ersparnis zeigt sich nur in den Stunden der Nodes

Wo es schiefgeht

  • HPA skaliert, Pods bleiben Pending. Symptom: Bei Lastspitzen stehen neue Replikas minutenlang ohne Node da. Ursache: Kein Headroom, und der Node-Autoscaler braucht Minuten für einen neuen Node; die Spitze ist vorbei, bevor die Kapazität da ist, die Kapazität bleibt bis zum Abbau.
  • HPA tut nichts. Symptom: Die Replikazahl bleibt bei Last konstant. Ursache: Einem Container fehlt der CPU-Request; die Auslastung ist undefiniert.
  • VPA-Empfehlung umgesetzt, Rechnung gleich. Symptom: Requests sind gesunken, die Instanzstunden nicht. Ursache: Kein Node wurde entbehrlich, oder die Mindestgröße des Pools hält die Nodes.
  • VPA und HPA schaukeln sich auf. Symptom: Nach einer VPA-Senkung steigen die Replikas. Ursache: Beide reagieren auf dieselbe Metrik; der HPA misst am gesenkten Request.
  • Scale-to-Zero ohne Wirkung. Symptom: Die Deployments stehen nachts auf null, die Node-Kosten bleiben. Ursache: Die Nodes bleiben stehen, weil die Mindestgröße des Pools größer als null ist oder ein anderer Pod sie hält.
  • Cooldown zu kurz. Symptom: Ein Worker startet und stoppt im Minutentakt. Ursache: cooldownPeriod liegt unter dem Abstand der Ereignisse, und jeder Start zahlt die Startzeit mit.

Beispiel

Listenpreise, gelesen am 2026-10-21: in Frankfurt (eu-central-1) kostet eine m6i.large (2 vCPU, 8 GiB) On-Demand unter Linux 0,115 USD je Stunde; in GKE Autopilot in Frankfurt (europe-west3) kosten eine vCPU 0,0573 USD und ein GiB 0,0063421 USD je Stunde.

Ein Deployment mit zwei Replikas, je 1 vCPU und 3 GiB Request, läuft auf zwei m6i.large. Ein HPA hebt es bei Last auf sechs Replikas; vier neue Pods brauchen zwei weitere Nodes, die der Node-Autoscaler erst anlegt, nachdem die Pods Pending sind. Nach der Spitze hält der HPA die Replikas über sein Stabilisierungsfenster (Standard 300 Sekunden), und der Cluster Autoscaler entfernt einen Node erst, nachdem er zehn Minuten entbehrlich war: Jede Spitze zahlt für zwei Nodes mindestens diese Nachlaufzeit, bei zehn Minuten 2 × (10/60) × 0,115 = 0,0383 USD, bei 30 Spitzen im Monat 1,15 USD, zuzüglich der Minuten, in denen die Nodes vor dem Abbau noch liefen. Ein Worker, der mit einer Replika von 0,5 vCPU und 2 GiB auf Autopilot wartet, kostet im Leerlauf 0,5 × 0,0573 + 2 × 0,0063421 = 0,0413 USD je Stunde, im Monat mit 730 Stunden 30,17 USD; mit KEDA auf null skaliert kostet er nichts, solange kein Ereignis anliegt. Auf einem Node-Cluster spart derselbe Schritt erst, wenn der Node, den er belegt hat, abgebaut wird.

Quellen

Gelesen am 2026-10-21. Kubernetes Horizontal Pod Autoscaling und Vertical Pod Autoscaling, KEDA Scaling Deployments und ScaledObject-Spezifikation, Cluster Autoscaler FAQ, AWS Price List Bulk API, Angebot AmazonEC2, eu-central-1, GKE-Preise.