Karpenter vs. Cluster Autoscaler: Node-Skalierung in AWS EKS im Vergleich

Einleitung

Drei Uhr nachts. Sie starren auf rote Alarme in Grafana – Pods hängen seit vier Minuten im Pending-Status. Der Traffic-Peak ist da, aber die Nodes stehen noch auf „Starting“.

Der Admin des Nachbarclusters schläft längst. Sein Skalierungssystem hat die Nodes in 55 Sekunden online gebracht.

Das ist keine Übertreibung. So groß ist der Unterschied zwischen Karpenter und Cluster Autoscaler in der Praxis.

Als ich diese Vergleichsdaten zum ersten Mal sah, war ich skeptisch. Macht eine Minute gegen drei wirklich so viel aus? Erst nach Tests beider Systeme auf EKS wurde mir klar: Der Unterschied ist groß genug, um die gesamte Skalierungsstrategie neu zu denken.

Laut Reintech-Bericht 2026 skaliert Karpenter in unter 60 Sekunden, Cluster Autoscaler (im Folgenden CA) braucht 3–5 Minuten [1]. Bei den Kosten berichten Nutzer von 20–40 % Ersparnis [2]. Salesforce hat die Migration im dreistelligen Cluster-Bereich abgeschlossen [3].

Dieser Artikel klärt: Wo liegen die Unterschiede? Welches Tool passt zu Ihnen? Wie migrieren Sie? Mit echten Daten, vollständigen Konfigurationsbeispielen und einem Migrationszeitplan.

1. Architekturvergleich: Warum ist der Geschwindigkeitsunterschied so groß?

Kernunterschied: CA hängt an Node Groups, Karpenter konfiguriert Nodes direkt.

Das klingt einfach, doch die Architektur prägt den gesamten Skalierungsablauf.

Der Umweg des Cluster Autoscaler

CA arbeitet wie ein Umweg.

Nach fehlgeschlagenem Pod-Scheduling prüft CA zuerst vordefinierte Node Groups. Jede Gruppe ist an feste Instanztypen gebunden – z. B. node-group-1 mit m5.large, node-group-2 mit c5.xlarge.

CA muss entscheiden: Welche Node Group passt? Dann ruft er die Cloud-API (AWS Auto Scaling Groups API) auf, wartet auf Instanzstart, Cluster-Join, Node Ready – erst dann werden Pods scheduliert.

Vier bis fünf Schritte, jeder mit Latenz.

Besonders kritisch: „Node Group prüfen → Node Group wählen“. Braucht ein Pod GPU, gibt es aber keine GPU-Node Group, ist CA machtlos – er kann nur aus vorhandenen Gruppen wählen.

Karpenters direkter Ansatz

Karpenter funktioniert grundlegend anders.

Pod-Scheduling fehlgeschlagen? Karpenter analysiert die Anforderungen: Wie viel CPU? Wie viel RAM? GPU nötig? Spezielle tolerations oder nodeSelector?

Danach provisioniert Karpenter per EC2-API die passendste Instanz. Keine Node Groups, kein ASG – direkte Abstimmung auf Pod-Bedarf.

Node startet, tritt dem Cluster bei, Pod wird scheduliert. Zwei Kernschritte statt Umwege.

AWS-Dokumentation formuliert es klar: Karpenter kann Compute-Ressourcen in unter einer Minute bereitstellen [4].

Eine Analogie

CA ist wie Bestellung im Restaurant: Der Gast will scharfes Huhn – der Kellner prüft die Karte (Node Groups), bestellt (ASG), die Küche bereitet vor (Instanzstart), dann kommt das Gericht (Pod-Scheduling).

Karpenter ist wie eine offene Küche: Der Koch sieht die Wünsche (Pod Specs), holt Zutaten (EC2-API) und serviert frisch.

Welches ist schneller? Offensichtlich.

Warum hängt CA an Node Groups?

CA wurde für Multi-Cloud entworfen. Node Groups ermöglichen dieselbe Logik auf AWS, GCP und Azure – nur mit unterschiedlichen Namen (AWS: ASG, GCP: MIG, Azure: VMSS).

Diese Entscheidung bringt Grenzen: Node Groups müssen vorab definiert werden. Neuer Instanztyp? Neue Node Group. Spot-Instanzen? Spot-Node Group. Wartungsaufwand steigt, Flexibilität sinkt.

Karpenter ist AWS-nativ. Keine Node-Group-Zwischenschicht, direkte EC2-API. Nachteil: schwächerer Multi-Cloud-Support (derzeit vor allem AWS). Vorteil: Geschwindigkeit und einfachere Konfiguration.

2. Performance-Benchmarks: Verhalten in echten Umgebungen

Karpenter skaliert schnell hoch – und nicht langsam runter.

Die Daten in diesem Kapitel stammen aus CHKK-Tests und Nutzerfeedback.

Scale-out-Geschwindigkeit: Messvergleich

CHKK-Daten sind eindeutig [5]:

• Karpenter: CPU-intensive Pods in ca. 55 Sekunden online
• Cluster Autoscaler: dieselbe Last in 3–4 Minuten

Das passt zu AWS’ Angabe „unter einer Minute“ [4].

Ein Reddit-Nutzer berichtete, der Unterschied falle bei ihm geringer aus – Node-Ready-Latenz ähnlich, vermutlich wegen kleinem Cluster (~10 Nodes) [6]. Einzelfall, begrenzte Stichprobe – als Hinweis, nicht als allgemeine Regel.

Vultr - Hochleistungs-NVMe-Cloud-Server mit 32 Standorten weltweit, Docker per Klick

Preise ansehen →Anzeige

Scale-down-Effizienz: Wer spart mehr?

Schnelles Scale-out ist nur die Oberfläche – Scale-down-Effizienz spart Geld.

CA prüft periodisch (Standard: alle 10 Sekunden), ob Nodes lange idle sind. Überschreitet die Leerlaufzeit den Schwellenwert (Standard: 10 Minuten), startet Scale-down.

Karpenter nutzt Consolidation – Echtzeit-Monitoring der Node-Auslastung: Zusammenführen, wo möglich; Ersetzen, wo sinnvoll.

Beispiel: Drei m5.xlarge-Nodes mit 30 %, 25 % und 20 % Auslastung. Karpenter prüft: Passen die Pods auf einen m5.large? Wenn ja – drei große Nodes löschen, einen kleinen erstellen.

AWS-Blog nennt dazu Zahlen: Spot plus Consolidation spart bis zu 90 % gegenüber On-demand [7].

Unterschiede in großen Clustern

CA stößt in großen Clustern (100+ Nodes) an Grenzen.

ScaleOps erwähnt: Je mehr Node Groups, desto langsamer CAs Scheduling-Entscheidungen [8]. CA durchläuft alle Gruppen – mehr Gruppen, mehr Latenz.

Karpenter ist davon unabhängig. Keine Node Groups – direkte Analyse der Pod-Anforderungen und optimale Instanzwahl. Logik bleibt gleich, egal wie groß der Cluster.

Praxisbeispiel: Batch-Processing

Ein Szenario aus der Praxis:

Eine Datenpipeline startet stündlich Batch-Jobs mit 50 Worker-Pods. Unter CA warteten Pods 3 Minuten im Pending – Batch verzögert, gesamter Pipeline-Zyklus verlängert.

Nach Migration zu Karpenter liefen alle Pods in 50 Sekunden. Batch startete pünktlich, Downstream-Verarbeitung normalisierte sich.

Entscheidend: Batch-Workloads reagieren empfindlich auf Startlatenz. Drei Minuten Wartezeit können die gesamte Kette verzögern. Scale-out unter einer Minute ist hier Pflicht.

3. Kostenersparnis: Das Geheimnis der 20–40 %

Karpenters Kostenvorteil basiert auf drei Mechanismen: Spot-Instanzen, Consolidation und Instanzauswahl.

Jeder Mechanismus allein ist nicht neu. Kombiniert ergeben sie 20–40 % Ersparnis – laut Reintech-Nutzerdaten [2].

Spot-Instanzen: bis zu 90 % Ersparnis

AWS Spot-Instanzen können gegenüber On-demand bis zu 90 % günstiger sein [7] – offizielle AWS-Angabe, hohe Verlässlichkeit.

Aber Spot kann jederzeit unterbrochen werden. AWS meldet 2 Minuten vorher und beendet die Instanz [7].

Mit CA brauchen Sie manuelle Spot-Node Groups und eigene Unterbrechungslogik – aufwendig, fehleranfällig.

Karpenter behandelt Spot-Unterbrechungen automatisch: Nach Benachrichtigung cordon und drain innerhalb von 2 Minuten – ohne Extra-Skript, eingebaut.

PCO-Strategie: Spot intelligent wählen

Karpenter nutzt Price Capacity Optimized (PCO) [7].

Kurz: Zuerst Spot-Pools mit niedrigster Unterbrechungswahrscheinlichkeit, dann günstigste Instanz im Pool.

Die Strategie balanciert Kosten und Stabilität. Nur der billigste Pool → häufige Unterbrechungen. Nur der stabilste → weniger Ersparnis. PCO liegt dazwischen.

AWS-Blog erklärt [7]:

1. Karpenter überwacht Spot-Pool-Unterbrechungsraten (AWS-Daten)
2. Pools mit hoher Rate werden gefiltert
3. Im verbleibenden Pool wird der günstigste Instanztyp gewählt

Standardmäßig aktiv, keine Extra-Konfiguration.

Consolidation: Echtzeit sparen

Consolidation wurde in Kapitel 2 erwähnt – hier die Konfiguration.

Karpenter unterstützt zwei Consolidation-Strategien [7]:

• WhenEmpty: Node löschen, wenn vollständig idle
• WhenUnderutilized: Bei niedriger Auslastung zusammenführen oder ersetzen

Standard ist WhenUnderutilized – aggressiver.

Beispiel:

# Karpenter NodePool – Consolidation-Konfiguration
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: default
spec:
  disruption:
    consolidationPolicy: WhenUnderutilized  # aggressive Zusammenführung
    consolidateAfter: 1m                     # nach 1 Minute Leerlauf auslösen

CA hat das nicht. Er löscht nur periodisch lange idle Nodes – kein „kleine Nodes zu großen zusammenführen“ oder „teure Instanzen durch günstigere ersetzen“.

ROI-Rechnung: realer Nutzen

Annahme: Cluster kostet monatlich 50.000 $ (100 Nodes, gemischte Instanztypen).

Nach Migration zu Karpenter, konservativ 20 % Ersparnis: 10.000 $/Monat.

Aggressiv (Spot plus Consolidation voll genutzt) 40 %: 20.000 $/Monat.

Pro Jahr: 120.000 bis 240.000 $ Ersparnis.

Basierend auf Reintech-Nutzerdaten [2]. Tatsächlicher Nutzen hängt von Workload, Spot-Anteil und Consolidation-Konfiguration ab.

Konfigurationsvergleich: wer ist unkomplizierter?

CA Spot-Einrichtung:

1. Spot-ASG erstellen (Instanztypen manuell wählen)
2. Spot-Allocation-Strategy am ASG konfigurieren
3. Unterbrechungs-Skript schreiben (Benachrichtigung überwachen, manuell drainen)
4. CA-Parameter --node-group-auto-discovery setzen

Karpenter Spot-Konfiguration:

# Eine NodePool-YAML reicht
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      requirements:
      - key: karpenter.sh/capacity-type
        operator: In
        values: ["spot", "on-demand"]  # automatisch Spot oder On-demand
      - key: karpenter.k8s.aws/instance-category
        operator: In
        values: ["c", "m", "r"]  # c/m/r-Serien für Diversität
  disruption:
    consolidationPolicy: WhenUnderutilized

Eine YAML für Spot-Auswahl, Instanzdiversität und Consolidation. Karpenter behandelt Unterbrechungen, wählt optimale Instanzen, konsolidiert Nodes.

Der Komfortunterschied ist deutlich.

4. Konfigurationskomplexität: Aufwand und Nutzen

CA ist schnell eingerichtet, Karpenter braucht Einarbeitung – langfristig kehrt sich der Wartungsaufwand um.

Reintech [1]: CA „wenige Stunden“, Karpenter „1–2 Tage“.

Am Anfang wirkte das übertrieben. Nach praktischer Durchführung stimmte es ungefähr.

CA: schneller Einstieg, mühsame Wartung

CA-Konfiguration:

# CA Deployment (vereinfacht)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: cluster-autoscaler
  namespace: kube-system
spec:
  containers:
  - name: cluster-autoscaler
    image: k8s.gcr.io/autoscaling/cluster-autoscaler:v1.30.0
    command:
    - ./cluster-autoscaler
    - --node-group-auto-discovery=asg:tag=k8s.io/cluster-autoscaler/enabled
    - --scale-down-unneeded-time=10m
    - --scale-down-delay-after-add=10m

Kernparameter: Node-Group-Discovery, Scale-down-Schwellen, Verzögerungen. Deployment plus Node Groups (ASG) – fertig.

Wenige Stunden, kein Wunder.

🔥 Verschwende keine Monate für ungenutzte Produkte! Teste deine SaaS-Nutzenversprechen mit Adsterra bei kleinem Budget →

Jetzt testen →Anzeige

Wartung kommt später.

Neuer Instanztyp? Neue Node Group. Spot? Spot-Node Group. Viele Gruppen bedeuten viel Verwaltung: min/max, Instanztypen, Labels pro ASG.

Langfristig stapeln sich YAML-Dateien. Eine Parameteränderung kann mehrere Gruppen betreffen.

Karpenter: langsamer Start, angenehme Wartung

Karpenter erfordert Konzeptverständnis.

NodePool, Disruption, Consolidation, requirements – beim ersten Mal brauchte ich einen Tag, um jeden Parameter zu verstehen.

# Karpenter NodePool (vollständig)
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      requirements:
      - key: karpenter.k8s.aws/instance-category
        operator: In
        values: ["c", "m", "r"]
      - key: karpenter.sh/capacity-type
        operator: In
        values: ["spot", "on-demand"]
      - key: karpenter.k8s.aws/instance-generation
        operator: Gt
        values: ["5"]  # Generation 5 und höher
      nodeClassRef:
        name: default
  disruption:
    consolidationPolicy: WhenUnderutilized
    consolidateAfter: 1m
  limits:
    cpu: 1000
    memory: 1000Gi

Mehr Parameter als CAs Deployment – aber eine NodePool deckt mehrere Instanztypen, Spot/On-demand-Mix und automatische Consolidation ab.

Wartungsaufwand nahe null.

Neuer Instanztyp? values in requirements erweitern. Consolidation anpassen? consolidationPolicy ändern.

Eine YAML statt vieler Node Groups.

Abwägung beider Ansätze

Reintech empfiehlt [1]:

• CA passt zu: begrenzte Engineering-Ressourcen, einfache Konfiguration bevorzugt, homogene Workloads
• Karpenter passt zu: Platform-Engineering-Team, vielfältige Workloads, kostenbewusst, Lerninvestition akzeptiert

Kleiner Cluster (10–20 Nodes), den Sie allein betreiben? CAs Einfachheit reicht oft.

Mittlerer bis großer Cluster (50+ Nodes) oder gemischte Last (Batch + Web + GPU)? Karpenters langfristiger Wartungsaufwand ist niedriger.

5. Migrations-Roadmap: von CA zu Karpenter

Migrationsdauer 2–4 Wochen; Hauptrisiko: Parallelbetrieb zweier Systeme.

Reintech [1]. Salesforce überzeugender: Migration in über 1.000 EKS-Clustern [3].

Salesforce nutzte das Karpenter Transition Tool mit Parallelbetrieb – Details folgen.

Woche 1: Vorbereitung

Ziel: Karpenter installieren, NodePool erstellen, IAM konfigurieren.

Aufgaben:

1. Karpenter installieren (Helm oder eksctl)
2. NodePool anlegen (einfach starten, Spot/On-demand gemischt)
3. IAM-Berechtigungen (Karpenter braucht EC2-Rechte)
4. Prüfen, dass Karpenter Nodes provisioniert

Wichtig:

• IAM vollständig: ec2:RunInstances, ec2:TerminateInstances, ec2:DescribeInstances u. a.
• NodePool-limits sinnvoll setzen (z. B. cpu: 100), um unkontrolliertes Scale-out zu verhindern
• CA weiterlaufen lassen – Karpenter zunächst als Reserve

Woche 2: Testphase

Ziel: Nicht-kritische Workloads auf Karpenter, Performance vergleichen.

Aufgaben:

1. Test-Workloads wählen (Batch, niedrige Priorität)
2. Per nodeSelector oder affinity auf Karpenter-Nodes lenken
3. Scale-out-Geschwindigkeit, Spot-Unterbrechung, Consolidation beobachten
4. Latenz und Kosten CA vs. Karpenter vergleichen

Wichtig:

• Test-Workload begrenzen (10–20 % der Cluster-Ressourcen)
• Metriken: Pod-Pending-Zeit, Node-Startzeit, Spot-Unterbrechungen, Node-Auslastung
• Bei schlechter Performance NodePool-requirements oder consolidationPolicy anpassen

Woche 3: Parallelbetrieb

Ziel: Produktions-Workloads schrittweise migrieren, CA und Karpenter parallel.

Aufgaben:

1. Täglich 10–15 % der Produktions-Last migrieren
2. Pod-Verteilung per nodeSelector (Teil CA-Nodes, Teil Karpenter-Nodes)
3. Skalierungsfrequenz, Kosten, Stabilität beider Systeme überwachen
4. Bei Problemen Rollback (Pods zurück auf CA-Nodes)

Wichtig:

• Gegenseitige Störung möglich: CA-Nodes könnte Karpenters Consolidation fälschlich löschen. nodeSelector-Trennung ist entscheidend.
• Alarm: Pod Pending > 3 Minuten (AWS-Empfehlung [7])
• Steigen die Kosten? Spot-Anteil und Consolidation prüfen

Woche 4: Vollständiger Wechsel

Ziel: CA deaktivieren, Node Groups bereinigen, Karpenter übernimmt alles.

Aufgaben:

1. CA deaktivieren (Deployment replicas auf 0)
2. CA-Node Groups (ASG) bereinigen
3. nodeSelector von allen Pods entfernen – Karpenter scheduliert automatisch
4. Vollständigen Karpenter-Betrieb überwachen, NodePool feintunen

Wichtig:

• CA erst abschalten, wenn Karpenter alle Lasten übernommen hat
• ASG-Löschung vorsichtig: keine laufenden Nodes in der Gruppe
• Nach Vollwechsel einige Tage beobachten

Salesforces Migrationserfahrung

Dokumentiert im AWS Architecture Blog [3].

Ablauf:

1. Karpenter Transition Tool erkennt CA-Node-Groups, erzeugt äquivalente NodePools
2. CA und Karpenter parallel, schrittweise Lastmigration
3. Scale-out-Latenz und Kosten pro Cluster überwachen
4. Nach CA-Abschaltung Node Groups bereinigen

Das Transition Tool vereinfacht die Konfigurationsmigration – CA-Node-Groups werden automatisch in Karpenter-NodePools überführt.

"Wir haben die Migration von Cluster Autoscaler zu Karpenter in über 1.000 EKS-Clustern abgeschlossen und das Karpenter Transition Tool zur Vereinfachung der Konfigurationsumstellung genutzt."

Risiko-Checkliste

1. Parallelbetrieb: CA nicht sofort abschalten
2. nodeSelector: Pod-Verteilung per Labels trennen
3. limits: CPU/Memory-Limits am NodePool gegen Über-Provisioning
4. Monitoring: Pod Pending > 3 Minuten alarmieren [7]
5. Rollback: CA-Konfiguration behalten für schnellen Rückweg

6. Entscheidungsrahmen: Was wählen Sie 2026?

Kein absolutes Richtig oder Falsch – es hängt von Ihren Prioritäten ab.

Reintech liefert eine Entscheidungstabelle [1], ergänzt um AWS-Informationen.

Fünf-Dimensionen-Matrix

Typische Szenarien

Szenario 1: kleines Team, einfache Last

• Cluster: 10–20 Nodes
• Last: vorwiegend Web, stabiler Traffic
• Priorität: einfache Konfiguration, schneller Start

Empfehlung: CA.

CA in wenigen Stunden einsatzbereit; Wartungsaufwand bei kleinen Clustern gering. Karpenters Lernaufwand lohnt sich selten.

Szenario 2: mittleres bis großes Team, kostenbewusst

• Cluster: 50+ Nodes
• Last: gemischt (Web + Batch + Spot-Jobs)
• Priorität: Kostenkontrolle, Automatisierung

Empfehlung: Karpenter.

20–40 % Ersparnis fällt in großen Clustern deutlich ins Gewicht [2]. Consolidation und Spot-Automatisierung entlasten den Betrieb.

Szenario 3: Multi-Cloud

KiloClaw - Managed OpenClaw für Unternehmen: AI-Agent-Orchestrierung und smartes Modell-Routing

Jetzt starten →Anzeige

• Cluster: AWS + GCP + Azure
• Priorität: einheitliche Skalierungslösung

Empfehlung: CA.

CA ist multi-cloud ausgereift; GCP und Azure haben Node-Group-Mechanismen. Karpenter derzeit vor allem AWS (native AWS-Architektur).

Zukunftstrend: EKS Auto Mode

AWS hat 2026 EKS Auto Mode eingeführt – eine native Lösung auf Karpenter-Basis [4].

Kurz: AWS integriert Karpenter-Logik in EKS Auto Mode. Keine separate Karpenter-Installation – EKS skaliert Nodes automatisch.

Das zeigt AWS’ Richtung: Karpenters Architektur ist die anerkannte Zukunftslösung.

Neuer Cluster? EKS Auto Mode prüfen – spart Installations- und Konfigurationsschritte.

Multi-Cloud-Vergleich

CA: AWS, GCP, Azure.

• AWS: Auto Scaling Groups
• GCP: Managed Instance Groups
• Azure: Virtual Machine Scale Sets

Node Groups passen natürlich zu Multi-Cloud.

Karpenter: vorwiegend AWS, andere Clouds langsam.

Offiziell nur AWS. Community-PRs für Azure (teilweise), GCP noch früh.

Bei Multi-Cloud-Bedarf ist CA derzeit die einzige ausgereifte Wahl. Langfristig wird sich Karpenter weiter öffnen.

Unsere Empfehlung

Cluster auf AWS und diese Bedingungen erfüllt:

1. Cluster > 30 Nodes
2. vielfältige Workload-Typen
3. Kosten sind zentral
4. Platform-Engineering-Team vorhanden

Direkt Karpenter – oder EKS Auto Mode.

Kleiner Cluster (< 20 Nodes) oder Multi-Cloud? CA bleibt die solide Wahl.

2026 ist Karpenter in AWS EKS die empfohlene Lösung. CA behält Wert in Nischen (Multi-Cloud, kleine Cluster).

Fazit

Kern in drei Sätzen:

Karpenter gewinnt bei Geschwindigkeit, Kosten und Flexibilität. CA bleibt wertvoll bei Einfachheit und Multi-Cloud.

2026 ist Karpenter in AWS EKS die Empfehlung. Migration braucht 2–4 Wochen Planung und Tests – kein überstürzter Wechsel.

AWS-nativer Cluster, vielfältige Last, kostenbewusst – starten Sie mit einem Test-NodePool. Offizielle Migrationsanleitung [9], zwei Wochen Parallelbetrieb, dann schrittweise umstellen.

Multi-Cloud oder kleiner, stabiler Cluster – CA reicht, erzwungene Migration unnötig.

Nächste Schritte:

• Karpenter-Migrationsdokumentation lesen [9]
• Test-NodePool anlegen, Batch-Job ausprobieren
• Pod-Pending-Zeit und Kosten überwachen, mit CA vergleichen

Weitere EKS-Praxisartikel folgen – abonnieren Sie den Blog für Updates.

Referenzen

[1] Reintech - Karpenter vs Cluster Autoscaler: Which Should You Use in 2026
https://reintech.io/blog/karpenter-vs-cluster-autoscaler-comparison-2026

[2] Reintech - Nutzerberichte zu Kostenersparnis (20–40 %)

[3] AWS Architecture Blog - How Salesforce migrated from Cluster Autoscaler to Karpenter
https://aws.amazon.com/blogs/architecture/how-salesforce-migrated-from-cluster-autoscaler-to-karpenter-across-their-fleet-of-1000-eks-clusters/

[4] AWS EKS Official Docs - Scale cluster compute with Karpenter and Cluster Autoscaler
https://docs.aws.amazon.com/eks/latest/userguide/autoscaling.html

[5] CHKK - Karpenter vs. Cluster Autoscaler
https://www.chkk.io/blog/karpenter-vs-cluster-autoscaler

[6] Reddit r/kubernetes - Nutzer-Tests (Node-Ready-Latenz)
https://www.reddit.com/r/kubernetes/comments/zsmqrk/karpenter_vs_cluster_autoscaler_findings/

[7] AWS Blog - Using Amazon EC2 Spot Instances with Karpenter
https://aws.amazon.com/blogs/containers/using-amazon-ec2-spot-instances-with-karpenter/

[8] ScaleOps - Karpenter vs Cluster Autoscaler: Definitive Guide for 2025
https://scaleops.com/blog/karpenter-vs-cluster-autoscaler/

[9] Karpenter Official Docs - Migrating from Cluster Autoscaler
https://karpenter.sh/docs/getting-started/migrating-from-cas/