Optimiser les coûts Kubernetes : gains rapides

Kubernetes permet d’aller vite… et de dépenser vite. La plupart des équipes n’ont pas “un gros problème” : elles ont plusieurs fuites. Requests surdimensionnées, environnements non-prod toujours allumés, pools trop fragmentés, et rétention logs/metrics sans limites.

Voici des gains rapides qui réduisent la facture sans créer de risque de fiabilité.

Où se cachent les coûts Kubernetes

• Requests CPU/mémoire surévaluées (bin packing dégradé)
• Environnements inactifs (dev/staging 24/7)
• Node pools trop gros ou mal conçus
• Rétention logs/metrics/traces non bornée

D’abord : mesurer de façon actionnable

Avant d’optimiser, rendez le coût lisible pour les ingénieurs :

• Coût par namespace / workload / service
• Requests vs usage réel (CPU/mémoire)
• Coût du non-prod (souvent très élevé)
• Coût observabilité (ingestion + rétention)

Si vous ne pouvez pas expliquer “ce qui a changé la semaine dernière”, vous optimisez à l’aveugle.

Les leviers les plus rapides

1) Right-sizing des requests (prudence sur les limits)

Le levier n°1 est souvent la surdéclaration de ressources.

• Ajustez les requests selon P95/P99 d’usage (pas au feeling)
• Attention aux memory limits trop agressives (OOMKills)
• Commencez par des services non critiques, élargissez ensuite

2) Éteindre le hors-prod selon un planning

Beaucoup d’environnements tournent “au cas où”.

• Réduire la voilure la nuit et le week-end
• Suspendre batch jobs et preview envs inutilisés
• Pools non-prod séparés et plus petits

3) Autoscaling là où c’est sûr

Puissant, mais à aligner avec le comportement du workload.

• HPA pour services stateless avec signaux stables
• Cluster autoscaler (ou équivalent) pour éviter les pools surdimensionnés
• Pools séparés pour workloads sensibles vs batch

4) Mieux remplir les nœuds : conception des node pools

Trop de pools “spéciaux” = fragmentation.

• Réduire le nombre de pools, clarifier l’intention de chacun
• Utiliser taints/tolerations et affinity avec parcimonie
• Vérifier que PDB et contraintes ne bloquent pas la consolidation

5) Storage et lifecycle

Le stockage grossit silencieusement :

• PVC/snapshots orphelins
• Storage classes hautes perfs “par défaut”
• Absence de lifecycle sur object storage/backups

6) Garde-fous sur rétention logs/metrics

Une rétention illimitée est un incident financier progressif.

• Rétention différente prod vs non-prod
• Échantillonnage et contrôle de cardinalité
• Privilégier les signaux actionnables à “tout collecter”

À éviter (optimisation qui casse la fiabilité)

• Baisser brutalement les memory limits sans tests
• Supprimer redondance sans comprendre les modes de panne
• Autoscaler des services critiques sans tests de charge et rollback plan
• Mettre tous les workloads dans un seul pool si l’isolation est nécessaire

Checklist : optimisation des coûts Kubernetes

• Requests calibrées sur l’usage réel
• Hors-prod réduit automatiquement en dehors des heures ouvrées
• Node pools intentionnels, peu fragmentés
• Autoscaling activé quand il a du sens
• Storage/snapshots avec ownership + lifecycle
• Observabilité à rétention bornée (par environnement)

Si vous ne savez pas où part l’argent

Un audit d’infrastructure ciblé (périmètre fixe, 2 à 4 semaines, 15 000 $) identifie les plus gros postes de coûts et les risques associés, puis les traduit en plan d’action priorisé. David Park, VP Engineering d’une HealthTech en série A, a réduit ses dépenses cloud de 28 % dès la première mission ; l’audit s’est rentabilisé en quelques semaines.