Kubernetes-Kostenoptimierung: 8 Schritte & 23 Tools

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 die Kosten als ihre größte Kubernetes-Herausforderung, während 88 % einen Anstieg der Gesamtbetriebskosten im Jahresvergleich sahen.¹

Wir haben 68 Fallstudien zur Kubernetes-Kostenoptimierung gesammelt und jeden erwähnten 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 Praxisbeispielen, um die Cluster-Ausgaben zu senken, und den Vergleich des Kubernetes-Kostenoptimierungstools.

1. Messen, bevor Sie irgendetwas ändern

Jede Zahl im Rest dieses Leitfadens ist ein Delta, und ein Delta braucht einen Ausgangspunkt. Ohne eine vor der ersten Änderung erfasste Ausgangsbasis lässt sich weder feststellen, ob Schritt 1 funktioniert hat, noch lassen sich die Einsparungen von Schritt 3 der Konsolidierung statt dem vorausgegangenen Rightsizing zuordnen. Das ist hier wichtiger als bei den meisten Engineering-Arbeiten, denn alle sechs Maßnahmen reduzieren dieselbe Rechnung, und ihre Einsparungen addieren sich nicht. Das Freigeben von 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. Diese Lücke ist Ihr Schritt-1-Backlog, sortiert nach Größe.
• Kosten pro Namespace und pro Workload. Dadurch werden die Quoten aus Schritt 2 zu einer Verhandlung statt zu einer Auflage.
• Bin-Packing-Effizienz, zuteilbar versus angefordert pro Node. Das Ziel von Schritt 3.
• Leerlaufkosten nach Tageszeit und Wochentag außerhalb der Produktion. Dimensioniert Schritt 5, bevor Sie ihn aufbauen.

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

Tooling

• Kostenzuordnung: OpenCost, das CNCF-Projekt hinter dem Zuordnungsmodell, ist die free-Basis. Kubecosts free-Stufe verpackt dieselbe Engine in einer UI für bis zu 250 Kerne.
• Utilisierung: Prometheus mit kube-state-metrics ist die Grundlage. Robusta KRR liest sie direkt, ohne etwas im Cluster zu installieren.
• Breitere Ausgaben: Wo Kubernetes 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 Kostentools ordnen anhand von Labels zu, daher kommt die Beschriftung zuerst. Unbeschriftete Ausgaben sind der häufigste Grund, warum sich eine Ausgangsbasis drei Wochen später als nutzlos erweist.

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

2. Namespace-Quoten als Leitplanken festlegen

Einsparungen schwinden, wenn Teams neue Workloads ohne festgelegte Anforderungen bereitstellen. Eine LimitRange liefert Standardanforderungen für Container, die sie weglassen, und eine ResourceQuota begrenzt, was ein Namespace insgesamt verbrauchen darf.

Setzen Sie die LimitRange vor der ResourceQuota ein. Sobald eine Quote eine Ressource einschränkt, wird jeder Pod ohne Anforderung für diese Ressource bei der Aufnahme abgelehnt; die umgekehrte Reihenfolge führt daher zu fehlgeschlagenen Deployments.²

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

2. CPU- und Arbeitsspeicheranforderungen richtig dimensionieren

Anforderungen bestimmen die Node-Anzahl, und die Node-Anzahl bestimmt die Rechnung. Die meisten Cluster laufen weit unter der bezahlten Kapazität, weil die Anforderungen einmal geschätzt und nie wieder überprüft wurden. Eine Analyse von 23.000 Produktionsclustern über AWS, Azure und Google Cloud hinweg ergab eine durchschnittliche CPU-Auslastung von 8 %, Arbeitsspeicher bei 20 % und GPU bei 5 %.³

Setzen Sie CPU-Anforderungen nahe dem 95th-Perzentil der beobachteten Nutzung. Setzen Sie Arbeitsspeicheranforderungen auf das beobachtete Maximum statt auf ein Perzentil und die Arbeitsspeichergrenze gleich der Anforderung. Ein Perzentil lässt den Container beim verbleibenden Datenverkehr zu knapp werden, und da die Grenze der Anforderung entspricht, zeigt sich diese Unterdeckung als OOMKill statt als Verlangsamung.

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

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

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

Praxisbeispiel: 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 Horizontal Pod Autoscaler und Vertical Pod Autoscaler, um Workloads dynamisch richtig zu dimensionieren und gleichzeitig das Service-Level zu halten, und senkte die Kubernetes-Cloudkosten allein mit Open-Source-Autoscalern um 50 %, 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 rechtzeitig bereit und packt Workloads auf weniger Nodes um. KEDA skaliert warteschlangengesteuerte Workloads auf null Replicas herunter, was ein Standard Horizontal Pod Autoscaler nicht kann.

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

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

Praxisbeispiel: Adidas

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

5. Richtig vorbereiten, bevor Workloads zu Spot verschoben werden

Spot-Instanzen bieten den größten verfügbaren Rabatt und die geringste Anwendbarkeit. Nichts sollte zu Spot wechseln, bis PodDisruptionBudgets, Instanzdiversifizierung, Topologieverteilung und Terminierungsbehandlung vorhanden sind.

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

Praxisbeispiel: 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 zu Spot-Instanzen und integrierte Terminierungsbehandlung und einen Descheduler in den Prozess, statt die Kapazitätstypen direkt zu wechseln.

• Die Infrastrukturkosten sanken um rund 70 %
• Spot-Rabatte erreichten bis zu 90 % gegenüber On-Demand-Preisen
• Die Plattform verkraftet Verkehrsspitzen 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. Ein geplantes Herunterfahren ist technisch einfach und politisch unumstritten, was es zur schnellsten umsetzbaren Einsparung macht und zu einer nützlichen ersten Maßnahme, wenn schwierigere Änderungen später Unterstützung benötigen.

Wenden Sie den Zeitplan standardmäßig auf alle Nicht-Produktions-Namespaces an und verlangen Sie von Teams ein explizites Opt-out. Eine Richtlinie, die eine Aktion zum Beitreten erfordert, erreicht weniger Teams als eine, die eine Aktion zum Verlassen erfordert.

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

Praxisbeispiel: 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 sanken allein durch die Zeitplanänderung um 47 %
• Der Zeitplan entfernte 80 Stunden Clusterbetrieb pro Woche
• Die Ressourcenauslastung stieg über 90 %.⁹

7. Kompatible Workloads zu ARM migrieren

ARM-basierte Instanzen ändern den Stückpreis, statt mit den obigen Maßnahmen um dieselbe Leerlaufkapazität zu konkurrieren; diese Einsparungen summieren sich daher wirklich mit den übrigen. Die Blockierer werden Abhängigkeiten ohne ARM64-Builds sein.

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

Praxisbeispiel: Pinterest

Pinterest migrierte seinen Web-API-Workload zu AWS-Graviton-Instanzen auf ARM64, motiviert durch Kosten- und CO₂-Reduktion.

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

8. Wenn das Tuning an Grenzen stößt, ändern Sie die Architektur

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

Zwei veröffentlichte Ergebnisse markieren die praktische Grenze. InCred Finance senkte die Ausgaben bei Clustern, die sein Team als optimiert betrachtete, um 30 %¹¹, und Yotpo erreichte 30–40 % bei 80 % der Workloads auf Spot-Instanzen¹². Jenseits dieses Bereichs liegt die verbleibende Verschwendung nicht mehr in den Clustern, sondern in der Anzahl der Cluster. Jeder einzelne verursacht eine Control-Plane-Gebühr und bildet eine Scheduling-Insel, die Bin-Packing nicht überqueren kann.

Mandantenfähigkeit 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 einen eigenen API-Server und eine virtuelle Control Plane, während Nodes gepoolt werden. Dadurch entfällt die Control-Plane-Gebühr pro Cluster, und Bin-Packing wird über den gemeinsamen Node-Pool hinweg ermöglicht statt innerhalb isolierter Bestände.

yaml

bash

Zwei Mechanismen stehen zur Verfügung. Namespaces sind immer günstiger, daher richtet sich die Wahl nach der benötigten Trennung der Tenants und nicht nach den Kosten.

• Namespaces partitionieren einen einzelnen Cluster und fügen keine eigene Control Plane hinzu. Sie reichen aus, wenn Tenants einander vertrauen und sich einen API-Server und 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 gemeinsamer API-Server nicht erfüllen kann.

Praxisbeispiel: Atlan

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

• Die physischen EKS-Cluster sanken von mehr als 100 auf 20, wobei weiterhin 100+ Kunden bedient werden
• 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 trotz der einfachsten Maßnahme an letzter Stelle. Sie vor dem Rightsizing zu kaufen, legt ein bis drei Jahre der Verschwendung fest, die Rightsizing gerade entfernen würde. Es ist der teuerste verfügbare Reihenfolgefehler und tritt häufig auf, weil er einen Einkauf statt Engineering-Arbeit erfordert.

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

Kubernetes-Kostenoptimierungstools

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

• Horizontal: Wie viele Fallstudien jedes Tool hat, jeweils einmal gezählt.
• Vertikal: Wie viele unterschiedliche Anwendungsfallkategorien diese Fälle abdecken, von zehn. Ein Tool zählt pro Kategorie einmal, unabhängig davon, wie oft es dort erscheint; CAST AIs 12 separate Rightsizing-Erwähnungen tragen 1 zu seinem Wert von 10 bei.
• Blasengröße: In wie vielen der acht Strategiephasen das Tool erscheint.

Open-Source-Frameworks

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

Jedes dieser Tools besitzt ein anderes Feld, 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 durchgehend 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 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 oberhalb von Karpenter. nOps optimiert einen bestehenden Cluster Autoscaler oder Karpenter, statt einen eigenen zu ersetzen. 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 sind nur lesend, kollidieren daher mit nichts und lassen sich frei stapeln. Setzen Sie eines ein, unabhängig davon, was sonst übernommen wird.

So kombinieren Sie diese Tools

Die Rechnung basiert auf laufenden Nodes, nicht auf deklarierten Anforderungen. Rightsizing senkt die Anforderungen, wodurch Platz auf bestehenden Nodes frei wird, aber keine davon entfernt wird; die Rechnung bleibt unverändert, bis ein Node-Tool diesen Platz wegkonsolidiert. Node-Tools allein scheitern aus dem spiegelbildlichen Grund: Sie packen, welche Anforderungen auch immer sie erhalten, sodass überhöhte Anforderungen dichter gepackt werden.

Zwei Möglichkeiten, beide Ebenen abzudecken:

• Zwei Tools: VPA, StormForge oder PerfectScale für Anforderungen, 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 Rightsizing-Tools für ein Deployment: VPA in Auto zusammen mit 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 stellen für dieselben nicht planbaren Pods bereit, sodass der Cluster am Ende ungefähr doppelt so viele Nodes hat wie benötigt.
• VPA und HPA für dieselbe Metrik: Die Nutzung steigt, VPA erhöht die Anforderung, die gemessene Auslastung sinkt, weil sie Nutzung durch Anforderung ist, HPA entfernt Replicas, die Last pro Pod steigt – wiederholen. Sicher, wenn HPA auf etwas skaliert, das VPA nicht berührt, etwa die Warteschlangentiefe über KEDA.
• Zwei Commitment-Tools für ein Zahlerkonto: Beide kaufen gegen dieselben ungedeckten Ausgaben und legen so eine Überbelegung für ein bis drei Jahre fest.
• Zwei vollständige Plattformen: CAST KI, Zesty und Spot Ocean installieren jeweils einen eigenen Provisioner und erwarten jeweils, ihn zu besitzen.

Alle von uns gesammelten Fallstudien anzeigen:

Weiterführende Informationen zu Cloud-Kosten

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

• Vergleichen Sie Top-Container-Orchestrierungstools
• Vergleichen Sie 20+ Cloud-Orchestratoren
• 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}},
  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.

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

vCluster

14.

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