Gemeinsame Kubernetes-Kosten sind die Positionen eines Clusters, die allen Teams dienen und keinem gehören: die Systempods in kube-system, die Add-ons, die Logging- und Monitoring-Agenten auf jedem Node, Ingress-Controller und die Sidecars eines Service Mesh, und die Gebühr für die Steuerungsebene. Sie entstehen, bevor der erste Workload läuft, wachsen mit der Zahl der Nodes statt mit der Last eines Teams, und erreichen die Teamzahlen nur über einen Verteilschlüssel. Diese Seite benennt die Posten, zeigt, wo sie in den Daten stehen, und rechnet die üblichen Schlüssel an einem Cluster durch. Die allgemeine Regel für geteilte Kosten gilt auch hier; der Leerlauf der Nodes ist ein eigener Rest (Leerlauf- und nicht zugeordnete Clusterkosten).

So funktioniert es

Die Posten lassen sich nach ihrer Form sortieren, denn die Form bestimmt, wie sie wachsen.

Die Gebühr für die Steuerungsebene ist ein fester Betrag je Cluster und Stunde, unabhängig von Nodes und Last: bei Amazon EKS 0,10 USD je Stunde im Standard Support und 0,60 USD im Extended Support, bei AKS im Tarif Standard 0,10 USD je Stunde, bei GKE 0,10 USD je Stunde für jeden Cluster, mit einer Gutschrift für einen zonalen oder Autopilot-Cluster je Rechnungskonto (EKS, AKS und GKE im Vergleich). Sie steht als eigene Position unter dem Kubernetes-Dienst des Anbieters und ist der einzige geteilte Posten, der schon auf der Rechnung so heißt.

DaemonSets wachsen mit den Nodes: Ein Logging-Agent, ein Metrik-Exporter, der Netzwerk-Agent und ein Cost-Agent laufen als eine Kopie je Node, und jede Kopie belegt Requests, die der Node-Preis bezahlt. Dazu kommt die Reservierung, die jeder Node für Kubelet, Container-Runtime und Betriebssystem zurückhält und die nie Allocatable wird. Diese Kosten entstehen in jedem Node-Pool und auf jedem Node, den der Autoscaler anlegt; sie sind der Grund, warum kleine Nodes einen größeren Fixanteil haben (Node-Pools und Instanzauswahl).

Deployments in kube-system und den Add-on-Namespaces wachsen mit dem Cluster, nicht mit den Nodes: CoreDNS, der Metrics Server, der Cluster Autoscaler oder Karpenter, Cert-Manager, der Ingress-Controller, die Steuerungsebene eines Service Mesh. Sie haben Requests wie jeder Workload und stehen in der Zuordnung als Pods mit eigenem Namespace. Die Sidecars eines Service Mesh sind der Sonderfall: Sie laufen im Namespace des Teams, in jedem Pod des Teams, mit eigenen Requests; ihre Kosten landen beim Team, obwohl das Mesh eine Plattformentscheidung war.

Dann die Posten außerhalb der Nodes, die ein Cluster für alle betreibt: ein Load Balancer je Ingress-Controller, die NAT-Gateways, die Datenträger der Systemkomponenten, die Logs der Steuerungsebene, die der Anbieter in seinen Logging-Dienst schreibt und nach Gigabyte berechnet (Services, Load Balancer und Egress). Sie stehen unter anderen Diensten als dem Cluster und werden ihm nur über Tags zugeordnet.

In den Werkzeugen heißen diese Reste verschieden: OpenCost führt die Systemworkloads als geteilte Kosten und die Clustergebühr als Overhead; AWS Split Cost Allocation Data verteilt Instanzkosten auf Pods, die Clustergebühr bleibt eine Position daneben; die Kostenanalyse von AKS weist System Charges und Service Charges getrennt aus; die GKE-Kostenzuordnung schreibt die Reservierung der Nodes unter kube:system-overhead und führt kube-system als gewöhnlichen Namespace.

neinjaden Nodesdem ClusterEin geteilter Posten des ClustersInnerhalb der Nodes?Die Control-Plane-Gebühr, fest jeCluster und Stunde; oder die Postenaußerhalb: Load Balancer, NAT-Gateways,System-Datenträger, Control-Plane-Logs,unter anderen Diensten, über Tags angebundenWächst mit?DaemonSets und die Reservierungdes Nodes: eine Kopie undein Anteil je NodeAdd-ons in kube-system: Podsmit eigenem Namespace; Mesh-Sidecars im Namespace des Teams
Geteilte Posten ordnen sich nach ihrer Form: eine Gebühr je Cluster, Agenten, die mit den Nodes wachsen, Add-ons, die mit dem Cluster wachsen, und Posten außerhalb der Nodes, nur über Tags angebunden

Was es für Ihre Kosten bedeutet

Drei Schlüssel sind üblich, und die OpenCost-Spezifikation nennt sie: gleichmäßig über die Mandanten, proportional zu ihrem Anteil an den Asset-Kosten, oder nach einer eigenen Kennzahl. Gleichmäßig ist einfach und bestraft kleine Teams. Proportional folgt dem Verbrauch und lässt ein Team seine Zahl durch Requests beeinflussen; es ist der Standard für Posten, die mit den Nodes wachsen, weil die DaemonSets dort laufen, wo die Workloads sind. Eine eigene Kennzahl passt dort, wo ein Posten einen messbaren Treiber hat: Ingress-Kosten nach Anfragen oder Bytes je Team, Logging nach ingestierten Gigabyte je Namespace, die Mesh-Sidecars ohnehin je Pod. Die Clustergebühr hat keinen Treiber und wird deshalb gleichmäßig oder proportional verteilt, oder bleibt beim Betreiber.

janeinja: Anfragen, Bytes,Gigabyte, Podsnein: die ClustergebührEin geteilter PostenWächst mit den Nodes?Anteilig zu den Asset-Kosten derTeams: die Agenten laufen dort,wo die Workloads sindEin messbarer Treiber?Eine eigene Metrik: Ingress nachAnfragen, Logging nach Gigabyte,Sidecars je PodGleichmäßig, oder als Zeilebeim Betreiber belassen
Posten, die mit den Nodes wachsen, nehmen den anteiligen Schlüssel, Posten mit messbarem Treiber eine eigene Metrik, und nur, was keines von beidem hat, wird gleichmäßig verteilt

Welcher Schlüssel gilt, ist eine Zuordnungsregel mit Datum, je Posten festgelegt und nicht je Monat neu entschieden. Vor der Verteilung bleiben die Posten als eigene Zeilen sichtbar, je Cluster, weil nur so zu sehen ist, ob ein Cluster zu viele Agenten, einen zu teuren Ingress oder eine Steuerungsebene im Extended Support hat; verteilt sind sie Teil jeder Teamzahl und für niemanden mehr ein Hebel. Ein Cluster je Umgebung multipliziert alle festen Posten (nicht-produktive Cluster).

Wo es schiefgeht

  • Agenten ohne Requests. Symptom: Die geteilten Kosten eines Clusters erscheinen klein, der Leerlauf groß. Ursache: DaemonSets ohne Requests werden nach Requests mit null bewertet; ihre Nutzung fällt in den Leerlauf des Nodes.
  • Sidecars beim Team. Symptom: Ein Team sieht nach Einführung des Service Mesh höhere Kosten bei gleicher Last. Ursache: Der Sidecar je Pod trägt eigene Requests im Namespace des Teams; die Plattformentscheidung wird dem Team zugerechnet.
  • Extended Support in den geteilten Kosten. Symptom: Die Clustergebühr versechsfacht sich. Ursache: Die Kubernetes-Version hat den Standard Support verlassen; der Posten steckt in den geteilten Kosten, und niemand hat ihn bemerkt.
  • Ein Load Balancer je Cluster, einer je Dienst. Symptom: Die geteilten Kosten enthalten Dutzende Load Balancer. Ursache: Services vom Typ LoadBalancer statt eines Ingress; die Posten sind nicht geteilt, sondern den Diensten zuzuordnen.
  • Schlüssel gewechselt. Symptom: Ein Team zahlt plötzlich mehr geteilte Kosten ohne Änderung an seinen Workloads. Ursache: Der Verteilschlüssel wurde geändert, oder ein anderes Team hat den Cluster verlassen.
  • Logs der Steuerungsebene ungesehen. Symptom: Der Logging-Dienst des Anbieters zeigt einen Cluster-Posten, den niemand erwartet. Ursache: Audit- und API-Server-Logs sind eingeschaltet und werden nach Gigabyte berechnet, außerhalb des Clusters.

Beispiel

Listenpreise, gelesen am 2026-10-21: Amazon EKS 0,10 USD je Cluster und Stunde im Standard Support; in Frankfurt (eu-central-1) kostet eine m6i.large (2 vCPU, 8 GiB) 0,115 USD je Stunde, woraus mit dem Verhältnis 9:1 0,0398 USD je vCPU-Stunde und 0,00442 USD je GiB-Stunde folgen (was ein Pod kostet); ein Application Load Balancer kostet 0,027 USD je Stunde ohne Kapazitätseinheiten.

Ein Cluster mit zehn Nodes trägt drei DaemonSets mit zusammen 300 Millicores und 384 MiB Request je Node: 10 × (0,3 × 0,0398 + 0,375 × 0,00442) = 10 × 0,0136 = 0,136 USD je Stunde, 99,28 USD im Monat mit 730 Stunden. CoreDNS, Metrics Server und ein Ingress-Controller mit zusammen 1,5 vCPU und 2 GiB Request kosten 1,5 × 0,0398 + 2 × 0,00442 = 0,0685 USD je Stunde, 50,01 USD im Monat. Die Clustergebühr beträgt 73,00 USD, der Load Balancer des Ingress 19,71 USD. Geteilte Kosten im Monat: 242,00 USD. Bei drei Teams zahlt jedes gleichmäßig 80,67 USD. Proportional, wenn Team A 57 Prozent der Workload-Kosten trägt, zahlt es 137,94 USD und jedes der beiden anderen 52,03 USD. Mit einer eigenen Kennzahl für den Ingress, etwa 80 Prozent der Anfragen bei Team A, trägt A 15,77 USD von dessen 19,71 USD und die übrigen 222,29 USD nach dem Schlüssel der anderen Posten.

Quellen

Gelesen am 2026-10-21. OpenCost-Spezifikation, Amazon EKS Preise, AWS Price List Bulk API, Angebote AmazonEC2 und AWSELB, eu-central-1, AWS Split Cost Allocation Data, Microsoft Kostenanalyse für AKS, Google Cloud GKE-Kostenzuordnung und GKE-Preise, Kubernetes DaemonSet und Rechenressourcen für System-Daemons reservieren.