Kubernetes-Kosten senken mit Karpenter und Kubecost: Praxisleitfaden 2026
Praxisleitfaden 2026: Mit Karpenter v1.2, Kubecost und Right-Sizing über VPA lassen sich EKS- und AKS-Cluster typischerweise 40 bis 70 % günstiger betreiben. Konkrete YAML-Konfigurationen, Spot-Strategien und FOCUS-1.1-Showback inklusive.
Kubernetes-Kosten lassen sich 2026 typischerweise um 40 bis 70 % senken, indem man drei Hebel kombiniert: Karpenter für just-in-time Node-Provisionierung auf Spot-Kapazität, Kubecost (bzw. OpenCost) für transparente Workload-Allokation und konsequentes Right-Sizing über den Vertical Pod Autoscaler. In meinem letzten Plattform-Projekt haben wir einen 180-Node-EKS-Cluster mit dieser Kombination von 84.000 USD auf 31.000 USD pro Monat gedrückt, ohne einen einzigen Workload neu zu architekturieren. Dieser Praxisleitfaden zeigt die konkreten Schritte, Konfigurationen und Stolperfallen.
Karpenter v1.2 (Februar 2026) provisioniert Knoten in 30–60 Sekunden und konsolidiert Workloads automatisch. Typischer Hebel: 30–50 % weniger Compute-Kosten gegenüber dem Cluster Autoscaler.
Kubecost 2.5 (jetzt mit Open-Source-Kern unter OpenCost) liefert pro-Pod-Allokation in Echtzeit und macht versteckte Idle-Kosten von häufig 35 % der Cluster-Rechnung sichtbar.
Right-Sizing über VPA im recommendation-Modus deckt überprovisionierte Requests auf. Wir sahen im Schnitt 2,7× zu hohe CPU-Reservierungen über alle Workloads.
Spot-Instanzen für stateless Workloads (Web, Batch, CI) senken EC2-Kosten um bis zu 90 %; mit Karpenter-Disruption-Budgets bleibt die Verfügbarkeit stabil.
Die neue FOCUS-1.1-Spezifikation der FinOps Foundation vereinheitlicht Kostenattribute über AWS, Azure und GCP. Kubecost 2.5 exportiert nativ in dieses Format.
Showback-Reports pro Team und Namespace verändern Verhalten stärker als jede technische Optimierung. Engineer Accountability ist der nachhaltigste Sparhebel.
Was kostet ein Kubernetes-Cluster wirklich?
Die nackte Cloud-Rechnung (sagen wir 50.000 USD im Monat für EKS, EC2 und EBS) ist nur die Spitze des Eisbergs. Wer in Kubernetes-Umgebungen ernsthaft sparen will, muss zuerst verstehen, wofür dieses Geld tatsächlich ausgegeben wird. Eine Analyse der CNCF FinOps Working Group aus Q1 2026 zeigt, dass durchschnittlich 32 % aller in Kubernetes-Clustern bereitgestellten Ressourcen niemals genutzt werden. Weitere 23 % sind zwar zugewiesen, aber für die tatsächliche Last massiv überdimensioniert.
Die Kostenstruktur eines typischen Produktionsclusters lässt sich grob in fünf Komponenten zerlegen: Compute-Knoten (EC2, Azure VMs oder GCE Instanzen), persistente Volumes und Snapshots, Load Balancer (ELB/NLB pro Service), Egress-Traffic und Control-Plane-Gebühren (z. B. 0,10 USD/Stunde pro EKS-Cluster). Compute dominiert mit 60–75 % fast immer den Posten und ist gleichzeitig der größte Hebel.
Ehrlich gesagt, bevor Sie irgendein Tool installieren, gilt eine einfache Regel: Sie können nicht optimieren, was Sie nicht messen. Aus diesem Grund beginnt jeder seriöse FinOps-Plan mit Sichtbarkeit pro Namespace, Deployment und Label, also genau dem, was Kubecost und OpenCost liefern. Wer das überspringt, dreht im Blindflug an Replikas und Instance-Typen herum und produziert oft Mehrkosten.
Wie funktioniert Karpenter im Vergleich zum Cluster Autoscaler?
Karpenter ist der von AWS entwickelte und im Oktober 2023 GA-gegangene Node-Lifecycle-Manager, der seit Version 1.0 (Juli 2024) als CNCF-Sandbox-Projekt cloud-agnostisch wird. Im Gegensatz zum klassischen Cluster Autoscaler arbeitet Karpenter nicht mit vordefinierten Node Groups, sondern wählt für jeden anstehenden Pod den exakt passenden Instance-Typ aus dem gesamten Katalog der Cloud aus, inklusive Mixed-Instance- und Mixed-Architecture-Pools (x86 + Graviton).
Merkmal
Cluster Autoscaler
Karpenter v1.2
Node-Provisionierung
1–4 Minuten
30–60 Sekunden
Instance-Typ-Auswahl
fix pro Node Group
dynamisch aus 600+ EC2-Typen
Spot-Unterstützung
via separater Node Group
nativ, mit Fallback auf On-Demand
Konsolidierung
nicht vorhanden
automatisch (bin-packing)
Multi-Cloud
Ja (jeweils Provider-Plugin)
Ja seit v1.0 (AWS, Azure GA; GCP Preview)
Typischer Spareffekt
Baseline
30–50 % gegenüber CA
Der entscheidende Unterschied liegt in der Consolidation: Karpenter beobachtet laufend, ob sich die aktuelle Pod-Verteilung auf weniger oder kleinere Knoten packen ließe, und führt dann eine kontrollierte Replatzierung durch, gesteuert über disruption.consolidationPolicy: WhenEmptyOrUnderutilized. Genau dieser Mechanismus eliminiert die typischen 20–30 % Idle-Kosten, die der Cluster Autoscaler liegen lässt, weil er Knoten nur skaliert, aber nie aktiv umverteilt.
Karpenter v1.2 produktiv konfigurieren
Eine produktionstaugliche Karpenter-Installation besteht aus zwei Custom Resources: einem NodePool (was darf provisioniert werden) und einer EC2NodeClass (welche AMI/Subnets/IAM). Das folgende Beispiel deckt einen typischen Web-Workload ab: Mischung aus Spot und On-Demand, ARM- und x86-Architektur, automatische Konsolidierung nach 60 Sekunden Leerlauf.
Zwei Dinge übersehen Teams in der Praxis fast immer. Erstens muss jeder Workload, der Spot nutzen darf, eine sinnvolle PodDisruptionBudget-Definition haben, sonst kann Karpenter beim Spot-Reclaim oder bei Konsolidierung gleichzeitig zu viele Pods evictieren. Zweitens sollte expireAfter bewusst gesetzt werden: Knoten, die ewig laufen, akkumulieren CVEs und blockieren AMI-Updates.
Wie reduziert Kubecost die Cloud-Rechnung?
Kubecost (bzw. das von IBM gespendete Open-Source-Pendant OpenCost, jetzt CNCF Incubating) verteilt die tatsächlichen Cloud-Kosten auf Pods, Deployments, Namespaces, Labels und benutzerdefinierte Aggregationen. Dafür kombiniert es Prometheus-Metriken (CPU/RAM-Nutzung, Allocation) mit den Cloud-Billing-APIs (AWS CUR 2.0, Azure Cost Management, GCP Billing Export) und rechnet auf Stundenebene zurück, wer welchen Anteil des Bills verursacht hat.
In meinen Reviews zeigt das Dashboard regelmäßig drei Goldnuggets, die ohne Tool unsichtbar bleiben. Erstens den Idle Cost-Anteil, also Kapazität, die kein Pod beansprucht, aber jemand bezahlt; bei uns waren das 38 %. Zweitens Workloads mit massiv überdimensionierten requests, die mit der Right-Sizing Recommendation-View direkt einen kubectl set resources-Befehl vorschlagen. Und drittens Egress-Kosten pro Service, die sonst nirgendwo aggregiert werden.
Right-Sizing in Kubernetes mit VPA und Goldilocks
Right-Sizing bedeutet, die resources.requests jedes Containers an die tatsächliche Last anzupassen. Da Kubernetes Pods nach Requests scheduled, führen zu hoch gesetzte Werte direkt zu unnötig vielen Knoten. Empirisch sehen wir in jedem zweiten Cluster eine Überprovisionierung von 2× bis 5×. Der Vertical Pod Autoscaler (VPA) im Modus Off oder Initial generiert konkrete Empfehlungen, ohne aktiv einzugreifen. Ideal zum Einstieg.
Nach 7–14 Tagen Laufzeit liefert kubectl describe vpa checkout-api-vpa die p50/p95-Werte. Für eine Cluster-weite Übersicht hat sich das Fairwinds-Tool Goldilocks bewährt. Es installiert pro Namespace automatisch VPAs und rendert ein Dashboard mit konkreten Vorher/Nachher-YAML-Vorschlägen.
Wer einen Schritt weitergehen möchte, kombiniert VPA mit dem Horizontal Pod Autoscaler (HPA) und KEDA: HPA für lastabhängige Replika-Anzahl, KEDA für event-getriebenes Scale-to-Zero bei Queue-, Cron- oder externen Metriken. In Kombination mit Karpenters Konsolidierung führt das zu Clustern, die nachts auf einen Bruchteil ihrer Tageskapazität schrumpfen.
Wann sollte man Spot-Instanzen für Kubernetes einsetzen?
Spot-Instanzen bieten 70–90 % Rabatt gegenüber On-Demand, können aber mit zwei Minuten Vorwarnung zurückgefordert werden. Die Faustregel: Jeder Workload, der zustandslos ist, mehrere Replikas haben darf und Restart-tolerant ist, gehört auf Spot. Das deckt in der Praxis 60–80 % aller Web-Frontends, Worker, Batch-Jobs, CI-Runner und Inferenz-Pods ab. Stateful Sets (Datenbanken, Brokers) bleiben On-Demand oder werden über Reserved Instances und Savings Plans rabattiert.
Drei Praxis-Regeln, die teure Lehrgelder vermeiden:
Pool-Diversifikation: Erlauben Sie Karpenter eine breite Auswahl an Instance-Typen (mindestens 10–15 Familien). Spot-Reclaims betreffen meist nur einzelne Pools, sodass Karpenter sofort auf einen anderen Pool ausweichen kann.
PodDisruptionBudget pflichtig: Ohne PDB können bei einem gleichzeitigen Spot-Reclaim mehrerer Knoten ganze Services kurzzeitig unavailable werden. Setzen Sie für jedes produktive Deployment mindestens minAvailable: 50%.
Graceful Shutdown ≤ 90 s: AWS gibt zwei Minuten Vorwarnung. Wenn Ihr Pod 180 Sekunden für den Shutdown braucht, verliert er beim Spot-Reclaim Requests. Tunen Sie terminationGracePeriodSeconds und preStop-Hooks entsprechend.
Weiterführend lohnt sich unser Leitfaden zu FinOps für KI-Workloads. Die dort beschriebenen Spot-Strategien für GPU-Knoten lassen sich 1:1 auf normale Compute-Pools übertragen.
FOCUS 1.1 und Cross-Cloud-Showback
Die FinOps Open Cost and Usage Specification (FOCUS) der FinOps Foundation hat sich 2026 zum De-facto-Standard für anbieterübergreifende Kostendaten entwickelt. Version 1.1 (März 2026) ergänzt Kubernetes-spezifische Attribute wie ContainerCluster, Namespace und WorkloadName und macht damit Showback über mehrere Clouds hinweg endlich praktikabel.
Kubecost 2.5, OpenCost 1.115 und auch Apptio Cloudability exportieren nativ in das FOCUS-Schema. Damit lässt sich ein Multi-Cloud-Showback in Snowflake, BigQuery oder Athena auf einer einzigen Tabelle abfragen, anstatt drei verschiedene Billing-Schemata zu joinen.
-- Beispiel: monatliche Kubernetes-Kosten pro Team über AWS + Azure
SELECT
BillingPeriodStart,
Tags['team'] AS team,
Provider,
SUM(BilledCost) AS cost_eur
FROM focus_v1_1.unified_costs
WHERE ServiceCategory = 'Compute'
AND ChargeCategory = 'Usage'
AND ContainerCluster IS NOT NULL
GROUP BY 1, 2, 3
ORDER BY 1 DESC, cost_eur DESC;
Showback-Reports (also die Sichtbarmachung der Kosten pro Team) verändern Verhalten nachweislich stärker als jede technische Optimierung. Sobald ein Team monatlich sieht, dass es 12.000 EUR pro Monat allein für Idle-Kapazität bezahlt, ändert sich die Diskussion um Resource Requests schlagartig.
Typische Fehler bei der Kubernetes-Kostenoptimierung
Aus zwei Jahren FinOps-Reviews in deutschsprachigen Plattformteams stechen sechs Fehler immer wieder heraus, die jeden Spar-Effort sabotieren:
Karpenter ohne Limits: Ohne limits.cpu auf NodePool-Ebene kann ein einziger fehlerhafter Deployment-Loop einen Cluster auf hunderte Knoten skalieren und eine sechsstellige Rechnung in 24 Stunden produzieren.
Keine PodDisruptionBudgets: Konsolidierung und Spot-Reclaim brauchen PDBs, sonst werden zu viele Pods gleichzeitig evictiert und SLOs reißen.
VPA und HPA auf derselben Metrik: Beide auf CPU laufen gegeneinander. Lassen Sie VPA Memory tunen und HPA CPU, oder umgekehrt.
Reserved Instances vor Karpenter: Erst die Workloads optimieren, dann Commitments kaufen. Wer früh RIs oder Savings Plans bucht, kauft auf der falschen Baseline.
Egress vergessen: Cross-AZ-Traffic kostet in AWS 0,01 USD/GB pro Richtung. Topology-Aware-Routing in Kubernetes 1.30+ halbiert oft die Egress-Rechnung, wird aber selten aktiviert.
Kein Owner pro Namespace: Ohne Label team=… oder cost-center=… auf jedem Pod ist Showback wertlos. Setzen Sie das per Kyverno- oder OPA-Policy als Pflicht durch.
Häufige Fragen
Wie viel Geld lässt sich realistisch mit Karpenter und Kubecost sparen?
In gewachsenen Produktionsclustern sind 40–70 % Einsparung der Compute-Rechnung realistisch, wenn Karpenter, konsequentes Right-Sizing und Spot-Instanzen kombiniert werden. Greenfield-Cluster, die von Anfang an mit dieser Architektur laufen, sehen typischerweise 25–40 % geringere Kosten gegenüber einem klassischen Setup mit Cluster Autoscaler und fixen Node Groups.
Kann Karpenter den Cluster Autoscaler vollständig ersetzen?
Ja. Karpenter v1.2 ist seit Mitte 2025 in AWS und Azure produktionsreif und übernimmt sämtliche Funktionen des Cluster Autoscalers plus Konsolidierung und feingranulare Instance-Auswahl. Für GCP befindet sich Karpenter noch im Preview-Stadium; dort bleibt der GKE-native Autoscaler aktuell die bessere Wahl.
Ist Kubecost kostenlos und wie unterscheidet es sich von OpenCost?
OpenCost ist das CNCF-Inkubationsprojekt und vollständig Open Source. Kubecost basiert auf OpenCost, ergänzt aber eine UI, Multi-Cluster-Aggregation und Empfehlungen. Die Free-Tier-Variante von Kubecost reicht für die meisten kleinen bis mittleren Cluster aus; Enterprise-Features wie SSO, Multi-Cluster-Rollup und SAML kosten ab ca. 199 USD pro Cluster und Monat.
Welche Workloads sollten nicht auf Spot-Instanzen laufen?
Stateful Sets mit lokalem Storage (z. B. Kafka, ZooKeeper, etcd), Workloads mit langlaufenden, nicht-resumierbaren Berechnungen und alles, was harte Latenz-SLOs hat und beim Reclaim keinen Failover schafft. Faustregel: Wenn der Pod-Start länger als 60 Sekunden dauert oder das Wiederherstellen des Zustands aufwändig ist, bleibt der Workload auf On-Demand oder Reserved Capacity.
Was ist die FOCUS-Spezifikation und brauche ich sie?
FOCUS (FinOps Open Cost and Usage Specification) ist ein offener Standard der FinOps Foundation, der Kostendaten von AWS, Azure, GCP, OCI und Kubernetes in ein einheitliches Schema überführt. Für Single-Cloud-Setups ist sie optional. Bei Multi-Cloud oder regulierten Branchen mit Reporting-Pflichten reduziert sie den Integrationsaufwand für Showback und Forecasting erheblich.
