INSIGHT #06 // CLOUD INFRASTRUCTURE & FINOPS
FinOps cloud-native : réduire sa facture sans sacrifier l'uptime
Comment diviser par deux le gaspillage de compute sur Kubernetes avec Karpenter, l'autoscaling par files de messages et une stratégie Spot étanche.
Martial GNINHI
Directeur Technique & Architecte Cloud
Secteur & Contexte
Plateforme SaaS B2B en hypercroissance (AWS EKS)
Contraintes d'exploitation
SLA contractuel de 99.95% de disponibilité et temps de réponse P99 < 300 ms en heures de pointe (09h-18h)
Enjeu critique
Enrayer une dérive budgétaire de +140% de coûts cloud en 12 mois sans risquer la moindre interruption de service client
Dans la plupart des architectures Kubernetes en production, le gaspillage de ressources n'est pas dû à de la négligence : c'est le résultat direct d'une stratégie de défense psychologique des équipes devops. Par peur d'un crash en plein pic d'activité ou d'un appel d'astreinte en pleine nuit, les ingénieurs allouent préventivement 4 vCPU et 8 Go de mémoire à des pods dont l'usage réel ne dépasse jamais 15%. Lorsque le cluster atteint 150 nœuds, ce réflexe se traduit par des dizaines de milliers d'euros brûlés chaque mois en serveurs fantômes. Réduire la facture de manière pérenne sans compromettre l'uptime n'est pas une question de négociation commerciale avec AWS ou GCP : c'est un problème d'ingénierie d'autoscaling dynamique et d'exploitation rigoureuse des instances Spot.
Les 3 fuites budgétaires majeures des clusters Kubernetes
L'analyse fine de clusters de production révèle systématiquement les mêmes mécanismes de surcoût invisible.
Le gouffre entre CPU Requests et consommation réelle
L'ordonnanceur Kubernetes réserve les nœuds sur la base des Requests, et non de l'usage effectif. Les serveurs tournent à 18% de charge moyenne mais affichent 95% d'allocation théorique.
Rigidité et lenteur du Cluster Autoscaler standard
Le Cluster Autoscaler historique met de 3 à 8 minutes pour démarrer un nœud EC2, incitant les équipes à maintenir un surprovisionnement permanent par sécurité.
Peur des interruptions sur les instances Spot
Parce qu'une coupure Spot a provoqué des erreurs 502 il y a deux ans, 100% du cluster a été rebasculé sur des instances On-Demand payées au tarif maximal.
Karpenter v0.37+, scaling sur files KEDA et orchestration Spot sans coupure
Nous remplaçons les Node Groups statiques par un approvisionnement juste-à-temps capable de tailler les nœuds au millimètre près en moins de 45 secondes.
Stack & Composants de production qualifiés
Pipeline d'optimisation FinOps continue
Audit d'attribution avec Kubecost v2.2+
Cartographie exacte des coûts par namespace, par pod et détection des surallocations de Requests vs consommation réelle (P99).
Granular Cost AttributionProvisionnement juste-à-temps via Karpenter
Abandon des Node Groups rigides : Karpenter sélectionne dynamiquement l'instance EC2 la moins chère (familles diversifiées m6i, c6i, r6i) en moins de 45 secondes.
Just-in-Time Node PackingDéport des workers sur instances Spot
Basculement de 100% des workers asynchrones sur Spot avec capture du préavis d'interruption de 2 minutes via l'AWS Node Termination Handler.
Graceful Spot DrainageAutoscaling événementiel via KEDA
Dimensionnement horizontal piloté par la profondeur réelle des files SQS / RabbitMQ plutôt que par un seuil CPU moyen souvent trompeur.
Queue-Driven Horizontal Autoscaling# NodePool Karpenter avec sélection Spot multi-familles et consolidation
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
name: batch-workers
spec:
template:
spec:
requirements:
- key: karpenter.sh/capacity-type
operator: In
values: ["spot"]
- key: instance-family
operator: In
values: ["c6i", "c6a", "m6i", "m6a", "c5", "m5"]
nodeClassRef:
name: default-nodeclass
disruption:
consolidationPolicy: WhenUnderutilized
expireAfter: 720h # Rotation préventive tous les 30 joursKarpenter rassemble automatiquement les pods sous-utilisés et détruit les nœuds excédentaires dès qu'une charge se termine.
Arbitrages techniques & Exigences logicielles
Diviser par deux une facture de serveurs n'est pas magique : cela impose de concevoir des applications réellement résilientes à l'interruption.
Imposer que tous les workers soient sans état et capables de reprendre une tâche interrompue sur file d'attente.
Exclut les jobs de traitement monolithiques longs non découplés tant qu'ils n'ont pas été réarchitecturés.
Conservation temporaire d'un NodePool On-Demand restreint pour les quelques jobs patrimoniaux non résilients.
Les 40 secondes nécessaires à Karpenter pour ajouter un nœud restent trop lentes pour un pic de trafic instantané en 2 secondes.
Risque de saturation passagère si le trafic décuple en quelques secondes.
Maintien permanent d'un buffer de 5% à 8% de pods fantômes à faible coût (Overprovisioning pods avec priorityClass basse), sacrifiés instantanément par Kubernetes lors d'un burst.
Résultats mesurés sur un cluster client de 150 nœuds
Bilan chiffré constaté après 90 jours de déploiement de Karpenter et KEDA en environnement de production.
-38.4%
Économie mensuelle récurrente sur le périmètre EC2
64%
Porté de 18% à 64% grâce au repacking Karpenter
0 minute
100% de disponibilité maintenue sur les SLA clients
Bénéfices d'exploitation constatés :
- Fin du surprovisionnement défensif sans compromettre la tranquillité des ingénieurs d'astreinte.
- Allocation des coûts d'infrastructure directement rattachable à chaque équipe produit via Kubecost.
- Vitesse de mise à l'échelle automatique multipliée par 5 par rapport au Cluster Autoscaler historique.
- Réconciliation durable entre la direction financière (FinOps) et les équipes d'ingénierie logicielle.
Prolonger cette architecture sur vos projets
Découvrez les services d'ingénierie et les solutions métiers directement liés à cette problématique :
Service 02 — Automatisation & Workflows
Gestion des pipelines asynchrones, résilience des files de messages et exécution déterministe.
Optimisation de grille intelligente
Équilibrage dynamique et réduction des coûts de consommation énergétique.
Maintenance prédictive IoT
Surveillance continue d'infrastructures et détection précoce d'anomalies opérationnelles.
Vous concevez ou auditez une architecture similaire ?