Les clusters EKS affichent une sous-utilisation moyenne de seulement 8 % en CPU, alors que 69 % de la capacité CPU provisionnée reste inutilisée. Ces chiffres, tirés du rapport 2026 sur l’optimisation de Kubernetes, montrent que l’adoption d’outils avancés comme Karpenter ne suffit pas à résoudre le problème de l’alignement entre les déclarations de ressources et l’usage réel des applications.

La difficulté fondamentale réside dans le fait que les systèmes d’autoscaling, y compris Karpenter, fonctionnent en se basant sur les requêtes de ressources déclarées par les pods, et non sur leur consommation effective. Si un service demande quatre cœurs CPU mais n’en utilise réellement que cinq cents millicores en pointe, Karpenter provisionne une instance capable de satisfaire cette demande gonflée. Cette pratique défensive, où les ingénieurs surdimensionnent les spécifications pour éviter un étranglement, devient le standard, même si elle engendre des gaspillages considérables.

Les conséquences financières sont directes. L’optimisation des coûts sur EKS nécessite une séquence d’actions : d’abord, ajuster la taille des pods (rightsizing), puis optimiser le provisionnement des nœuds. Selon Cast AI, le rightsizing des pods est l’action offrant le meilleur retour sur investissement, d’autant que 79 % de la mémoire est également surprovisionnée.

Les limites du provisionnement dynamique

Karpenter est efficace pour le provisionnement par pod, il est plus rapide que ses prédécesseurs, avec des déploiements de nœuds disponibles en soixante à quatre-vingt-dix secondes sur AWS. Il gère également les instances Spot en utilisant une stratégie optimisée prix-capacité, ce qui réduit le risque d’interruptions simultanées. Cependant, cette agilité s’arrête au niveau de la requête. Comme l’explique Cast AI, « La sélection du type d’instance ne fait que se baser sur les requêtes. » C’est un choix de conception délibéré, mais il signifie que le système est aveugle à la réalité opérationnelle.

Ce fossé entre l’intention déclarée et le comportement réel est particulièrement visible dans le domaine de l’IA. Pour les charges de travail de machine learning, où les pics d’inférence sont suivis de longues périodes d’inactivité, le modèle dédié coûte cher. Une plateforme éducationnelle, par exemple, a réduit ses coûts de calcul de plus de 70 % sur AWS EKS en mutualisant des modèles sur des GPU partagés, en passant d’instances dédiées à une approche combinant time-slicing et répartition Spot/on-demand.

La complexité de la gestion à l’échelle

Au-delà du problème d’utilisation, la gestion à grande échelle ajoute une complexité d’ingénierie. Karpenter opère sur un plan par pod, il n’offre pas de vue consolidée au niveau du fleet. Il n’y a pas de politique d’application transversale entre clusters, ni de données de facturation attribuables au niveau du namespace. De plus, il n’a aucune connaissance des mécanismes d’achat comme les Instances Réservées ou les Plans d’Économies.

Pour les équipes gérant de nombreux environnements, la prolifération de NodePools et les dérives de configuration constituent une charge de travail d’ingénierie constante. On doit aussi surveiller les clusters EKS qui dépassent la période de support standard de quatorze mois, car AWS applique alors des frais de support étendus, qui s’accumulent vite. Enfin, l’utilisation moyenne des GPU sur AWS reste à 5 %, principalement à cause du modèle d’allocation dédié, qui ne s’adapte pas aux charges de travail en rafales typiques de l’inférence.

Sources

• Open-Source Karpenter Limitations: What the Gaps Are at Enterprise Scale, cast.ai
• EKS Cost Optimization: The Engineer’s Guide for 2026, cast.ai
• EKS Powers the Cloud’s Largest Kubernetes Fleets – So Why Is It Still Running Mostly Idle?, Cloud Native Now, 3 novembre 2026
• Amazon EKS Auto Mode now supports Kubernetes Gateway API, AWS, 28 octobre 2026

Crédits photo

• Image en une : Wikimedia Servers-0051 16, par Helpameout, CC BY-SA 3.0, via Wikimedia Commons (recadrée)