Kubernetes-Kostenzuordnung nach Namespace und Label

Kubernetes-Kostenzuordnung nach Namespace verteilt die Kosten der Nodes eines Clusters über die Pods auf Namespaces und Labels: Jeder Pod erhält einen Anteil an den Kosten seines Nodes, bemessen nach Requests, Nutzung oder dem Größeren aus beidem, und Namespaces und Labels summieren diese Anteile zu Teams, Produkten oder Umgebungen. Bei Clustern, die je Node abgerechnet werden, berechnet der Anbieter Nodes, keine Pods; woher die Daten kommen, beschreibt Kubernetes-Kostendaten. Für die Rechnung zählt die Zuordnung, weil dieselbe Clusterrechnung je nach drei Entscheidungen (Einheit, Basis, Umgang mit dem Rest) andere Teamsummen ergibt und weil der Teil, den kein Pod beansprucht, ohne Regel bei niemandem landet.

So funktioniert es

Die Einheit: Namespace, Label oder Workload

Ein Namespace teilt die Ressourcen eines Clusters zwischen Nutzern auf. Jedes Namespace-gebundene Objekt liegt in genau einem Namespace. Nodes, Persistent Volumes und Storage Classes gehören zu keinem Namespace; ihre Kosten erreichen einen Namespace nur über die Pods, die sie nutzen. Innerhalb eines Namespace unterscheiden Labels die Ressourcen.

Daraus folgen drei Einheiten. Der Namespace taugt, wenn er genau einem Team gehört. Ein Team- oder Produkt-Label an den Pods ist nötig, wenn sich mehrere Teams einen Namespace teilen. Der Workload (Deployment, StatefulSet, Job) ist die Einheit, wenn ein Team die Kosten einzelner Dienste sehen will. Welcher Namespace zu welchem Team gehört, steht nicht in den Abrechnungsdaten: Diese Zuordnung ist eine Tabelle oder ein Label am Namespace und wird wie jedes andere Segment gepflegt. Pod-Labels erreichen die Berichte als Tags. GKE schreibt sie als k8s-label/ gefolgt vom Schlüssel in den Export. Bei AWS übernimmt Split cost allocation data bis zu 50 Pod-Labels je Pod (die ersten 50 in alphabetischer Reihenfolge) als benutzerdefinierte Cost Allocation Tags, die das Management-Konto aktivieren muss, und ergänzt eigene Tags wie aws:eks:namespace und aws:eks:workload-name. Damit sie zu den übrigen Tags und Labels passen, folgen die Label-Schlüssel derselben Tagging-Richtlinie.

Die Basis: Requests, Nutzung oder das Größere

Ein Request reserviert Kapazität. Der Scheduler platziert einen Pod nur auf einem Node, auf dem die Summe der Requests unter der Kapazität bleibt, auch wenn die tatsächliche Auslastung niedrig ist. Ein Container darf mehr nutzen, als er angefordert hat, solange der Node Platz hat; Limits setzt das Kubelet durch, und ist nur ein Limit gesetzt, übernimmt Kubernetes es als Request.

Auf Instanzen mit Beschleunigern (GPU, Trainium, Inferentia) verteilt AWS immer nach Requests, gleich welche Option gewählt ist.

Ein Node hat einen Preis, keinen Preis je vCPU und je Gigabyte. AWS gewichtet für Split cost allocation data vCPU und Arbeitsspeicher im Verhältnis 9:1, abgeleitet aus den Preisen je vCPU-Stunde und je GB-Stunde von AWS Fargate. Die OpenCost-Spezifikation empfiehlt Preise je Ressource im Verhältnis der Grenzpreise der Instanzfamilie, normiert auf den Preis des Nodes, und als Eingabe die vollständig amortisierten Nettokosten. AWS rechnet ebenfalls mit den amortisierten Kosten der Instanz.

Die Reste: Leerlauf, Systemlast, geteilte Clusterkosten

Die OpenCost-Spezifikation fasst die Verteilung in zwei Gleichungen: Die Kosten der Assets sind Workload-Kosten plus Leerlaufkosten, und die Gesamtkosten des Clusters sind Workload-Kosten plus Leerlauf plus Overhead wie Clustergebühren. Leerlaufkosten sind der Teil der zeitbasierten Kosten, den kein Workload beansprucht; was nur nach Nutzung abgerechnet wird, läuft nie leer. Daneben stehen die Systemlast (Kapazität, die jeder Node für Kubelet, Container-Runtime und andere Systemprozesse zurückhält, und Systemworkloads wie kube-system), geteilte Clusterkosten (Clustergebühren, Load Balancer, Monitoring) und Kosten, die das Werkzeug keinem Namespace zuordnen kann. System charges bei AKS und kube:system-overhead bei GKE umfassen nur die auf jedem Node reservierte Kapazität; Systemworkloads wie kube-system laufen als Pods in einem eigenen Namespace.

Jeder Rest bleibt zuerst als eigene Zeile sichtbar und wird dann nach einer vereinbarten Regel zugewiesen. Die OpenCost-Spezifikation nennt drei Verfahren für geteilte Kosten: gleichmäßig über die Mandanten, im Verhältnis zu ihrem Anteil an den Asset-Kosten oder nach einer eigenen Kennzahl wie dem Netzwerk-Egress. Die OpenCost-API verteilt Leerlauf mit shareIdle im Verhältnis zu den übrigen Kosten jeder Zuordnung, je Ressource getrennt und wahlweise je Cluster oder je Node. AWS verteilt die ungenutzte Kapazität einer Instanz bereits auf die Pods, die auf ihr liefen, hält sie aber in einer eigenen Spalte neben den Split-Kosten.

Was es für Ihre Kosten bedeutet

Die Basis bestimmt das Verhalten der Teams. Wird nach Requests verteilt, trägt ein Team, was es reserviert, und senkt seine Kosten nur, indem es Requests senkt. Wird nach dem Größeren verteilt, zahlt es zusätzlich Lastspitzen über den Request hinaus. Die Basis ist deshalb eine Zuordnungsregel wie jede andere, mit Datum festgehalten und nicht mitten im Jahr still gewechselt.

Im Bericht steht je Namespace oder Team eine Zeile, dazu je eine für Leerlauf, Systemlast, geteilte Clusterkosten und Nicht-Zuordenbares; zusammen ergeben sie die Clusterkosten der Rechnung in derselben Kostensicht. Die AKS-Ansichten zeigen standardmäßig tatsächliche Kosten und amortisierte erst nach Umstellung, die AWS-Split-Daten amortisierte; ein Bericht, der beide mischt, vergleicht verschiedene Sichten. Bleibt der Leerlauf eine eigene Zeile, liegt er beim Eigentümer des Clusters und zeigt, wie viel bezahlte Kapazität niemand angefordert hat. Ob sie sich abbauen lässt, klärt Ungenutzte und verwaiste Ressourcen, was Nodes und Cluster kosten, Virtuelle Maschinen und Instanzfamilien und Container und Kubernetes, die Verteilschlüssel Geteilte Kosten, und was nach allen Regeln übrig bleibt, gehört zu den nicht zugeordneten Kosten.

Wo es schiefgeht

• Leerlauf verschwindet in den Teamsummen. Symptom: Die Teams tragen zusammen genau die Clusterkosten, aber niemand sieht die ungenutzte Kapazität. Ursache: Der Leerlauf wird verteilt, etwa mit shareIdle in OpenCost oder durch Addieren der Unused-Kosten bei AWS, ohne vorher als eigene Zeile zu erscheinen.
• Ein Namespace für mehrere Teams. Symptom: Ein Namespace trägt hohe Kosten, und kein Team erkennt sie als seine. Ursache: Mehrere Teams teilen den Namespace, und die Pods tragen kein Team-Label.
• Labels gehen auf dem Weg verloren. Symptom: Im GKE-Export oder im CUR fehlen bei einzelnen Pods die Team-Labels, oder Sidecar-Kosten stehen unter kube:unallocated. Ursache: Bei mehr als 50 Labels übernimmt GKE keines, und Requests nativer Sidecar-Container ordnet es nicht dem Namespace zu; AWS übernimmt nur die ersten 50 Labels in alphabetischer Reihenfolge und zeigt keines, bevor es aktiviert ist.
• Autoscaling erzeugt unbekannte Zeilen. Symptom: In Monaten mit vielen Skalierungen erscheinen Posten mit goog-k8s-unknown. Ursache: GKE kann Posten beim Start und Stopp von Nodes noch nicht zuordnen, etwa bei automatischer Skalierung.

Quellen

Gelesen am 2026-10-16. OpenCost OpenCost Specification und API; Kubernetes Resource Management for Pods and Containers und Namespaces; AWS Understanding split cost allocation data, Enabling split cost allocation data, Split Cost Allocation Data mit CloudWatch Container Insights, Kubernetes-Labels für die Kostenzuordnung in EKS, Example of split cost allocation data und Split line item columns; Microsoft Azure Kubernetes Service (AKS) cost analysis und View Kubernetes costs; Google Get key spending insights for your GKE resource allocation and cluster costs.