La règle qu’Onicost applique
Chaque conteneur paie le plus haut de sa request et de son usage, minute par minute, au prix unitaire de son nœud, plus les disques qu’il monte. La request compte parce qu’elle réserve de la capacité, même inutilisée. L’usage compte parce qu’un conteneur peut consommer plus que sa request quand le nœud a de la place. Si la somme dépasse le coût du nœud, Onicost réduit les parts en proportion pour retomber sur ce coût.
Sur Fargate, GKE Autopilot et les nœuds virtuels AKS, un workload paie la taille facturée par son fournisseur. Un GPU se paie sur sa request, et un GPU partagé compte pour sa fraction. Ces montants sont des estimations, à partir des prix publics ou de vos propres tarifs pour les nœuds sur site. Le trafic réseau en est exclu.
Les namespaces d’abord, les labels quand ils ne suffisent plus
Un namespace est la clé d’allocation la plus simple quand une seule équipe en est responsable. Les labels prennent le relais quand un namespace héberge plusieurs produits, ou quand un produit s’étend sur plusieurs namespaces. Le projet Kubernetes recommande un jeu de labels commun sous le préfixe app.kubernetes.io, dont app.kubernetes.io/part-of pour rattacher un composant à une application. Les clés comme team ou cost-center restent à votre main : définissez-les une fois pour toutes.
L’explorateur de coûts regroupe par cluster, namespace, workload ou valeur d’une clé de label. Onicost lit les labels de l’objet workload : posez-les sur vos Deployments, StatefulSets et CronJobs, dans vos charts Helm. Pour un workload connu par ses seuls pods, il garde les labels communs à tous ses pods. Le groupe Sans ce label montre ce que votre convention ne couvre pas encore. Servez-vous-en comme mesure de couverture avant de comparer des équipes. L’option exclude.labelKeys du chart retire des clés avant l’envoi : gardez vos clés d’allocation hors de cette liste.
Les coûts partagés gardent leurs propres lignes
Onicost ne répartit pas les coûts partagés sur vos workloads. Chacun garde sa ligne, et l’utilisé plus l’inutilisé donnent le coût total du cluster. Une équipe ne paie donc pas une capacité libre qu’elle n’a jamais demandée, et l’équipe plateforme voit ce qu’elle doit expliquer.
La FinOps Foundation note qu’une pratique débutante envoie souvent ces coûts vers un budget central ou l’équipe plateforme. Elle demande de définir un mécanisme pour chaque poste partagé. Trois choix reviennent : budget central, partage au prorata du coût alloué, partage égal. Appliquez le vôtre sur les exports, car Onicost ne fait pas ce calcul. Un service commun placé dans son namespace, comme un contrôleur d’ingress ou le monitoring, apparaît comme un namespace ordinaire. Voici les lignes à trancher :
- Inutilisé : la capacité des nœuds qu’aucun workload n’a demandée ni utilisée, et les disques qu’aucun workload ne monte.
- Système : les namespaces de Kubernetes lui-même et de l’agent Onicost.
- Plan de contrôle : les frais du cluster, un coût du cluster dans son ensemble.
Du showback au chargeback
Pour le FinOps Framework, la différence principale entre showback et chargeback tient à la formalité. Le showback montre à chaque groupe les coûts de son périmètre, et toute pratique FinOps en a besoin. Le chargeback envoie les dépenses vers les budgets comptables officiels, selon vos règles de comptabilité. Commencez par le showback : chaque équipe lit ses coûts et prend en charge la suite.
Avec Team, vous exportez l’explorateur en CSV et imprimez un rapport de coûts en PDF. Ce rapport donne les coûts par namespace, les workloads les plus chers et la rubrique Qui utilise chaque cluster. Les exports suivent votre découpage par label, pour refacturer un projet ou un client si besoin. Avant un chargeback, convenez avec la finance du traitement des estimations. Avec l’espace Cloud, la vue Kubernetes sur la facture confronte l’estimation des nœuds au coût facturé.
Business ajoute les équipes à périmètre de visibilité. Une équipe limite ce que voient ses membres à ses clusters, namespaces et comptes cloud. Chaque responsable de produit ouvre ainsi les mêmes chiffres, sur son seul périmètre.
Un premier mois d’allocation
Gardez le premier cycle petit. L’offre Free montre les coûts par nœud, workload et namespace sur 31 jours, pour un seul cluster d’au plus 32 cœurs. Team garde 6 mois d’historique à partir de 39 € HT par mois, et Business 13 mois.
- Choisissez une clé de label et un responsable par namespace.
- Lisez le groupe Sans ce label et comblez les plus gros manques.
- Écrivez qui porte les lignes Inutilisé, Système et Plan de contrôle.
- Envoyez à chaque équipe son CSV ou son PDF et notez ses questions.
- Recommencez le mois suivant et comparez.
Questions fréquentes
Onicost répartit-il automatiquement les coûts partagés ?
Non. La capacité inutilisée, les namespaces système et le plan de contrôle restent sur des lignes séparées. Vous choisissez la règle et vous l’appliquez sur les exports.
Que deviennent les workloads sans label ?
Ils tombent dans le groupe Sans ce label quand vous regroupez par cette clé. Leur coût reste visible, et vous savez quels workloads corriger.
Puis-je facturer mes clients avec ces montants ?
Ils servent de base, mais ce sont des estimations. Convenez d’abord avec la finance et vos clients de la règle pour les coûts partagés, puis comparez avec la facture de votre fournisseur.