Karpenter-Kosten sind die Kosten der Nodes, die Karpenter anlegt, und die Einsparung aus den Nodes, die es wieder entfernt; dasselbe gilt für den Cluster Autoscaler und für die verwalteten Varianten der Anbieter. Ein Node-Autoscaler hat keinen eigenen Preis, außer dort, wo der Anbieter ihn als Dienst verkauft, aber jede seiner Einstellungen ist ein Betrag auf der Rechnung: die Mindestzahl der Nodes, die Wartezeit vor dem Abbau, die Auslastungsschwelle, die Konsolidierungsregel. Diese Seite beschreibt diese Einstellungen als Kosten, was Karpenters NodePools, Konsolidierung und Disruption Budgets daran ändern, was EKS Auto Mode, AKS Node Auto Provisioning und die automatische Node-Pool-Erstellung von GKE kosten, und worauf nach dem Einschalten in der Rechnung zu achten ist. Wie die Autoscaler entscheiden, beschreibt Kubernetes-Effizienz; hier geht es um den Preis der Entscheidung.

So funktioniert es

Beide Node-Autoscaler reagieren auf Requests, nicht auf Nutzung: Sie legen Nodes an, wenn Pods wegen fehlender Kapazität nicht platziert werden können, und entfernen Nodes, deren Pods anderswo Platz finden. Zwischen beiden Richtungen liegen Verzögerungen, und die Verzögerungen kosten Geld.

Der Cluster Autoscaler hält einen Node für entbehrlich, wenn die Summe der CPU-Requests und die der Speicher-Requests unter 50 Prozent seiner Allocatable-Kapazität liegen (Schwelle einstellbar), und entfernt ihn, nachdem er zehn Minuten in diesem Zustand war; nach einem Scale-up wartet er weitere zehn Minuten, bevor er den Abbau überhaupt prüft. Jeder dieser Zeiträume ist bezahlte Node-Zeit ohne Arbeit. Dazu kommt die Mindestgröße der Node-Gruppe, die ein Boden unter der Rechnung ist, gleich wie leer der Cluster wird, und die Liste der Pods, die einen Abbau blockieren: Pods ohne Controller, Pods mit lokalem Speicher, kube-system-Pods ohne PodDisruptionBudget, Pods mit einem zu restriktiven Budget und solche mit der Annotation safe-to-evict: "false". Ein einziger solcher Pod hält einen ganzen Node am Leben.

neinjajaneinjaneinEin NodeCPU- und Speicher-Requests unter der Hälfteseiner zuteilbarenKapazität?BehaltenZehn Minuten entbehrlich,und zehn weitere nach jedemHochskalieren: bezahlteLeerlaufzeitBlockiert? Ein Pod ohneController, lokaler Speicher,ein Disruption Budget, eineSafe-to-evict-AnnotationÜber dem Minimumder Node-Gruppe?Entfernt
Ein Node verlässt den Cluster Autoscaler erst, wenn seine Requests die Wartezeit lang unter der Schwelle liegen und nichts auf ihm die Entfernung blockiert

Karpenter ersetzt die statische Node-Gruppe durch einen NodePool mit Anforderungen: zulässige Familien, Größen, Architekturen und Kapazitätstypen, Limits für die Summe der Ressourcen, und eine Disruption-Konfiguration. Für jeden wartenden Pod wählt es die günstigste passende Instanz; die Konsolidierung entfernt einen Node, dessen Pods auf freie Kapazität anderer Nodes passen, oder ersetzt ihn durch einen günstigeren. consolidationPolicy legt fest, welche Nodes infrage kommen: nur leere (WhenEmpty), alle, die sich entfernen oder günstiger ersetzen lassen (WhenEmptyOrUnderutilized, der Standard), oder, als Balanced, nur solche, bei denen die Einsparung die Störung laufender Pods aufwiegt. consolidateAfter (Standard 0s) ist die Wartezeit, bevor ein Node nach einer Pod-Änderung geprüft wird; Never schaltet die Konsolidierung ab. Disruption Budgets begrenzen, wie viele Nodes gleichzeitig unterbrochen werden, standardmäßig 10 Prozent, wahlweise nach Grund (Underutilized, Empty, Drifted) und Zeitfenster; ein enges Budget schützt Workloads und verlangsamt die Einsparung. Die Annotation karpenter.sh/do-not-disrupt am Pod und ein blockierendes PodDisruptionBudget nehmen einen Node aus der freiwilligen Unterbrechung. Spot-Nodes werden standardmäßig nur gelöscht, nicht durch günstigere Spot-Nodes ersetzt; der Ersatz verlangt das Feature-Flag SpotToSpotConsolidation und mindestens 15 zulässige Instanztypen.

AWS

EKS Auto Mode betreibt Karpenter als Teil des Dienstes: Nodes werden für nicht platzierbare Pods angelegt, wegkonsolidiert, nach spätestens 21 Tagen ersetzt, und Spot-Unterbrechungen werden vom Dienst behandelt. Dafür berechnet AWS je gestarteter Instanz und Stunde eine Verwaltungsgebühr nach Instanztyp zusätzlich zum EC2-Preis; die Positionen stehen unter Amazon EKS mit Usage Types wie EKS-Auto:m6i.large-management-hours (EKS, ECS und Fargate). Ohne Auto Mode ist Karpenter Open-Source-Software, die der Kunde installiert und betreibt, ohne Gebühr, mit dem Betrieb als Kosten.

Azure

Node Auto Provisioning (NAP) betreibt Karpenter für AKS und wählt VM-Größen nach den Requests wartender Pods; in AKS Automatic ist es vorkonfiguriert, in AKS Standard wird es eingeschaltet. NAP selbst hat keinen eigenen Preis; AKS Automatic berechnet je Cluster und Stunde die gehostete Steuerungsebene und je vCPU und Stunde eine Gebühr nach VM-Kategorie. Der Cluster Autoscaler von AKS arbeitet mit den Standardwerten 0,5 und zehn Minuten.

Google Cloud

In GKE Standard legt die automatische Node-Pool-Erstellung für wartende Pods eigene Node-Pools an und entfernt sie wieder, ohne eigene Gebühr; der Cluster Autoscaler kennt die Profile balanced (Reserven für schnelle Starts) und optimize-utilization (früherer, stärkerer Abbau). Autopilot hat keine Nodes zu skalieren: Dort entfällt die ganze Mechanik, und der Preis ist der der Requests.

Was es für Ihre Kosten bedeutet

Die Rechnung eines Clusters mit Nodes hat drei Bestandteile, die der Node-Autoscaler bestimmt: einen Boden aus Mindestgrößen und System-Pools (Node-Pools und Instanzauswahl), einen Nachlauf aus Wartezeiten und blockierten Nodes, und einen Verschnitt aus Nodes, deren Pods zusammengepackt werden könnten. Karpenter senkt vor allem den Verschnitt, weil es Nodes einzeln passend wählt und wegkonsolidiert; der Cluster Autoscaler senkt ihn nur innerhalb der Gruppen, die es gibt. Beide lassen den Boden stehen, den die Mindestgrößen setzen. Der Preis der verwalteten Varianten ist die Gebühr gegen den Betrieb: Was ein Team an Karpenter-Upgrades, Node-Images und Unterbrechungsbehandlung nicht mehr selbst macht, zahlt es als Gebühr je Instanz.

Die Node-RechnungDer Boden: Mindestgrößenund Systempools, wie leerder Cluster auch wirdDer Schwanz: Wartezeitenund von der Entfernungblockierte NodesDer Verschnitt: Nodes,deren Pods sichzusammenpacken ließenKarpenter: wählt jeden Node passendzum wartenden Pod und konsolidiert;der Cluster Autoscaler nur innerhalbbestehender GruppenVon beiden belassen: dieMindestgrößen setzen ihn
Die Node-Rechnung eines Clusters ist ein Boden, ein Schwanz und Verschnitt, und Karpenter senkt vor allem den Verschnitt, indem es Nodes einzeln passend wählt und konsolidiert

Nach dem Einschalten eines Node-Autoscalers oder dem Wechsel zu Karpenter sind in der Rechnung drei Dinge zu prüfen: Die Instanzstunden der Nodes müssen sinken, sonst konsolidiert nichts; die Mischung der Instanztypen ändert sich, weil Karpenter aus allen zulässigen Typen wählt, und ein Commitment, das auf eine Familie gebucht war, kann dadurch unausgelastet bleiben; und neue Positionen kommen hinzu, die Verwaltungsgebühr je Instanz bei Auto Mode und die Gebühren von AKS Automatic. Welche Nodes der Autoscaler warum behält, meldet Karpenter als Ereignis am Node; ohne diesen Blick bleibt die Ursache eines stehenden Nodes Vermutung.

Wo es schiefgeht

  • Boden statt Einsparung. Symptom: Nachts laufen genau so viele Nodes wie die Mindestgröße erlaubt, obwohl kaum Pods laufen. Ursache: Die Mindestgröße des Pools oder der Node-Gruppe ist der Boden der Rechnung; der Autoscaler kann ihn nicht unterschreiten.
  • Node bleibt wegen eines Pods. Symptom: Ein fast leerer Node läuft tagelang. Ursache: Ein Pod ohne Controller, mit lokalem Speicher, mit restriktivem PodDisruptionBudget oder mit do-not-disrupt blockiert den Abbau.
  • Konsolidierung ausgebremst. Symptom: Karpenter meldet Konsolidierungskandidaten, entfernt sie aber nur langsam. Ursache: Das Disruption Budget erlaubt wenige Nodes gleichzeitig, oder consolidateAfter ist lang gesetzt.
  • Commitment nach Karpenter unausgelastet. Symptom: Die Abdeckung eines Savings Plan oder einer Reservierung sinkt nach dem Wechsel. Ursache: Karpenter wählt andere Familien und Größen als die, auf die das Commitment lautete.
  • Gebühr nicht eingeplant. Symptom: Unter Amazon EKS erscheinen neue Positionen je Instanz. Ursache: Die Verwaltungsgebühr von EKS Auto Mode läuft je gestarteter Instanz und Stunde, zusätzlich zu EC2.
  • Spot-Nodes nicht ersetzt. Symptom: Teure Spot-Nodes bleiben, obwohl günstigere verfügbar wären. Ursache: SpotToSpotConsolidation ist nicht eingeschaltet, oder der NodePool lässt weniger als 15 Instanztypen zu.

Beispiel

Listenpreise, gelesen am 2026-10-21 aus den AWS-Preislisten für Frankfurt (eu-central-1): m6i.large On-Demand unter Linux 0,115 USD je Stunde; EKS Auto Mode Verwaltungsgebühr für m6i.large 0,0138 USD, für c6a.2xlarge (EC2 0,3492 USD) 0,0419 USD je Stunde.

Ein Pool aus zehn m6i.large kostet 10 × 0,115 × 730 = 839,50 USD im Monat. Passen die Pods von drei Nodes auf die freie Kapazität der übrigen sieben, spart die Konsolidierung 3 × 0,115 × 730 = 251,85 USD im Monat; eine Mindestgröße von drei Nodes lässt davon nichts übrig, wenn der Cluster nachts leer ist, weil 3 × 83,95 = 251,85 USD der Boden bleiben. Jeder Scale-down-Vorgang mit zehn Minuten Wartezeit kostet je Node 10/60 × 0,115 = 0,0192 USD; bei 30 Vorgängen im Monat auf drei Nodes 1,73 USD. Mit EKS Auto Mode kämen für die zehn Nodes 10 × 0,0138 × 730 = 100,74 USD Verwaltungsgebühr im Monat hinzu, zwölf Prozent des EC2-Betrags; für c6a.2xlarge ebenfalls 0,0419/0,3492 = zwölf Prozent.

Quellen

Gelesen am 2026-10-21. Cluster Autoscaler FAQ, Karpenter Disruption und NodePools, AWS EKS Auto Mode und Amazon EKS Preise, AWS Price List Bulk API, Angebote AmazonEC2 und AmazonEKS, eu-central-1, Microsoft Node Auto Provisioning und Cluster Autoscaler in AKS, Google Cloud GKE Cluster Autoscaler und automatische Erstellung von Node-Pools.