Azure AKS Karpenter ist GA — Node-Provisioning ohne Cluster-Autoscaler

Microsoft hat heute Karpenter für Azure Kubernetes Service offiziell auf GA-Status gesetzt. Damit zieht Azure mit AWS gleich, die Karpenter seit 2021 als bevorzugten Node-Autoscaler unterstützen. Cluster-Autoscaler in AKS bleibt verfügbar, wird aber zur Legacy-Option.

TL;DR

• Karpenter für AKS ist GA — in allen kommerziellen Regionen, inklusive Germany West Central und Sweden Central.
• Pod-Scheduling-Latenz: laut Microsoft ~30 Sekunden vs Cluster-Autoscaler 2–4 Minuten.
• Native Unterstützung für Spot-VMs, Ephemeral-OS-Disks, Reserved-Instance-Pools und Mixed-Instance-Types.
• Konfiguration über CRDs (AKSNodeClass, NodePool) statt AKS-VM-Scale-Sets.
• Migration-Pfad für bestehende Cluster: Karpenter und CAS können parallel laufen, schrittweise Workload-Migration möglich.

Was wurde geändert

Karpenter macht Node-Autoscaling pod-driven statt VMSS-driven: wenn ein Pod nicht schedulen kann, sucht Karpenter passende VM-SKUs aus Azures Katalog (mit gewünschten CPU/RAM/GPU-Anforderungen, zone-aware, Spot- oder On-Demand) und provisioniert direkt — keine Vorab-Definition von Node-Pools nötig.

Konkret heißt das:

• Statt 5 Node-Pools (small/medium/large/gpu/spot) reicht eine AKSNodeClass mit Constraints.
• Karpenter pickt den günstigsten passenden SKU pro Pod-Set.
• Spot-Eviction-Handling ist out-of-the-box: bei Eviction rescheduled Karpenter sofort auf On-Demand.

Voraussetzungen: AKS-Version 1.30+, Workload-Identity, Networking via Azure CNI oder CNI Overlay.

Was bedeutet das für DACH-Teams

Wer AKS in Produktion fährt, sollte Karpenter in der nächsten Sprint-Iteration in Staging testen. Drei Gewinne, die sofort sichtbar werden:

• 20–40 % weniger Compute-Cost durch besser passende VM-Sizes und intelligentere Spot-Nutzung. AWS-Teams berichten seit Jahren ähnliche Numbers für EKS.
• Schnellere Deploys bei spike-load-Workloads (Web, Batch, CI-Runner) — 30 Sekunden statt 3 Minuten Node-Spin-up macht den Unterschied zwischen "Pod pending" und "Pod running" sichtbar.
• Einfachere Cluster-Konfiguration: weniger Node-Pools, weniger Pinning, weniger Toleranz-Magic.

Aber Karpenter ist nicht für alle Workloads die richtige Wahl:

• Stateful Sets mit lokalem Storage profitieren wenig, weil Nodes häufiger neu provisioniert werden.
• Lange Bootstrapping-Phasen (z. B. ML-Container, die per Init-Container 10 GB Models pullen) brauchen Caching oder warmup-Strategien.
• Compliance-Setups mit fest gepinnten VM-SKUs verlieren Flexibilität — hier ist CAS weiterhin besser.

Der Wechsel selbst ist nicht trivial: Karpenter setzt einige Cluster-Voraussetzungen voraus (CNI-Modus, Identity, RBAC). Wer einen alten AKS-Cluster mit Kubenet hat, muss erst migrieren.

Quelle: Azure Updates

Stand: 8. Mai 2026. Karpenter-Konfigurations-APIs sind GA-stabil, aber Best-Practices entwickeln sich noch — Azure-Doku regelmäßig prüfen.