Kubernetes Kosten lassen sich nicht in einer einzelnen Zahl ausdrücken, weil sie sich aus sechs unterschiedlichen Blöcken zusammensetzen: Nodes, Load Balancer, Storage, Egress-Traffic, die Betriebszeit deines Teams und, wenn du Managed Kubernetes nutzt, ein Aufschlag des Anbieters obendrauf. Wer nur die Node-Preise vergleicht, unterschätzt seine tatsächlichen Kosten fast immer, weil gerade der letzte Block, die eigene Betriebszeit, in keiner Preisliste eines Cloud-Anbieters auftaucht.
Ich betreibe produktionsreife Kubernetes-Cluster auf gemieteter Cloud-Infrastruktur und berate Unternehmen dabei, ihre Cluster-Kosten realistisch einzuschätzen. Alle meine Beiträge zum Betrieb von Kubernetes-Clustern findest du gesammelt auf der Seite Kubernetes. Konkrete Euro-Beträge nenne ich hier bewusst nicht, weil sie sich mit jedem Anbieter, jeder Region und jedem Vertrag ändern und ohne aktuelle Quelle schnell veraltet und irreführend wären. Was du stattdessen bekommst, ist die Struktur, mit der du deine eigene Rechnung sauber aufstellen kannst.
Kubernetes Kosten: die sechs Blöcke, die zählen
Der erste Block sind die Nodes selbst, also die virtuellen oder physischen Server, auf denen deine Pods laufen. Der zweite Block ist der Load Balancer, den fast jeder Cluster für eingehenden Traffic braucht. Der dritte Block ist Storage, für persistente Volumes ebenso wie für Backups und Object Storage. Der vierte Block ist Egress-Traffic, also Daten, die den Cluster oder das Rechenzentrum des Anbieters verlassen. Der fünfte Block ist die Betriebszeit deines Teams, für Updates, Monitoring, Fehlersuche und Kapazitätsplanung. Der sechste Block ist der Managed-Aufschlag, den ein Anbieter für die Übernahme der Control Plane und eines Teils der Betriebslast verlangt.
Diese sechs Blöcke wiegen bei jedem Unternehmen unterschiedlich schwer. Ein datenintensiver Dienst mit viel externem Traffic spürt den Egress-Block deutlich stärker als ein internes Tool ohne nennenswerten ausgehenden Traffic. Ein kleines Team ohne eigene Kubernetes-Erfahrung spürt die Betriebszeit stärker als ein eingespieltes Plattform-Team. Genau deshalb ist eine pauschale Zahl für „was kostet ein Kubernetes-Cluster" wenig hilfreich, eine Aufschlüsselung nach diesen Blöcken dagegen schon.
Node-Kosten: worauf es wirklich ankommt
Node-Kosten hängen zunächst simpel von Größe und Anzahl ab, aber zwei Punkte werden regelmäßig übersehen. Erstens braucht jeder Node einen Sockel an Ressourcen für Kubernetes-eigene Prozesse wie Kubelet, Container-Runtime und Systemdienste, bevor überhaupt eine deiner Anwendungen dort Platz findet. Diese Reserve ist bei kleinen Nodes prozentual größer als bei großen, weshalb viele kleine Nodes tendenziell teurer sind als wenige große, bei gleicher gesamter Kapazität. Zweitens brauchst du bei Managed Kubernetes zusätzliche Nodes für die Control Plane meist nicht selbst zu bezahlen, während du bei einem selbst betriebenen Cluster, etwa mit k3s auf gemieteter Infrastruktur, die Control-Plane-Nodes aus eigener Tasche finanzierst, auch wenn sie selbst keine Anwendungslast tragen.
Wie viele Ressourcen deine Anwendungen tatsächlich brauchen, siehst du am ehesten über die Metriken deines Clusters, nicht über eine Schätzung vom Schreibtisch aus. Ein einfacher erster Schritt:
kubectl top nodes
kubectl describe node <nodename> | grep -A 5 Allocatable
Der erste Befehl zeigt dir die aktuelle CPU- und Speicherauslastung jedes Nodes, der zweite die tatsächlich für Pods verfügbare Kapazität nach Abzug der Systemreserve. Liegt die Auslastung dauerhaft weit unter der Allocatable-Kapazität, zahlst du für Kapazität, die nie genutzt wird, ein häufiger und leicht zu behebender Kostentreiber.
Load Balancer und Storage: die unterschätzten Posten
Ein Load Balancer wirkt auf den ersten Blick nach einer Kleinigkeit, wird aber schnell zum eigenen Kostenblock, sobald du für mehrere Dienste jeweils einen eigenen Load Balancer anlegst, statt eingehenden Traffic über einen gemeinsamen Ingress-Controller zu bündeln. Bei den meisten Cloud-Anbietern kostet jeder Load Balancer laufend, unabhängig davon, wie viel Traffic tatsächlich durchläuft.
Bei Storage lohnt sich eine getrennte Betrachtung von drei Dingen: den persistenten Volumes deiner Anwendungen, den Backups dieser Volumes und dem Object Storage, den du für größere Datenmengen oder für die Ablage von Backups selbst nutzt. Alle drei laufen technisch über unterschiedliche Schnittstellen und werden bei den meisten Anbietern getrennt abgerechnet, nach belegtem Speicherplatz und teilweise zusätzlich nach Ein- und Ausgabeoperationen. Wer nur die Volume-Kosten seiner Anwendungen im Blick hat, übersieht leicht, dass Backups über die Zeit oft mehr Speicherplatz belegen als die Originaldaten selbst.
Egress-Traffic: die versteckte Kostenfalle
Egress-Traffic, also Daten, die dein Cluster in Richtung Internet oder in Richtung eines anderen Rechenzentrums verlassen, ist bei fast jedem Cloud-Anbieter der am wenigsten transparente Kostenblock. Eingehender Traffic ist bei den meisten Anbietern kostenlos, ausgehender Traffic dagegen nicht, und die genaue Berechnung unterscheidet sich stark zwischen den Anbietern. Für Anwendungen mit viel Traffic zu externen Nutzern oder zu Diensten außerhalb des eigenen Rechenzentrums kann dieser Block über die Zeit zu einem der größten überhaupt werden, obwohl er in ersten Kostenschätzungen fast immer fehlt.
Ein praktischer Hebel dagegen: Datenverkehr, der ohnehin innerhalb desselben Rechenzentrums oder derselben Region bleibt, verursacht bei den meisten Anbietern deutlich weniger oder gar keinen Egress. Wo du Dienste und ihre Nutzer platzierst, wirkt sich also direkt auf diesen Kostenblock aus.
Betriebszeit: der größte Posten, den niemand einpreist
Der Kostenblock, der in den wenigsten Vergleichen auftaucht, ist die Zeit, die dein Team mit dem Cluster verbringt: Updates einspielen, Sicherheitswarnungen prüfen, Kapazität planen, Vorfälle untersuchen. Bei Managed Kubernetes übernimmt der Anbieter einen Teil davon, nämlich alles rund um die Control Plane, während ein selbst betriebener Cluster diese Arbeit vollständig bei dir belässt. Diese Zeit erscheint auf keiner Rechnung eines Cloud-Anbieters, sie steckt trotzdem in jedem Cluster, den du betreibst.
Wie stark dieser Block wiegt, hängt fast ausschließlich von der Erfahrung deines Teams ab. Ein Team, das Kubernetes bereits produktiv betreibt, braucht für dieselben Aufgaben spürbar weniger Zeit als ein Team, das sich alles neu erarbeiten muss. Genau deshalb lohnt sich vor der Modellwahl ein ehrlicher Blick auf das vorhandene Wissen im Team, mehr dazu in Kubernetes on-premise oder Cloud?.
Managed-Aufschlag: was du für weniger Betrieb zahlst
Der Managed-Aufschlag ist der Preis, den ein Anbieter für die Übernahme von Betriebszeit verlangt, meist als kleine Grundgebühr je Cluster, teilweise auch eingepreist in leicht höhere Node-Preise. Ökonomisch betrachtet tauschst du hier einen Teil deines Betriebszeit-Blocks gegen einen festen, planbaren Aufschlag. Ob sich das lohnt, hängt davon ab, wie teuer deine eigene Betriebszeit im Vergleich zu diesem Aufschlag ist, und wie sehr dir Planbarkeit gegenüber Kontrolle wichtig ist.
Ein Rechenbeispiel als Struktur
Ohne Euro-Beträge lässt sich trotzdem eine Struktur zeigen, mit der du deine eigene Rechnung aufstellst. Summiere die Kosten deiner Nodes über den Abrechnungszeitraum, addiere die laufenden Kosten deiner Load Balancer, addiere Storage nach belegtem Volumen für Volumes, Backups und Object Storage getrennt, schätze deinen Egress-Traffic und addiere ihn nach dem Tarif deines Anbieters, multipliziere die geschätzten Betriebsstunden deines Teams mit ihrem internen Stundensatz, und addiere bei Managed Kubernetes den Aufschlag des Anbieters obendrauf. Das Ergebnis ist keine exakte Zahl, sondern eine Struktur, die dir zeigt, welcher Block bei dir tatsächlich am stärksten wiegt, und genau dort lohnt sich die erste Optimierung.
Als Formel für die eigene Rechnung, mit deinen Zahlen aus der Anbieter-Preisliste:
Monatskosten =
Anwendungs-Nodes (Anzahl x Preis)
+ Control-Plane-Nodes oder Managed-Grundgebühr
+ Load Balancer (Anzahl x Preis)
+ Storage (belegte GB x Preis, Volumes plus Backups)
+ Egress (GB über dem Freikontingent x Preis)
+ Betriebszeit (Stunden pro Monat x interner Stundensatz)
Der letzte Posten ist der, der in Angeboten fehlt und in der Realität am schwersten wiegt. Setz ihn ehrlich an, auch wenn niemand dafür eine Rechnung schreibt.
Die folgende Übersicht zeigt, wer welchen Block bei welchem Betriebsmodell trägt:
| Kostenblock |
Managed Kubernetes |
Eigenbetrieb (z. B. k3s auf gemieteter Cloud) |
| Nodes für Anwendungen |
du |
du |
| Nodes für die Control Plane |
meist im Anbieterpreis enthalten |
zusätzlich du |
| Load Balancer |
du |
du |
| Storage (Volumes, Backups, Object Storage) |
du |
du |
| Egress-Traffic |
du |
du |
| Betriebszeit der Control Plane |
überwiegend Anbieter |
vollständig du |
| Betriebszeit der Anwendungsebene |
du |
du |
| Zusätzlicher Aufschlag |
ja, meist als Grundgebühr |
nein |
Häufige Fragen
Ist Kubernetes kostenlos?
Die Software selbst ist Open Source und kostet keine Lizenzgebühr. Der Betrieb ist trotzdem nie kostenlos, weil du in jedem Fall Nodes, Netzwerk, Storage und Betriebszeit brauchst, ob bei einem Cloud-Anbieter oder auf eigener Hardware. „Kubernetes kostenlos" bezieht sich also immer nur auf die Software, nie auf den laufenden Betrieb.
Wie viel kostet ein gemieteter Kubernetes-Cluster im Monat?
Das hängt zu stark von Anbieter, Region, Node-Größe und Traffic ab, um seriös als einzelne Zahl beantwortet zu werden. Realistischer ist es, die sechs Kostenblöcke aus diesem Beitrag für dein eigenes Szenario durchzugehen und dabei aktuelle Preislisten deines Anbieters heranzuziehen, statt dich auf pauschale Angaben zu verlassen.
Wann lohnt sich Managed Kubernetes trotz des Aufschlags?
Immer dann, wenn deine eigene Betriebszeit teurer wäre als der Aufschlag, oder wenn dein Team schlicht keine eigene Kubernetes-Erfahrung aufbauen will oder kann. Für Teams mit vorhandenem Kubernetes-Wissen kehrt sich die Rechnung häufig um, weil der Aufschlag dann für eine Aufgabe bezahlt wird, die das Team ohnehin effizient selbst erledigen kann.
Wie behalte ich meine Kubernetes-Kosten dauerhaft im Blick?
Am zuverlässigsten mit denselben Werkzeugen, die du ohnehin für Monitoring einsetzt: Ressourcenauslastung je Node und je Namespace regelmäßig prüfen, ungenutzte Load Balancer und verwaiste Volumes aufspüren und Egress-Traffic pro Dienst beobachten, statt erst bei der Rechnung des Anbieters darauf zu schauen.
Wie du weitermachst
Bevor du deine Kostenrechnung aufstellst, lohnt sich die Grundsatzfrage, welches Betriebsmodell überhaupt zu dir passt, dazu mehr in Kubernetes on-premise oder Cloud? und in Kubernetes im Mittelstand: Betriebsmodell. Wer seine Node-Kosten senken will, ohne Kapazität zu verschenken, findet in Kubernetes Autoscaling mit HPA den passenden Hebel, um Pods automatisch an die tatsächliche Last anzupassen.
Mein Vorschlag: Geh die sechs Kostenblöcke aus diesem Beitrag für deinen eigenen Cluster einmal durch und markiere, welcher davon aktuell am wenigsten Aufmerksamkeit bekommt. In meiner Erfahrung ist das fast immer entweder Egress-Traffic oder die eigene Betriebszeit.
Mein Kubernetes-Praxisbuch bei Rheinwerk geht in Kapitel 2 auf die unternehmerischen Gründe für und gegen Kubernetes ein, konkrete Kostenblöcke wie in diesem Beitrag rechne ich dort nicht durch, weil sich Preise schneller ändern, als ein Buch aktuell bleiben kann. Alle Informationen zum Buch findest du auf meiner Kubernetes-Seite. Wie du Ressourcenanforderungen sauber setzt, beschreibt die Kubernetes-Dokumentation zum Ressourcenmanagement, den Quellcode von Kubernetes selbst findest du im Kubernetes-Projekt auf GitHub.
