Kubernetes-Kostenoptimierung: 8 Schritte, 23 Tools & Fallstudien

Kubernetes-Cluster können völlig gesund aussehen, während die Rechnung steigt. Autoscaling ist konfiguriert, Dashboards sind grün, und die Ausgaben steigen trotzdem. In einer Umfrage nannten 42 % von 455 Plattform-Ingenieuren Kosten als ihre größte Kubernetes-Herausforderung, während 88 % einen jährlichen Anstieg der Gesamtbetriebskosten verzeichneten.¹

Wir haben 68 Kubernetes-Kostenoptimierungs-Fallstudien gesammelt und jeden genannten Anwendungsfall dem jeweiligen Anbieter zugeordnet, der ihn veröffentlicht hat:

Dunklere Zellen bedeuten mehr Erwähnungen. Leere Zellen bedeuten, dass dieses Tool keinen veröffentlichten Fall für diesen Anwendungsfall hat.

Scrollen Sie weiter für einen 8-Schritte-Leitfaden mit Beispielen aus der Praxis, um Cluster-Ausgaben zu senken, und den Vergleich der Kubernetes-Kostenoptimierungs-Tools.

1. Messen, bevor Sie etwas ändern

Jede Zahl im Rest dieses Leitfadens ist ein Delta, und ein Delta braucht einen Ausgangspunkt. Ohne eine vor der ersten Änderung erfasste Baseline gibt es keine Möglichkeit zu erkennen, ob Schritt 1 funktioniert hat, und keine Möglichkeit, die Einsparungen aus Schritt 3 der Konsolidierung zuzuschreiben statt dem Rightsizing, das ihr vorausging. Das ist hier wichtiger als bei den meisten technischen Arbeiten, denn alle sechs Maßnahmen senken dieselbe Rechnung, und ihre Einsparungen summieren sich nicht. Freigewordene Kapazität in Schritt 1 bewirkt auf der Rechnung nichts, bis Schritt 3 die Nodes entfernt.

Messen Sie vier Dinge:

• Angeforderte versus genutzte CPU und Arbeitsspeicher, pro Workload. Die Lücke ist Ihr Schritt-1-Backlog, sortiert nach Größe.
• Kosten pro Namespace und pro Workload. Das macht aus Schritt-2-Quotas eine Verhandlung statt einer Anordnung.
• Bin-Packing-Effizienz, zuteilbar versus angefordert pro Node. Das Ziel von Schritt 3.
• Leerlaufkosten nach Tagesstunde und Wochentag in Nicht-Produktion. Dimensioniert Schritt 5, bevor Sie ihn aufbauen.

Messen Sie über mindestens einen vollständigen Geschäftszyklus. Sieben Tage sind das Minimum, und dreißig ist besser. Das Zeitfenster ist keine prozedurale Vorsicht. Schritt 1 setzt Memory-Requests auf das beobachtete Maximum, und ein beobachtetes Maximum ist nur so gut wie das Fenster, das es beobachtet hat. Ein Maximum über 48 Stunden verpasst einen wöchentlichen Batch-Job und verursacht am folgenden Sonntag einen OOMKill.

Werkzeuge

• Kostenzuordnung: OpenCost, das CNCF-Projekt hinter dem Allokationsmodell, ist der kostenlos Mindeststandard. Kubecosts kostenlos Stufe verpackt dieselbe Engine in eine UI für bis zu 250 Cores.
• Auslastung: Prometheus mit kube-state-metrics ist die Grundlage. Robusta KRR liest es direkt aus, ohne etwas im Cluster zu installieren.
• Umfassendere Ausgaben: Wo Kubernetes nur ein Teil einer Rechnung ist, die auch die Finanzabteilung erklären muss, sitzen CloudZero, Vantage und Finout über dieser Ebene, statt sie zu ersetzen.

Beide Kosten-Tools ordnen die Kosten nach Labels zu, daher kommt die Kennzeichnung zuerst. Unbeschriftete Ausgaben sind der häufigste Grund dafür, dass sich eine Baseline drei Wochen später als nutzlos erweist.

Jede nachfolgende Maßnahme nennt die Empfehlung, die Methode, die Konfiguration und ein Unternehmen, das diesen Schritt umgesetzt hat. Jede Fallstudie und jede Statistik enthält einen Quellenlink.

2. Namespace-Quotas als Leitplanken festlegen

Einsparungen schwinden, wenn Teams neue Workloads ohne angegebene Requests bereitstellen. Eine LimitRange liefert Standard-Requests an Container, die sie weglassen, und eine ResourceQuota begrenzt, was ein Namespace insgesamt verbrauchen darf.

Stellen Sie die LimitRange vor der ResourceQuota bereit. Sobald eine Quota eine Ressource einschränkt, wird jeder Pod ohne einen Request für diese Ressource bei der Zulassung abgelehnt; die umgekehrte Reihenfolge würde Deployments daher zerstören.²

Jeder Load Balancer wird vom Cloud-Anbieter separat abgerechnet, und verwaiste Volumes werden weiter abgerechnet, nachdem ihre Pods entfernt wurden.

2. CPU- und Memory-Requests richtig dimensionieren

Requests bestimmen die Anzahl der Nodes, und die Anzahl der Nodes bestimmt die Rechnung. Die meisten Cluster laufen weit unter der Kapazität, für die sie bezahlen, weil Requests einmal geschätzt und nie wieder überprüft wurden. Eine Analyse von 23.000 Produktionsclustern in AWS, Azure und Google Cloud ergab eine durchschnittliche CPU-Auslastung von 8 %, beim Speicher 20 % und bei GPU 5 %. ³

Setzen Sie CPU-Requests nahe am 95th-Perzentil der beobachteten Nutzung. Setzen Sie Memory-Requests auf das beobachtete Maximum statt auf ein Perzentil und setzen Sie das Memory-Limit gleich dem Request. Ein Perzentil lässt den Container während des verbleibenden Datenverkehrs zu knapp ausfallen, und da das Limit dem Request entspricht, führt dieser Mangel zu einem OOMKill statt zu einer Verlangsamung.

Lassen Sie das CPU-Limit weg. CPU-Throttling verschlechtert die Latenz, ohne den Pod zu beenden, und der Request reserviert bereits, was der Workload benötigt.

Der Vertical Pod Autoscaler im Nur-Empfehlungsmodus erzeugt diese Zahlen ohne Produktionsrisiko.

Lesen Sie die Empfehlungen mit kubectl describe vpa payments-api und vergleichen Sie den Zielwert mit dem aktuellen Request.

Praxis-Fallstudie: Tryg Insurance

Tryg Insurance ist der größte Schaden- und Unfallversicherer in der nordischen Region und betreibt Kubernetes auf Oracle Cloud Infrastructure. Das Engineering-Team kombinierte den Horizontal Pod Autoscaler und den Vertical Pod Autoscaler, um Workloads dynamisch richtig zu dimensionieren und gleichzeitig das Service-Level zu halten, und senkte die Kubernetes-Cloud-Kosten mit 50 % – ausschließlich mit Open-Source-Autoscalern und ohne kommerzielle Optimierungsplattform.⁴

4. Nodes mit Karpenter konsolidieren und inaktive Workloads auf null skalieren

Rightsizing setzt Kapazität frei, aber diese Kapazität liegt auf Nodes, die weiterlaufen, bis etwas sie entfernt. Karpenter stellt Instanzen just-in-time bereit und packt Workloads auf weniger Nodes um. KEDA skaliert warteschlangengetriebene Workloads auf null Replicas herunter, was ein Standard-Horizontal-Pod-Autoscaler nicht kann.

Setzen Sie die Konsolidierungsrichtlinie auf WhenEmptyOrUnderutilized. Die Alternative WhenEmpty beschränkt Störungen auf Nodes, die überhaupt keine Workload-Pods ausführen, und solche treten ohne Eingriff selten auf. ⁵

Eine enge Instanzliste macht das zunichte, denn Karpenter kann keine günstigen Ausreißer finden, und Ihre Spot-Resilienz sinkt. Sie sollten es über ganze Instanzfamilien hinweg wählen lassen.

Praxis-Fallstudie: Adidas

Adidas betreibt mehrere Kubernetes-Cluster auf AWS EKS. Das Platform-Engineering-Team setzte Karpenter für die Node-Bereitstellung ein, ergänzte KEDA für ereignisgesteuertes Skalieren, erstellte Vertical-Pod-Autoscaler-Objekte automatisch über Kyverno-Richtlinien und nutzte kube-downscaler für Leerlaufumgebungen. Sie senkten die Kosten für den Betrieb ihrer Kubernetes-Cluster auf AWS um bis zu 50 % – mit einem vollständig quelloffenen Stack.⁶

5. Vor der Umstellung auf Spot ordentlich vorbereiten

Spot-Instanzen bieten den größten verfügbaren Rabatt und die geringste Anwendbarkeit. Es sollte nichts auf Spot umziehen, bis PodDisruptionBudgets, Instanz-Diversifizierung, Topologieverteilung und Termination-Handling vollständig eingerichtet sind.

Ein PodDisruptionBudget, das keinen Puffer lässt, blockiert alle freiwilligen Störungen, einschließlich der Karpenter-Konsolidierung; die Werte brauchen daher Spielraum. ⁷

Praxis-Fallstudie: Delivery Hero

Delivery Hero betreibt 390 Anwendungen in 43 Ländern, wobei rund 90 % der Workloads auf AWS EKS laufen. Das Team migrierte über etwa sechs Monate auf Spot Instances und baute Termination-Handling und einen Descheduler in den Prozess ein, statt die Kapazitätstypen direkt zu wechseln.

• Die Infrastrukturkosten fielen um rund 70 %
• Die Spot-Rabatte erreichten bis zu 90 % gegenüber On-Demand-Preisen
• Die Plattform absorbiert Traffic-Spitzen vom 4- bis 5-fachen des normalen Volumens.⁸

6. Nicht-Produktion nach Zeitplan herunterfahren

Entwicklungs- und Staging-Umgebungen haben über Nacht und an Wochenenden wenig oder keine Last. Geplantes Herunterfahren ist technisch einfach und politisch unumstritten, was es zur schnellsten umsetzbaren Einsparung und zu einer nützlichen ersten Maßnahme macht, wenn später schwierigere Änderungen Unterstützung benötigen.

Wenden Sie den Zeitplan standardmäßig auf alle Nicht-Produktions-Namespaces an und verlangen Sie von Teams eine ausdrückliche Abmeldung. Eine Richtlinie, die eine aktive Teilnahme erfordert, erreicht weniger Teams als eine, die eine aktive Abmeldung erfordert.

Die Einsparung erreicht die Rechnung nur, wenn die Node-Konsolidierung bereits läuft, da herunterskalierte Deployments leere Nodes hinterlassen.

Praxis-Fallstudie: Bud Financial

Bud Financial reichert Finanztransaktionsdaten für den Finanzdienstleistungssektor an und betreibt rund 25 Cluster auf Google Kubernetes Engine. Das Team nutzte geplantes Pausieren und Fortsetzen, um Cluster-Nodes über Nacht und an Wochenenden zu verkleinern, zusammen mit täglichem Rebalancing.

• Die Kosten fielen allein durch die Zeitplanänderung um 47 %
• Der Zeitplan entfernte 80 Stunden Cluster-Betrieb pro Woche
• Die Ressourcenauslastung stieg auf über 90 %.⁹

7. Kompatible Workloads auf ARM migrieren

ARM-basierte Instanzen verändern den Stückpreis, statt wie die obigen Maßnahmen um dieselbe Leerlaufkapazität zu konkurrieren; diese Einsparungen summieren sich also tatsächlich mit den übrigen. Die Hindernisse werden Abhängigkeiten ohne ARM64-Builds sein.

Anwender sollten dies pro Workload abgrenzen statt über den gesamten Bestand, und Multi-Architektur-Images erstellen, bevor sie etwas einplanen.

Praxis-Fallstudie: Pinterest

Pinterest migrierte seinen Web-API-Workload auf AWS-Graviton-Instanzen mit ARM64 – motiviert sowohl durch Kosten- als auch durch CO₂-Reduktion.

• Die Kosten fielen um 47 %
• Der Compute-Verbrauch fiel um 38 %
• Die CO₂-Emissionen fielen um 62 %.¹⁰

8. Wenn das Tuning ausgereizt ist, ändern Sie die Architektur

Die sechs obigen Maßnahmen optimieren Workloads innerhalb bestehender Cluster. Sind sie ausgeschöpft, erfordern weitere Verbesserungen architektonische Änderungen statt weiteres Tuning.

Zwei veröffentlichte Ergebnisse markieren die praktische Grenze. InCred Finance senkte die Ausgaben in Clustern, die sein Team bereits als optimiert ansah, um 30 %¹¹, und Yotpo erreichte 30–40 %, während bereits 80 % der Workloads auf Spot Instances liefen¹². Jenseits dieser Spanne liegt die verbleibende Verschwendung nicht mehr in den Clustern, sondern in der Anzahl der Cluster. Jeder einzelne verursacht Control-Plane-Kosten und bildet eine Scheduling-Insel, die Bin-Packing nicht überwinden kann.

Multi-Tenancy beseitigt beide Kosten. Statt jedem Kunden, Team oder jeder Umgebung einen eigenen Cluster zu widmen, laufen virtuelle Cluster auf gemeinsam genutzter physischer Infrastruktur. Jeder Tenant erhält seinen eigenen API-Server und eine virtuelle Control Plane, während die Nodes gepoolt werden. Das eliminiert die Control-Plane-Kosten pro Cluster und ermöglicht Bin-Packing über den gemeinsamen Node-Pool statt innerhalb isolierter Bereiche.

yaml

bash

Zwei Mechanismen sind verfügbar. Namespaces sind immer günstiger, daher wird die Wahl anhand der von den Tenants benötigten Trennung getroffen, nicht anhand der Kosten.

• Namespaces partitionieren einen einzelnen Cluster und fügen keine eigene Control Plane hinzu. Sie genügen, wenn Tenants einander vertrauen und sich einen API-Server sowie einen Satz CRDs teilen können.
• Virtuelle Cluster geben jedem Tenant einen eigenen API-Server, der als Workload auf dem Host läuft. Diese Kosten sind in zwei Fällen gerechtfertigt: bei Tenants, die eigene clusterweite Ressourcen benötigen, und bei Isolationsanforderungen, die ein gemeinsam genutzter API-Server nicht erfüllen kann.

Praxis-Fallstudie: Atlan

Atlan ist ein Datenkatalog-Unternehmen, das die Plattform für rund 95 % seiner Kunden hostet, viele davon im Gesundheitswesen und Finanzwesen, wo die Datentrennung vertraglich vorgeschrieben ist. Es betrieb einen vollständigen EKS-Cluster pro Kunde und überschritt 100 Cluster – ein Bestand, der rund um die Uhr teuer im Betrieb und schwer zu warten war. Ab Q1 2022 evaluierte es Multi-Tenancy-Optionen und baute auf vCluster um, sodass jeder Kunde einen virtuellen Cluster statt eines physischen erhielt.

• Die physischen EKS-Cluster sanken von mehr als 100 auf 20 – und bedienen weiterhin 100+ Kunden
• Die Kubernetes-Ausgaben sanken um 600.000 US-Dollar.¹⁴

Verpassen Sie nicht unsere Benchmarks und datengestützten Erkenntnisse. Die Schaltfläche öffnet Google; die Auswahl von AIMultiple bestätigt, dass Sie AIMultiple häufiger in den Google-Suchergebnissen sehen möchten.

Als bevorzugte Quelle hinzufügen

Reihenfolge der Umsetzung

Commitments stehen an letzter Stelle, obwohl sie die einfachste Maßnahme sind. Sie vor dem Rightsizing zu kaufen, schreibt ein bis drei Jahre der Verschwendung fest, die das Rightsizing beseitigen sollte. Das ist der teuerste verfügbare Reihenfolgefehler, und er ist häufig, weil er einen Einkauf statt technischer Arbeit erfordert.

Maßnahme 7 ist eine Verzweigung, kein Schritt. Führen Sie erst aus, wenn die ersten sechs abgeschlossen sind und das Ergebnis immer noch zu kurz greift, denn sie ändert, wie viele Cluster laufen, statt wie effizient jeder einzelne läuft.

Kubernetes-Kostenoptimierungs-Tools

Wir haben Tools mit drei oder mehr veröffentlichten Fallstudien abgebildet, die 47 der 68 Fallstudien im Datensatz abdecken:

• Horizontal: wie viele Fallstudien jedes Tool hat, jeweils einmal gezählt.
• Vertikal: wie viele verschiedene Anwendungsfall-Kategorien diese Fälle abdecken, von zehn. Ein Tool zählt einmal pro Kategorie, egal wie oft es dort vorkommt; so tragen CAST AIs 12 einzelne Rightsizing-Erwähnungen nur 1 zu seinem Score von 10 bei.
• Blasengröße: in wie vielen der acht Strategiephasen das Tool vorkommt.

Open-Source-Frameworks

Open-Source-Frameworks können für die Phasen 0 bis 6 eingesetzt werden. Die Anwender tragen die Upgrades, die Versionswechsel, die Prometheus-Speicherkosten und die Ermessensentscheidungen, die ein kommerzieller Empfehler für sie treffen würde.

Jedes dieser Tools deckt ein anderes Feld ab, weshalb mehrere gleichzeitig laufen.

• Robusta KRR oder VPA in updateMode: "Off" erzeugt das Schritt-1-Backlog. Schreibt nichts.
• Karpenter besitzt die Nodes: Bereitstellung, Konsolidierung, Instanzauswahl, Spot-Diversifizierung, Architektur. Trägt die Schritte 3, 4 und 6.
• KEDA besitzt die Replica-Anzahl, einschließlich Skalierung auf null, was HPA allein nicht kann.
• py-kube-downscaler oder kube-green besitzt den Nicht-Produktions-Zeitplan. Günstigste Einsparung auf der Liste.
• OpenCost misst durchgängig und beteiligt sich an nichts.

Kommerzielle Plattformen

Jedes kommerzielle Tool nimmt eine von drei Positionen auf der Node-Ebene ein. Das ist die Entscheidung, und sie ist wichtiger als Preis oder Funktionsumfang, denn das NodePool-Manifest aus Schritt 3 bleibt entweder erhalten oder nicht.

• In Ruhe lassen: StormForge, PerfectScale, Sedai und Kubex dimensionieren nur Workloads richtig. Sie benötigen Karpenter oder Cluster Autoscaler darunter und fassen ihn nie an. Die sicherste Ergänzung für ein bestehendes Setup.
• Damit arbeiten: ScaleOps ergänzt Bin-Packing auf Karpenter. nOps optimiert einen bestehenden Cluster Autoscaler oder Karpenter, statt einen eigenen einzusetzen. Mehr Abdeckung, der Provisioner bleibt Ihrer.
• Ersetzen: CAST KI und Spot Ocean installieren ihren eigenen Provisioner und verwerfen das Manifest. Größte Abdeckung, geringste Kontrolle.
• Visibility-Tools sitzen außerhalb: OpenCost, Kubecost, CloudZero, Vantage und Finout lesen nur, kollidieren daher mit nichts und lassen sich frei kombinieren. Betreiben Sie eines, unabhängig davon, was sonst eingeführt wird.

Wie man diese Tools kombiniert

Die Rechnung basiert auf laufenden Nodes, nicht auf deklarierten Requests. Rightsizing senkt Requests, wodurch Platz auf bestehenden Nodes frei wird, aber keine davon entfernt wird; die Rechnung bleibt also unverändert, bis ein Node-Tool diesen Platz durch Konsolidierung beseitigt. Node-Tools allein scheitern aus dem spiegelbildlichen Grund: Sie packen, welche Requests man ihnen auch gibt, sodass überhöhte Requests einfach dichter gepackt werden.

Zwei Möglichkeiten, beide Ebenen abzudecken:

• Zwei Tools: VPA, StormForge oder PerfectScale für Requests, plus Karpenter für Nodes. Günstiger, und die Node-Ebene bleibt unter direkter Kontrolle.
• Eine Plattform: CAST KI, Zesty oder Spot Ocean erledigen beides in einem einzigen Produkt. Teurer, und ihr Provisioner ersetzt Karpenter.

Fünf Tool-Kombinationen, die Dinge kaputt machen:

• Zwei mutierende Rightsizer in einem Deployment: VPA in Auto neben StormForge, ScaleOps, PerfectScale oder Zesty bedeutet zwei Controller, die unterschiedliche Zahlen in dasselbe Feld schreiben. Ein mutierender Admission Controller pro Workload.
• Karpenter und Cluster Autoscaler in einer Node-Gruppe: Beide provisionieren gegen dieselben nicht planbaren Pods, sodass der Cluster am Ende ungefähr doppelt so viele Nodes hat, wie er benötigt.
• VPA und HPA auf derselben Metrik: Die Nutzung steigt, VPA erhöht den Request, die gemessene Auslastung sinkt, weil sie Nutzung durch Request ist, HPA entfernt Replicas, die Last pro Pod steigt – und so weiter. Sicher, wenn HPA auf etwas skaliert, das VPA nicht anfasst, etwa die Warteschlangentiefe über KEDA.
• Zwei Commitment-Tools auf einem Zahlerkonto: Beide kaufen gegen dieselben ungedeckten Ausgaben und schreiben so eine Überbelegung für ein bis drei Jahre fest.
• Zwei vollständige Plattformen: CAST KI, Zesty und Spot Ocean installieren jeweils ihren eigenen Provisioner und erwarten jeweils, ihn zu besitzen.

Übersicht aller von uns gesammelten Fallstudien:

Weiterführende Informationen

Lesen Sie mehr, um die Pod-Platzierung zu meistern und Ihre Cloud-Compute-Ausgaben zu senken:

• Top-Container-Orchestrierungs-Tools vergleichen
• 20+ Cloud-Orchestratoren vergleichen
• Top-Hybrid-Cloud-Job-Scheduler

Diese Forschung zitieren

Wählen Sie das Format, das zu Ihrem Veröffentlichungsort passt. Wenn Sie die Link-Version in Ihr CMS einfügen, bleibt der Backlink erhalten.

@misc{simsek2026,
  author = {Şimşek, Hazal},
  title  = {{Kubernetes-Kostenoptimierung: 8 Schritte, 23 Tools & Fallstudien}},
  year   = {2026},
  month  = sep,
  howpublished    = {\url{https://aimultiple.com/kubernetes-cost-optimization}},
  note   = {AIMultiple. Abgerufen am 18. September 2026}
}

Referenzlinks

1.

https://hs-20518613.f.hubspotemail.net/hubfs/20518613/Spectro%20Cloud%202025%20State%20of%20Production%20Kubernetes.pdf

2.

Resource Quotas | Kubernetes

3.

2026 Kubernetes Optimization: Data & Best Practices - Cast AI

Cast AI

4.

How Tryg Insurance saved 50% of Kubernetes cloud costs: Patterns for dynamic right-sizing of Kubernetes | cloud-infrastructure

5.

Disruption | Karpenter

6.

https://medium.com/adidoescode/reducing-cloud-costs-of-kubernetes-clusters-c8c1e3bdb669

7.

Disruptions | Kubernetes

8.

Spot Instances at Delivery Hero | Delivery Hero Tech

9.

Bud Achieved 90%+ Utilization and Higher Engineering Productivity – Cast AI

Cast AI

10.

How potential performance upside with AWS Graviton helps reduce your costs further | AWS Compute Blog

11.

InCred Finance Unlocked 30% Cost Savings in Kubernetes Clusters – Cast AI

Cast AI

12.

Yotpo Kubernetes Optimization Case Study - Cast AI

Cast AI

13.

Page restricted | ScienceDirect

14.

How Atlan Reduced Their Infrastructure From 100 Kubernetes Clusters To 1 Using vCluster

vCluster

15.

Save up to 60% on AWS costs with EKS and Karpenter - Qovery Blog

Qovery

Hazal Şimşek

Branchenanalystin

Folgen auf

Hazal ist Branchenanalystin bei AIMultiple und konzentriert sich auf Prozessintelligenz (einschließlich Process Mining) und Unternehmensautomatisierung (einschließlich IT-Automatisierung und Low-Code-/No-Code-Automatisierung).

Vollständiges Profil anzeigen

Seien Sie der Erste, der kommentiert

Ihre E-Mail-Adresse wird nicht veröffentlicht. Alle Felder sind erforderlich. Kommentare werden in ihrer Originalsprache belassen.

Name

E-Mail-Adresse

Kommentar

0/450

Kommentar posten