Dépôt GitHub officiel : github.com/opencost/opencost
Page officielle CNCF (Incubating) : cncf.io/projects/opencost • Site : opencost.io

L’adoption massive de Kubernetes pour orchestrer à la fois des microservices critiques, des pipelines de données et des charges d’inférence IA a créé un angle mort financier majeur : la boîte noire des coûts partagés. Lorsqu’un cluster mutualise des dizaines de namespaces, des pools de nœuds autoscalés (Karpenter / Cluster Autoscaler), des volumes persistants (CSI), des LoadBalancers et des GPU fractionnés (MIG / Time-Slicing), la facture globale du fournisseur Cloud (AWS, Azure, GCP, Scaleway) ou le coût d’amortissement du matériel Bare-Metal ne dit absolument pas qui consomme quoi, ni quelle part de la dépense correspond à du gaspillage pur (idle resources et sur-allocation des requests).

C’est précisément ce problème que résout OpenCost, le moteur de mesure et d’allocation des coûts Kubernetes open-source devenu la référence industrielle au sein de la Cloud Native Computing Foundation (CNCF).

1. Pourquoi la reconnaissance d’OpenCost par la CNCF change la donne

Initialement né chez Kubecost puis reversé à la communauté sous licence Apache 2.0, OpenCost n’est pas un simple outil de tableau de bord : il est à la fois une spécification mathématique ouverte (le standard de calcul FinOps pour conteneurs) et une implémentation de référence en Go.

Son parcours au sein de la Cloud Native Computing Foundation (fiche officielle CNCF) témoigne de sa maturité technique et de sa neutralité industrielle :

1. Juin 2022 : Entrée en CNCF Sandbox : Création d’une spécification ouverte soutenue par AWS, Google Cloud, Microsoft Azure, Adobe, SUSE et Pixie.
2. Octobre 2024 : Promotion au rang de projet CNCF Incubating : Après un audit de sécurité complet et l’adoption en production par des milliers d’entreprises, le Technical Oversight Committee (TOC) de la CNCF valide le passage d’OpenCost en Incubating (voir la page officielle CNCF d’OpenCost).
3. Janvier 2026 : Convergence FOCUS & Serveur MCP natif : En 2026, OpenCost intègre nativement l’export au format FOCUS (FinOps Open Cost and Usage Specification), le suivi énergétique Carbon/Kepler, la télémétrie GPU NVIDIA DCGM et même un serveur MCP (Model Context Protocol) permettant aux agents SRE d’interroger les dérives budgétaires en langage naturel.

Choisir un projet CNCF Incubating comme OpenCost garantit trois piliers essentiels pour un architecte Cloud :

• Zéro verrouillage éditeur (Vendor Lock-in) : La gouvernance appartient à la Linux Foundation / CNCF.
• Interopérabilité native avec Prometheus : OpenCost s’intègre comme un citoyen de première classe dans la pile d’observabilité existante (kube-state-metrics, cAdvisor, node-exporter, VictoriaMetrics, Thanos ou Mimir).
• Facturation réelle multi-cloud & On-Premise : Connexion directe aux API de tarification temps réel (AWS Cost & Usage Report / Spot Feed, Azure Billing RateCard, GCP Cloud Billing) ET prise en charge de grilles tarifaires personnalisées (JSON/CSV) pour les datacenters privés ou homelabs Bare-Metal.

2. Architecture interne : Comment OpenCost calcule le coût exact d’un Pod

Contrairement aux outils naïfs qui se contentent de multiplier la requête CPU d’un Pod par un tarif arbitraire, OpenCost réconcilie en continu trois sources de vérité :

┌─────────────────────────────────────────────────────────────────────────┐
│                    SOURCES DE TÉLÉMÉTRIE & FACTURATION                  │
│  ┌──────────────────────┐  ┌──────────────────────┐  ┌───────────────┐  │
│  │ Kubernetes API       │  │ Prometheus / Mimir   │  │ Cloud Billing │  │
│  │ Pods, Nodes, PVCs,   │  │ cAdvisor, KSM,       │  │ AWS CUR, GCP, │  │
│  │ Labels, DaemonSets   │  │ NVIDIA DCGM Exporter │  │ Azure, Custom │  │
│  └──────────┬───────────┘  └──────────┬───────────┘  └───────┬───────┘  │
└─────────────┼─────────────────────────┼──────────────────────┼──────────┘
              │                         │                      │
              ▼                         ▼                      ▼
┌─────────────────────────────────────────────────────────────────────────┐
│                     MOTEUR D'ALLOCATION OPENCOST (Go)                   │
│  • Coût par ressource = MAX(Usage réel P95/Moy, Request réservée)       │
│  • Répartition de l'Idle Node Cost (CPU/RAM non alloués mais payés)     │
│  • Imputation du stockage (PV/PVC), Egress réseau & LoadBalancers       │
│  • Agrégation dynamique : Namespace, Deployment, Label, Team, Service   │
└─────────────┬─────────────────────────┬──────────────────────┬──────────┘
              │                         │                      │
              ▼                         ▼                      ▼
     ┌─────────────────┐       ┌─────────────────┐    ┌──────────────────┐
     │ Métriques Prom  │       │ API REST / UI   │    │ Serveur MCP &    │
     │ /metrics (:9003)│       │ Allocation/Cloud│    │ Export FOCUS/CSV │
     └─────────────────┘       └─────────────────┘    └──────────────────┘

La formule fondamentale d’allocation (Usage vs Request)

Sur Kubernetes, un conteneur bloque des ressources dès qu’il définit des requests, mais peut consommer davantage jusqu’à ses limits. Si vous ne facturez que l’usage réel, une équipe qui réserve 16 vCPU et 64 GiB de RAM pour n’en utiliser que 2 % empêche l’ordonnanceur (kube-scheduler) d’y placer d’autres charges tout en payant une facture dérisoire.

La spécification OpenCost résout cette asymétrie en prenant le maximum entre la ressource réservée (request) et la ressource réellement consommée (usage) sur chaque fenêtre temporelle $\Delta t$ :

$$\text{Coût CPU}_{\text{conteneur}} = \max\left(\text{CPU}_{\text{request}}, \text{CPU}_{\text{usage}}\right) \times \text{Durée} \times \text{Prix horaire du vCPU sur ce Nœud}$$

$$\text{Coût RAM}_{\text{conteneur}} = \max\left(\text{RAM}_{\text{request}}, \text{RAM}_{\text{usage}}\right) \times \text{Durée} \times \text{Prix horaire du GiB sur ce Nœud}$$

La différence entre la capacité totale facturée par les nœuds du cluster et la somme des allocations des Pods constitue le coût Idle (inactif), qu’OpenCost peut soit isoler dans une ligne __idle__, soit redistribuer proportionnellement à chaque namespace.

3. Déploiement déclaratif via Helm et connexion à Prometheus

Le déploiement d’OpenCost en production est remarquablement léger : un unique Deployment contenant le binaire serveur (opencost) et l’interface web (opencost-ui), sans base de données propriétaire lourde à maintenir.

# Ajout du dépôt Helm officiel OpenCost
helm repo add opencost https://opencost.github.io/opencost-helm-chart
helm repo update

# Installation dans le namespace opencost connecté à votre Prometheus existant
helm upgrade --install opencost opencost/opencost \
  --namespace opencost --create-namespace \
  --set opencost.prometheus.internal.serviceName=prometheus-server \
  --set opencost.prometheus.internal.namespaceName=monitoring \
  --set opencost.prometheus.internal.port=80 \
  --set opencost.ui.enabled=true \
  --set opencost.mcp.enabled=true

Configuration d’une grille tarifaire Bare-Metal / On-Premise (default.json)

Pour les clusters auto-hébergés (Proxmox, Talos Linux, Bare-Metal) où aucune API de facturation AWS/GCP n’existe, OpenCost permet d’injecter le coût d’amortissement matériel réel et le tarif électrique via customPricing :

# values-onprem.yaml
opencost:
  customPricing:
    enabled: true
    provider: custom
    costModel:
      description: "Tarification Bare-Metal amortie sur 36 mois + kWh Datacenter"
      CPU: "0.024"          # $ / vCPU / heure
      spotCPU: "0.010"
      RAM: "0.0032"         # $ / GiB / heure
      spotRAM: "0.0015"
      GPU: "0.85"           # $ / GPU / heure
      storage: "0.00012"    # $ / GiB / heure (NVMe Ceph / Longhorn)
      zoneNetworkEgress: "0.01"
      regionNetworkEgress: "0.01"
      internetNetworkEgress: "0.05"

4. Requêtes PromQL et API d’Allocation FinOps

Dès son démarrage, OpenCost expose sur son port :9003/metrics des métriques Prometheus enrichies (node_cpu_hourly_cost, node_ram_hourly_cost, container_cpu_allocation, container_memory_allocation_bytes, pod_pvc_allocation) qui permettent d’écrire des règles d’alerte ou des tableaux Grafana immédiats.

Exemple 1 : Coût mensuel projeté par Namespace en PromQL pur

sum by (namespace) (
  (
    container_cpu_allocation
    * on(node) group_left() node_cpu_hourly_cost
  )
  +
  (
    (container_memory_allocation_bytes / 1024 / 1024 / 1024)
    * on(node) group_left() node_ram_hourly_cost
  )
) * 730

Exemple 2 : Interrogation de l’API REST /allocation/compute

L’API HTTP d’OpenCost (port :9090) effectue pour vous la jointure complète (CPU, RAM, GPU, PV, réseau, LoadBalancers et partage de l’Idle) :

curl -sG "http://localhost:9090/allocation/compute" \
  --data-urlencode "window=7d" \
  --data-urlencode "aggregate=namespace,label:app.kubernetes.io/part-of" \
  --data-urlencode "includeIdle=true" \
  --data-urlencode "shareIdle=false" | jq '.data[0]'

Cette requête retourne instantanément, pour chaque namespace et chaque application, le coût CPU, RAM, GPU, PersistentVolume, ainsi que le score d’efficience (totalEfficiency) qui révèle en un coup d’œil les déploiements sur-dimensionnés (par exemple une efficience de 0.12 signifie que 88 % des ressources réservées dans le manifeste YAML dorment inutilement).

5. Synthèse : Pourquoi adopter OpenCost dès aujourd’hui

Pour explorer le code source, contribuer ou déployer le chart Helm officiel :

• GitHub OpenCost : https://github.com/opencost/opencost
• Page du projet sur la CNCF : https://www.cncf.io/projects/opencost/
• Documentation & Spécification FinOps : https://www.opencost.io/docs/