Comment maîtriser Karpenter en 2026

Karpenter est un auto-scaler open-source pour Kubernetes, conçu par AWS pour surpasser le Cluster Autoscaler traditionnel. Contrairement à ce dernier, qui repose sur des heuristiques statiques et des cycles de réconciliation lents (jusqu'à 10 minutes), Karpenter réagit en secondes grâce à une architecture événementielle et disruptless. Il provisionne dynamiquement des nœuds EC2 (sur EKS) en analysant les pods pending en temps réel, sans interruption des workloads existants.

Pourquoi est-ce crucial en 2026 ? Les clusters Kubernetes en production gèrent des pics de trafic imprévisibles, des coûts cloud exorbitants et des SLO stricts. Karpenter réduit les coûts de 30-50 % via un bin-packing intelligent et un drift vers des instances spot/économiques. Il s'intègre nativement avec le scheduler Kubernetes, évitant les silos. Ce tutoriel expert, sans code, se concentre sur la théorie profonde, les flux de décision et les patterns avancés. Vous apprendrez à modéliser mentalement Karpenter comme un 'just-in-time provisioning engine', prêt à bookmarker pour vos revues d'architecture.

Analogie : Imaginez Karpenter comme un chef d'orchestre qui, au lieu d'ajouter des musiciens en bloc pour un solo de violon, provisionne exactement l'instrument requis, optimise la scène et recycle les ressources inutiles – fluidité et économie maximales.

• Maîtrise avancée de Kubernetes : pods, nodes, scheduler, taints/tolerations, affinity.
• Expérience EKS (ou autre managed K8s compatible) : IAM Roles for Service Accounts (IRSA), VPC CNI.
• Connaissances AWS EC2 : instance types, spot instances, capacity blocks, savings plans.
• Notions de bin-packing et scheduling : théorèmes d'approximation pour NP-hard problems.
• Outils de monitoring : Prometheus, CloudWatch pour analyser les signaux Karpenter.

Karpenter s'articule autour de trois piliers : Controller, Provisioner et NodePool (évolution des Provisioners depuis v1).

• Controller : Déployé comme un Deployment dans kube-system, il watch les Unschedulable Pods via l'API Kubernetes. À chaque événement (pod pending), il déclenche un workflow asynchrone : évaluation des contraintes (requests/limits CPU/Mémoire), matching avec Provisioners, sélection d'instance EC2 via AWS API (DescribeInstanceTypes).

1. Signal Capture : Inotify-like sur pods/events.
2. Consolidation : Agrège les pods pending par 'shape' (CPU/Mem vector).
3. Provisioning Loop : Résout le bin-packing (First-Fit Decreasing heuristic) pour minimiser le nombre de nœuds.
4. Launch Template : Génération dynamique via EC2 Fleet API.

• Provisioner (v0.x) / NodePool (v1+) : CRDs définissant les règles : instance families (e.g., m7g), zones, taints, labels, exigences Spot (>80% pour économies).

Différence clé avec Cluster Autoscaler : Pas de scale-down basé sur utilisation (Karpenter utilise des TTLs ou consolidation signals), focus sur overprovisioning minimal.

Provisioner (legacy) : YAML CRD avec requirements (nodeSelector-like), limits (max nodes per family), ttlAfterEmpty (auto-drain).

NodePool (actuel) : Plus granulaire, supporte disruption budgets, KMS encryption, security groups dynamiques.

Théorie de décision :

• Requirements Matching : Pod affinity/taints mappés sur NodePool selectors. Utilise un subset sum problem approximé pour fitting.
• Instance Selection : Trie par pricePerformance (vCPU/$), priorise Graviton (ARM) pour workloads CPU-bound.
• Diversity : Évite single-point via zoneSpread, instanceOS (Bottlerocket/Al2).

Karpenter n'intervient jamais dans le scheduling des pods ; il étend le scheduler natif.

Flux end-to-end :

1. Scheduler assigne pod à node → Si échec (NoFitError), pod devient Unschedulable.
2. Karpenter intercepte → Simule scheduling sur nœuds hypothétiques.
3. Provisionne → Nodes joinent en <2min via bootstrap (cloud-init).

Théorie des signaux :

• Deprovisioning : TTLSecondsAfterEmpty (e.g., 30s), Signal (Prometheus query: node_cpu_usage < 10%).
• Consolidation : Merge pods de petits nœuds vers un gros (bin-packing inverse), respecte PDB.

Patterns experts :

• Multi-NodePools : Un par workload family (e.g., CPU, GPU, Storage).
• Capacity Blocks : Réserve pour pics prévisibles (2026 feature).

• Modélisez par workloads : Un NodePool par 'persona' (e.g., stateless-apps, statefulsets). Évitez l'over-generalization.
• Spot-First Strategy : Set capacityType: spot avec fallback OnDemand à 20%. Surveillez interruption rates via CloudWatch.
• Taints/Tolerations stricts : Forcez les pods à matcher NodePools, prévient cross-contamination.
• Monitoring holistique : Dashboards Grafana pour provisioner_unschedulable_pod_reasons, node_claim_failures. Alertez sur >5% drift.
• Consolidation proactive : Activez avec expireAfter: 7200s, testez en staging avec chaos engineering (Litmus).

• Over-limits : limits: {resources: cpu: 100} bloque scaling ; utilisez soft limits ou multi-Provisioners.
• IAM sous-dimensionné : Oubli de ec2:RunInstances ou eks:DescribeNodegroup → Pods stuck en pending éternel.
• No Diversity : Single AZ/instance family → Blast radius énorme lors d'events AWS.
• Ignore PDB : Consolidation évite les nœuds mais viole SLO si PDB mal calé (e.g., minAvailable=1 sur Deployment de 1 réplica).

Approfondissez avec la documentation officielle Karpenter. Étudiez les benchmarks AWS re:Invent 2025 sur coûts vs. Keda/Autoscaler.

Ressources :

• Livre blanc : 'Disruptless Scaling in Kubernetes' (AWS).
• Repo GitHub : Contribuez à des NodePools pour ARM workloads.
• Outils : karpenter.dev CLI pour dry-runs.