Optimiser les coûts Kubernetes : quick wins

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 quick wins qui réduisent la facture sans créer de risque de fiabilité.

Où la dépense se cache

• 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 des engineers” :

• 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 non-prod par schedule

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

• Scale down 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 packer : design 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 quick Kubernetes cost optimization

• Requests calibrées sur l’usage réel
• Non-prod automatiquement downscalé
• 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ù sont les plus gros drivers

Un audit d’infrastructure ciblé identifie rapidement les plus gros postes de coûts et les risques associés, puis les traduit en plan d’action priorisé.