Kubernetes-Kapazitätsplanung legt fest, wie viel Node-Kapazität ein Cluster vorhält, bevor die Last sie braucht, und zu welchem Preis: welcher Teil als Grundlast mit einem Commitment bezahlt wird, welcher Teil als Headroom auf Abruf bereitsteht, und welcher Teil erst bei Bedarf aus Spot oder On-Demand kommt. Headroom ist bezahlte Kapazität ohne Arbeit, also Leerlauf, aber einer mit Zweck, und er gehört als eigene Kostenzeile ausgewiesen statt im übrigen Leerlauf zu verschwinden. Diese Seite beschreibt Headroom als Kostenzeile, die Puffer, mit denen Cluster überprovisioniert werden, und die Grenzen des Autoscalers, die Aufteilung in Grundlast und Spitze, die Signale, aus denen geplant wird, und ein Beispiel aus Grundlast plus Spitze. Die Wahl und Bemessung der Commitments selbst ist Commitment-Strategie, ihre laufende Auslastung Commitment-Abdeckung und -Auslastung.

So funktioniert es

Ein Cluster mit Nodes hat zwei Zeitachsen. Ein Pod braucht Sekunden bis zum Start, ein neuer Node Minuten, und zwischen beiden liegt die Zeit, in der neue Replikas Pending sind (HPA, VPA, KEDA und die Rechnung). Headroom schließt diese Lücke: freie Allocatable-Kapazität auf laufenden Nodes, auf die ein Pod sofort passt. Der Cluster Autoscaler hält von sich aus keinen Headroom; er legt Nodes erst an, wenn ein Pod nicht platzierbar ist. Ein überprovisionierender Puffer erzwingt ihn: ein Deployment aus Platzhalter-Pods mit niedriger PriorityClass, die Kapazität reservieren und verdrängt werden, sobald ein echter Pod sie braucht, worauf der Autoscaler für die verdrängten Platzhalter einen neuen Node anlegt. Die Größe des Puffers ist die Größe des Headrooms und damit eine Zahl auf der Rechnung. Karpenter bietet dasselbe über einen NodePool mit Mindestkapazität oder Platzhalter-Pods, GKE über das Profil balanced seines Autoscalers, das Reserven für schnelle Starts hält.

Nach oben begrenzen drei Dinge die Kapazität: die Maximalgröße des Pools oder die Limits des NodePools, die Kontingente des Kontos je Instanzfamilie und Region, und die Verfügbarkeit von Spot-Kapazität. Jede dieser Grenzen ist ein Punkt, an dem Pods Pending bleiben, ohne dass eine Rechnung steigt; sie gehören deshalb geplant und nicht erst beim Lasttest entdeckt.

Die Aufteilung folgt der Form der Last. Die Grundlast ist die Kapazität, die zu jeder Stunde des Monats belegt ist; sie wird mit einem Commitment bezahlt, bei AWS über Savings Plans oder Reserved Instances, bei Azure über Reservierungen oder Savings Plans, bei Google Cloud über Committed Use Discounts. Die Spitze darüber ist die Kapazität, die nur Stunden am Tag belegt ist; sie kommt aus einem Spot-Pool, wo die Workloads Unterbrechungen vertragen, sonst On-Demand. Der Headroom liegt zwischen beiden und wird On-Demand bezahlt, weil er sich mit der Grundlast bewegt und dennoch jederzeit abgebaut werden können muss.

Die Last über einen MonatDie Grundlast: Kapazität,die zu jeder Stundebelegt istDer Headroom: freieKapazität, damit Podssofort startenDie Spitze: Kapazität,die nur Stunden amTag belegt istEin Commitment: SavingsPlans, Reservierungen oderCommitted Use DiscountsOn-Demand: er bewegtsich mit der GrundlastSpot, wo die WorkloadsUnterbrechungen vertragen,sonst On-Demand
Die Grundlast läuft auf einem Commitment, der Headroom darüber On-Demand und die Spitze auf Spot, wo die Workloads Unterbrechungen vertragen

Geplant wird aus vier Signalen, die der Cluster liefert. Die Summe der Requests je Pool über die Zeit, verglichen mit der Allocatable-Kapazität, zeigt die Grundlast und die Spitzen; die gemessene Nutzung darunter zeigt, wie viel der Requests Leerlauf innerhalb der Workloads ist; die Zahl und Dauer der Pending-Pods zeigt, wo der Headroom zu klein war; die Startzeit neuer Nodes zeigt, wie groß er sein muss. Ohne diese vier bleibt Kapazitätsplanung Schätzung, und der Autoscaler korrigiert die Schätzung mit Verzögerung.

Was es für Ihre Kosten bedeutet

Headroom kostet den On-Demand-Preis der Nodes, die er belegt, jede Stunde, und sein Nutzen ist die Zeit, die Pods nicht warten. Er ist deshalb eine Kostenzeile mit Eigentümer, dem Betreiber des Clusters, und mit einer Zahl, die begründet wird: so viele Nodes, weil ein Node so viele Minuten braucht und die Last in dieser Zeit so stark steigt. Ein Headroom, der nie belegt wird, ist zu groß; einer, bei dem Pods regelmäßig Pending sind, zu klein.

Headroom niebelegtPods regelmäßigPendingPods starten sofort,wenig bleibt übrigHeadroom: freie Kapazität auflaufenden Nodes zum On-Demand-Preis,Eigentümer ist der Betreiber des ClustersSeine Zahl begründet: so vieleNodes, weil ein Node so vieleMinuten braucht und die Last indieser Zeit so stark steigtWas zeigtder Cluster?Zu großZu kleinRichtig
Headroom ist eine Kostenzeile mit Eigentümer und begründeter Größe: nie belegt heißt zu groß, Pods in Pending heißt zu klein

Das Commitment deckt die Grundlast und nur sie. Ein Commitment, das auf die Spitze bemessen ist, bleibt zwei Drittel des Tages unausgelastet; eines, das auf eine Instanzfamilie lautet, die Karpenter nicht mehr wählt, ebenso (Cluster Autoscaler, Karpenter und Node-Provisioning). Die Rechnung eines geplanten Clusters hat damit drei Zeilen: Grundlast zum Commitment-Preis, Headroom zum On-Demand-Preis, Spitze zum Spot- oder On-Demand-Preis; eine vierte, der Leerlauf ohne Zweck, soll klein sein. Welche Nodes die Zeilen tragen, entscheidet der Node-Pool: ein Pool für die Grundlast mit einem Typ, der sich reservieren lässt, ein Pool für die Spitze mit vielen zulässigen Typen.

Wo es schiefgeht

  • Headroom im Leerlauf versteckt. Symptom: Die Leerlaufquote wird als Verschwendung gemeldet, obwohl sie geplant war. Ursache: Der Puffer ist nicht als eigene Zeile ausgewiesen; Headroom und Verschnitt stehen in einer Zahl.
  • Commitment auf die Spitze. Symptom: Die Auslastung des Savings Plan liegt tagsüber hoch und nachts tief. Ursache: Das Commitment wurde auf die Spitzenlast bemessen, nicht auf die Stunde mit der geringsten Last.
  • Pending trotz Autoscaler. Symptom: Pods warten minutenlang, obwohl der Pool skalieren darf. Ursache: Kein Headroom, und die Startzeit eines Nodes übersteigt die Dauer der Spitze.
  • Kontingent als Grenze. Symptom: Der Autoscaler meldet Fehler, neue Nodes kommen nicht. Ursache: Das vCPU-Kontingent der Familie in der Region ist erreicht; die Maximalgröße des Pools lag darüber.
  • Puffer ohne Priorität. Symptom: Die Platzhalter-Pods werden nicht verdrängt, echte Pods bleiben Pending. Ursache: Die PriorityClass der Platzhalter ist nicht niedriger als die der Workloads.
  • Spot für die Grundlast. Symptom: Die Grundlast fällt bei Spot-Unterbrechungen aus. Ursache: Spot wurde für den Teil gewählt, der immer laufen muss; er gehört in die Spitze.

Beispiel

Listenpreise, gelesen am 2026-10-21 aus der AWS-Preisliste für Frankfurt (eu-central-1), Linux: m6i.large (2 vCPU, 8 GiB) On-Demand 0,115 USD je Stunde; als Standard Reserved Instance über ein Jahr ohne Vorauszahlung 0,07607 USD je Stunde.

Ein Cluster belegt zu jeder Stunde sechs m6i.large, in Spitzen von vier Stunden am Werktag bis zu zehn. Grundlast: sechs Nodes auf der Reservierung, 6 × 0,07607 × 730 = 333,19 USD im Monat. Headroom: ein Node On-Demand, 0,115 × 730 = 83,95 USD. Spitze: bis zu vier Nodes an etwa 20 Prozent der Stunden, On-Demand 4 × 0,115 × 146 = 67,16 USD, oder weniger auf Spot. Zusammen 484,30 USD im Monat, drei Zeilen mit je einem Grund. Derselbe Cluster mit elf Nodes rund um die Uhr On-Demand, damit nie ein Pod wartet, kostet 11 × 0,115 × 730 = 923,45 USD; sechs reservierte Nodes ohne Headroom kosten 333,19 USD, und jede Spitze beginnt mit wartenden Pods, bis der Autoscaler nachgelegt hat.

Quellen

Gelesen am 2026-10-21. Cluster Autoscaler FAQ, Kubernetes Pod-Priorität und Verdrängung, Karpenter NodePools, Google Cloud GKE Cluster Autoscaler, AWS Reserved Instances für EC2, AWS Price List Bulk API, Angebot AmazonEC2, eu-central-1.