Kubernetes senkt Cloud-Kosten im Mittelstand

Die Cloud-Rechnung steigt, die Auslastung der Cluster liegt bei 30 Prozent. Dieses Missverhältnis ist der Normalzustand in vielen Kubernetes-Umgebungen im Mittelstand. Wer Kosten senken will, findet die Hebel eine Ebene unterhalb des Billing-Dashboards: bei Requests, Limits und der Frage, wie dicht die Workloads wirklich gepackt sind.

Das Wichtigste in Kürze

Verwandt:30 Prozent Cloud-Kosten senken  /  Der billige Cloud-Chip

Warum die Hyperscaler-Rechnung zu wenig zeigt

Das Billing-Dashboard eines Hyperscalers zeigt, was eine Instanz kostet. Es zeigt nicht, ob diese Instanz zu einem Drittel leerläuft. In einem Kubernetes-Cluster liegt genau dort das Geld: Die Nodes werden nach den reservierten Requests der Pods bezahlt, nicht nach ihrer tatsächlichen Nutzung. Wer Requests großzügig setzt, um auf der sicheren Seite zu sein, bezahlt diese Sicherheit rund um die Uhr.

Der erste Schritt ist deshalb Transparenz auf Pod-Ebene. Metriken über die reale CPU- und Speichernutzung im Verhältnis zu den gesetzten Requests decken die Lücke auf. In der Praxis liegt die durchschnittliche Auslastung vieler Cluster deutlich unter der Hälfte der reservierten Kapazität. Das ist keine Ausnahme, das ist der Startpunkt jeder ernsthaften Optimierung.

Drei Kubernetes-Hebel für echte Kostensenkung

Rightsizing steht an erster Stelle. Requests und Limits werden an die tatsächlich gemessene Nutzung angepasst, mit einem realistischen Puffer für Lastspitzen. Der Vertical Pod Autoscaler liefert dafür Empfehlungen, die man zunächst im Empfehlungsmodus beobachtet und dann kontrolliert übernimmt.

Der zweite Hebel ist der Horizontal Pod Autoscaler. Statt eine feste Zahl von Replikaten für den Spitzenfall vorzuhalten, skaliert er die Zahl der Pods entlang von CPU, Speicher oder eigenen Metriken. Der dritte Hebel ist die Node-Ebene: Ein Cluster Autoscaler fährt ungenutzte Nodes herunter, sobald die Pods darauf keinen Bedarf mehr haben. Zusammen sorgen die drei dafür, dass die reservierte Kapazität der realen Last folgt.

Bin Packing und Resource Quotas einrichten

Bin Packing beschreibt, wie dicht der Scheduler die Pods auf die vorhandenen Nodes verteilt. Ein Scheduler, der auf Auslastung optimiert, packt Workloads enger zusammen und braucht in Summe weniger Nodes. Das senkt die Grundkosten spürbar, verlangt aber saubere Requests, damit keine Node überbucht wird.

Resource Quotas ziehen die Leitplanken pro Namespace. Sie verhindern, dass ein einzelnes Team unbemerkt Kapazität an sich zieht und die Rechnung des ganzen Clusters treibt. Für den Mittelstand mit wenigen, gemischt genutzten Clustern sind Quotas das einfachste Mittel, Kostendisziplin technisch zu erzwingen, statt sie in Meetings zu erbitten.

Wann Bare-Metal günstiger ist als Public Cloud

Nicht jeder Workload gehört in die Public Cloud. Für Lasten, die konstant und vorhersehbar laufen, kann eigene oder gemietete Bare-Metal-Hardware über die Laufzeit günstiger sein als die stündliche Abrechnung eines Hyperscalers. Die Elastizität der Cloud ist bei gleichmäßiger Grundlast ein Aufpreis, den man nicht braucht.

Die ehrliche Rechnung berücksichtigt die Gesamtkosten inklusive Betrieb, nicht nur den Compute-Preis. Ein pragmatischer Ansatz ist die Trennung: konstante Grundlast auf günstiger Dauerkapazität, elastische Spitzen in der Public Cloud. Kubernetes macht diese Aufteilung technisch handhabbar, weil dieselben Workloads auf beiden Untergründen laufen.

Showback pro Microservice mit Kubecost

Optimierung, die niemand zugeordnet bekommt, verpufft. Werkzeuge wie Kubecost brechen die Cluster-Kosten auf Namespaces, Deployments und einzelne Microservices herunter. Jedes Team sieht, was sein Dienst pro Monat kostet. Dieses Showback ist der Punkt, an dem FinOps aus einer Kennzahl eine Verhaltensänderung wird.

Wichtig ist die Kadenz. Ein Kostenreport, den niemand liest, ändert nichts. Ein kurzer, monatlicher Blick pro Team auf die Entwicklung der eigenen Kosten schafft den Anreiz, ineffiziente Requests und vergessene Testumgebungen selbst aufzuräumen.

Ein monatlicher Rightsizing-Workflow

Kostenoptimierung ist eine dauerhafte Routine. Ein schlanker Monatszyklus reicht: Nutzungsdaten der letzten Wochen auswerten, die größten Abweichungen zwischen Request und realer Last identifizieren, für die Top-Kandidaten neue Werte setzen und im nächsten Zyklus prüfen, ob die Anpassung gehalten hat.

Der Reiz dieses Vorgehens liegt in seiner Wiederholbarkeit. Wer den Zyklus einmal etabliert, hält die Auslastung dauerhaft hoch, statt einmal aufzuräumen und dann zuzusehen, wie die Requests wieder wachsen. Planbare Cloud-Kosten entstehen aus einer Gewohnheit, die man einmal etabliert und dann laufen lässt.

Häufige Fragen