Une facture cloud Kubernetes arrive par nœud, jamais par équipe ni par application : le fournisseur facture des machines, pas les workloads qui tournent dessus. Sur un cluster partagé par plusieurs équipes, cette réalité transforme une question simple en énigme collective : combien coûte réellement le namespace de l’équipe A par rapport à celui de l’équipe B ?

Le nœud n’est pas l’unité de coût qui compte

Un cluster Kubernetes mutualise ses nœuds entre tous les namespaces qui y tournent : un même nœud héberge simultanément des pods de plusieurs équipes, chacun consommant une fraction de sa capacité. La facture, elle, ne connaît que le nœud dans son ensemble. Répartir ce coût entre les équipes qui le partagent exige un mécanisme d’allocation qui n’existe dans aucune facture cloud brute.

# La facture connaît le nœud, jamais les pods qu'il héberge :
# aucune ligne "namespace X : 340€ ce mois-ci" n'existe nativement
kubectl top nodes

Les requests, proxy imparfait mais seul disponible

La méthode d’allocation la plus répandue répartit le coût d’un nœud entre les pods qu’il héberge au prorata de leurs requests CPU et mémoire (voir l’article sur les requests et limits), pas de leur consommation réelle. Ce choix a une conséquence directe : un namespace qui sur-demande des requests par prudence (sans jamais les consommer réellement) se voit facturer une part disproportionnée du nœud, pendant qu’un namespace bien dimensionné, qui demande juste ce qu’il utilise, paie moins pour un usage équivalent.

# Ce namespace paiera pour 2 CPU demandés,
# même s'il n'en consomme réellement que 200m
resources:
  requests:
    cpu: "2"
    memory: "4Gi"

Ce mécanisme récompense donc, paradoxalement, le sur-dimensionnement prudent au détriment du dimensionnement rigoureux, l’inverse de l’incitation qu’on voudrait créer.

La capacité inutilisée, un coût que personne ne porte

Un cluster dimensionné avec une marge de sécurité (pour absorber les pics, pour laisser de la place au scheduler) paie pour cette marge en continu, qu’elle serve ou non à un instant donné. Cette capacité inutilisée ne s’attribue à aucun namespace en particulier : c’est un coût structurel du cluster entier, souvent invisible dans un tableau de bord qui ne montre que les coûts déjà alloués par équipe, jamais le résidu inutilisé qui reste à la charge de la plateforme.

OpenCost / Kubecost : rendre l’allocation visible

Des outils comme OpenCost (projet CNCF, moteur derrière Kubecost) automatisent cette allocation en croisant les métriques de consommation réelle (via metrics-server ou Prometheus) avec les tarifs du fournisseur cloud, pour produire un coût par namespace, par label, ou par déploiement, actualisé en continu plutôt que reconstruit manuellement à partir de la facture brute une fois par mois.

# Coût alloué par namespace sur les 7 derniers jours,
# reconstruit automatiquement depuis les métriques de conso
kubectl cost namespace --window 7d

Cette visibilité change le comportement en pratique : une équipe qui voit le coût réel de son sur-dimensionnement a un motif concret de le corriger, une information qui n’existe simplement pas sans cet outillage.

À retenir

La facture cloud Kubernetes ne connaît que le nœud, jamais le namespace : sans mécanisme d’allocation dédié, aucune équipe ne peut savoir ce qu’elle coûte réellement sur un cluster partagé. L’allocation par requests (la méthode la plus répandue) récompense paradoxalement le sur-dimensionnement prudent, et la capacité inutilisée du cluster reste un coût structurel sans namespace responsable. Des outils comme OpenCost rendent cette allocation visible en continu, une visibilité qui devient nécessaire dès qu’un cluster mutualisé grandit, un sujet qui s’inscrit dans la continuité d’une migration Kubernetes une fois plusieurs équipes réellement en production.