Kubernetes et FinOps : les leviers pour éliminer 70 % du gaspillage des clusters

Entre 40 et 70 % des ressources de calcul Kubernetes provisionnées restent inutilisées. Si, en tant qu’ingénieur plateforme, vous ne corrigez pas les requêtes, vous continuez à payer pour des capacités inoccupées qu’aucun autoscaler ne peut optimiser. Les quatre leviers qui comptent vraiment suivent un ordre précis – le right-sizing d’abord, tout le reste s’appuie dessus.

Les points clés en bref

• Le gaspillage est une fourchette, pas une valeur fixe : 40 à 70 % des ressources de calcul K8s ne sont pas exploitées. Mesurer avant d’optimiser – cette fourchette révèle où agir dans votre propre cluster.
• Le right-sizing est la base : Sans CPU et mémoire corrigés dans les requêtes, les leviers en aval multiplient des valeurs erronées. HPA, Karpenter et les pools Spot calculent alors sur des définitions fausses.
• KEDA pour les workloads pilotés par événements : Le scale-to-zero en cas d’inactivité est rentable pour les services basés sur des files d’attente, mais pas pour les API toujours actives avec des exigences de latence constantes.
• Karpenter est l’alternative plus récente au Cluster Autoscaler : Provisionnement direct des nœuds sans couche intermédiaire de Node Group, plus flexible pour les types de workloads dynamiques.

En lien :FinOps : réduire réellement de 30 % les coûts du cloud  /  Ce que la mise à niveau Cilium peut supprimer dans le cluster

Pourquoi le right-sizing est le pivot central

Les requêtes et les limites constituent la base sur laquelle chaque levier en aval calcule. Si vous les ignorez et passez directement à Karpenter ou aux instances Spot, vous optimisez sur des fondations erronées. Le HPA scale sur des seuils incorrects. Karpenter provisionne des types de nœuds inadaptés. Les pools Spot sont mal dimensionnés. Sans requêtes corrigées, aucun levier ultérieur ne fonctionne correctement.

Le right-sizing corrige la définition elle-même. Il détermine, pour chaque workload, la quantité réelle de CPU et de mémoire nécessaire, plutôt que de s’appuyer sur des règles empiriques ou des valeurs par défaut. Le VPA en mode recommandation fournit cette base – le mode automatique ne doit pas être déployé directement en production sans une stratégie de drain. En confrontant les requêtes à l’utilisation réelle une fois par trimestre, vous éliminez la principale source de gaspillage avant même qu’un autoscaler n’intervienne.

Scale-to-zero avec KEDA pour les workloads pilotés par événements

KEDA étend le Horizontal Pod Autoscaler avec des déclencheurs externes comme Kafka, SQS ou RabbitMQ. Là où le HPA réagit à des seuils de CPU ou de mémoire, KEDA scale en fonction de la profondeur de la file d’attente ou du taux d’événements, et réduit les workloads à zéro en cas d’inactivité. Pour les services qui ne fonctionnent qu’en réponse à des événements, c’est le levier le plus efficace contre la consommation inutile en période de veille.

KEDA n’est pas une solution universelle. Les API toujours actives avec des exigences de latence constantes ne bénéficient pas du scale-to-zero, car le démarrage à froid rompt les SLA. Son utilisation est pertinente pour les services pilotés par événements avec des phases d’inactivité claires – workers batch, traitements asynchrones, consommateurs de webhooks. Si vous utilisez KEDA là où le HPA serait la bonne réponse, vous payez en instabilité plutôt qu’en argent.

Cluster Autoscaler ou Karpenter – ajouter dynamiquement des nœuds

Le Cluster Autoscaler est une solution éprouvée qui fonctionne avec des Node Groups. Il ajoute des nœuds lorsque des pods restent en attente. Si l’utilisation baisse, il les retire. Karpenter provisionne directement les nœuds sans couche intermédiaire de Node Group et représente l’option plus récente et plus flexible pour les types de workloads dynamiques.

Le choix dépend de la stratégie de cluster et de la maturité du fournisseur. Karpenter bénéficie d’un support prioritaire sur EKS et est disponible sous une autre forme sur GKE. Ceux qui privilégient des Node Groups fixes et une migration prudente restent sur le Cluster Autoscaler. Ceux qui souhaitent mixer dynamiquement les types de nœuds en fonction des besoins des workloads gagnent en flexibilité avec Karpenter, une souplesse que le Cluster Autoscaler ne peut offrir par conception.

VM Spot et préemptibles – le compromis risqué

Les VM Spot réduisent considérablement les coûts pour les charges de travail tolérantes aux pannes, comme les batchs, les runners CI ou les workers asynchrones. La condition préalable est une tolérance propre à la préemption : PodDisruptionBudgets, Graceful Shutdown et répartition des réplicas sur plusieurs nœuds. Celui qui ne vérifie pas cette condition s’expose à une perte de réplicas à chaque vague de préemption.

Les VM Spot sont rentables là où une perte soudaine de pods ne casse pas l’application. Les services stateful, les API critiques en latence et les charges de travail à réplica unique n’ont pas leur place sur des VM Spot. La séparation claire par type de charge de travail est le point décisif – un cluster qui met tout sur des VM Spot échange des économies de coûts contre la fiabilité.

Ordre et mesure – ce qui doit être appliqué et quand

L’ordre n’est pas optionnel. D’abord, établir les bases des métriques (kube-metrics, recommandations VPA), puis appliquer le Right-Sizing comme fondement. Sur ces valeurs corrigées suivent HPA et KEDA pour le scaling des charges de travail. Karpenter ou le Cluster-Autoscaler provisionnent des nœuds adaptés aux besoins des charges de travail. Les VM Spot réduisent les coûts sur les charges de travail tolérant la préemption. Les CUD et les couches managées comme Autopilot sont des niveaux d’engagement ou de commodité à appliquer en toute dernière étape.

Celui qui inverse cet ordre optimise à l’aveugle. Les VM Spot sans requêtes corrigées touchent les mauvaises charges de travail. Karpenter sans Right-Sizing provisionne les mauvais types de nœuds. La discipline consiste à faire d’abord le travail de base – et c’est rarement glamour dans Kubernetes, mais c’est le levier économique le plus puissant.

Foire aux questions

Plus d’articles du réseau MBF Media

Source de l’image : générée par IA (juillet 2026)