Karpenter vs Cluster Autoscaler : comparaison des stratégies de mise à l'échelle des nœuds sur AWS EKS

Introduction

Trois heures du matin. Vous fixez l’alerte rouge sur Grafana : vos Pods sont en Pending depuis quatre minutes. Le pic de trafic est là, mais les nœuds sont encore « en cours de démarrage ».

L’administrateur du cluster voisin dort depuis longtemps. Son système de mise à l’échelle a mis les nœuds en ligne en 55 secondes.

Ce n’est pas une exagération. C’est l’écart réel entre Karpenter et Cluster Autoscaler.

Franchement, la première fois que j’ai vu ces chiffres, j’étais sceptique. Une minute contre trois — est-ce vraiment si important ? Jusqu’à ce que je fasse tourner les deux systèmes sur EKS : l’écart est assez grand pour repenser toute votre stratégie de mise à l’échelle.

Selon le rapport Reintech 2026, Karpenter met à l’échelle en moins de 60 secondes, contre 3 à 5 minutes pour Cluster Autoscaler (CA) [1]. Côté coûts, des utilisateurs réels rapportent 20 à 40 % d’économies [2]. Salesforce a même migré à l’échelle de milliers de clusters [3].

Cet article clarifie : où ces outils diffèrent-ils ? Lequel choisir ? Comment migrer ? Je m’appuie sur des données réelles, des exemples de configuration complets et un calendrier de migration.

1. Comparaison d’architecture : pourquoi un tel écart de vitesse ?

Différence clé : CA repose sur les groupes de nœuds ; Karpenter configure les nœuds directement.

Cela paraît simple, mais l’écart architectural impacte tout le flux de mise à l’échelle.

Le détour de Cluster Autoscaler

CA fonctionne comme un long détour.

Quand la planification d’un Pod échoue, CA vérifie d’abord les groupes de nœuds prédéfinis (Node Group). Chaque groupe est lié à des types d’instances fixes — par exemple node-group-1 en m5.large, node-group-2 en c5.xlarge.

CA doit choisir le bon groupe, puis appeler l’API cloud (AWS Auto Scaling Groups) pour demander une mise à l’échelle. Ensuite : démarrage de l’instance, adhésion au cluster, nœud Ready, enfin planification du Pod.

Quatre à cinq étapes. Chacune ajoute de la latence.

Surtout l’étape « vérifier le groupe → choisir le groupe ». Si votre Pod a besoin d’un GPU mais qu’aucun groupe n’en propose, CA ne peut rien faire — il ne choisit que parmi les groupes existants.

L’approche directe de Karpenter

Karpenter est tout autre.

Pod non planifiable ? Karpenter lit les besoins : CPU, mémoire, GPU, tolerations ou nodeSelector particuliers ?

Après analyse, il appelle directement l’API EC2 et provisionne l’instance la plus adaptée. Pas de groupe de nœuds, pas d’ASG — correspondance directe aux besoins du Pod.

Puis démarrage, adhésion au cluster, planification. Deux étapes clés, sans les détours intermédiaires.

La documentation AWS est claire : Karpenter peut démarrer des ressources de calcul en moins d’une minute [4].

Une analogie

CA, c’est la commande au restaurant : le client veut du poulet épicé, le serveur vérifie la carte (groupes de nœuds), passe commande (ASG), la cuisine prépare (instance), le plat arrive (Pod).

Karpenter, c’est la cuisine ouverte : le client dit ce qu’il veut (specs du Pod), le chef prend les ingrédients (API EC2), prépare et sert.

Le plus rapide ? Évident.

Pourquoi CA dépend des groupes de nœuds ?

CA a été conçu pour le multi-cloud. Le mécanisme de groupes de nœuds permet la même logique sur AWS, GCP et Azure — seul le nom change (ASG, MIG, VMSS).

Mais cette conception limite aussi : vous devez prédéfinir les groupes. Nouveau type d’instance ? Créez un groupe. Spot ? Créez un groupe Spot. Coût de maintenance en hausse, flexibilité en baisse.

Karpenter est natif AWS. Pas de couche intermédiaire de groupes de nœuds — interaction directe avec l’API EC2. Inconvénient : faible support multi-cloud (surtout AWS). Avantages : vitesse et configuration plus simples.

2. Benchmarks de performance : comportement en conditions réelles

Karpenter met à l’échelle vite ; la réduction d’échelle n’est pas en reste.

Les données de ce chapitre viennent surtout des tests CHKK et de retours utilisateurs.

Vitesse de mise à l’échelle : comparaison mesurée

Les tests CHKK sont parlants [5] :

• Karpenter : Pod CPU-intensif en ligne en environ 55 secondes
• Cluster Autoscaler : même charge, 3 à 4 minutes

Cet écart correspond à la promesse AWS « moins d’une minute » [4].

Sur Reddit, un utilisateur a testé et trouvé l’écart moins marqué — latence de disponibilité des nœuds similaire, probablement à cause d’un petit cluster (~10 nœuds) [6]. Donnée isolée, échantillon limité : à prendre comme indication, pas comme conclusion.

🔥 Ne perdez plus des mois sur des produits sans demande ! Validez vos promesses SaaS avec Adsterra à petit budget →

Tester l'MVP →Pub

Efficacité de réduction : qui économise le plus ?

Une mise à l’échelle rapide n’est qu’une façade ; l’efficacité de réduction fait vraiment économiser.

CA scanne périodiquement le cluster (par défaut toutes les 10 secondes) pour repérer les nœuds longtemps inactifs. Au-delà du seuil (par défaut 10 minutes), réduction déclenchée.

Karpenter utilise Consolidation — surveillance en temps réel de l’utilisation : fusionner quand c’est possible, remplacer quand c’est pertinent.

Exemple : 3 nœuds m5.xlarge à 30 %, 25 % et 20 % d’utilisation. Karpenter se demande : ces Pods tiennent-ils sur 1 m5.large ? Si oui, suppression des 3 grands nœuds, remplacement par 1 petit.

Le blog AWS quantifie le gain : Spot + Consolidation, jusqu’à 90 % d’économie vs On-demand [7].

Écart sur les grands clusters

CA montre des goulots sur les grands clusters (100+ nœuds).

Le blog ScaleOps note que plus il y a de groupes de nœuds, plus la décision de CA ralentit [8] — il parcourt tous les groupes pour trouver le bon. Plus de groupes, plus de temps, plus de latence.

Karpenter n’a pas cette limite. Pas de groupes de nœuds : analyse directe des besoins du Pod et choix du type d’instance optimal. Même logique, quel que soit la taille du cluster.

Cas pratique : traitement par lots

Un scénario que j’ai vu en production.

Un pipeline de données déclenche un batch horaire nécessitant 50 worker Pods. Sous CA, les Pods restent Pending 3 minutes ; le batch démarre en retard, le cycle global du pipeline s’allonge.

Après migration vers Karpenter, tous les Pods sont Running en 50 secondes. Le batch démarre à l’heure, le cycle aval reprend la normale.

Point clé : les charges batch sont sensibles au délai de démarrage. Trois minutes d’attente peuvent retarder toute la chaîne ; une mise à l’échelle en moins d’une minute devient un besoin réel.

3. Économies de coûts : le secret des 20-40 %

L’avantage coût de Karpenter repose sur trois mécanismes : Spot, Consolidation et stratégie de choix d’instances.

Pris séparément, rien de nouveau. Combinés, l’effet atteint 20 à 40 % d’économies — données utilisateurs Reintech [2].

Instances Spot : jusqu’à 90 % d’économie

Les instances Spot AWS peuvent coûter jusqu’à 90 % moins cher que On-demand [7] — chiffre officiel AWS, haute confiance.

Mais Spot comporte un risque : interruption à tout moment. AWS prévient 2 minutes à l’avance, puis reprend l’instance [7].

Avec CA et Spot, vous créez manuellement un groupe Spot et configurez la gestion des interruptions. Processus lourd, erreurs fréquentes.

Karpenter gère les interruptions Spot automatiquement. À la notification, en 2 minutes : cordon (nœud non planifiable) et drain (migration des Pods). Pas de script supplémentaire — logique intégrée.

Stratégie PCO : choisir Spot intelligemment

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

En bref : d’abord le pool Spot à plus faible probabilité d’interruption, puis l’instance la moins chère dans ce pool.

L’intérêt : équilibrer économie et stabilité. Le pool le moins cher interrompt souvent ; le plus stable coûte plus. PCO cherche le milieu.

Le blog AWS détaille [7] :

1. Karpenter surveille le taux d’interruption des pools Spot (données AWS)
2. Filtre les pools à taux élevé
3. Choisit le type d’instance le moins cher parmi les restants

Activé par défaut, sans configuration.

Consolidation : économies en temps réel

La Consolidation a été évoquée au chapitre 2. Voici la configuration.

Karpenter propose deux stratégies [7] :

• WhenEmpty : suppression quand le nœud est totalement inactif
• WhenUnderutilized : fusion ou remplacement quand l’utilisation est faible

Par défaut : WhenUnderutilized, plus agressif.

Exemple :

# Karpenter NodePool - Configuration Consolidation
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: default
spec:
  disruption:
    consolidationPolicy: WhenUnderutilized  # Fusion agressive
    consolidateAfter: 1m                     # Déclenchement après 1 min d'inactivité

CA n’a pas cette fonction. Il ne supprime que les nœuds longtemps inactifs — pas de « fusion de petits nœuds en un grand » ni de « remplacement d’instances chères par des moins chères ».

Calcul du ROI : gains réels

Supposons un cluster à 50 000 $/mois (100 nœuds, types mixtes).

Après migration vers Karpenter, estimation prudente 20 % : 10 000 $/mois.

Estimation agressive (Spot + Consolidation poussés) 40 % : 20 000 $/mois.

Sur un an : 120 000 $ à 240 000 $ économisés.

Calcul basé sur les données utilisateurs Reintech [2]. Le gain réel dépend du type de charge, de la part Spot et de la config Consolidation.

Comparaison de configuration : le plus simple ?

Configuration Spot avec CA :

1. Créer un ASG Spot (choix manuel des types)
2. Configurer la stratégie d’allocation Spot de l’ASG
3. Écrire un script d’interruption (surveillance, drain manuel)
4. Configurer --node-group-auto-discovery de CA

Configuration Spot avec Karpenter :

# Un seul NodePool suffit
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      requirements:
      - key: karpenter.sh/capacity-type
        operator: In
        values: ["spot", "on-demand"]  # Choix automatique Spot ou On-demand
      - key: karpenter.k8s.aws/instance-category
        operator: In
        values: ["c", "m", "r"]  # Séries c/m/r, diversité suffisante
  disruption:
    consolidationPolicy: WhenUnderutilized

Un YAML couvre Spot, diversité des types, Consolidation. Karpenter gère les interruptions, choisit l’instance optimale, fusionne les nœuds.

L’écart de simplicité est net.

4. Complexité de configuration : analyse coût-bénéfice

CA se configure vite ; Karpenter demande plus d’apprentissage, mais le coût de maintenance s’inverse à long terme.

Données Reintech [1] : CA « quelques heures », Karpenter « 1 à 2 jours ».

La première fois, j’ai trouvé ça exagéré. Après un déploiement complet, Reintech avait raison.

CA : démarrage rapide, maintenance lourde

Flux de configuration CA :

# Déploiement CA (version simplifiée)
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

Quelques paramètres clés : découverte des groupes, seuils de réduction, délais. Déploiement + groupes de nœuds (ASG), CA tourne.

Quelques heures, ce n’est pas exagéré.

Vultr - Serveur cloud NVMe haute performance, 32 emplacements mondiaux, déploiement Docker en un clic

Voir les tarifs →Pub

Mais la maintenance arrive ensuite.

Nouveau type d’instance ? Nouveau groupe. Spot ? Groupe Spot. Plus de groupes, plus de gestion : min/max, types, étiquettes par ASG.

À long terme, des piles de YAML. Modifier un paramètre peut impacter plusieurs groupes.

Karpenter : démarrage lent, maintenance légère

La complexité de Karpenter est conceptuelle.

Il faut maîtriser NodePool, Disruption, Consolidation, requirements. La première fois, j’ai mis une journée à comprendre chaque paramètre.

# Karpenter NodePool (version complète)
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"]  # Génération 5 et au-delà
      nodeClassRef:
        name: default
  disruption:
    consolidationPolicy: WhenUnderutilized
    consolidateAfter: 1m
  limits:
    cpu: 1000
    memory: 1000Gi

Plus de paramètres que le Deployment CA. Mais une fois compris : un NodePool couvre plusieurs types, mix Spot/On-demand, Consolidation automatique.

Coût de maintenance quasi nul.

Nouveau type ? Ajoutez une série dans requirements. Ajuster Consolidation ? Changez consolidationPolicy.

Un YAML à maintenir, pas une pile de groupes.

Compromis entre les deux approches

Reintech est pragmatique [1] :

• CA convient à : équipe limitée, config simple, charges homogènes
• Karpenter convient à : équipe plateforme, charges variées, sensibilité aux coûts, volonté d’investir dans l’apprentissage

Petit cluster perso (10-20 nœuds) ? La simplicité de CA peut suffire.

Cluster moyen/grand en équipe (50+ nœuds), ou charges mixtes (batch + web + GPU) ? Karpenter coûte moins à maintenir sur la durée.

5. Feuille de route de migration : de CA vers Karpenter

Cycle 2 à 4 semaines ; risque principal = deux systèmes en parallèle.

Données Reintech [1]. Le cas Salesforce est plus parlant : migration sur 1 000+ clusters EKS [3].

Salesforce a utilisé le Karpenter transition tool (outil officiel) avec exécution parallèle. Détails ci-dessous.

Semaine 1 : préparation

Objectif : installer Karpenter, créer le NodePool, configurer les droits IAM.

Tâches :

1. Installer Karpenter (helm ou eksctl)
2. Créer un NodePool simple (mix Spot/On-demand)
3. Configurer IAM (permissions EC2 pour Karpenter)
4. Vérifier que Karpenter provisionne correctement

Points clés :

• Permissions IAM complètes : ec2:RunInstances, ec2:TerminateInstances, ec2:DescribeInstances, etc.
• limits du NodePool raisonnables pour éviter une sur-provision (ex. cpu: 100).
• Ne pas arrêter CA — Karpenter en secours.

Semaine 2 : tests

Objectif : migrer des charges non critiques vers Karpenter, comparer les métriques.

Tâches :

1. Choisir des charges de test (batch, services basse priorité)
2. Utiliser nodeSelector ou affinity pour cibler les nœuds Karpenter
3. Observer vitesse de mise à l’échelle, interruptions Spot, Consolidation
4. Comparer latence et coûts CA vs Karpenter

Points clés :

• Limiter à 10-20 % des ressources du cluster.
• Métriques : temps Pod Pending, démarrage des nœuds, interruptions Spot, utilisation.
• Si Karpenter underperforme, ajuster requirements ou consolidationPolicy.

Semaine 3 : exécution hybride

Objectif : migration progressive de la production ; CA et Karpenter en parallèle.

Tâches :

1. Migrer 10-15 % de la production par jour
2. nodeSelector pour répartir les Pods (partie CA, partie Karpenter)
3. Surveiller fréquence de mise à l’échelle, coûts, stabilité
4. Rollback si besoin (Pods vers nœuds CA)

Points clés :

• Risque d’interférence : Consolidation Karpenter peut supprimer des nœuds CA. Séparer avec nodeSelector est essentiel.
• Alerte : Pod Pending > 3 minutes (recommandation AWS [7]).
• Si les coûts montent, vérifier la part Spot et la config Consolidation.

Semaine 4 : bascule complète

Objectif : désactiver CA, nettoyer les groupes, Karpenter prend tout.

Tâches :

1. Désactiver CA (replicas à 0)
2. Nettoyer les groupes de nœuds (ASG)
3. Retirer les nodeSelector des Pods pour laisser Karpenter planifier
4. Surveiller Karpenter en charge totale, ajuster le NodePool

Points clés :

• Confirmer que Karpenter gère toutes les charges avant d’arrêter CA.
• Supprimer un ASG seulement s’il n’héberge plus de nœuds actifs.
• Observer plusieurs jours après la bascule.

Expérience de migration Salesforce

Le cas Salesforce est documenté sur AWS Architecture Blog [3].

Leur flux :

1. Karpenter transition tool : détection des groupes CA, génération de NodePools équivalents
2. CA et Karpenter en parallèle, migration progressive
3. Surveillance latence et coûts par cluster
4. Après désactivation de CA, nettoyage des groupes

Point clé : le transition tool simplifie la conversion de configuration — groupes CA → NodePools Karpenter, sans reconfiguration manuelle longue.

"Nous avons migré de Cluster Autoscaler vers Karpenter sur plus de 1 000 clusters EKS, en utilisant le Karpenter transition tool pour simplifier la conversion de configuration."

Liste de mitigation des risques

1. Exécution parallèle : ne pas désactiver CA d’un coup
2. nodeSelector : séparer les Pods par étiquettes
3. limits : plafonds CPU/Memory sur le NodePool
4. Alertes : Pod Pending > 3 minutes [7]
5. Plan de rollback : conserver la config CA

6. Cadre de décision : que choisir en 2026 ?

Pas de bonne réponse universelle — tout dépend de vos priorités.

Reintech propose une matrice [1], complétée avec les infos AWS officielles.

Matrice de décision en cinq dimensions

Recommandations par scénario

Scénario 1 : petite équipe, charge simple

• Taille : 10-20 nœuds
• Charge : surtout web, trafic stable
• Priorité : config simple, démarrage rapide

Recommandation : CA.

CA se configure en quelques heures ; sur un petit cluster, la maintenance pèse peu. Le coût d’apprentissage de Karpenter peut ne pas valoir le coup.

Scénario 2 : équipe moyenne/grande, sensible aux coûts

• Taille : 50+ nœuds
• Charge : mix web + batch + Spot
• Priorité : maîtrise des coûts, automatisation

Recommandation : Karpenter.

20-40 % d’économies sur un grand cluster [2]. Consolidation et Spot automatisés réduisent la charge ops.

Scénario 3 : multi-cloud

Railway - Plateforme de déploiement moderne, sans opérations complexes, en ligne en quelques minutes

Commencer →Pub

• Clusters : AWS + GCP + Azure
• Priorité : schéma de mise à l’échelle unifié

Recommandation : CA.

Support multi-cloud mature ; GCP et Azure ont leurs mécanismes de groupes. Karpenter reste surtout AWS (conception native).

Tendance : EKS Auto Mode

AWS a lancé en 2026 EKS Auto Mode — solution native basée sur Karpenter [4].

En bref : AWS intègre la logique Karpenter dans EKS Auto Mode ; pas d’installation séparée, mise à l’échelle automatique des nœuds.

Direction AWS claire : l’architecture Karpenter est le schéma retenu pour l’avenir.

Nouveau cluster ? Envisagez EKS Auto Mode pour éviter l’installation manuelle de Karpenter.

Comparaison multi-cloud

CA : AWS, GCP, Azure.

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

Le mécanisme de groupes s’adapte naturellement au multi-cloud.

Karpenter : surtout AWS ; avancement lent ailleurs.

Support officiel AWS uniquement. PR Azure partielles en communauté ; GCP en phase initiale.

Besoin multi-cloud aujourd’hui ? CA est le seul choix mature. À long terme, Karpenter devrait progresser.

Mon conseil

Si votre cluster est sur AWS et que :

1. Taille > 30 nœuds
2. Types de charge variés
3. Coût = critère clé
4. Équipe plateforme disponible

Passez à Karpenter, ou EKS Auto Mode.

Petit cluster (< 20 nœuds) ou multi-cloud ? CA reste un choix sûr.

En 2026 sur AWS EKS, Karpenter est la recommandation. CA garde de la valeur (multi-cloud, petits clusters).

Conclusion

En trois phrases :

Karpenter l’emporte sur vitesse, coût et flexibilité. CA garde de la valeur en simplicité et multi-cloud.

Sur AWS EKS en 2026, Karpenter est recommandé. La migration demande 2 à 4 semaines de planification et de tests — ne basculez pas dans la précipitation.

Cluster AWS natif, charges variées, sensibilité aux coûts ? Lancez un NodePool de test. Suivez le guide de migration officiel [9], parallélisez deux semaines, basculez progressivement.

Multi-cloud, ou petit cluster à charge stable ? CA suffit — pas besoin de forcer la migration.

Prochaines étapes :

• Lire la documentation de migration Karpenter [9]
• Créer un NodePool de test avec une tâche batch
• Surveiller Pod Pending et coûts, comparer à CA

Je publierai d’autres articles pratiques sur la gestion de clusters EKS — abonnez-vous pour ne rien manquer.

Références

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

[2] Reintech - Rapport utilisateurs sur les économies réelles (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 - Retours utilisateurs (latence de disponibilité des nœuds)
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/