Pourquoi Kubernetes cache les coûts
Sur AKS ou EKS, la facture du cloud montre des machines virtuelles : les nœuds. Elle ne dit pas quelle application consomme quoi. Sans outil d'allocation, un cluster partagé devient une boîte noire, et personne ne se sent responsable de son coût.
Étape 1 : allouer les coûts
- Un namespace par application, ou un label application reprenant le tag de la CMDB.
- Un outil d'allocation : OpenCost (open source, projet de la CNCF), Kubecost, ou l'analyse de coûts intégrée à AKS.
- Une part des coûts partagés (system pods, capacité inutilisée) répartie selon une règle claire. Les dernières versions du format FOCUS prévoient justement ce découpage.
Étape 2 : ajuster les requests
Le scheduler place les pods selon leurs requests de CPU et de mémoire, pas selon leur usage réel. Des requests trop généreuses obligent à ajouter des nœuds pour rien. Comparez requests et usage réel (en P95) sur plusieurs semaines, et ajustez, par exemple avec les recommandations du Vertical Pod Autoscaler.
Étape 3 : adapter les nœuds à la charge
- Autoscaling des nœuds : cluster autoscaler sur AKS, Karpenter ou cluster autoscaler sur EKS.
- Des node pools adaptés : tailles de VM cohérentes avec les pods, pour limiter la capacité perdue.
- Spot pour les workloads sans état et interruptibles, surtout en non-prod.
- Réservations ou savings plans pour la base de nœuds qui tourne en permanence.
Étape 4 : éteindre la non-prod
Un cluster de développement ou de recette n'a pas besoin de tourner la nuit et le week-end. AKS permet d'arrêter un cluster complet ; on peut aussi réduire les node pools à zéro hors des heures d'usage. C'est le même principe que le Stop/Start des VM.
Ce qu'il faut suivre
| Indicateur | Ce qu'il révèle |
|---|---|
| Requests / usage réel | Le surdimensionnement des pods |
| Taux de remplissage des nœuds | La capacité payée mais inutilisée |
| Coût par namespace | Qui consomme quoi |
| Part de Spot et de capacité réservée | L'efficacité du rate optimization |