Karpenter sur EKS : nodes autoscaling
À la fin de ce tutoriel, vous saurez installer Karpenter sur un cluster Amazon EKS, déclarer un EC2NodeClass et un NodePool, lancer une charge qui scale les nœuds, observer les NodeClaims, puis activer la consolidation (dont Spot) — le tout en région
ca-central-1, angle DevOps Elastic Hayway (DEH).Niveau : Intermédiaire · Temps estimé : 60–80 min · Versions cibles : Karpenter 1.x · EKS 1.30+ · Helm 3 · AWS CLI v2 · kubectl · Dernière vérification : 2026-09-11 · Region :
ca-central-1Slug :
wow-karpenter-eks· Série : WOW (18/50) · Mot-clé SEO : karpenter eks · Publish : HOLD← Précédent : Kubernetes Gateway API 2026 · → Suivant : EKS Pod Identity · Aussi : Spot Instances en prod · Crossplane AWS · EKS concepts
Prérequis
- Cluster EKS lab (managed node group minimal ou Fargate bootstrap accepté) avec
kubectladmin - Helm 3, AWS CLI v2, profil
lab— droits EC2, IAM, EKS, SSM lecture - Sous-réseaux privés tagués pour Karpenter / discovery, security groups cohérents
- Notions Pods / Deployments / requests-limits ; Spot de base dans wow-spot-instances-prod
- Lab jetable : NodePools et instances EC2 créés par Karpenter à détruire en fin de session
Coût estimé : quelques € (EC2 On-Demand/Spot pendant le lab). Cleanup obligatoire. Pas de NAT/RDS « pour tester ».
export AWS_PROFILE=lab
export AWS_DEFAULT_REGION=ca-central-1
aws sts get-caller-identity
kubectl config current-context
kubectl get nodes -o wide
Vérifiez l’identité lab et la région ca-central-1 — jamais un compte de production.
Ce que nous allons construire
Lab Karpenter EKS (WOW 18/50) — ca-central-1
├── Pourquoi Karpenter vs Cluster Autoscaler / ASG
├── Concepts : EC2NodeClass, NodePool, NodeClaim, disruption
├── Prérequis EKS : tags subnets, OIDC / IRSA (ou Pod Identity)
├── Install Helm controller Karpenter 1.x
├── Manifests EC2NodeClass + NodePool (OD + Spot mix)
├── Scale Deployment → observer nodes / NodeClaims
├── Consolidation + scale-down
└── Cleanup + anti-patterns + quiz + FAQ
(Schéma — alt : « Karpenter provisionne des nœuds EC2 EKS depuis des NodePools en ca-central-1 ».)
Étape 1 — Pourquoi Karpenter (vs Cluster Autoscaler)
Le Cluster Autoscaler (CA) réagit aux Pods Pending en ajustant des ASG pré-dimensionnés. Karpenter commande directement l’API EC2 : il choisit type, AZ et capacité (On-Demand ou Spot) pour juste satisfaire les Pods, puis consolide quand la charge baisse.
| Approche | Forces | Limites |
|---|---|---|
| ASG + CA | Mature, simple à raisonner | ASG figés ; scale lent ; fragmentation |
| Managed node groups seuls | Opéré AWS | Moins flexible pour burst Spot |
| Karpenter | Bin-packing, Spot natif, consolidation | IAM/OIDC soigneux ; CRD à maîtriser |
DEH : Karpenter pour les worker nodes élastiques ; garder un petit managed group (ou Fargate) pour le plan de contrôle applicatif critique si besoin. Même discipline Spot que wow-spot-instances-prod : diversification + drain.
Étape 2 — Concepts clés Karpenter 1.x
| Objet | Rôle |
|---|---|
| EC2NodeClass | AMI, subnets, security groups, role instance, userData |
| NodePool | Contraintes (familles, arches, capacity-type), limites, disruption |
| NodeClaim | Demande concrète de nœud (créée par le controller) |
| Disruption | Consolidation, expiration, Drift — comment on remplace/retire |
Le flux : Pod Pending (requests non satisfaits) → Karpenter calcule un nœud → NodeClaim → instance EC2 → kubelet joint le cluster → Pods schedulés.
Étape 3 — Préparer EKS (tags, OIDC, IAM)
Karpenter découvre les sous-réseaux et SG via tags (adaptez le nom de cluster) :
CLUSTER=deh-lab-eks
# Exemple : tag discovery sur subnets privés
aws ec2 create-tags --region ca-central-1
--resources subnet-PRIV1 subnet-PRIV2
--tags Key=karpenter.sh/discovery,Value=$CLUSTER
Activez l’OIDC du cluster et créez un rôle IAM pour le controller (IRSA). En 2026, préférez EKS Pod Identity quand disponible — voir wow-eks-pod-identity. Permissions typiques : ec2:* scoped, iam:PassRole sur le node role, SSM GetParameter pour les AMI AL2023 EKS, pricing/SQS interruption Spot si activé.
Prod DEH : least privilege, SQS queue pour Spot interruption, metrics CloudWatch/Prometheus, pin de chart Helm.
Étape 4 — Installer Karpenter avec Helm
Adaptez le chart officiel / OCI registry AWS (version 1.x pinée). Exemple de forme :
export KARPENTER_NAMESPACE=kube-system
export CLUSTER_NAME=deh-lab-eks
helm upgrade --install karpenter oci://public.ecr.aws/karpenter/karpenter
--namespace "${KARPENTER_NAMESPACE}" --create-namespace
--set "settings.clusterName=${CLUSTER_NAME}"
--set "settings.defaultInstanceProfile=KarpenterNodeInstanceProfile-${CLUSTER_NAME}"
--set "settings.interruptionQueue=${CLUSTER_NAME}"
--version 1.0.0
--wait
kubectl -n "${KARPENTER_NAMESPACE}" get deploy,pods -l app.kubernetes.io/name=karpenter
kubectl get crd | grep karpenter || true
Attendu : Deployment controller Ready ; CRD nodepools.karpenter.sh, ec2nodeclasses.karpenter.k8s.aws, nodeclaims.karpenter.sh.
Étape 5 — EC2NodeClass + NodePool (mix OD / Spot)
Remplacez les selecteurs par vos tags réels. Role instance = rôle nœud EKS (CNI, EBS CSI selon besoin).
apiVersion: karpenter.k8s.aws/v1
kind: EC2NodeClass
metadata:
name: default
spec:
role: "KarpenterNodeRole-deh-lab-eks"
amiSelectorTerms:
- alias: al2023@latest
subnetSelectorTerms:
- tags:
karpenter.sh/discovery: deh-lab-eks
securityGroupSelectorTerms:
- tags:
karpenter.sh/discovery: deh-lab-eks
tags:
Name: karpenter-deh-lab
Environment: lab
ManagedBy: karpenter
---
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: default
spec:
template:
metadata:
labels:
workload: general
spec:
nodeClassRef:
group: karpenter.k8s.aws
kind: EC2NodeClass
name: default
requirements:
- key: kubernetes.amazonaws.com/instance-category
operator: In
values: ["c", "m", "r"]
- key: kubernetes.amazonaws.com/instance-generation
operator: Gt
values: ["4"]
- key: kubernetes.amazonaws.com/instance-cpu
operator: In
values: ["2", "4", "8"]
- key: topology.kubernetes.io/zone
operator: In
values: ["ca-central-1a", "ca-central-1b"]
- key: karpenter.sh/capacity-type
operator: In
values: ["on-demand", "spot"]
- key: kubernetes.amazonaws.com/instance-hypervisor
operator: In
values: ["nitro"]
limits:
cpu: "64"
memory: 128Gi
disruption:
consolidationPolicy: WhenEmptyOrUnderutilized
consolidateAfter: 1m
kubectl apply -f ec2nodeclass-nodepool.yaml
kubectl get ec2nodeclass,nodepool
Points clés DEH : multi-familles (c/m/r), multi-AZ, Spot et On-Demand, limits CPU/mémoire pour éviter la surprise facture, consolidation activée.
Étape 6 — Scale une charge et observer
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"
memory: 256Mi
kubectl apply -f inflate.yaml
kubectl scale deployment inflate --replicas=8
kubectl get nodeclaims -w
kubectl get nodes -o wide -w
kubectl get pods -l app=inflate -o wide
Attendu : NodeClaims Pending → Launched → Registered → Ready ; Pods Running sur les nouveaux nœuds. Inspectez kubectl describe nodeclaim … (type instance, capacity-type Spot/OD, zone).
Étape 7 — Consolidation et scale-down
kubectl scale deployment inflate --replicas=0
# Attendre consolidateAfter
kubectl get nodeclaims,nodes
Avec WhenEmptyOrUnderutilized, Karpenter draine et termine les nœuds inutiles. En prod, alignez consolidateAfter, budgets de disruption et PDBs applicatifs.
Étape 8 — Observabilité et anti-patterns
- Logs controller :
kubectl logs -n kube-system -l app.kubernetes.io/name=karpenter -f - Métriques Prometheus (si scrapées) : décisions de provisioning, erreurs EC2
- EventBridge / SQS Spot interruption : même runbook que Spot ASG
- CloudWatch : facturation EC2 + alarmes budget lab
Anti-patterns :
- Un seul type d’instance / une seule AZ
- 100 % Spot sans PDB ni grace drain
- Requests CPU/mémoire absents (Karpenter ne « voit » pas le besoin)
- Limits NodePool absents (facture ouverte)
- Tags discovery manquants → zero subnet match
- Laisser inflate + nœuds tourner hors lab
Cleanup (obligatoire)
kubectl delete deployment inflate --ignore-not-found
kubectl delete nodepool default --ignore-not-found
kubectl delete ec2nodeclass default --ignore-not-found
# Attendre la fin des NodeClaims / instances
kubectl get nodeclaims,nodes
helm uninstall karpenter -n kube-system || true
Vérifiez la console EC2 ca-central-1 : plus d’instances Karpenter orphelines.
Checklist DEH
- [ ] Region
ca-central-1, profillab - [ ] Tags
karpenter.sh/discoverysur subnets/SG - [ ] IRSA ou Pod Identity pour le controller
- [ ] NodePool multi-familles + multi-AZ + OD/Spot
- [ ]
limitsCPU/mémoire posés - [ ] Consolidation + interruption queue Spot
- [ ] Cleanup Deployments / NodePool / instances vérifié
Quiz (5 questions)
1. Karpenter provisionne surtout via :
– A. Des ASG pré-créés uniquement
– B. L’API EC2 + NodeClaims dynamiques
– C. Uniquement Fargate
2. L’objet qui décrit AMI, subnets et SG est :
– A. NodePool
– B. EC2NodeClass
– C. HorizontalPodAutoscaler
3. En prod DEH, le mix recommandé dans le NodePool est :
– A. Un seul type Spot
– B. On-Demand + Spot, multi-familles, multi-AZ
– C. GPU uniquement
4. Region lab de ce tuto :
– A. us-east-1
– B. ca-central-1
– C. eu-west-3
5. Sans requests CPU/mémoire sur les Pods :
– A. Karpenter scale mieux
– B. Le bin-packing et le scale-out sont faussés
– C. La consolidation est obligatoire
Réponses : 1‑B · 2‑B · 3‑B · 4‑B · 5‑B
FAQ
Pourquoi ca-central-1 ?
Standard lab DevOps Elastic Hayway : cohérence IAM/FinOps entre tutos AWS/EKS. Diversifiez les AZ dans ca-central-1.
Karpenter remplace-t-il totalement les managed node groups ?
Souvent on garde un petit groupe managé (addons système) et on laisse Karpenter gérer le burst applicatif. Tout-Karpenter est possible avec discipline IAM/AMI.
Karpenter vs Cluster Autoscaler ?
CA scale des ASG existants. Karpenter choisit instance/AZ/Spot à la volée et consolide. DEH privilégie Karpenter pour l’élasticité EKS moderne.
Spot et interruption ?
Même contrat ~2 min / rebalance que Spot EC2. Branchez la queue d’interruption et des PDB. Voir wow-spot-instances-prod.
IRSA ou Pod Identity ?
Les deux authentifient le controller auprès d’AWS. Pod Identity simplifie la rotation — détail dans wow-eks-pod-identity.
Quelle AMI ?
amiSelectorTerms avec alias AL2023 EKS (ou Bottlerocket). Évitez les AMI custom non patchées en lab.
Combien ça coûte ?
Facturation EC2 réelle (OD/Spot) + EKS control plane. Limits NodePool + cleanup = garde-fous. Budget alert AWS recommandé.
Drift et mises à jour AMI ?
Karpenter peut remplacer les nœuds quand l’AMI / NodeClass change (drift). Planifiez une fenêtre et des PDB avant d’activer des politiques agressives.
Pour aller plus loin
- Spot Instances en prod
- EKS Pod Identity
- Kubernetes Gateway API
- Crossplane AWS
- EKS concepts
- AWS Cost FinOps
- Démarrer avec AWS
Maillage série WOW
| ← Précédent | Kubernetes Gateway API 2026 |
| → Suivant | EKS Pod Identity |
| Aussi | Spot Instances en prod · Crossplane AWS · EKS concepts |
Meta publication (SEO)
- Title SEO : Karpenter sur EKS : nodes autoscaling (guide FR)
- Meta description : Karpenter sur EKS : NodePool, EC2NodeClass, consolidation Spot/On-Demand, lab ca-central-1, FAQ, quiz et checklist DEH.
- Focus keyword : karpenter eks
- Secondary : Karpenter NodePool, EC2NodeClass, EKS autoscaling, Karpenter Spot
- Image :
assets/web/devopelastichayway/cover-wow-karpenter-eks-1200x630.webp(à générer) - Catégorie : WOW / Kubernetes · Niveau : Intermédiaire
- URL cible : https://devopelastichayway.com/tutoriels/wow-karpenter-eks/
- Post live : N/A (nouveau) · slug
wow-karpenter-eks· Publish : HOLD (draft only — feu vert Maître requis)
Pour aller plus loin — hubs live
Retour parcours Catalogue Tutoriels — hub de la série et leçons sœurs.