Hohe Kubernetes-Requests bezahlen leere Knoten

Die Cloud-Rechnung eines Kubernetes-Clusters folgt den reservierten Ressourcen, weil Scheduler und Knoten-Autoscaler auf Requests arbeiten. Limits, Namespace-Budgets und Autoscaling greifen nur, wenn sie an diese Reservierung gekoppelt sind. Wer Requests dauerhaft hoch setzt, bezahlt vorgehaltene Kapazität.

Das Wichtigste in Kürze

Verwandt:Observability frisst das Cloud-Budget unbemerkt  /  EKS 1.36 wird teuer, wenn die FinOps-Disziplin fehlt

Was sind Kubernetes-Requests? Kubernetes behandelt CPU- und Speicher-Requests als Reservierung für die Platzierung. Der Scheduler weist den Pod nur einem Knoten zu, der diese Menge noch frei hat. Der Cluster Autoscaler zählt dieselbe Zahl, wenn er entscheidet, ob ein neuer Knoten nötig ist. Wer Requests dauerhaft hoch setzt, bezahlt vorgehaltene Kapazität. Limits begrenzen den Verbrauch zur Laufzeit.

Warum Requests die Knotenzahl festlegen

Kubernetes behandelt CPU- und Speicher-Requests als Reservierung für die Platzierung. Der Scheduler addiert die Requests der bereits laufenden Pods auf einem Knoten und nimmt einen neuen Pod nur an, wenn der Rest laut Request ausreicht. Die gemessene Nutzung spielt in diesem Schritt keine Rolle. Ein Dienst mit kleiner Last und großem Request blockiert dieselbe Kapazität wie ein Dienst, der die Reservierung tatsächlich auslastet. Systemdienste und DaemonSets ziehen von derselben Knotensumme ab, bevor Anwendungspods Platz finden.

Knoten-Autoscaler beobachten Pods, die im Zustand Pending bleiben, weil nirgends genug Request-Kapazität frei ist. Dann entsteht ein zusätzlicher Knoten und mit ihm eine weitere Instanz in der Cloud-Rechnung. Wachsen Requests über viele Namespaces und Replikas, wächst die Flotte auch bei flachem Traffic. Die Abrechnung der großen Anbieter hängt an laufenden Instanzen, an Persistent Volumes und am Netz. Nach einem Lasttest bleiben solche Knoten stehen, wenn niemand Requests oder Replikazahl zurücknimmt.

Requests bestimmen damit, wie viel Kapazität die Plattform faktisch vorhält. Wer sie dauerhaft hoch setzt, bezahlt vorgehaltene Kapazität. Wer sie zu knapp setzt, erzeugt Pending, Verdrängung unter Druck und Scale-up, das nach dem Peak stehen bleiben kann. Eine Plattform, die nur Rechnungen kommentiert und Specs nicht anfasst, hat die Steuerung nicht in der Hand. Fragmentierung verstärkt das, weil wenige große Pods Restkapazität liegen lassen, die für andere Requests nicht reicht.

Viele interne Verteilmodelle legen Knotenkosten entlang der Requests um. Das ist konsistent, weil genau diese Felder die Packung und oft die Knotenzahl treiben. Fehlen belastbare Requests, wird jedes Budgetgespräch zur Schätzung. Dann diskutiert das Team Anteile, während die Flotte unbemerkt weiter wächst. Daraus folgt der erste Prüfstand: steht in der Spec, was die Knoten wirklich bindet.

Limits begrenzen den Schaden zur Laufzeit

Limits kappen CPU und Speicher, sobald ein Container die Grenze überschreitet. Bei CPU entsteht Throttling, das sich in der Schwanzlatenz der Anfragen zeigt. Bei Speicher endet der Ausreißer typischerweise in einem OOMKill. Beides schützt Nachbarworkloads auf demselben Knoten und begrenzt den lokalen Blast-Radius. Beides ändert die Rechnung nicht, solange die Requests unverändert bleiben und die Knoten weiterlaufen.

Die Quality-of-Service-Klasse ergibt sich aus Request und Limit. Sind beide gesetzt und gleich, gilt Guaranteed. Ist der Request kleiner als das Limit, gilt Burstable. Fehlen beide, landet der Pod in BestEffort und wird bei Mangel zuerst verdrängt. Teams setzen oft Request gleich Limit, um Guaranteed zu erzwingen, wodurch der Request mit dem Limit steigt und die Packungsdichte fällt.

Ein Limit ohne tragfähigen Request kehrt das Problem um. Der Scheduler packt eng, zur Laufzeit darf der Container weit über die Reservierung hinaus. Unter Last entsteht CPU-Steal und Speicherdruck bei Nachbarn. Kosten und Stabilität kippen dann gemeinsam, weil der Knoten voller ist als die Packungslogik angenommen hat. Limits sind eine Betriebsbremse.

Rightsizing braucht Nutzung plus Kopfreserve

Rightsizing setzt Requests auf die beobachtete Last plus eine bewusst gewählte Kopfreserve. Dafür sind Nutzungsreihen über Tage und Wochen nötig, weil ein einzelner Peak aus einem Deploy-Fenster als Maß nicht trägt. Wer nur den Werktagmittag misst, unterschätzt Batch in der Nacht. Wer nur das Deploy-Fenster misst, überschätzt den Dauerbetrieb. CPU und Speicher folgen unterschiedlichen Ausfallbildern, weil CPU sich drosseln lässt und Speicher nicht.

Vertikale Autoscaler können Requests vorschlagen oder setzen. Das verkürzt die manuelle Schleife und verschiebt die Verantwortung auf Beobachtungsfenster, Untergrenzen und Stabilität. Zu kurze Fenster erzeugen Pendeln zwischen Größenklassen. Jede Änderung am Request ändert die Packung und kann Knoten entfernen oder hinzufügen. Rightsizing ohne Blick auf den Knoten-Autoscaler bleibt unvollständig, weil die Ersparnis erst entsteht, wenn Instanzen wirklich verschwinden.

Die Kopfreserve ist Teil des Designs. Batch-Jobs, Heaps, Caches und Startspikes brauchen Luft, die in den Requests stehen muss. Die Regel sollte benannt sein, etwa relativ zu einem hohen Nutzungsperzentil und periodisch geprüft werden. Sonst versteinert die Reserve zur unbegründeten Überprovisionierung. Eine Reserve, die niemand mehr erklären kann, ist in der Praxis ein zweites verstecktes Budget.

Unterschiedliche Dienstklassen vertragen keine Einheitsformel. Zustandslose Frontends, Worker an Queues und speicherlastige Laufzeiten haben verschiedene Profile. Der Review gilt der Klasse und ihrer Lastform. Eine globale Kürzung über alle Namespaces erzeugt systematisch Throttling an einer Stelle und Leerknoten an der anderen.

Namespace-Budgets stoppen stillen Kapazitätszuwachs

Ohne Deckel wächst die Request-Summe mit jedem Deployment, jedem Sidecar und jeder Replica. ResourceQuotas auf CPU- und Speicher-Requests begrenzen, was ein Namespace insgesamt reservieren darf. LimitRanges setzen Defaults, Minima und Maxima pro Container. Dadurch entstehen weniger Pods ohne Request. Fehlende Defaults sind eine häufige Quelle stiller Reservierung, weil später ein vermeintlich kleiner Dienst nachgerüstet wird.

Ein Budget, das nur Limits deckelt, lässt die Reservierung weiterlaufen. Ein Budget nur auf die Pod-Anzahl ignoriert fette Specs. Die Quota sollte an dem ansetzen, was Knoten bindet: Request-CPU, Request-Speicher, PersistentVolumeClaims und bei Bedarf die Zahl der Lasten. Wie ein Anbieter das später in der Rechnung spiegelt, unterscheidet sich.

Quotas ohne Prozess werden umgangen. Neue Namespaces, ein zweiter Cluster und Requests in gemeinsam genutzten System-Namespaces unterlaufen den Deckel. Erhöhungen gehören in denselben Review wie eine Kapazitätserweiterung. Ein Team, das mehr Reservierung will, muss Nutzung und Limit-Ereignisse zeigen. Sonst finanziert die Plattform unbelegte Hoffnung.

Getrennte Budgets für Produktion und Nicht-Produktion verhindern, dass Lasttests die produktive Reservierung auffressen. Ein gemeinsamer Cluster ohne getrennte Quotas macht genau das zur Standardüberraschung. Die Plattform sollte sichtbar machen, welcher Anteil einer Quota bereits durch Requests gebunden ist. Ohne diese Sichtbarkeit kommt die Ablehnung eines Deploys überraschend und das Team sucht einen Weg um den Deckel.

Autoscaling verstärkt jeden Fehler in der Spec

Der Horizontal Pod Autoscaler ändert die Replikazahl entlang von CPU, Speicher oder benutzerdefinierten Metriken. Die relative CPU-Auslastung hängt am Request und damit an der gewählten Reservierung. Jede Replika trägt ihre Requests vollständig in die Packung. Ist der Request zu hoch, entstehen teure Kopien und früher Bedarf an Knoten. Ist der Request zu niedrig, wirkt die Auslastung hoch und der Autoscaler skaliert früh, während der Scheduler dünn geschnittene Pods trotzdem schlecht packt.

Vertikales und horizontales Skalieren ohne klare Zuständigkeit erzeugt Schwingungen. Der vertikale Pfad ändert die Größe, der horizontale die Anzahl. Der Knoten-Autoscaler antwortet mit Instanzen. In der Übergangszeit laufen oft alte und neue Größen parallel. Genau dort steigen Kosten und Pending-Queues gemeinsam, oft zusammen mit Throttling, weil die neue Größe noch nicht stabil ist.

Skalierungsgrenzen müssen zu den Namespace-Quotas passen. Eine hohe Obergrenze bei enger Quota erzeugt Pending statt Kapazität. Eine weite Quota ohne Obergrenze erzeugt Knotenwachstum. Die Kette bleibt fest: zuerst Request-Größe, dann Replikazahl, dann Namespace-Deckel, zuletzt Knotenzahl. Wer eine Stufe überspringt, sieht den Effekt erst in der Abrechnung.

Stabilisierungsfenster gehören in denselben Review. Zu kurze Fenster erzeugen Flapping und ständige Packungsänderungen. Zu lange Fenster halten nach dem Peak Knoten, die niemand mehr braucht. Autoscaling multipliziert die Spec, die bereits in der Datei steht.

Welche drei Kennzahlen jede Woche zählen

Für den wöchentlichen Schnitt durch die Kostenlage reicht ein knappes Set, das Betrieb und Rechnung verbindet. Erstens die Request-Auslastung: gemessene CPU- und Speichernutzung relativ zum Request, getrennt nach Workload und Namespace, über die Woche aggregiert. Liegt sie dauerhaft sehr niedrig, ist die Reservierung zu fett. Liegt sie dauerhaft nahe an der vollen Reservierung, fehlt Reserve oder der Request ist zu knapp. CPU und Speicher sind getrennt zu lesen, weil sie unterschiedliche Korrekturen verlangen.

Zweitens ungenutzte Request-Kapazität im Cluster. Gemeint ist das Delta zwischen reservierter Kapazität, packbarer Kapazität und gemessener Last. Es zeigt sich als schwach ausgelastete Knoten, als niedriger Packungsgrad oder als Namespaces mit hoher Reservierung bei geringer Nutzung. Diese Größe erklärt, warum die Rechnung nicht mit dem Traffic fällt. Sie gibt App-Team und Plattform eine gemeinsame Zahl.

Drittens Limit-Ereignisse: CPU-Throttling-Zeit und OOMKills je Workload. Steigen sie nach einem Rightsizing, war die Reserve zu aggressiv. Bleiben sie hoch bei niedriger Request-Auslastung, sind Request und Limit falsch zueinander gesetzt. Eine Kostenkontrolle, die nur die Rechnung senkt und diese Ereignisse ignoriert, verschiebt den Schaden in den Incident. Throttling zeigt sich als Latenz im Nutzerpfad. Drei Kennzahlen, ein fester Wochenrhythmus.

Wer die Spec ändern darf, hält die Rechnung

Die Mechanik greift nur, wenn klar ist, wer Requests, Limits und Quotas ändern darf. App-Teams brauchen Spielraum in ihrem Namespace. Die Plattform braucht ein Veto, sobald die Request-Summe Knoten erzwingt. Ein Selbstbedienungsportal ohne Quota-Bezug macht jedes Scaling zur Bestellung auf Plattformkosten.

Änderungen an Requests gehören in denselben sichtbaren Pfad wie andere produktionswirksame Specs. Ein Change, der CPU-Requests verdoppelt, ist eine Kapazitätsentscheidung. Er sollte Nutzungsreihen und die drei Wochenkennzahlen mitführen. Sonst bleibt ein Default aus einem Tutorial monatelang in Produktion und belegt Kapazität, die niemand mehr begründet.

Die Rechnung folgt weiter den Instanzen. Wer Requests, Limits und Namespace-Deckel wöchentlich an denselben drei Kennzahlen prüft, hält Knotenzahl und Schadenausbreitung in einem gemeinsamen Review. Wer das auf das Ticket nach dem Abrechnungsmonat verschiebt, kommt zu spät.

Häufige Fragen

Bildquelle: KI-generiert (September 2026)