Karpenter sur AWS : l'autoscaling des nœuds EKS, de A à Z

Karpenter face à Kubernetes Cluster Autoscaler sur AWS

Karpenter et Cluster Autoscaler ajoutent tous deux de la capacité de calcul lorsque des pods ne peuvent pas être planifiés, mais ils reposent sur des modèles de scaling différents.

Cluster Autoscaler travaille avec des groupes de nœuds existants, comme les groupes de nœuds managés Amazon EKS ou les groupes Auto Scaling. Il augmente ou réduit la taille de ces groupes en fonction des pods en attente et des nœuds inutilisés. Il convient bien lorsque les workloads tiennent dans un petit nombre de types de nœuds connus. Il est prévisible et largement adopté, mais exige souvent une planification minutieuse. Les équipes doivent définir les groupes de nœuds, fixer les tailles minimale et maximale et décider quels types d'instances chaque groupe doit utiliser.

Karpenter ne requiert aucun groupe de nœuds prédéfini. Il provisionne des instances EC2 en fonction des exigences des pods en attente, ce qui lui permet de choisir parmi un éventail plus large de types d'instances et d'options de capacité au moment du provisionnement. Karpenter est adapté aux environnements où les besoins des workloads évoluent souvent. Il peut sélectionner les nœuds selon le CPU, la mémoire, l'architecture, la zone de disponibilité et le type de capacité.

Le principal compromis se joue entre contrôle et flexibilité :

• Cluster Autoscaler repose sur un modèle de groupes de nœuds fixes.
• Karpenter offre un provisionnement plus dynamique, mais demande de gérer des ressources propres à Karpenter comme NodePool et EC2NodeClass.

Contenu associé : pour une comparaison détaillée, consultez notre guide Karpenter vs. Cluster Autoscaler.

Tutoriel : premiers pas avec Karpenter sur AWS

Ce tutoriel montre comment créer un cluster Amazon EKS, installer Karpenter, définir un NodePool par défaut et tester le provisionnement automatique de nœuds. Le déroulé utilise eksctl, kubectl, helm et l'AWS CLI.

Étape 1 : avant de commencer, installez les outils requis :

aws --version
kubectl version --client
eksctl version
helm version

Karpenter a besoin de permissions AWS pour pouvoir lancer et arrêter des instances EC2. Dans cette configuration, ces permissions sont attachées au service account Karpenter via Pod Identity.

Étape 2 : commencez par définir les principales variables d'environnement :

export KARPENTER_NAMESPACE="kube-system"
export KARPENTER_VERSION="1.14.0"
export K8S_VERSION="1.36"
export AWS_PARTITION="aws"
export CLUSTER_NAME="${USER}-karpenter-demo"
export AWS_DEFAULT_REGION="us-west-2"
export AWS_ACCOUNT_ID="$(aws sts get-caller-identity --query Account --output text)"
export TEMPOUT="$(mktemp)"

Ces variables sont réutilisées par les commandes suivantes. CLUSTER_NAME identifie le cluster EKS, tandis que AWS_ACCOUNT_ID sert à la création des rôles et politiques IAM.

Étape 3 : récupérez ensuite les ID d'AMI Amazon Linux 2 recommandés pour la version de Kubernetes :

export ARM_AMI_ID="$(aws ssm get-parameter \
  --name /aws/service/eks/optimized-ami/${K8S_VERSION}/amazon-linux-2-arm64/recommended/image_id \
  --query Parameter.Value --output text)"

export AMD_AMI_ID="$(aws ssm get-parameter \
  --name /aws/service/eks/optimized-ami/${K8S_VERSION}/amazon-linux-2/recommended/image_id \
  --query Parameter.Value --output text)"

Karpenter utilise ces AMI lorsqu'il crée des nœuds EC2. Les conserver dans des variables facilite la réutilisation de la définition EC2NodeClass plus loin.

Étape 4 : créez l'infrastructure AWS de support et le cluster EKS :

curl -fsSL https://raw.githubusercontent.com/aws/karpenter-provider-aws/v"${KARPENTER_VERSION}"/website/content/en/preview/getting-started/getting-started-with-karpenter/cloudformation.yaml > "${TEMPOUT}"

aws cloudformation deploy \
  --stack-name "Karpenter-${CLUSTER_NAME}" \
  --template-file "${TEMPOUT}" \
  --capabilities CAPABILITY_NAMED_IAM \
  --parameter-overrides "ClusterName=${CLUSTER_NAME}"

Cette stack CloudFormation crée les ressources AWS dont Karpenter a besoin, y compris les permissions IAM pour provisionner des nœuds.

Étape 5 : créez maintenant le cluster EKS :

eksctl create cluster -f - <<EOF
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: ${CLUSTER_NAME}
  region: ${AWS_DEFAULT_REGION}
  version: "${K8S_VERSION}"
  tags:
    karpenter.sh/discovery: ${CLUSTER_NAME}

iam:
  withOIDC: true
  podIdentityAssociations:
  - namespace: "${KARPENTER_NAMESPACE}"
    serviceAccountName: karpenter
    roleName: ${CLUSTER_NAME}-karpenter
    permissionPolicyARNs:
    - arn:${AWS_PARTITION}:iam::${AWS_ACCOUNT_ID}:policy/KarpenterControllerPolicy-${CLUSTER_NAME}

iamIdentityMappings:
- arn: "arn:${AWS_PARTITION}:iam::${AWS_ACCOUNT_ID}:role/KarpenterNodeRole-${CLUSTER_NAME}"
  username: system:node:{{EC2PrivateDNSName}}
  groups:
  - system:bootstrappers
  - system:nodes

managedNodeGroups:
- instanceType: m5.large
  amiFamily: AmazonLinux2023
  name: ${CLUSTER_NAME}-ng
  desiredCapacity: 2
  minSize: 1
  maxSize: 10

addons:
- name: eks-pod-identity-agent
EOF

Cette commande crée un petit groupe de nœuds managés pour exécuter les composants système et Karpenter lui-même. Le cluster est taggé avec karpenter.sh/discovery, que Karpenter utilise ensuite pour découvrir les sous-réseaux et groupes de sécurité.

Étape 6 : installez Karpenter avec Helm :

helm registry logout public.ecr.aws

helm upgrade --install karpenter oci://public.ecr.aws/karpenter/karpenter \
  --version "${KARPENTER_VERSION}" \
  --namespace "${KARPENTER_NAMESPACE}" \
  --create-namespace \
  --set "settings.clusterName=${CLUSTER_NAME}" \
  --set "settings.interruptionQueue=${CLUSTER_NAME}" \
  --set controller.resources.requests.cpu=1 \
  --set controller.resources.requests.memory=1Gi \
  --set controller.resources.limits.cpu=1 \
  --set controller.resources.limits.memory=1Gi \
  --wait

Cette commande déploie le contrôleur Karpenter dans le cluster. Le contrôleur surveille les pods que Kubernetes ne peut pas planifier, puis appelle les API AWS pour créer des instances EC2 adaptées.

Étape 7 : créez ensuite un NodePool et une EC2NodeClass par défaut :

cat <<EOF | envsubst | kubectl apply -f -
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      requirements:
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64"]
        - key: kubernetes.io/os
          operator: In
          values: ["linux"]
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["on-demand"]
        - key: karpenter.k8s.aws/instance-category
          operator: In
          values: ["c", "m", "r"]
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
      expireAfter: 720h
  limits:
    cpu: 1000
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 1m
---
apiVersion: karpenter.k8s.aws/v1
kind: EC2NodeClass
metadata:
  name: default
spec:
  amiFamily: AL2023
  role: "KarpenterNodeRole-${CLUSTER_NAME}"
  subnetSelectorTerms:
    - tags:
        karpenter.sh/discovery: "${CLUSTER_NAME}"
  securityGroupSelectorTerms:
    - tags:
        karpenter.sh/discovery: "${CLUSTER_NAME}"
  amiSelectorTerms:
    - id: "${AMD_AMI_ID}"
EOF

Le NodePool définit les nœuds que Karpenter est autorisé à créer. Dans cet exemple, il autorise des instances On-Demand Linux amd64 issues des familles de calcul, généralistes et optimisées mémoire.

L'EC2NodeClass contient les paramètres propres à AWS. Elle indique à Karpenter quels rôle IAM, sous-réseaux, groupes de sécurité et AMI utiliser lors du lancement des nœuds.

Étape 8 : pour tester le scaling, créez un déploiement avec zéro replica :

cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: inflate
spec:
  replicas: 0
  selector:
    matchLabels:
      app: inflate
  template:
    metadata:
      labels:
        app: inflate
    spec:
      terminationGracePeriodSeconds: 0
      containers:
      - name: inflate
        image: public.ecr.aws/eks-distro/kubernetes/pause:3.7
        resources:
          requests:
            cpu: 1
EOF

Ce déploiement utilise l'image pause, très légère. Chaque replica demande un CPU, ce qui en fait un bon test de provisionnement de nœuds.

Étape 9 : augmentez le nombre de replicas pour créer des pods non planifiables :

kubectl scale deployment inflate --replicas 5

Karpenter devrait détecter les pods en attente et créer de nouveaux nœuds EC2. Vous pouvez suivre les logs du contrôleur avec :

kubectl logs -f -n "${KARPENTER_NAMESPACE}" \
  -l app.kubernetes.io/name=karpenter \
  -c controller

Après le test, supprimez le déploiement :

kubectl delete deployment inflate

Comme le NodePool utilise WhenEmptyOrUnderutilized, Karpenter peut supprimer les nœuds vides ou sous-utilisés après consolidation. Cela aide à réduire les coûts lorsque les workloads n'ont plus besoin de capacité supplémentaire.

Étape 10 : pour nettoyer l'environnement de démonstration, désinstallez Karpenter et supprimez le cluster :

helm uninstall karpenter --namespace "${KARPENTER_NAMESPACE}"

aws cloudformation delete-stack \
  --stack-name "Karpenter-${CLUSTER_NAME}"

eksctl delete cluster --name "${CLUSTER_NAME}"

Cette étape supprime les principales ressources créées durant le tutoriel et évite des frais AWS supplémentaires.

Bonnes pratiques pour Karpenter sur AWS

Voici quelques pratiques utiles à considérer lorsque vous utilisez Karpenter sur AWS.

1. Figer les AMI en production

Dans les environnements de production, évitez de vous fier aux AMI sélectionnées automatiquement. Figez plutôt des ID d'AMI spécifiques dans vos définitions EC2NodeClass. Les équipes gardent ainsi le contrôle de l'image système utilisée pour les nœuds workers et réduisent le risque de changements inattendus liés aux nouvelles versions d'AMI. Les AMI figées renforcent aussi la cohérence entre environnements et simplifient le diagnostic.

Actions recommandées :

• Les équipes peuvent valider les correctifs de sécurité, les runtimes de conteneurs et la compatibilité Kubernetes avant de déployer les mises à jour.
• Testez les nouvelles AMI dans des environnements hors production avant de mettre à jour les NodePools de production.
• Maintenez un processus documenté de mise à jour des AMI incluant revues de sécurité, procédures de rollback et suivi des versions.

2. Utiliser les contrôles de disruption

Karpenter inclut des fonctionnalités de disruption et de consolidation qui aident à réduire les coûts en remplaçant ou supprimant les nœuds sous-utilisés. Si ces capacités améliorent l'efficacité, une consolidation agressive peut nuire à la disponibilité des workloads si les nœuds sont arrêtés trop vite. Les contrôles de disruption permettent de concilier optimisation des coûts et stabilité applicative en maîtrisant comment et quand les remplacements de nœuds ont lieu.

Actions recommandées :

• Combinez les politiques de consolidation avec des pod disruption budgets, des contraintes de répartition topologique et des priorités de workloads.
• Pour les services critiques, envisagez d'allonger les délais de consolidation ou de limiter les remplacements de nœuds pendant les heures ouvrées.
• Dans les clusters de production, configurez soigneusement les paramètres de disruption et de consolidation pour éviter des interruptions de workloads inutiles.

3. Séparer les types de workloads avec des NodePools

Des workloads différents ont souvent des exigences d'infrastructure différentes. Par exemple, les workloads batch stateless peuvent s'exécuter sur des NodePools basés sur Spot, tandis que les applications exposées aux clients peuvent utiliser de la capacité On-Demand. Les workloads GPU, les workloads sur ARM et les applications à forte mémoire peuvent aussi bénéficier de NodePools dédiés avec des contraintes d'instances spécifiques.

Actions recommandées :

• Répartissez les workloads dans des NodePools dédiés selon la sensibilité aux coûts, les exigences de performance, l'architecture ou la tolérance aux interruptions.
• Utilisez taints, tolerations, node selectors et règles d'affinité pour garantir que les workloads sont planifiés sur les NodePools appropriés.
• Appliquez à chaque NodePool des politiques de disruption, de consolidation et de type de capacité adaptées aux caractéristiques des workloads.

4. Surveiller le comportement de Karpenter

Surveillez Karpenter comme n'importe quel autre composant du cluster. La visibilité sur les décisions de provisionnement, les événements du cycle de vie des nœuds et les résultats de scheduling aide les équipes à repérer les inefficacités, diagnostiquer les problèmes et vérifier que le comportement de scaling répond aux besoins des workloads. Une surveillance régulière permet aussi de détecter les contraintes de capacité AWS, les problèmes de configuration ou un churn de nœuds inattendu avant qu'ils n'affectent les applications.

Actions recommandées :

• Suivez les événements de provisionnement de nœuds, les lancements en échec, l'activité de consolidation, les pods en attente et les interruptions d'instances EC2.
• Utilisez Amazon CloudWatch, Prometheus et les événements Kubernetes pour observer le comportement de Karpenter. Les métriques importantes incluent la latence de provisionnement, le temps de démarrage des nœuds, les délais de scheduling des pods et le churn de nœuds.
• Examinez les logs du contrôleur pour diagnostiquer les problèmes liés aux permissions IAM, à la découverte de sous-réseaux ou aux types d'instances indisponibles.

5. Tester avant d'activer des politiques agressives

Des fonctionnalités comme la consolidation agressive, l'expiration rapide des nœuds ou un usage étendu de Spot peuvent réduire les coûts, mais introduire de l'instabilité si elles ne sont pas testées. Les workloads peuvent réagir différemment aux remplacements fréquents de nœuds, en particulier ceux avec de longs temps de démarrage, des composants stateful ou des exigences strictes de disponibilité. Les tests aident les équipes à mesurer l'impact opérationnel avant d'appliquer ces réglages en production.

Actions recommandées :

• Avant d'activer ces réglages en production, validez-les dans des environnements intermédiaires avec des workloads et des profils de scaling réalistes.
• Portez une attention particulière aux workloads avec connexions longue durée, temps de démarrage importants ou exigences strictes de disponibilité.
• Testez le comportement des applications lors des remplacements de nœuds, des interruptions Spot et des opérations de scale-down rapide.

Comment PerfectScale maximise votre autoscaling Karpenter sur AWS

Les autoscalers de nœuds comme Karpenter et Cluster Autoscaler sont des outils puissants pour ajuster le nombre de nœuds à la demande, améliorer la disponibilité du cluster et réduire les coûts d'inactivité. Mais même avec un autoscaling bien configuré, les équipes se heurtent souvent à trois problèmes qui en sapent les bénéfices : des conteneurs surprovisionnés qui gaspillent de la capacité et forcent l'autoscaler à lancer plus de nœuds que nécessaire, des conteneurs sous-provisionnés qui entraînent des évictions de pods et une pression sur les nœuds, et un bin-packing inefficace qui laisse des ressources sous-utilisées tout en déclenchant des événements de scaling superflus. PerfectScale résout ce problème en appliquant de façon autonome le right-sizing de vos workloads et en vous offrant une visibilité fine sur l'efficacité au niveau des nœuds, afin que Karpenter provisionne exactement le compute dont votre cluster a réellement besoin.

Capacités clés de PerfectScale :

• Correction proactive des erreurs de configuration : analyse en continu vos workloads pour identifier et corriger les erreurs de configuration — telles que CPU Request Not Set, Memory Request Not Set et Memory Limit Not Set — afin d'éviter les évictions imprévisibles, le surengagement des nœuds et un autoscaling inefficace.
• Right-sizing autonome des workloads : ajuste instantanément les ressources des workloads selon l'utilisation réelle et améliore le bin-packing des pods pour renforcer l'efficacité de l'autoscaling, sans aucune intervention manuelle.
• Efficacité d'autoscaling maximisée : offre une visibilité exceptionnelle sur les coûts et l'utilisation de vos groupes d'autoscaling et node pools, met en évidence les inefficacités et vous aide à choisir les types de nœuds optimaux pour améliorer l'utilisation, répartir précisément les ressources et maximiser l'efficacité des coûts.

Prêt à tirer le meilleur parti de Karpenter sur AWS ? Découvrez comment PerfectScale optimise de façon autonome vos workloads et l'autoscaling de vos nœuds sur la page de la solution d'autoscaling de nœuds PerfectScale.