Kubernetes-Kosten kommen selten aus Kubernetes selbst. Sie kommen aus dem Node-Pool: zu viele Nodes, zu große Nodes, zu wenig Spot. Karpenter löst die ersten zwei Probleme elegant — und macht das dritte Problem einfach angehbar.
Was Karpenter anders macht
Cluster Autoscaler arbeitet mit vordefinierten Node-Groups. Karpenter wählt stattdessen den optimalen Instance-Typ für die gerade zu platzierenden Pods — direkt aus dem AWS-Katalog. Der Unterschied in der Praxis:
- Bessere Bin-Packing-Dichte: Karpenter packt Pods auf Nodes, die zur Summe der Requests passen — nicht auf vorausbestimmte Größen
- Schnelleres Scale-Up: keine Node-Group-Abhängigkeit, Nodes starten in 30-60 Sekunden statt 2-3 Minuten
- Consolidation: leere oder unterausgelastete Nodes werden proaktiv konsolidiert, ohne menschlichen Eingriff
- Spot-nativ: Spot-Instances sind first-class, nicht nachträglich drangeklatscht
Aggressive Spot-Strategie
Die größten Kosteneinsparungen in einer produktiven Kubernetes-Umgebung kommen aus Spot — wenn man sich traut. Mit Karpenter lässt sich Spot mit akzeptablen Risiken aggressiv nutzen:
- NodePools nach Workload-Kritikalität trennen: kritische Stateful-Services nur auf On-Demand, Batch/Worker-Pods auf Spot
- Node Interruption Handler aktivieren — Karpenter reagiert auf Spot-Interruption-Events in unter 2 Minuten
- Instance-Type-Diversity: Karpenter-Requirements erlauben mehrere Instance-Families; AWS verteilt Interruption-Risiko
- Pod Disruption Budgets ernst nehmen — sonst werden kritische Services bei Consolidation ungünstig verlegt
Zahlen aus einem Enterprise-Engagement
In einer AWS/EKS-Plattform mit 1.000+ Services haben wir Cluster Autoscaler durch Karpenter ersetzt:
- Compute-Kosten deutlich reduziert (zweistelliger Prozentsatz) — hauptsächlich durch höheren Spot-Anteil
- Time-to-scale von durchschnittlich 3 Minuten auf unter 60 Sekunden für neue Pods
- Cluster-Utilization-Rate signifikant gestiegen (Node-Auslastung durch besseres Bin-Packing)
- Operativer Aufwand gesunken: keine Node-Group-Pflege mehr, keine manuellen Instance-Type-Updates
Wo Karpenter nicht passt
Karpenter ist nicht immer die richtige Wahl. Wer harte Hardware-Anforderungen hat (bestimmte GPU-Typen, specialized Nodes), profitiert wenig. Wer mit kleinem Cluster ohne Node-Pool-Vielfalt arbeitet, bekommt keinen nennenswerten Vorteil. Für alles dazwischen — und das ist die Mehrheit produktiver EKS-Cluster — ist Karpenter heute die bessere Wahl.
“Der einfachste Weg, Cloud-Kosten zu senken, ist nicht Reserved Instances. Es ist, die Nodes besser zu nutzen, die man ohnehin bezahlt.”