Kubernetes-Leerlaufkosten sind der Teil des Node-Preises, den kein Workload beansprucht: Die Nodes laufen und kosten, aber die Summe der Requests und der Nutzung bleibt unter dem, was die Nodes bereitstellen. In einem Cluster mit Nodes gibt es diesen Rest immer, weil Nodes in ganzen Maschinen kommen und Pods nicht; die Frage ist nur, wie groß er ist, wer ihn sieht und wem er zugerechnet wird. Diese Seite trennt den Leerlauf der Assets vom Leerlauf innerhalb der Workloads, ordnet System-Overhead und Headroom ein, beschreibt die drei Verfahren, Leerlauf auf Teams zu verteilen, und rechnet vor, was jedes Verfahren mit der Zahl eines Teams macht. Was danach keinem Team gehört, behandelt nicht zugeordnete Kosten; die Tabelle, welche Spalte jeder Anbieter dafür hat, steht in Kubernetes-Kostenzuordnung.
So funktioniert es
Die OpenCost-Spezifikation definiert die Leerlaufkosten eines Clusters als den Teil der Ressourcenkosten, der keinem Workload zugeordnet ist, und stellt zwei Gleichungen auf: Die Kosten der Assets, also Nodes, Datenträger und Load Balancer, sind die Workload-Kosten plus die Leerlaufkosten, und die Gesamtkosten des Clusters sind Workload-Kosten plus Leerlauf plus Overhead wie die Clustergebühr. Der Leerlauf lässt sich je Asset, je Gruppe, je Cluster und je Ressource getrennt ausrechnen, und der Anteil am Ganzen ist die Leerlaufquote des Clusters. Nur zeitbasierte Kosten haben Leerlauf; was nach Nutzung abgerechnet wird, etwa Anfragen an einen Load Balancer, läuft nie leer.
Zwei Arten von Leerlauf sind zu unterscheiden, weil sie verschiedenen Personen gehören. Der Asset-Leerlauf ist die Kapazität eines Nodes, die kein Pod anfordert: Allocatable minus Summe der Requests, bewertet mit dem Preis je vCPU-Stunde und je GiB-Stunde, den was ein Pod kostet aus dem Node-Preis ableitet. Er entsteht durch Verschnitt beim Packen, durch Mindestgrößen und Wartezeiten des Node-Autoscalers und durch bewusst gehaltenen Headroom; sein Eigentümer ist der Betreiber des Clusters. Der Workload-Leerlauf ist die Differenz zwischen Request und Nutzung innerhalb eines Pods: Der Pod ist mit seinem Request bewertet, nutzt aber weniger. Er steckt schon in der Zahl des Teams, das den Request gesetzt hat, und nur das Team kann ihn senken. Verteilt wird deshalb nur der Asset-Leerlauf; der Workload-Leerlauf ist eine Effizienzfrage (Kubernetes-Effizienz).
Vom Leerlauf getrennt bleibt der System-Overhead: die Kapazität, die jeder Node für Kubelet, Container-Runtime und Betriebssystem zurückhält und die nie Allocatable wird, dazu die Systempods in kube-system. Das ist kein Leerlauf, sondern ein geteilter Betrieb und gehört zu den gemeinsamen Clusterkosten. Headroom, also absichtlich freie Kapazität für Lastspitzen, ist dagegen Leerlauf mit Zweck; er wird als eigene Zeile sichtbar gehalten (Kapazitätsplanung und Headroom) und nicht als Versehen behandelt.
Für die Verteilung des Asset-Leerlaufs auf Teams gibt es drei Verfahren. Keine Verteilung: Der Leerlauf bleibt eine eigene Zeile beim Betreiber des Clusters, die Teams sehen nur, was sie angefordert haben. Proportional: Jedes Team trägt den Leerlauf im Verhältnis seiner Workload-Kosten, so verteilt die OpenCost-API mit shareIdle je Ressource und wahlweise je Cluster oder je Node, und so verteilt AWS die ungenutzte Kapazität einer Instanz auf die Pods, die auf ihr liefen. Gleichmäßig: Jedes Team trägt denselben Betrag, gleich wie viel es angefordert hat. Die OpenCost-Spezifikation nennt als drittes Verfahren für geteilte Kosten eine eigene Kennzahl, etwa den Netzwerk-Egress; für Leerlauf ist das selten sinnvoll.
AWS
Split Cost Allocation Data verteilt die ungenutzte Kapazität einer Instanz anteilig auf ihre Pods und weist sie in der Spalte split_line_item_unused_cost getrennt vom Pod-Anteil aus, so dass die Verteilung sichtbar bleibt und zurückgerechnet werden kann.
Azure
Die Kostenanalyse von AKS weist Idle Charges je Cluster und Namespace als eigene Kategorie neben System Charges und Unallocated Charges aus und verteilt sie nicht.
Google Cloud
Die GKE-Kostenzuordnung schreibt nicht angeforderte Node-Kapazität im Abrechnungsexport unter den Namespace kube:unallocated und die Systemreserve unter kube:system-overhead; Autopilot kennt keinen Leerlauf, weil es Requests abrechnet.
Was es für Ihre Kosten bedeutet
Das Verfahren entscheidet, wie ein Team seine Zahl beeinflussen kann. Ohne Verteilung ist der Leerlauf das Problem des Betreibers, und nur er hat die Hebel: Node-Größen, Autoscaler, Pools. Proportional zahlt ein Team mehr Leerlauf, wenn es mehr anfordert, und sieht einen Grund, Requests zu senken, auch wenn das den Leerlauf selbst nicht ändert, sondern nur verschiebt. Gleichmäßig zahlt ein kleines Team denselben Betrag wie ein großes, und kein Team kann seine Zahl durch Requests ändern. Welches Verfahren gilt, ist eine Zuordnungsregel mit Datum; ein Wechsel mitten im Jahr macht die Teamzahlen unvergleichbar.
In jedem Fall bleibt der Leerlauf zuerst als eigene Zeile sichtbar, je Cluster und Zeitraum, bevor er verteilt wird. Erst diese Zeile zeigt, ob er aus Verschnitt, Mindestgrößen oder Headroom kommt, und nur der Betreiber kann ihn senken: kleinere oder passendere Nodes, Konsolidierung, niedrigere Mindestgrößen, Spot für den Teil, der ohnehin frei bleibt. Ein Leerlauf, der auf Teams verteilt wurde, verschwindet aus dem Blick, ohne zu verschwinden.
Wo es schiefgeht
- Leerlauf verteilt, Ursache unsichtbar. Symptom: Kein Team kann sagen, warum seine Zahl gestiegen ist. Ursache: Der Leerlauf wird proportional verteilt, ohne dass die Zeile je Cluster daneben sichtbar bleibt.
- Leerlaufquote fällt, Rechnung nicht. Symptom: Nach dem Anheben von Requests sinkt der ausgewiesene Leerlauf. Ursache: Der Asset-Leerlauf ist zu Workload-Leerlauf geworden; die Nodes und ihr Preis sind gleich.
- Headroom als Verschwendung gemeldet. Symptom: Die Leerlaufquote wird als Fehler des Betreibers gelesen. Ursache: Absichtlich gehaltener Headroom ist nicht als eigene Zeile vom übrigen Leerlauf getrennt.
- System-Overhead im Leerlauf. Symptom: Der ausgewiesene Leerlauf liegt über dem, was Nodes frei haben. Ursache: Die Reservierung für Kubelet und Betriebssystem wird mitgezählt, obwohl sie nie Allocatable war.
- Teamzahlen unvergleichbar. Symptom: Ein Team zahlt im Juni doppelt so viel Leerlauf wie im Mai bei gleicher Nutzung. Ursache: Das Verteilverfahren wurde gewechselt, oder ein Team hat den Cluster verlassen und der Rest trägt seinen Anteil.
- Nach Nutzung abgerechnete Posten mit Leerlauf. Symptom: Load-Balancer-Anfragen oder Egress erscheinen als Leerlauf. Ursache: Nur zeitbasierte Kosten haben Leerlauf; nutzungsbasierte Positionen gehören zu den geteilten Kosten.
Beispiel
Listenpreis, gelesen am 2026-10-21 aus der AWS-Preisliste für Frankfurt (eu-central-1): eine m6i.xlarge (4 vCPU, 16 GiB) kostet On-Demand unter Linux 0,23 USD je Stunde. Mit dem Verhältnis 9:1 von AWS ergeben sich 0,0398 USD je vCPU-Stunde und 0,00442 USD je GiB-Stunde (Rechnung unter was ein Pod kostet).
Drei Teams teilen sich den Node. Team A fordert 1,5 vCPU und 4 GiB an: 1,5 × 0,0398 + 4 × 0,00442 = 0,0774 USD je Stunde. Team B und Team C fordern je 0,5 vCPU und 2 GiB an: je 0,0287 USD je Stunde. Zusammen 0,1349 USD; der Asset-Leerlauf ist 0,23 − 0,1349 = 0,0951 USD je Stunde, 41 Prozent des Nodes. Ohne Verteilung zahlt Team A im Monat mit 730 Stunden 56,50 USD und die Zeile Leerlauf 69,42 USD. Gleichmäßig verteilt trägt jedes Team 0,0317 USD je Stunde zusätzlich: Team A 79,65 USD, Team B 44,14 USD. Proportional trägt Team A 0,0774/0,1349 = 57 Prozent des Leerlaufs: 0,0774 + 0,0546 = 0,1320 USD je Stunde, 96,36 USD im Monat; Team B 0,0287 + 0,0203 = 0,0490 USD, 35,77 USD im Monat. Dieselbe Rechnung, dieselben Requests: Die Zahl von Team B liegt je nach Verfahren zwischen 20,95 und 44,14 USD.
Quellen
Gelesen am 2026-10-21. OpenCost-Spezifikation und OpenCost-API, AWS Split Cost Allocation Data, Microsoft Kostenanalyse für AKS, Google Cloud GKE-Kostenzuordnung, Kubernetes Rechenressourcen für System-Daemons reservieren, AWS Price List Bulk API, Angebot AmazonEC2, eu-central-1.