Die Kosten eines Kubernetes-Pods sind der Anteil am Stundenpreis des Nodes, auf dem er läuft, bemessen nach dem Größeren aus seinen Resource Requests und seiner tatsächlichen Nutzung, je Ressource getrennt. Kein Cloud-Anbieter stellt einen Pod in Rechnung: AWS, Azure und Google Cloud berechnen Nodes, und erst eine Zuordnungsregel macht daraus einen Preis je Pod. Diese Seite beschreibt die Regel, die OpenCost und GKE Autopilot verwenden, was Limits und QoS-Klassen daran ändern, wie der Preis eines Nodes auf CPU und Arbeitsspeicher aufgeteilt wird und warum die Lücke zwischen Request und Nutzung als Leerlauf übrig bleibt. Die Verteilung auf Teams behandelt Kubernetes-Kostenzuordnung, die Datengrundlage Kubernetes-Kostendaten.

So funktioniert es

Ein Pod fordert mit seinen Resource Requests CPU und Arbeitsspeicher an. Der Scheduler reserviert diese Menge auf einem Node, gleich ob der Container sie nutzt, und ein Node ist voll, sobald die Summe der Requests seine Allocatable-Kapazität erreicht. Ein Limit begrenzt, was der Container höchstens nutzen darf; es reserviert nichts. Aus Requests und Limits ergibt sich die QoS-Klasse: Guaranteed, wenn jeder Container für CPU und Arbeitsspeicher ein Limit gleich dem Request hat, Burstable, wenn mindestens ein Request oder Limit gesetzt ist, BestEffort, wenn keines gesetzt ist. Die Klasse steuert die Verdrängung bei Speicherdruck und ändert am Preis des Nodes nichts.

Die OpenCost-Spezifikation definiert die Kosten eines Workloads je Ressource als max(request, usage): Wer reserviert, zahlt die Reservierung, wer über den Request hinaus nutzt, zahlt die Nutzung. Limits kommen in der Formel nicht vor. Die Spezifikation rechnet zuerst die Asset-Kosten des Clusters aus, also Nodes, Datenträger und Load Balancer, und zerlegt dann jeden Node: Die Kosten der Workloads plus die Leerlaufkosten ergeben die Kosten der Assets, und mit dem Overhead wie der Clustergebühr die Gesamtkosten des Clusters.

Dafür braucht ein Node einen Preis je vCPU-Stunde und je GiB-Stunde, den kein Anbieter veröffentlicht; veröffentlicht ist nur der Preis der ganzen Maschine. Die Spezifikation empfiehlt ein festes Verhältnis zwischen den Ressourcenpreisen, das auf den Preis des Nodes normiert wird: AWS verwendet für Split Cost Allocation Data das Verhältnis 9:1 zwischen vCPU-Stunde und GB-Stunde, abgeleitet aus den Fargate-Preisen. Der Preis einer vCPU-Stunde ist dann der Node-Preis mal dem Anteil der CPU-Gewichte an allen Gewichten, geteilt durch die Zahl der vCPUs; für den Arbeitsspeicher entsprechend. Eingabe sind nach der Spezifikation die vollständig amortisierten Nettokosten des Nodes, nicht der On-Demand-Listenpreis, wenn ein Commitment oder ein Spot-Preis auf ihm liegt.

Der amortisierte Nettopreis des Nodesje Stunde, die einzige öffentliche ZahlMit festem Gewicht zwischen CPUund Speicher geteilt, skaliertauf den Preis des NodesEin Preis je vCPU-Stundeund je GiB-StundeDie Kosten eines Pods: das Größere ausRequest und Nutzung je Ressource, maldiesem Preis; Limits spielen keine RolleWorkload-Kosten plus Leerlauf ergebendie Kosten des Nodes; mit Clustergebührund Overhead die Summe des Clusters
Der Preis des Nodes wird mit festem Gewicht in vCPU- und GiB-Preise geteilt, jeder Pod zahlt das Größere aus Request und Nutzung, und der Rest ist der Leerlauf des Nodes

AWS

Bei Amazon EKS mit EC2-Nodes entsteht der Pod-Preis allein durch diese Rechnung; die Rechnung von AWS kennt nur die Instanz. Split Cost Allocation Data im Cost and Usage Report nimmt die Rechnung AWS ab und verteilt die amortisierten Instanzkosten nach Requests, wahlweise nach dem Größeren aus Request und Nutzung mit Metriken aus Container Insights oder Amazon Managed Service for Prometheus. Auf AWS Fargate gibt es keinen Node: AWS berechnet je Pod die angeforderte vCPU und den angeforderten Arbeitsspeicher je Sekunde, und max(request, usage) wird zu request, weil ein Fargate-Pod nicht über seine Requests hinaus wachsen kann.

Azure

AKS berechnet Nodes als virtuelle Maschinen. Die Kostenanalyse von AKS zerlegt sie nach Namespaces und weist Leerlauf, Systemanteil und Dienstgebühren getrennt aus; die Regel ist dieselbe wie oben, die Kosten je Pod kommen aus den Requests.

Google Cloud

GKE Autopilot ist der eine Fall, in dem der Anbieter selbst nach Pods abrechnet: CPU, Arbeitsspeicher und Ephemeral Storage aus den Requests jedes eingeplanten Pods, je Sekunde, in der allgemeinen Compute-Klasse ohne Node-Preis. Fehlende Requests ersetzt Autopilot durch Standardwerte, zu kleine hebt es auf das Minimum und das zulässige Verhältnis von CPU zu Arbeitsspeicher an. In GKE Standard gilt die Node-Rechnung wie bei EKS, und die GKE-Kostenzuordnung im Abrechnungsexport verteilt nach Requests.

Was es für Ihre Kosten bedeutet

Die Konvention bestimmt, welches Verhalten ein Team bezahlt. Nach max(request, usage) kostet ein zu großer Request, weil die Reservierung bezahlt wird, und ein zu kleiner Request kostet ebenfalls, sobald die Nutzung darüber liegt. Ein Team senkt seine Pod-Kosten deshalb nur, indem es Requests an die gemessene Nutzung heranführt, mit Spitzen eingerechnet. Was zwischen der Summe der Pod-Kosten und dem Preis des Nodes bleibt, ist der Leerlauf des Nodes; er gehört zunächst niemandem, und Leerlauf- und nicht zugeordnete Clusterkosten beschreibt, wie er verteilt wird.

der Requestdie NutzungDer Request eines Pods gegenseine gemessene NutzungWas ist größer?Die Reservierung wird bezahlt:die Lücke zur Nutzung sind Kostenfür Kapazität, die nichts tutDie Nutzung wird bezahlt: der Podwuchs über das Reservierte hinausPod-Kosten sinken nur, wenn Requestsan die gemessene Nutzung heranrückenWas unter dem Preis des Nodes bleibt,ist der Leerlauf des Nodes,zunächst niemandes
Unter der Konvention zahlt ein zu großer Request die Reservierung und ein zu kleiner die Nutzung, deshalb senkt ein Team seine Pod-Kosten nur, indem es Requests an die gemessene Nutzung heranführt

Erstens erhalten BestEffort-Pods ohne Request bei reiner Request-Verteilung null Kosten, obwohl sie Kapazität belegen; die Nutzungskomponente von max(request, usage) fängt das auf, verlangt aber Nutzungsmetriken. Zweitens ist der Pod-Preis eine Ableitung aus dem Node-Preis: Ein günstigerer Node-Pool senkt jeden Pod auf ihm, ein Spot-Node ebenso, ohne dass ein Manifest sich ändert. Drittens ändern Limits den Preis nicht; sie entscheiden nur, ob ein Container gedrosselt oder beendet wird, und in GKE Autopilot wird ohnehin der Request abgerechnet. Ein Preis je Pod ist deshalb eine Zuordnungsregel mit Datum, keine Rechnungszeile.

Wo es schiefgeht

  • Pod ohne Request kostet nichts. Symptom: Ein Namespace mit vielen Pods weist fast keine Kosten aus. Ursache: Die Pods sind BestEffort, und die Verteilung rechnet nur nach Requests; ihre Nutzung landet im Leerlauf des Nodes.
  • Requests gesenkt, Pod-Kosten gleich. Symptom: Nach dem Rightsizing der Requests ändert sich die Summe je Pod kaum. Ursache: Die Nutzung lag über dem neuen Request, und max(request, usage) rechnet nun die Nutzung.
  • Teamsummen schwanken mit der Last. Symptom: Die Kosten eines Teams steigen in Lastspitzen, obwohl die Node-Zahl gleich bleibt. Ursache: Die Nutzungskomponente der Formel folgt den Spitzen; nur die Verteilung ändert sich, nicht die Rechnung.
  • Autopilot teurer als das Manifest. Symptom: Ein Pod wird mit mehr vCPU oder Arbeitsspeicher abgerechnet, als im Manifest steht. Ursache: Autopilot hebt Requests auf das Minimum und das zulässige Verhältnis an und berechnet auch Pods in Fehlerschleifen.
  • Listenpreis statt amortisierter Kosten. Symptom: Die Summe der Pod-Kosten liegt über dem, was die Rechnung für die Nodes zeigt. Ursache: Die Zuordnung rechnet mit dem On-Demand-Preis, obwohl ein Savings Plan oder eine Reservierung auf den Nodes liegt.

Beispiel

Listenpreis, gelesen am 2026-10-21 aus der AWS-Preisliste für Frankfurt (eu-central-1): eine Instanz m6i.large (2 vCPU, 8 GiB) kostet On-Demand unter Linux 0,115 USD je Stunde, im Monat mit 730 Stunden 83,95 USD. Mit dem Verhältnis 9:1 von AWS wiegen die 2 vCPU 18 und die 8 GiB 8 Einheiten, zusammen 26. Der CPU-Anteil ist 18/26 × 0,115 = 0,0796 USD je Stunde, also 0,0398 USD je vCPU-Stunde; der Speicheranteil 8/26 × 0,115 = 0,0354 USD je Stunde, also 0,00442 USD je GiB-Stunde.

Ein Pod mit 500 Millicores und 1 GiB Request, der 200 Millicores und 600 MiB nutzt, wird nach max(request, usage) mit 0,5 vCPU und 1 GiB bewertet: 0,5 × 0,0398 + 1 × 0,00442 = 0,0243 USD je Stunde, 17,76 USD im Monat. Ein zweiter Pod mit 250 Millicores und 512 MiB Request, der 800 Millicores nutzt, wird mit 0,8 vCPU und 0,5 GiB bewertet: 0,8 × 0,0398 + 0,5 × 0,00442 = 0,0341 USD je Stunde, 24,86 USD im Monat. Zusammen beanspruchen beide 0,0584 USD der 0,115 USD, die der Node je Stunde kostet; die übrigen 0,0566 USD je Stunde sind Leerlauf, bis weitere Pods ihn füllen. In GKE Autopilot in Frankfurt (europe-west3) kostet derselbe erste Pod nach der Preisliste vom 2026-10-21 direkt 0,5 × 0,0573 + 1 × 0,0063421 = 0,0350 USD je Stunde, 25,54 USD im Monat, ohne Node und ohne Leerlauf.

Quellen

Gelesen am 2026-10-21. OpenCost-Spezifikation, Kubernetes Ressourcenverwaltung für Pods und Container und Quality of Service für Pods, AWS Split Cost Allocation Data, AWS Fargate Preise, AWS Price List Bulk API, Angebot AmazonEC2, eu-central-1, Microsoft Kostenanalyse für AKS, Google Cloud Resource Requests in Autopilot, GKE-Kostenzuordnung und GKE-Preise.