Karpenter : l'autoscaler intelligent pour EKS

Découvrez Karpenter, l'autoscaler moderne conçu pour EKS : plus rapide, plus flexible et plus économique que le Cluster Autoscaler.

I. Karpenter, c’est quoi ?  

Karpenter est un autoscaler open-source pour Kubernetes, créé par AWS.
Son rôle : ajuster automatiquement la capacité des nœuds (EC2) d’un cluster EKS en fonction de la charge réelle.

En résumé :

• Quand ton cluster manque de ressources, Karpenter ajoute des nœuds.
• Quand les nœuds deviennent inutiles, il les supprime.

Mais surtout :

Il le fait plus vite, plus intelligemment et plus efficacement que l’autoscaler classique de Kubernetes (Cluster Autoscaler).

Dans cet article, on explore :

• pourquoi Karpenter existe,
• ce qu’il fait mieux que le Cluster Autoscaler,
• comment il fonctionne,
• les pièges à éviter en production,
• et pourquoi il est devenu un composant incontournable pour EKS.

II. Pourquoi Karpenter existe ?  

Le Cluster Autoscaler (CA) natif de Kubernetes :

• ne peut gérer que des Auto Scaling Groups (ASG)
• lance des instances dans une liste prédéfinie (figée)
• met plusieurs minutes à réagir
• ne “voit pas” toutes les options EC2 disponibles
• n’est pas performant pour les Spot

Karpenter corrige tous ces problèmes.

III. Ce que Karpenter fait mieux  

1. Il choisit dynamiquement le meilleur type d’instance  

Plus besoin de définir manuellement des dizaines d’instance types dans un ASG.

Karpenter peut décider seul :

• t3 ou c6i ?
• une grande instance ou plusieurs petites ?
• Spot ou On-Demand ?
• quelle AZ a encore de la capacité ?

Il sélectionne l’instance au moment du besoin, en fonction de :

• la disponibilité Spot
• le prix
• les ressources demandées par les pods (CPU, RAM, GPU…)
• les contraintes (architecture, taille de disque, labels, taints…)

2. Il lance des nœuds en 10 à 30 secondes  

Beaucoup plus rapide que :

• Cluster Autoscaler (qui agit via ASG)
• ASG lui-même (qui a ses délais internes)

Karpenter crée le nœud directement via l’API EC2. Il est donc ultra rapide.

3. Il gère les nœuds inutiles automatiquement  

Si un nœud devient vide (plus de pods utiles), Karpenter le :

• cordonne,
• drainne,
• puis supprime.

Résultat : le coûts est moindre et le cluster plus propre

4. Il gère les interruptions Spot proprement  

Quand AWS annonce une interruption Spot :

• Karpenter détecte l’événement
• déplace les pods vers un autre nœud
• recrée un nœud aussitôt

Très utile dans les périodes difficiles… comme décembre voir l’article Spot en Décembre

IV. Comment ça marche ?  

Karpenter utilise un Custom Resource :

Provisioner

C’est un objet qui décrit :

• les types d’instances autorisées
• les zones utilisables
• les quotas max
• les préférences Spot / On-Demand
• les tailles minimales / maximales des nœuds

Ensuite, il observe les pods en Pending et crée le nœud parfait pour les accueillir.

V. Exemple ultra simple de Provisioner  

apiVersion: karpenter.sh/v1alpha5
kind: Provisioner
metadata:
  name: default
spec:
  requirements:
    - key: karpenter.sh/capacity-type
      operator: In
      values: ["spot", "on-demand"]
  limits:
    resources:
      cpu: 500
  provider:
    subnetSelector:
      kubernetes.io/cluster/my-cluster: owned
    securityGroupSelector:
      kubernetes.io/cluster/my-cluster: owned

Karpenter vs Cluster Autoscaler  

VI. Les problèmes courants avec Karpenter  

1. Risques de sur-provisionnement (scaling trop agressif)  

Karpenter est beaucoup plus rapide que Cluster Autoscaler.
Parfois trop rapide.

Symptômes :

• création de plus de nœuds que nécessaire
• nœuds inutiles peu après leur création
• la facture AWS augmente durant quelques minutes
• puis Karpenter supprime les nœuds… mais vous avez payé

Cause :
Karpenter réagit instantanément aux pods en Pending, même si ces pods n’auraient pas dû être programmés.

Comment éviter :

• activer la stratégie consolidation
• configurer intelligemment les maxPods et les demandes CPU/RAM de vos workloads
• mettre une limite stricte dans le Provisioner :

  limits:
    resources:
      cpu: 200
  

2. Un deprovisioning parfois “trop” efficace  

Karpenter supprime les nœuds qui semblent inutilisés.

Problèmes possibles :

• certains DaemonSets ou pods système peuvent rendre un nœud “vide” mais non supprimable
• des workloads temporaires peuvent créer des oscillations
• scale-in peut-être trop agressif, il y a une recréation immédiate qui peut engendrer un effet ping-pong

Solutions :

• augmenter ttlSecondsAfterEmpty
• utiliser des taints pour protéger certains nœuds
• activer la consolidation progressive

3. Intégration obligatoire avec VPC, IAM et tags AWS  

Karpenter ne fonctionne pas sans :

• un IAM Role adapté
• des Subnets taggés
• des Security Groups taggés
• des permissions EC2 avancées

Tags indispensables :  

kubernetes.io/cluster/<cluster-name>: owned
karpenter.sh/discovery: <cluster-name>

Sans ces tags, aucun nœud ne pourra être créé.

4. Entraîne des comportements inattendus avec certains DaemonSets lourds  

Exemples :

• Prometheus Node Exporter
• Falco
• Cilium
• Agents de logs lourds (Datadog, New Relic…)
• CSI EBS/EFS (selon les versions)

Pourquoi ?  

Karpenter choisit la taille du nœud en fonction de la consommation réelle des pods.

Si vos DaemonSets consomment beaucoup :

• nœud trop petit, il peut y avoir des crashloop
• nœud trop grand, le coût peut être inutilement élevé

Solutions :  

• définir des resources.requests réalistes sur tous les DaemonSets
• exclure certains DaemonSets via des taints
• utiliser des Provisioners dédiés, par exemple : system-nodes

5. Spot + Karpenter = excellent… mais sensible aux pénuries  

En période saturée (ex : décembre) :

Karpenter va :

• tester plusieurs familles d’instances
• rescheduler
• essayer d’autres AZ
• recommencer en boucle

Ce qui peut provoquer :  

• instabilité
• “flapping” de nœuds Spot
• latence accrue pour certains workloads

Conseil important :  

Ne jamais utiliser 100% Spot.
Toujours garder une baseline On-Demand, par exemple :

on-demand: 20–40%

6. Peut casser une stratégie ASG existante  

Beaucoup d’infrastructures utilisent :

• un ASG On-Demand + un ASG Spot
• des autoscaling policies
• des lifecycle hooks
• des warm pools

Karpenter ignore complètement les ASG.
Il crée les instances directement via l’API EC2, sans passer par un ASG.

Si votre architecture repose sur :

• le scaling basé EC2
• les hooks
• les warm pools

Vous perdez ces mécanismes en migrant vers Karpenter.

7. Coûts inattendus à cause d’instances trop grandes  

Karpenter optimise pour :

• le scheduling des pods
• la disponibilité
• la rapidité

…mais pas forcément pour minimiser le coût de votre cluster.

Cas classique :  

“J’ai demandé 2 CPU et 4 Go…
Pourquoi Karpenter m’a créé une m6i.2xlarge ?”

Raisons possibles :  

• petites tailles indisponibles (surtout côté Spot)
• grande instance temporairement meilleur marché
• DaemonSets imposant une taille minimale

Solution : restreindre les instance types dans les requirements.

8. Attention aux Provisioners trop permissifs  

Exemple dangereux :

requirements:
  - key: karpenter.sh/capacity-type
    operator: In
    values: ["spot"]

Si les Spot disparaissent :

• plus aucun nœud ne peut être créé
• cluster down

Toujours :

• inclure On-Demand
• limiter les familles d’instances
• définir des fallback AZ

9. Peut provoquer des interruptions de pods plus fréquentes  

Exemple :

• Karpenter consolide
• supprime un nœud “vide”
• un DaemonSet se lance juste après
• le nœud était en réalité utile

Résultat :

• les pods sont reprogrammés sans raison valable, provoquant des micro-interruptions et une instabilité perceptible dans les workloads.
• un rescheduling non nécessaire qui entraîne de la turbulence et une dégradation temporaire des performances.

Solution :
augmenter les TTL ou désactiver la consolidation à certains horaires.

Les 9 points de vigilance avec Karpenter  

Conclusion  

Karpenter est incroyable, surtout pour :

• optimiser les coûts
• accélérer le scaling
• utiliser les Spot efficacement
• simplifier la gestion des nodes

Mais il donne beaucoup de pouvoir, et donc : il faut le configurer avec prudence.

Bien maîtrisé, c’est aujourd’hui l’un des meilleurs outils pour EKS.

🔗 Liens utiles  

• Documentation officielle Karpenter
• Guide de démarrage (installation)
• Concepts clés : Provisioners, consolidation, interruptions Spot
• Karpenter vs Cluster Autoscaler (FAQ)
• Bonnes pratiques Spot sur EKS (AWS)