Le Cluster Autoscaler résout le scaling de nœuds en restant prisonnier d’une contrainte structurelle : il ne peut ajouter que des nœuds appartenant à un groupe déjà défini à l’avance (un Auto Scaling Group AWS, un node pool GKE). Karpenter supprime cette contrainte en provisionnant directement l’instance qui correspond au pod en attente, sans détour par un groupe préconfiguré.

La contrainte des groupes de nœuds

Le Cluster Autoscaler choisit, parmi les groupes de nœuds existants, celui dont le type d’instance correspond le mieux aux pods en attente, puis demande une machine supplémentaire à ce groupe précis. Si aucun groupe ne correspond bien au besoin réel (un pod qui a besoin de beaucoup de mémoire et peu de CPU, alors que tous les groupes configurés sont équilibrés), le nœud provisionné est soit surdimensionné (gaspillage), soit tout simplement absent si personne n’a anticipé ce profil à l’avance.

# Cluster Autoscaler : le choix se limite aux groupes
# de nœuds déjà définis, peu importe le profil réel du pod
apiVersion: v1
kind: ConfigMap
data:
  nodes.max: "20"
  # Le type d'instance est fixé au niveau du node group,
  # pas décidé dynamiquement par pod

Karpenter : le pod décrit son besoin, Karpenter choisit l’instance

Karpenter n’a pas de notion de groupe de nœuds préconfiguré. Il observe directement les pods en attente et interroge l’API du fournisseur cloud pour choisir, parmi tous les types d’instances disponibles, celui qui correspond le mieux au besoin réel (CPU, mémoire, architecture, exigences de GPU), en tenant compte du prix.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64"]

Ce NodePool ne fixe aucun type d’instance précis : il pose des contraintes (architecture, type de capacité), et Karpenter résout dynamiquement l’instance optimale à chaque décision de provisionnement, pod par pod.

La consolidation, pas seulement le scale down

Le Cluster Autoscaler retire un nœud sous-utilisé, mais seulement si tous ses pods peuvent être replacés sans violer une contrainte. Karpenter va plus loin avec la consolidation active : il peut proactivement remplacer plusieurs nœuds sous-utilisés par un nombre inférieur de nœuds mieux dimensionnés, un rebin-packing continu que le Cluster Autoscaler ne fait pas nativement.

disruption:
  consolidationPolicy: WhenEmptyOrUnderutilized
  consolidateAfter: 30s

Ce que ça change en pratique

L’absence de groupes de nœuds préconfigurés élimine une classe entière de tâches opérationnelles : plus besoin d’anticiper et de maintenir une liste de types d’instances par profil de charge, Karpenter décide à la volée. La contrepartie est réelle : Karpenter, historiquement lié à AWS EKS, a un support multi-cloud plus récent et moins mature que celui, déjà bien établi, du Cluster Autoscaler sur GKE ou AKS ; vérifier la maturité du support pour le fournisseur cloud concerné reste la première étape avant migration.

À retenir

Le Cluster Autoscaler reste prisonnier des groupes de nœuds préconfigurés à l’avance, ce qui force un compromis entre couverture des profils de charge et complexité opérationnelle. Karpenter élimine cette contrainte en choisissant dynamiquement l’instance exacte que chaque pod en attente réclame, avec une consolidation active en prime. Le choix entre les deux dépend surtout de la maturité du support Karpenter sur le fournisseur cloud utilisé, un des arbitrages qui se posent dès la conception d’une migration Kubernetes.