Kubernetes-FinOps: Die Hebel, die 70 Prozent Cluster-Verschwendung schließen
40 bis 70 Prozent der K8s-Ressourcen liegen brach. Vier Hebel schließen die Verschwendung – Right-Sizing zuerst.
40 bis 70 Prozent der provisionierten Kubernetes-Compute-Ressourcen liegen brach. Wer als Platform-Engineer Requests nicht korrigiert, zahlt weiter für Leerstand, den kein Autoscaler wegoptimiert. Die vier Hebel, die wirklich zählen, folgen einer festen Reihenfolge – Right-Sizing zuerst, alles andere baut darauf auf.
Das Wichtigste in Kürze
- Verschwendung ist eine Spanne, kein fester Wert: 40 bis 70 Prozent der K8s-Compute-Ressourcen sind ungenutzt. Messen vor optimieren – die Spanne zeigt, wo der Hebel im eigenen Cluster liegt.
- Right-Sizing ist die Basis: Ohne korrigierte CPU- und Memory-Requests multiplizieren nachgelagerte Hebel falsche Werte. HPA, Karpenter und Spot-Pools rechnen dann auf falschen Definitionen.
- KEDA für event-getriebene Workloads: Scale-to-zero bei Idle lohnt sich für queue-basierte Services, nicht für immer-on APIs mit konstanter Latenzanforderung.
- Karpenter ist die neuere Alternative zum Cluster-Autoscaler: Direkte Node-Provisionierung ohne Node-Group-Zwischenschicht, flexibler bei dynamischen Workload-Typen.
Verwandt:FinOps: 30 Prozent Cloud-Kosten realistisch senken / Was das Cilium-Upgrade im Cluster kappen kann
Warum Right-Sizing der Dreh- und Angelpunkt ist
Requests und Limits sind die Basis, auf der jeder nachgelagerte Hebel rechnet. Wer sie ignoriert und direkt auf Karpenter oder Spot setzt, optimiert auf einem fehlerhaften Fundament. HPA skaliert auf falsche Schwellen. Karpenter stellt falsche Node-Typen bereit. Spot-Pools werden falsch dimensioniert. Ohne korrigierte Requests greift kein nachfolgender Hebel sauber.
Right-Sizing korrigiert die Definition selbst. Es beantwortet pro Workload, wie viel CPU und Memory tatsächlich gebraucht werden, statt sich an Daumenregeln oder Default-Werten zu orientieren. VPA im Empfehlungsmodus liefert dafür die Grundlage – der Auto-Modus gehört nicht ohne Drain-Strategie direkt in die Produktion. Wer einmal pro Quartal die Requests gegen die tatsächliche Auslastung zieht, schließt die größte Verschwendungsquelle, bevor ein einziger Autoscaler greift.
Scale-to-zero mit KEDA für event-getriebene Workloads
KEDA erweitert den Horizontal Pod Autoscaler um externe Trigger wie Kafka, SQS oder RabbitMQ. Wo HPA auf CPU- oder Memory-Schwellen reagiert, skaliert KEDA auf Queue-Tiefe oder Event-Rate und fährt Workloads bei Idle auf null herunter. Für Services, die nur bei Ereignissen arbeiten, ist das der sauberste Hebel gegen Dauerleistung für Leerlauf.
KEDA ist keine Universal-Lösung. Immer-on APIs mit konstanter Latenzanforderung profitieren nicht von Scale-to-zero, weil der Kaltstart die SLA bricht. Der Einsatz lohnt sich für event-getriebene Services mit klaren Idle-Phasen – Batch-Worker, asynchrone Verarbeitung, Webhook-Konsumenten. Wer KEDA dort einsetzt, wo HPA die richtige Antwort wäre, zahlt mit Instabilität statt mit Geld.
Cluster-Autoscaler oder Karpenter – Nodes dynamisch nachschalten
Cluster-Autoscaler ist etabliert und arbeitet auf Node-Groups. Er fügt Nodes hinzu, wenn Pods pending bleiben. Sinkt die Auslastung, nimmt er sie zurück. Karpenter provisioniert Nodes direkt ohne Node-Group-Zwischenschicht und ist die neuere, flexiblere Variante bei dynamischen Workload-Typen.
Die Wahl hängt von der Cluster-Strategie und der Provider-Reife ab. Karpenter ist auf EKS primärer Support, auf GKE in anderer Form verfügbar. Wer feste Node-Groups und konservative Migration pflegt, bleibt beim Cluster-Autoscaler. Wer Node-Typen je nach Workload-Anforderung dynamisch mischen will, gewinnt mit Karpenter Flexibilität, die der Cluster-Autoscaler von Design her nicht liefert.
Spot- und Preemptible-VMs – der Risikokompromiss
Spot-VMs drücken Kosten für fehlertolerante Workloads wie Batch, CI-Runner oder asynchrone Worker deutlich. Voraussetzung ist saubere Preemption-Toleranz: PodDisruptionBudgets, Graceful Shutdown und Replica-Verteilung über mehrere Nodes. Wer diese Voraussetzung nicht prüft, riskiert Replica-Verlust bei jeder Preemption-Welle.
Spot lohnt sich dort, wo ein plötzlicher Pod-Verlust die Anwendung nicht bricht. Stateful Services, latenzkritische APIs und Single-Replica-Workloads gehören nicht auf Spot. Die saubere Trennung nach Workload-Typ ist der entscheidende Punkt – ein Cluster, der alles auf Spot packt, tauscht Kosteneinsparung gegen Zuverlässigkeit.
Reihenfolge und Messung – was wann greifen sollte
Die Reihenfolge ist nicht optional. Zuerst die Metrics-Grundlage schaffen (kube-metrics, VPA-Recommendations), dann Right-Sizing als Basis. Auf den korrigierten Werten folgen HPA und KEDA für Workload-Scaling. Karpenter oder Cluster-Autoscaler provisionieren Nodes passend zum Workload-Bedarf. Spot-VMs reduzieren Kosten auf den Workloads, die Preemption tolerieren. CUDs und Managed-Layer wie Autopilot sind Commitment- beziehungsweise Bequemlichkeitsebenen ganz am Schluss.
Wer diese Reihenfolge umdreht, optimiert im Blindflug. Spot ohne korrigierte Requests trifft die falschen Workloads. Karpenter ohne Right-Sizing stellt die falschen Node-Typen bereit. Die Disziplin liegt darin, Basisarbeit zuerst zu machen – und das ist in Kubernetes selten glamourös, aber wirtschaftlich der stärkste Hebel.
Häufige Fragen
Wann KEDA statt HPA?
Bei externen Triggern wie Kafka, SQS oder RabbitMQ. HPA bleibt die richtige Antwort für CPU- oder Memory-basiertes Scaling. KEDA lohnt sich nur für event-getriebene Workloads mit klaren Idle-Phasen, nicht für immer-on APIs mit konstanter Latenzanforderung.
Karpenter oder Cluster-Autoscaler auf bestehendem GKE oder EKS?
Karpenter bei dynamischen Node-Typen und wenn der Provider primären Support liefert (EKS). Cluster-Autoscaler bei festen Node-Groups und konservativer Migration. Die Entscheidung hängt an der Cluster-Strategie, nicht am Geschmack.
Ist VPA im Empfehlungsmodus sicher?
Ja, für die Initial-Messung der tatsächlichen Ressourcennutzung. Der Auto-Modus gehört nicht ohne Drain-Strategie direkt in die Produktion. Empfehlungsmodus liefert die Datenbasis für sauberes Right-Sizing, ohne Pods aktiv zu beeinflussen.
Sind 70 Prozent Verschwendung realistisch oder Marketing?
Es ist eine Spanne von 40 bis 70 Prozent, keine feste Zahl. Der eigene Cluster kann überall in diesem Bereich liegen. Messen Sie die tatsächliche Auslastung gegen die Requests, bevor sie eine Zahl aus einer Studie übernehmen – sie ist Orientierung, kein Befund.
Lohnt sich Goldilocks als Tool für Right-Sizing?
Goldilocks visualisiert VPA-Recommendations als Resource-Requests-Vorschläge und ist ein guter Einstieg, wenn sie noch keine eigene Metrics-Pipeline haben. Für reife Setups reicht oft VPA im Empfehlungsmodus plus ein Quartals-Rhythmus gegen die tatsächliche Auslastung.
Weiterführende Lektüre
cloudmagazinFinOps: 30 Prozent Cloud-Kosten realistisch senkencloudmagazinWas das Cilium-Upgrade im Cluster kappen kanncloudmagazinIngress-NGINX ist abgekündigt: Der Weg zur Gateway APIBildquelle: KI-generiert (Juli 2026)
