Kubernetes coûte trop cher : 10 leviers immédiats

Kubernetes, c’est un peu le paradoxe moderne. On l’adopte pour industrialiser, standardiser, scaler proprement. Et quelques mois plus tard, on se retrouve à regarder une facture cloud qui grimpe sans prévenir. Pas parce que la plateforme est « mauvaise ». Plutôt parce que Kubernetes rend très facile… le fait de consommer. Trop.

Ce qui coûte cher, dans 80 % des cas, ce n’est pas « Kubernetes ». C’est le combo : surallocation CPU/RAM, autoscaling mal réglé, clusters surdimensionnés, stockage qui s’accumule, environnements non éteints, trafic inter zones, et un manque de visibilité (le classique).

Dans cet article, je te donne 10 leviers immédiats. Pas des grands chantiers « on verra au prochain trimestre ». Des actions concrètes qui font baisser la note et qui, souvent, améliorent aussi la stabilité.

Note rapide : j’écris ça dans l’esprit du Blog Tech Pro de Samyn-Antoy ABASSE (oui, celui sur Blogger). Du pratique, du terrain. Si tu veux d’autres checklists ops et productivité, passe faire un tour sur https://monblog-sa-abasse.blogspot.com, il y a de quoi piocher.

---

1) arrêter de surdemander : requests/limits réalistes, sinon tu payes du vide

La base. Le truc le plus bête et le plus fréquent.

Dans Kubernetes, le scheduler place les pods selon les requests. Donc si tu demandes 2 CPU et 4 Go pour un service qui consomme en vrai 200 mCPU et 600 Mo, tu viens de réserver de la capacité inutile. Et en cluster managé, cette capacité se traduit en nœuds en plus. Donc en euros.

Action immédiate :

• mesurer l’usage réel (sur 7 à 14 jours si possible)
• réduire progressivement les requests
• garder des limits cohérentes (ou ne pas en mettre partout si ça cause du throttling CPU)

Commandes utiles : bash kubectl top pods -A kubectl top nodes

Si tu as Prometheus :

• regarde p95 CPU, p95 RAM par workload
• ajuste requests à p95 (ou p90) selon ton appétit de risque

Exemple simple : yaml resources: requests: cpu: "200m" memory: "512Mi" limits: cpu: "1" memory: "1Gi"

Petit rappel qui pique : la RAM non utilisée, tu la payes quand même si elle force de nouveaux nœuds.

---

2) activer (ou corriger) l’autoscaling pods : HPA bien réglé, sinon il fait n’importe quoi

Beaucoup de teams ont « un HPA ». Oui. Mais avec des seuils copiés de Terraform examples et une métrique CPU moyenne qui ne correspond pas au vrai goulot.

Erreurs classiques :

• targetCPUUtilizationPercentage: 50 sur une app I/O bound
• minReplicas trop haut « au cas où »
• scale down trop lent (stabilizationWindowSeconds énorme)

Action immédiate :

• vérifier min/max replicas
• vérifier la fenêtre de stabilisation
• si possible, basculer sur une métrique applicative (requests per second, latence, queue length)

Exemple (CPU, mais propre) : yaml behavior: scaleDown: stabilizationWindowSeconds: 60 scaleUp: stabilizationWindowSeconds: 0

Résultat attendu : moins de pods inutilement allumés la nuit, et moins de « pics » qui déclenchent trop tard.

---

3) autoscaler nœuds : éviter les machines premium et les tailles absurdes

Le Cluster Autoscaler (ou équivalent managé) est ton ami. Mais il faut lui donner de bonnes cartes.

Ce qui fait exploser le coût :

• node pools uniques avec de gros nœuds (beaucoup de gaspillage)
• types d’instances « généralistes premium » par défaut
• pas de séparation entre workloads critiques et batch

Action immédiate :

• créer 2 à 3 node pools : « web », « worker », « ops »
• préférer plusieurs nœuds moyens plutôt que peu de nœuds énormes
• activer la consolidation si tu es sur Karpenter (ou l’équivalent)

Astuce terrain : pour beaucoup de stacks, les nœuds 2 à 4 vCPU donnent un meilleur bin packing que les monstres 16 vCPU.

---

4) utiliser des instances spot/préemptibles (au bon endroit), c’est souvent -50 % à -80 %

C’est l’un des leviers les plus rapides, et le plus rentable. Oui, ça peut être interrompu. Mais tout n’a pas besoin d’être sur du « on-demand ».

Candidats parfaits :

• jobs batch
• workers asynchrones (queue)
• CI runners
• environnements de preview
• traitements nocturnes

Action immédiate :

• créer un node pool spot
• ajouter des tolerations/affinity pour y placer les workloads adaptés
• vérifier que tes workloads gèrent la perte d’un nœud (graceful shutdown, retries)

Exemple côté pod : yaml tolerations:

• key: "spot" operator: "Equal" value: "true" effect: "NoSchedule"

Même un mix 30 % spot sur un cluster peut faire une vraie différence.

---

5) couper les environnements oubliés : dev, staging, preview, et les « on verra demain »

Tu veux une vérité simple : beaucoup de factures Kubernetes, c’est du non-production.

Des namespaces de features, des branches de preview, des clusters de test créés un vendredi… et jamais supprimés.

Action immédiate :

• inventorier tout ce qui tourne hors prod
• mettre une politique d’expiration (TTL) sur les environnements éphémères
• automatiser la suppression via pipeline (GitHub Actions, GitLab CI)

Commandes utiles : bash kubectl get ns kubectl get all -A | head

Si tu veux faire ça proprement : taggue, labelle, et fais un script qui tue tout ce qui dépasse X jours.

Oui, c’est un levier « process ». Mais c’est immédiat.

---

6) storage : PV orphelins, snapshots, logs… le cimetière silencieux

Le stockage, c’est traître. Tu peux optimiser CPU et nœuds, et te faire rattraper par :

• volumes persistants non supprimés
• snapshots automatiques
• rétention de logs infinie
• bases de données surdimensionnées

Action immédiate :

• lister les PV/PVC et repérer les « Released »
• vérifier la reclaimPolicy (Delete vs Retain)
• réduire la rétention logs (Loki, Elasticsearch, Cloud Logging)

Commandes : bash kubectl get pv kubectl get pvc -A

Et côté cloud : regarde les disques « unattached ». Ça fait mal de payer des disques fantômes.

---

7) traffic et réseau : attention aux coûts inter zones et aux load balancers

Sur certains clouds, le réseau peut devenir un poste majeur. Kubernetes, lui, adore multiplier :

• load balancers
• ingress
• services de type LoadBalancer
• trafic cross zone

Action immédiate :

• mutualiser les entrées via un Ingress controller au lieu de 20 load balancers
• vérifier si ton ingress crée un LB par service ou un LB partagé
• aligner les nœuds et le trafic (topology aware routing, local traffic policy selon cas)
• éviter les appels inter cluster inutiles

Commande : bash kubectl get svc -A | grep LoadBalancer

Un quick win fréquent : passer certains services internes en ClusterIP au lieu de LoadBalancer.

---

8) droits et quotas : mettre des garde fous, sinon les équipes « testent » en prod

C’est pas glamour, mais c’est efficace. Sans quotas, n’importe qui peut déployer 50 replicas « pour voir ».

Action immédiate :

• appliquer des ResourceQuota par namespace
• appliquer des LimitRange pour éviter les pods sans requests
• interdire certains types via policies (Kyverno, Gatekeeper)

Exemple quota : yaml apiVersion: v1 kind: ResourceQuota metadata: name: quota-ns spec: hard: requests.cpu: "4" requests.memory: "8Gi" limits.cpu: "8" limits.memory: "16Gi"

Tu ne cherches pas à brider. Tu cherches à éviter les accidents.

---

9) observabilité des coûts : FinOps Kubernetes, sinon tu pilotes à l’aveugle

Si tu ne peux pas répondre à : « quel service coûte combien ? », tu es coincé. Parce que tu vas optimiser au hasard. Et tu vas te fatiguer.

Action immédiate :

• activer la ventilation des coûts par namespace, deployment, label
• imposer une convention de labels : app, team, env, cost-center
• installer un outil de coûts Kubernetes (Kubecost, OpenCost, ou dashboards maison)

Labels recommandés :

• app.kubernetes.io/name
• app.kubernetes.io/part-of
• team
• environment
• owner

Même si tu n’installes rien, commence par les labels. Sans ça, toute initiative FinOps devient du bricolage.

---

10) right sizing de la plateforme : un cluster par environnement, parfois c’est juste trop

C’est un sujet sensible, parce que « best practice » dit souvent : un cluster prod, un cluster staging, un cluster dev. Ok.

Mais dans la vraie vie, tu peux :

• mutualiser dev et staging
• réduire staging à des tailles minimales
• utiliser des namespaces et des quotas plutôt que multiplier les clusters

Action immédiate :

• regarder le taux d’utilisation moyen des clusters non prod
• envisager une consolidation
• mettre une plage horaire d’extinction si c’est compatible (nœuds à zéro la nuit via autoscaling)

Même en restant prudent, tu peux économiser beaucoup juste en arrêtant de faire tourner un staging « comme la prod » 24 h sur 24.

---

Si tu veux une séquence simple, sans te disperser :

1. kubectl top pods -A et repérer les plus gros consommateurs, puis les plus gros requests.
2. Lister les services LoadBalancer et voir ceux qui devraient être internes.
3. Lister PV/PVC et identifier les volumes orphelins.
4. Vérifier HPA sur les gros workloads (minReplicas, seuils).
5. Regarder les clusters non prod et décider quoi éteindre ou réduire aujourd’hui.

Pas demain. Aujourd’hui.

---

conclusion : Kubernetes n’est pas cher, c’est l’absence de garde fous qui l’est

Tu peux garder Kubernetes et faire baisser la facture. Souvent sans toucher au code. Juste en remettant du bon sens sur l’allocation, l’autoscaling, le stockage, et la gouvernance.

Si tu veux, je peux aussi te proposer une checklist « audit coût » plus détaillée (labels, métriques à regarder, seuils, et un plan sur 2 semaines). Sur Le Blog Tech Pro de Samyn-Antoy ABASSE, je publie régulièrement des méthodes et des templates que tu peux réutiliser. Passe sur https://monblog-sa-abasse.blogspot.com et jette un œil aux pages services si tu veux un coup de main plus concret.

Et oui, la meilleure optimisation coûte, c’est parfois juste ça : supprimer ce qui ne sert plus. Le reste suit.

Questions fréquemment posées

Pourquoi ma facture cloud augmente-t-elle après l'adoption de Kubernetes ?

La hausse de la facture cloud n'est pas due à Kubernetes lui-même, mais souvent à une consommation excessive facilitée par la plateforme. Cela inclut la surallocation CPU/RAM, un autoscaling mal configuré, des clusters surdimensionnés, un stockage accumulé, des environnements non éteints et un manque de visibilité.

Comment éviter de payer pour des ressources Kubernetes inutilisées ?

Il est essentiel de définir des requests et limits réalistes pour les pods. Mesurez l'usage réel sur 7 à 14 jours, ajustez progressivement les requests en fonction du p95 ou p90 d'utilisation CPU et RAM, et évitez de réserver plus que nécessaire pour ne pas payer des ressources vides.

Comment optimiser l'autoscaling des pods dans Kubernetes ?

Vérifiez et ajustez les paramètres du Horizontal Pod Autoscaler (HPA) : fixez des seuils adaptés à votre application (pas seulement CPU), ajustez minReplicas et maxReplicas, réduisez la fenêtre de stabilisation pour un scale down plus réactif, et si possible utilisez des métriques applicatives comme le nombre de requêtes par seconde.

Quelle stratégie adopter pour l'autoscaling des nœuds dans un cluster Kubernetes ?

Créez plusieurs node pools adaptés aux différents types de workloads (web, worker, ops), préférez plusieurs nœuds moyens (2 à 4 vCPU) plutôt que peu de gros nœuds, évitez les machines premium coûteuses par défaut, et activez la consolidation avec des outils comme Karpenter pour optimiser le bin packing.

Quels sont les avantages d'utiliser des instances spot ou préemptibles dans Kubernetes ?

Les instances spot/préemptibles peuvent réduire les coûts d'infrastructure de 50% à 80%. Bien qu'elles puissent être interrompues, elles sont idéales pour les workloads batch ou tolérants aux interruptions. Leur utilisation judicieuse permet d'importantes économies sans compromettre la stabilité globale.

Quelles actions concrètes puis-je mettre en place immédiatement pour réduire mes coûts Kubernetes ?

Parmi les leviers rapides : ajuster requests/limits selon l'usage réel, corriger la configuration du HPA, segmenter les node pools avec tailles adaptées, utiliser des instances spot là où c'est possible, éteindre les environnements non utilisés et surveiller le trafic inter zones. Ces mesures améliorent aussi souvent la stabilité.