Kubernetes-Kostenzuordnung mit OpenCost auf AKS

Die Kubernetes-Preisseite jedes Cloud-Anbieters wirbt mit einer kleinen Verwaltungsgebühr. Was sie verschweigt: Ein einzelner AKS-Cluster mit vierzig Workloads über zwölf Teams erzeugt eine einzige, undifferenzierte Rechnung. Das Controlling sieht "AKS-Compute: EUR 38.000". Niemand kann sagen, welche Produktlinie, welches Team oder welches Feature diese Kosten verursacht hat. Diese Intransparenz ist der häufigste Grund, warum Kubernetes-Kosteninitiativen ins Stocken geraten.

Die Kubernetes-Kostenzuordnung ist die Disziplin, diese eine Zahl in eine Aufschlüsselung pro Namespace, pro Team und pro Workload zu verwandeln, die Sie in einer Budgetbesprechung vertreten können. OpenCost — das CNCF-Projekt — und sein kommerzielles Pendant Kubecost sind die Standardwerkzeuge dafür auf AKS. Dieser Beitrag beschreibt das Zuordnungsmodell, das wir bei CC Conceptualise ausrollen — einschließlich der Punkte, die die Dokumentation auslässt.

TL;DR / Kernaussagen

• OpenCost ordnet die Kosten geteilter AKS-Knoten bis auf einzelne Pods zu — anhand von Ressourcen-Requests, tatsächlicher Nutzung und realen Azure-Preisen — und ermöglicht so Namespace- und Team-Chargeback.
• Idle-Kosten (die Lücke zwischen bezahlter und genutzter Kapazität) betragen typischerweise 30-50 % der AKS-Compute-Ausgaben und müssen getrennt ausgewiesen werden, sonst tricksen Teams einander aus, statt sie zu beheben.
• OpenCost ist die kostenlose, offene Zuordnungs-Engine; Kubecost ist die kommerzielle Schicht (Oberfläche, Aufbewahrung, Multi-Cluster, Governance) darüber. Die Wahl hängt vom Betriebsmodell und der Skalierung ab, nicht von der Zuordnungsgenauigkeit.
• Binden Sie OpenCost zuerst an Ihren Azure-Abrechnungsexport an, damit die Zuordnung Reserved-Instance- und Savings-Plan-Rabatte widerspiegelt und mit der tatsächlichen Rechnung abstimmbar ist.
• Zuordnung schafft nur dann Wert, wenn sie mit einem Verantwortungsmodell verbunden ist — zunächst Showback, Chargeback erst, wenn die Zahlen vertrauenswürdig sind.

Warum Container-Kostentransparenz auf AKS schwierig ist

Das Azure-Portal rechnet pro Knoten, pro Datenträger, pro Load Balancer ab. Kubernetes plant viele Pods auf jeden Knoten, ohne natives Konzept davon, welcher Pod was gekostet hat. Die Zuordnung zwischen der Ressource, für die Sie zahlen (ein Knoten), und der Einheit, die Sie interessiert (ein Workload im Besitz eines Teams), existiert in keinem der beiden Systeme. Die Kostenzuordnung ist die Schicht, die sie herstellt.

Drei Tatsachen machen dies schwieriger als das Taggen von VMs:

1. Pods teilen sich Knoten. Der Stundenpreis eines Knotens muss auf jeden darauf geplanten Pod aufgeteilt werden, gewichtet nach dem jeweiligen Verbrauch.
2. Requests und Nutzung weichen ab. Ein Team fordert vielleicht 4 vCPU an und nutzt 0,5. Sie können nach Request (was reserviert wurde) oder nach Nutzung (was verbraucht wurde) zuordnen — und die Antwort verändert die Rechnung erheblich.
3. Kapazität wird nie vollständig genutzt. Der ungeplante Rest jedes Knotens sind reale Ausgaben, die keinem Workload gehören. Verteilen Sie sie stillschweigend auf die Teams, bestrafen Sie effiziente Teams für die Überprovisionierung des Clusters.

OpenCost löst das Erste durch anteilige Zuordnung, macht das Zweite durch Ausweis beider Dimensionen sichtbar und löst das Dritte, indem es Idle-Kosten als eigene Position ausweist.

Wie OpenCost die Zuordnung berechnet

OpenCost läuft als leichtgewichtiger Agent neben Prometheus. Für jeden Pod misst es über jedes Zeitfenster den Verbrauch von CPU, Arbeitsspeicher, GPU, persistentem Volume und Netzwerk. Es multipliziert jede Dimension mit dem effektiven Stundenpreis der zugrunde liegenden Ressource — gezogen aus der Azure Rate Card oder, besser, aus Ihrem Abrechnungsexport, damit Rabatte greifen — und summiert sie zu Kosten pro Pod.

Loading diagram...

Aus den Kosten je Pod aggregiert es nach jeder gewünschten Dimension:

Aggregationsschlüssel	Typischer Einsatz	Eignung für Chargeback
Namespace	Team- oder Produktgrenze	Stark — sofern Namespaces sauber auf Kostenstellen abbilden
Label / Annotation	Querschnitt (z. B. cost-center, env)	Am stärksten — übersteht Namespace-Wildwuchs
Controller / Deployment	Kosten je Service	Gut für Engineering, zu granular fürs Controlling
Cluster	Umgebung (Prod/Stage/Dev)	Grobe Aggregation für das Management-Reporting

Die wichtigste Entscheidung ist der Zuordnungsschlüssel, und er sollte ein Label sein, kein Namespace. Namespaces driften; ein per Admission-Policy erzwungenes cost-center-Label nicht. Wir geben beim Cluster-Onboarding einen kleinen Satz verpflichtender Labels vor, gerade damit die Zuordnung später nie bricht.

Das Problem der Idle-Kosten

Bei den Idle-Kosten finden die meisten Projekte ihre Einsparungen — und die meisten internen Werkzeuge verstecken sie. Wenn die Knoten Ihres Clusters 100 vCPU bereitstellen und die Workloads 60 anfordern, sind die 40 vCPU Differenz bezahlte, ungenutzte Kapazität.

OpenCost weist Idle als eigenen Posten aus, statt es in die Team-Zuordnung einzurechnen. Das ist eine Frage des Verhaltens, nicht nur der Genauigkeit. Wird Idle versteckt, wird die Überprovisionierung des Platform-Teams den Produktteams in Rechnung gestellt, die dann über eine Zahl streiten, die sie nicht beeinflussen können. Wird Idle sichtbar, sehen alle eine gemeinsame Ineffizienz von 40 %, und das Gespräch dreht sich um die tatsächlichen Hebel: Rightsizing der Requests, Tuning des Cluster Autoscalers und Konsolidierung fragmentierter Node Pools.

Speziell auf AKS treiben drei Muster die Idle-Kosten:

• Überdimensionierte Requests, aus einer Vorlage kopiert, die niemand mehr überprüft hat. Requests, nicht Limits, reservieren planbare Kapazität — aufgeblähte Requests verbrennen also direkt Geld.
• Node-Pool-Fragmentierung — zu viele kleine Pools, die jeweils Overhead für Systemkomponenten tragen und sich nicht eng bin-packen lassen.
• Autoscaler-Reserve, vorgehalten für Lastspitzen, die selten eintreffen. Etwas Reserve ist legitim; die meisten Cluster tragen weit mehr, als ihr tatsächliches Lastprofil rechtfertigt.

OpenCost vs. Kubecost: Was Sie wirklich brauchen

Das ist die Frage, die jeder Platform Lead stellt, und die ehrliche Antwort lautet: Sie sind keine Konkurrenten — Kubecost baut auf OpenCost auf. Die Entscheidung betrifft Ihr Betriebsmodell.

Dimension	OpenCost (Open Source)	Kubecost (kommerziell)
Zuordnungsgenauigkeit	Voll	Voll (gleiche Engine)
Kosten	Kostenlos	Lizenz je Cluster / je Knoten
Oberfläche	Basis; Grafana selbst bauen	Reichhaltige, rollenbasierte Dashboards
Datenaufbewahrung	Prometheus-gebunden (standardmäßig kurz)	Langfristig, dauerhafter Speicher
Multi-Cluster-Aggregation	Manuell	Integriert
Einsparempfehlungen	Keine	Gesteuert, umsetzbar
SSO / RBAC für Finanznutzer	Nein	Ja
Support	Community	Enterprise-SLA

Wählen Sie OpenCost, wenn Sie ein oder zwei Cluster betreiben, Ihr Team Prometheus und Grafana sicher beherrscht und das Controlling exportierte CSV-Dateien verarbeitet. Wählen Sie Kubecost, wenn Sie viele Cluster betreiben, lange Aufbewahrung für Trendanalysen und Nachweispflichten brauchen oder Nicht-Techniker hinter SSO selbst auf Kostendaten zugreifen sollen. Der Auslöser ist Skalierung und Breite der Beteiligten, nicht eine Lücke in der Zuordnungsmathematik.

In einer jüngst von uns begleiteten Post-Merger-Konsolidierung für einen Fertigungskunden genügte OpenCost für die ersten beiden Cluster; als wir sieben Geschäftsbereiche auf eine gemeinsame Plattform vereint hatten, machten die Anforderungen an Aufbewahrung und Multi-Cluster Kubecost zur günstigeren Option — sobald wir den damit ersetzten Grafana-Eigenbau einrechneten.

Checkliste für Einführung und Rollout

1. OpenCost installieren mit Prometheus auf jedem Cluster (Helm). Prüfen, dass Knoten- und Pod-Metriken erfasst werden.
2. Azure-Preise anbinden über den Abrechnungsexport, nicht Listenpreise, damit Reserved-Instance- und Savings-Plan-Rabatte in die Zuordnung einfließen und mit der Rechnung abstimmbar sind.
3. Zuordnungs-Labels erzwingen (cost-center, team, env) über eine Admission-Policy — Azure Policy für AKS oder eine Gatekeeper/Kyverno-Constraint — sodass Workloads ohne Label abgelehnt werden.
4. Gegen die Rechnung validieren. Summieren Sie alle Zuordnungen plus Idle und prüfen Sie, ob das Ergebnis innerhalb weniger Prozent mit der Azure-Rechnung übereinstimmt. Falls nicht, ist Ihre Preisquelle falsch.
5. Mit Showback beginnen. Veröffentlichen Sie ein Quartal lang Dashboards je Team. Lassen Sie die Teams die Zahlen sehen und ihnen vertrauen, bevor Geld fließt.
6. Idle getrennt ausweisen und es dem Platform-Team als explizites, verantwortetes Effizienzziel zuweisen.
7. Zu Chargeback übergehen erst, wenn die Zuordnung vertrauenswürdig ist und das Verantwortungsmodell abgestimmt wurde.

Werkzeuge zur Zuordnung sind notwendig, aber nicht hinreichend. Die Zahl verändert Verhalten erst, wenn sie bei einem benannten Verantwortlichen mit Budget landet. Wir nutzen die FinOps-Phasen Inform, Optimize, Operate als Betriebsrahmen: OpenCost liefert Inform, Rightsizing und Autoscaler-Tuning liefern Optimize, und Chargeback mit Policy-Leitplanken liefert Operate.

Wo dies in Ihr breiteres Azure-Kostenprogramm passt

Kubernetes ist eine Workload-Klasse. Dieselbe FinOps-Disziplin gilt für Ihre gesamte Umgebung, und die Container-Zuordnung sollte sich darin einfügen, statt als Silo zu existieren. Wenn Sie das breitere Programm aufbauen, kombinieren Sie dies mit Azure Cost Anomaly Detection, damit eine plötzliche AKS-Spitze noch am selben Tag erkannt wird, mit GPU- und KI-Workload-Kostensteuerung, falls Sie Modelltraining oder Inferenz auf GPU-Node-Pools betreiben, und mit Microsoft Fabric Capacity Sizing, wo Ihre Datenplattform dasselbe Chargeback-Modell teilt.

Der Zielzustand ist eine einzige Verantwortungslandkarte: Jeder Euro Cloud-Ausgabe lässt sich einem Verantwortlichen zuordnen — Container-Kosten eingeschlossen.

FAQ

Was ist der Unterschied zwischen OpenCost und Kubecost?

OpenCost ist das quelloffene CNCF-Projekt, das eine herstellerneutrale Spezifikation für die Kubernetes-Kostenzuordnung definiert und einen kostenlosen Monitoring-Agenten bereitstellt. Kubecost ist das kommerzielle Produkt auf derselben Engine und ergänzt eine reichhaltigere Oberfläche, längere Datenaufbewahrung, Multi-Cluster-Aggregation, Einsparempfehlungen und Enterprise-Support. Für die meisten Teams liefert OpenCost die Zuordnungsdaten, Kubecost die Workflow- und Governance-Ebene darüber.

Wie ordnet OpenCost die Kosten eines geteilten AKS-Knotens einzelnen Pods zu?

OpenCost misst je Pod die angeforderten und tatsächlich genutzten Ressourcen für CPU, Arbeitsspeicher, GPU, persistenten Speicher und Netzwerk und weist dem Pod einen anteiligen Teil des Stundenpreises des zugrunde liegenden Knotens zu. Es zieht reale Azure-Preise über die Azure Rate Card sowie Ihre Reservierungs- oder Savings-Plan-Rabatte heran, sodass die Zuordnung dem entspricht, was Sie tatsächlich zahlen, nicht dem Listenpreis. Kosten, die keinem Workload zugeordnet werden können, werden als Idle-Kosten ausgewiesen.

Kann OpenCost die Kosten eines einzelnen Namespace oder Teams auf AKS anzeigen?

Ja. Die Zuordnung lässt sich nach Namespace, Label, Annotation, Controller, Deployment oder beliebiger Kombination aggregieren, was Namespace- oder Label-basiertes Chargeback überhaupt erst ermöglicht. Die meisten Unternehmen ordnen Namespaces oder ein Team-Label den Kostenstellen zu und exportieren diese Aggregate in Showback-Dashboards oder Chargeback-Berichte. Das ist die Grundlage der Container-Kostentransparenz in einem mandantenfähigen Cluster.

Berücksichtigt OpenCost AKS Reserved Instances und Savings Plans?

OpenCost spiegelt den effektiv gezahlten Tarif wider, sobald es mit Ihrem Azure-Abrechnungsexport oder einer eigenen Preisquelle konfiguriert ist, sodass Reservierungs- und Savings-Plan-Rabatte in die Zuordnung pro Namespace einfließen. Ohne diese Integration fällt es auf On-Demand-Listenpreise zurück, was die Kosten überzeichnet. Wir binden OpenCost grundsätzlich zuerst an den Azure-Abrechnungsexport an, damit die Chargeback-Zahlen mit der tatsächlichen Rechnung abstimmbar sind.

Was sind Idle-Kosten in Kubernetes und warum sind sie relevant?

Idle-Kosten sind die Differenz zwischen der bezahlten Knotenkapazität und der Kapazität, die Ihre Workloads tatsächlich anfordern und nutzen. In realen AKS-Clustern betragen sie häufig 30 bis 50 Prozent der Compute-Ausgaben, getrieben durch überdimensionierte Requests, fragmentiertes Bin-Packing und Reserve für Autoscaling. Idle-Kosten getrennt auszuweisen verhindert, dass sich Teams gegenseitig für eine gemeinsame Ineffizienz verantwortlich machen, und weist direkt auf Rightsizing und Autoscaler-Tuning hin.

Genügt OpenCost oder brauchen Unternehmen Kubecost?

OpenCost genügt, wenn Sie ein oder zwei Cluster betreiben, ein Team haben, das mit Prometheus und Grafana vertraut ist, und ein Finanzprozess die exportierten Daten verarbeitet. Kubecost rechtfertigt seine Lizenz, wenn Sie viele Cluster betreiben, lange Aufbewahrung für Trendanalysen und Nachweispflichten brauchen, gesteuerte Einsparempfehlungen wünschen oder rollenbasierten Zugriff und SSO für nicht-technische Beteiligte benötigen. Die Entscheidung betrifft Betriebsmodell und Skalierung, nicht eine Lücke in der Zuordnungsgenauigkeit.

---

Wenn Sie die Kubernetes-Kostenzuordnung auf AKS aufbauen — oder Ihre bestehenden Chargeback-Zahlen sich nicht mit der Rechnung abstimmen lassen — unterstützen Sie unsere Architekten beim Aufbau eines Modells, dem das Controlling vertraut. Mehr dazu unter Cloud-Architektur und FinOps.