Un cluster AKS partagé entre cinq équipes, une seule ligne de facturation sur ta note Azure, et personne ne sait qui consomme quoi. Tu reconnais la situation ? C’est le problème numéro un du FinOps appliqué à Kubernetes : la granularité de facturation d’Azure s’arrête au groupe de ressources, alors que la vraie consommation se joue au niveau du pod et du namespace.
Depuis 2026, Azure propose une réponse native à ce problème avec l’add-on AKS Cost Analysis, construit directement sur le projet open source OpenCost. Dans cet article, tu vas voir comment l’activer, comment lire les données qu’il produit, et comment t’en servir pour bâtir un vrai showback ou chargeback entre équipes.
Pourquoi Cost Management seul ne suffit pas sur Kubernetes
Microsoft Cost Management fait très bien son travail au niveau des ressources Azure — VM, disques, load balancers, IP publiques. Le problème, c’est qu’un cluster AKS mutualise ces ressources entre des dizaines d’applications qui n’ont pas le même profil de consommation. Un cluster avec un seul workload, tu peux t’en sortir en lisant directement le coût du groupe de ressources. Dès que plusieurs équipes partagent le même cluster, tu as besoin d’une couche supplémentaire capable de répartir ce coût par namespace, par label, ou par déploiement.
C’est exactement le rôle de l’add-on de cost analysis : il capture la consommation réelle (CPU, mémoire, stockage, réseau) au niveau du pod, puis réconcilie ces données avec ta facture Azure pour obtenir un coût précis et vérifiable — pas une simple estimation proportionnelle au nombre de pods.
Activer AKS Cost Analysis
L’add-on nécessite un cluster en tier Standard ou Premium (pas disponible sur le tier Free). Sur un cluster existant :
az aks update \
--resource-group $RESOURCE_GROUP \
--name $CLUSTER_NAME \
--enable-cost-analysisOu dès la création :
az aks create \
--resource-group $RESOURCE_GROUP \
--name $CLUSTER_NAME \
--location $LOCATION \
--enable-managed-identity \
--generate-ssh-keys \
--tier standard \
--enable-cost-analysisCompte entre 8 et 24 heures avant que les premières données remontent dans le portail. Si tu gères plusieurs clusters dans le même abonnement, il faut activer l’add-on sur chacun individuellement — l’agrégation multi-cluster ne se fait qu’au niveau de la vue Cost Management, pas au niveau de la collecte.
Lire les données : les trois vues Kubernetes de Cost Management
Une fois l’add-on actif, trois nouvelles vues apparaissent dans Cost Management > Cost analysis :
- Kubernetes clusters — coût agrégé par cluster, pour une vue macro rapide
- Kubernetes namespaces — coût agrégé par namespace, tous clusters confondus dans l’abonnement : c’est la vue à utiliser pour du chargeback par équipe si chaque équipe a son namespace
- Kubernetes assets — coût détaillé par ressource individuelle au sein du cluster
Ces vues nécessitent un contrat Enterprise Agreement ou Microsoft Customer Agreement — les autres types d’abonnement Azure n’y ont pas accès pour l’instant. Détail important pour la lecture des chiffres : les coûts se répartissent en quatre catégories bien distinctes.
| Type de charge | Signification |
|---|---|
| Idle charges | Capacité disponible mais non utilisée par aucun workload — ton indicateur numéro un de sur-provisionnement |
| System charges | Capacité réservée par AKS sur chaque nœud pour kubelet et le runtime — incompressible |
| Service charges | Uptime SLA, Microsoft Defender for Containers, et autres services activés sur le cluster |
| Unallocated charges | Coûts qui n’ont pas pu être rattachés à un namespace précis |
Un taux d’idle charges élevé est en général le signal le plus actionnable : ça veut dire que tu payes pour de la capacité réservée que personne n’utilise, et que revoir tes requests/limits ou activer le cluster autoscaler te fera économiser plus vite qu’en négociant une remise.
Aller plus loin : chargeback par équipe avec les tags de node pool
Pour un vrai modèle de chargeback (facturation interne, pas juste de la visibilité), combine la vue namespace avec des tags posés sur tes node pools à la création :
az aks nodepool add \
--resource-group $RESOURCE_GROUP \
--cluster-name $CLUSTER_NAME \
--name teamdata \
--labels team=data cost-center=CC-4471 \
--node-count 3Ces labels remontent dans les rapports personnalisés Cost Management et te permettent de générer un rapport par centre de coût, même quand plusieurs équipes partagent physiquement les mêmes nœuds. Pour la théorie complète du modèle de répartition (showback vs chargeback, gestion des coûts partagés), la documentation officielle Microsoft détaille l’ensemble du sujet : View Kubernetes costs sur Microsoft Learn.
Le socle open source : OpenCost
L’add-on AKS Cost Analysis n’est pas une invention propriétaire de Microsoft — il s’appuie sur OpenCost, un projet incubé par la Cloud Native Computing Foundation devenu le standard de facto pour l’allocation de coûts Kubernetes. L’avantage : si tu es multicloud ou si tu gères aussi des clusters hors Azure, la même logique d’allocation (par namespace, deployment, label) s’applique avec les mêmes concepts, ce qui évite de réapprendre un modèle différent par fournisseur.
Optimiser une fois que tu vois enfin les coûts
Une fois la visibilité en place, les leviers d’optimisation classiques deviennent enfin actionnables avec des chiffres précis à l’appui : réduire les requests/limits surdimensionnés repérés par un fort taux d’idle charges, activer le cluster autoscaler plutôt que sur-provisionner en prévention, basculer les node pools non critiques vers des VM Spot, et migrer de Container Insights vers Prometheus managé pour réduire la facture Log Analytics. Le guide officiel des bonnes pratiques de coût AKS détaille l’ensemble de ces leviers : Best practices for cost optimization in AKS.
FAQ
L’add-on AKS Cost Analysis a-t-il un coût supplémentaire ?
Non, l’add-on lui-même est gratuit. Tu payes uniquement les ressources normales de ton cluster ; ce que tu gagnes, c’est la granularité de lecture, pas un coût additionnel.
Ça fonctionne sur un cluster multi-tenant avec des centaines de namespaces ?
Oui, c’est justement le cas d’usage principal. Plus tu as de namespaces et d’équipes partageant un cluster, plus la valeur de l’outil augmente par rapport à une lecture au niveau du groupe de ressources.
Que faire si mon abonnement n’est pas Enterprise Agreement ou Microsoft Customer Agreement ?
Les vues Kubernetes de Cost Management ne seront pas disponibles pour l’instant. Tu peux dans ce cas déployer OpenCost directement en self-hosted sur ton cluster via Helm, sans dépendre du type de contrat Azure.
Est-ce compatible avec les workloads Kubernetes 1.37 ?
Oui, aucune contrainte de version côté Kubernetes. Si tu as prévu une montée de version prochainement, vérifie d’abord notre article sur les nouveautés de Kubernetes 1.37 pour anticiper d’éventuels impacts sur tes node pools.
En résumé
Le FinOps sur Kubernetes bute presque toujours sur le même mur : une facture globale, aucune granularité. AKS Cost Analysis lève ce mur en quelques heures d’activation, sans agent tiers à maintenir. Si le sujet FinOps t’intéresse plus largement, notre article sur la maîtrise des coûts Azure avec Cost Management complète bien celui-ci côté vision globale de l’abonnement. Prochaine étape logique : active l’add-on sur ton cluster le moins visible côté coûts, et regarde ce que la vue namespace te révèle après 24 heures.
Laisser un commentaire