▸ saaro:~/blog ▊ Notizen & Artikel
← zurück

📷 "Docker HQ, San Francisco, California" by willbuckner is licensed under CC BY 2.0. To view a copy of this license, visit https://creativecommons.org/licenses/by/2.0/.

Kubernetes-Autoscaling 2026: Warum Karpenter den Cluster Autoscaler ablöst

06. August 2026 · 5 min · Martin Jochum #Kubernetes#Karpenter#Autoscaling#DevOps#Cluster Autoscaler#Cloud Native

Kubernetes-Autoscaling war lange Zeit eine Domäne des Cluster Autoscaler, der seit 2016 zuverlässig Node-Gruppen hoch- und herunterskaliert. Doch 2026 hat sich das Blatt gewendet: Karpenter, das ursprünglich von AWS entwickelte und inzwischen zur CNCF gehörende Projekt, wird zunehmend zum neuen Standard für intelligente Node-Provisionierung. Mit EKS Auto Mode hat AWS Karpenter sogar zum Managed Default gemacht. Was steckt hinter diesem Wandel, und welche Vorteile bietet Karpenter gegenüber dem etablierten Cluster Autoscaler?

Was ist Karpenter?

Karpenter ist ein Open-Source-Node-Provisioner für Kubernetes, der direkt mit der Cloud-API kommuniziert – ohne den Umweg über Auto Scaling Groups oder vergleichbare Abstraktionsebenen. Während der Cluster Autoscaler vordefinierte Node-Gruppen skaliert, analysiert Karpenter die tatsächlichen Anforderungen ausstehender Pods (CPU, Memory, GPU, Architektur, Zonen-Constraints) und provisioniert genau passende Instanzen in Echtzeit.

Die Architektur ist denkbar einfach: Karpenter beobachtet den Scheduler auf unschedulable Pods, ermittelt über einen NodePool die zulässigen Instanztypen und Kapazitätsoptionen und ruft direkt die Compute-API des Cloud-Anbieters auf. Sobald der neue Node dem Cluster beitritt, platziert der Scheduler die wartenden Pods. Der gesamte Vorgang dauert in der Regel 30 bis 60 Sekunden – der Cluster Autoscaler benötigt dafür meist 2 bis 5 Minuten.

Karpenter vs. Cluster Autoscaler: Die wichtigsten Unterschiede

Der grundlegende architektonische Unterschied prägt alle weiteren Eigenschaften:

Provisioning-Geschwindigkeit: Karpenter provisioniert Nodes direkt über die EC2-Fleet-API (bzw. die entsprechenden APIs bei Azure). Der Cluster Autoscaler hingegen pollt alle 10 Sekunden, simuliert das Scheduling und skaliert dann eine Auto Scaling Group – ein Prozess, der mehrere Minuten dauert. Für burst-lastige Workloads (Flash-Sales, Batch-Jobs, die von null hochfahren) kann der Unterschied zwischen einer unbemerkten Verzögerung und einem Pager-Alarm bedeuten.

Bin-Packing und Konsolidierung: Karpenter bewertet den Cluster-Zustand kontinuierlich und ersetzt mehrere unterbelegte Nodes durch weniger, besser gefüllte Instanzen – ohne auf feste Instanztypen festgelegt zu sein. Der Cluster Autoscaler kann unterbelegte Nodes zwar ebenfalls entfernen, aber nur innerhalb der Grenzen seiner vordefinierten Node-Gruppen. In Produktionsdeployments sehen Teams nach der Migration zu Karpenter typischerweise eine 20–35 % niedrigere Node-Anzahl bei gleicher Workload, allein durch dichteres Bin-Packing.

Spot-Instanzen: Karpenter behandelt Spot-Instanzen als erstklassige Bürger. Ein einziger NodePool kann Spot und On-Demand mischen, und Karpenter kümmert sich automatisch um interruptions-bewusste Konsolidierung und Fallback auf On-Demand. Beim Cluster Autoscaler müssen Spot-Workloads über separate Node-Gruppen verwaltet werden, und die Unterbrechungsbehandlung erfordert zusätzliche Tools wie den AWS Node Termination Handler.

Cloud-Unterstützung: Während der Cluster Autoscaler als CNCF-Projekt auf allen großen Clouds (AWS, GCP, Azure) gleichermaßen ausgereift ist, lag der Fokus von Karpenter lange auf AWS. Das hat sich geändert: Azure AKS bietet inzwischen einen offiziellen, produktionsreifen Karpenter-Provider (auch als Node Autoprovisioning bekannt). Die GCP-Integration bleibt hinterher, aber die Community arbeitet daran.

Was 2026 neu ist

Das Jahr 2026 hat einige wichtige Meilensteine für Karpenter gebracht:

CNCF-Zugehörigkeit: Karpenter ist mittlerweile offiziell ein CNCF-Projekt, was die langfristige Vendor-Neutralität unterstreicht. Die aktuelle Version v1.14.0 bringt stabile APIs und erweiterte Konfigurationsmöglichkeiten.

EKS Auto Mode: AWS hat Karpenter als Standard-Node-Provisioner in EKS Auto Mode integriert. Teams auf EKS erhalten damit Karpenter-ähnliche Provisionierung, ohne den Controller selbst verwalten zu müssen – ein klares Signal, dass AWS Karpenter als strategische Richtung sieht.

Erweiterte Disruption-Budgets: Karpenter erlaubt jetzt zeitbasierte Disruption-Budgets, die Konsolidierung während der Geschäftszeiten einschränken und nachts oder am Wochenende freigeben. Das verhindert überraschende Pod-Neustarts während der Hauptlast.

Praxisbeispiel: Konfiguration eines NodePools

Ein typischer Karpenter-NodePool für eine Produktionsumgebung könnte so aussehen:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: production
spec:
  template:
    spec:
      requirements:
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64", "arm64"]
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]
        - key: karpenter.k8s.aws/instance-category
          operator: In
          values: ["c", "m", "r"]
        - key: karpenter.k8s.aws/instance-generation
          operator: Gt
          values: ["5"]
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
      limits:
        cpu: 1000
        memory: 1000Gi
  disruption:
    consolidationPolicy: WhenUnderutilized
    consolidateAfter: 1m
    budgets:
      - nodes: "10%"

Die dazugehörige EC2NodeClass definiert AWS-spezifische Einstellungen wie Subnetze, Sicherheitsgruppen und die AMI-Familie. Karpenter wählt dann aus dem gesamten Katalog der EC2-Instanztypen die kostengünstigste Kombination, die die Pod-Anforderungen erfüllt.

Für wen lohnt sich der Umstieg?

Die Entscheidung für oder gegen Karpenter hängt stark vom konkreten Umfeld ab:

Karpenter ist die erste Wahl, wenn ihr auf AWS (EKS) unterwegs seid, burst-lastige oder stark variierende Workloads habt, signifikante Spot-Anteile nutzt oder eure Cloud-Kosten durch besseres Bin-Packing senken wollt.

Der Cluster Autoscaler bleibt die richtige Wahl, wenn ihr auf GCP oder einem Multi-Cloud-Setup ohne Azure-Karpenter-Provider arbeitet, eure Workloads auf wenige, gut planbare Instanztypen passen, oder euer bestehendes Cluster Autoscaler-Setup stabil läuft und kein akuter Kostendruck besteht.

Ein gut gewarteter Cluster Autoscaler muss nicht um jeden Preis ersetzt werden. Der Umstieg hat reale Kosten: Testen des Scaling-Verhaltens, Aktualisieren von Runbooks und Einarbeiten des Bereitschaftsdiensts. Wer jedoch einen neuen Cluster aufsetzt oder mit den Einschränkungen des Cluster Autoscaler kämpft, sollte Karpenter ernsthaft in Betracht ziehen.

Fazit

Karpenter hat sich 2026 vom AWS-Experiment zum ernsthaften Kandidaten für die Node-Provisionierung in Kubernetes entwickelt. Die direkte Cloud-API-Anbindung, das intelligente Bin-Packing und die native Spot-Unterstützung adressieren genau die Schwachstellen, die Teams am Cluster Autoscaler seit Jahren bemängeln. Mit der Aufnahme in die CNCF, der wachsenden Azure-Unterstützung und der Integration in EKS Auto Mode ist Karpenter bereit für den breiten Produktionseinsatz.

Die Botschaft für 2026 ist jedoch nicht „Karpenter überall", sondern „das richtige Tool für den Job". Wer auf AWS unterwegs ist oder einen Neustart plant, bekommt mit Karpenter ein leistungsfähigeres, kosteneffizienteres Werkzeug – wer einen stabil laufenden Cluster Autoscaler hat, kann getrost abwarten, bis der konkrete Leidensdruck einen Wechsel rechtfertigt.

Quellen