Kubernetes-Kostendaten entstehen erst durch Zuordnung: Bei Clustern, die je Node abgerechnet werden, berechnet der Cloud-Anbieter Nodes, Disks, Load Balancer und Clustergebühren, keine Pods (GKE Autopilot berechnet Pods für allgemeine Zwecke nach ihren Requests), und erst das Verteilen dieser Kosten nach Requests und Nutzung über die Zeit gibt einem Container, einem Pod oder einem Namespace einen Preis. Für die Rechnung zählt das, weil ein Cluster ohne diese Verteilung ein Block von Instanzkosten bleibt, den sich mehrere Teams teilen, und weil die Wahl der Methode bestimmt, wer reservierte, aber ungenutzte Kapazität bezahlt.
So funktioniert es
Vom Node zum Pod
Ein Pod reserviert mit seinen Requests Kapazität auf einem Node. Der Kubernetes-Scheduler platziert ihn nur dort, wo die Summe der Requests unter der Kapazität des Nodes bleibt, auch wenn die tatsächliche Auslastung niedrig ist; ein Container darf mehr nutzen als angefordert, wenn der Node es hergibt. Die Kosten eines Pods sind deshalb nicht seine Nutzung allein.
OpenCost, ein Incubating-Projekt der Cloud Native Computing Foundation, beschreibt dafür eine herstellerneutrale Spezifikation. Die Gesamtkosten eines Clusters sind dort Asset-Kosten (Nodes, Persistent Volumes, Disks, Load Balancer, Netzwerk) plus Overhead wie die Clustergebühren des Anbieters. Workload-Kosten für CPU, Arbeitsspeicher und GPU rechnet die Spezifikation als das Größere aus Request und Nutzung, Speicher nach dem Request des Persistent Volume Claim, auf Container-Ebene und danach summiert nach Pod, Deployment, Namespace, Label oder Cluster. Was von den zeitbasierten Asset-Kosten keinem Workload zugeordnet ist, sind Idle-Kosten. Idle, Systemlasten wie kube-system und Overhead sind geteilte Kosten, die sich gleichmäßig, im Verhältnis zum Verbrauch oder nach einer eigenen Kennzahl auf die Teams verteilen lassen. Für Kosten aus der Rechnung des Anbieters bindet OpenCost dessen Abrechnungsdaten an.
AWS
Split cost allocation data bringt Kosten je Amazon-ECS-Task und je Kubernetes-Pod in Amazon EKS als eigene Posten in den AWS Cost and Usage Report: je Pod und Stunde zwei Nutzungszeilen für CPU und Arbeitsspeicher, auf Instanzen mit Beschleunigern drei. split_line_item_split_usage ist das Größere aus split_line_item_reserved_usage (konfiguriert) und split_line_item_actual_usage (genutzt), split_line_item_split_cost der Anteil an den amortisierten Kosten der EC2-Instanz, split_line_item_unused_cost der Anteil an ihrer ungenutzten Kapazität, split_line_item_parent_resource_id die Instanz. Dazu kommen die Kostenzuordnungs-Tags aws:eks:cluster-name, aws:eks:namespace, aws:eks:node, aws:eks:workload-name, aws:eks:workload-type und aws:eks:deployment, standardmäßig aktiviert, sowie bis zu 50 Labels je Pod (die ersten 50 in alphabetischer Reihenfolge) als benutzerdefinierte Kostenzuordnungs-Tags, die das Management-Konto aktivieren muss.
Azure
Das Add-on für die Kostenanalyse von AKS baut auf OpenCost auf und gleicht die gemessene Nutzung mit den Rechnungsdaten ab. Es zeigt in Cost analysis die Ansicht Kubernetes clusters mit Namespaces und Assets und weist vier Kostenarten aus: Idle charges (ungenutzte Kapazität), Service charges (etwa Uptime SLA), System charges (von AKS je Node reservierte Kapazität) und Unallocated charges. Voraussetzung sind die Tarife Standard oder Premium und ein Enterprise Agreement oder Microsoft Customer Agreement; virtuelle Nodes werden nicht unterstützt. Die Daten liegen meist nach 8 bis 24 Stunden vor.
Google Cloud
Die Kostenzuordnung für GKE (Standard-Cluster) schreibt Cluster und Namespace als Labels in den Detailed-Export von Cloud Billing: goog-k8s-cluster-name, k8s-namespace, k8s-workload-type, k8s-workload-name und jedes Pod-Label als k8s-label/ mit seinem Schlüssel. Die Zuordnung beruht auf Requests, nicht auf Nutzung. Kapazität, die das System für den Node reserviert, erscheint als Namespace kube:system-overhead, nicht angeforderte Kapazität als kube:unallocated. Unterstützt werden SKUs für vCPU, RAM, GPU, Persistent Disk und Cloud TPU; nach dem Aktivieren dauert es bis zu drei Tage, rückwirkend lädt GKE nichts.
| Quelle | Wo die Daten landen | Einheit | Idle und geteilte Kosten | Was fehlt |
|---|---|---|---|---|
| OpenCost | eigene Installation im Cluster | Container, summierbar | Idle als Differenz, Verteilung nach Methode | was der Agent nicht sieht; Rechnungsdaten nur über die Anbindung |
| AWS | CUR 2.0, Split-Line-Item-Spalten | ECS-Task, EKS-Pod je Stunde | ungenutzte Kosten je Pod in eigener Spalte | alles außer CPU, Arbeitsspeicher und Beschleunigern der Instanz |
| Azure | Ansichten in Cost analysis | Namespace, Asset | Idle, System, Service, Unallocated charges | Free-Tarif, andere Vertragsarten, virtuelle Nodes |
| Google Cloud | Detailed-Export in BigQuery | Namespace, Workload, Label | kube:unallocated, kube:system-overhead | Nutzung über den Request hinaus, nicht unterstützte SKUs, Standard-Export |
Was es für Ihre Kosten bedeutet
Die Zuordnung ändert die Rechnung nicht, sie verteilt sie; Google weist ausdrücklich darauf hin, dass die Summe im Export gleich bleibt. Unterschiedlich ist die Regel: OpenCost berechnet das Größere aus Request und Nutzung, GKE nur den Request und AWS das, was der Zahler beim Aktivieren der Split Cost Allocation Data aus drei Optionen gewählt hat: nur die Resource Requests oder das Größere aus Request und Nutzung, mit Nutzungsmetriken entweder aus Amazon Managed Service for Prometheus oder aus Amazon CloudWatch Container Insights. Auf Instanzen mit Beschleunigern (GPU, Trainium, Inferentia) verteilt AWS immer nach Requests, gleich welche Option gewählt ist. Ein Team, das hohe Requests setzt, trägt damit Kapazität, die es reserviert und nicht nutzt, und dieselbe Nutzung ergibt je nach Quelle verschiedene Teamsummen.
Für den Bericht entscheidet, wie mit Idle, System und Nicht-Zugeordnetem umgegangen wird. Als eigene Zeile zeigen sie, wie viel des Clusters niemandem gehört; der Anteil der Clusterkosten, der auf Namespaces liegt, ist der Zuordnungsgrad. Verteilt man sie auf die Teams, stimmen die Teamsummen mit der Rechnung überein, und die ungenutzte Kapazität verschwindet aus dem Blick. Ob sie abgebaut werden kann, ist eine Frage von ungenutzten und verwaisten Ressourcen; was ein Node kostet, beschreibt Virtuelle Maschinen und Instanzfamilien.
Namespaces und Labels sind die Schlüssel der Kostenzuordnung im Cluster, so wie Tags es außerhalb sind (Tags und Labels). Bei AWS verteilen die Split-Daten nur die Instanz, bei GKE nur die unterstützten Instanz-, Disk- und TPU-SKUs; Load Balancer, Clustergebühren und Datentransfer bleiben dort außerhalb der Pods. Wo die Rohdaten liegen, beschreiben Google-Cloud-Abrechnungsexport nach BigQuery und Azure-Kostenexporte.
Wo es schiefgeht
- Pod-Kosten werden nur aus der Nutzung gerechnet. Symptom: Die Summe der Namespaces liegt weit unter den Node-Kosten. Ursache: Requests reservieren Kapazität unabhängig von der Nutzung; der Rest ist Idle und muss als eigene Zeile oder verteilt erscheinen.
- Die Namespace-Labels fehlen im GKE-Export. Symptom: Nur Node-Kosten, kein
k8s-namespace. Ursache: Die Kostenzuordnung ist nicht aktiviert, ist jünger als drei Tage, oder es wird der Standard-Export abgefragt. - Pod-Labels fehlen trotz Kostenzuordnung. Symptom: Namespace vorhanden, keine
k8s-label/-Labels. Ursache: Hat ein Pod mehr als 50 Kubernetes-Labels, übernimmt GKE keines davon. - Die AKS-Ansicht bleibt leer. Symptom: Keine Namespaces in Cost analysis. Ursache: Der Cluster läuft im Free-Tarif, das Abonnement hat keinen EA- oder MCA-Vertrag, oder die Workloads laufen auf virtuellen Nodes.
- Die Teamsummen ergeben nicht die Clusterkosten. Symptom: Eine Lücke zwischen Namespaces und Rechnung. Ursache: Idle, System-Overhead, nicht zugeordnete Kapazität und clusterweite Kosten stehen in eigenen Zeilen oder außerhalb der Pod-Daten.
Quellen
Gelesen am 2026-10-16. OpenCost Overview und OpenCost Specification; Kubernetes Resource Management for Pods and Containers; AWS Understanding split cost allocation data, Split Cost Allocation Data aktivieren, Split Cost Allocation Data mit CloudWatch Container Insights, Kubernetes-Labels für die Kostenzuordnung in EKS und Split line item columns; Microsoft Azure Kubernetes Service (AKS) cost analysis; Google Get key spending insights for your GKE resource allocation and cluster costs und GKE-Preise.