MÉTHODOLOGIE ÉNERGIE ET CARBONE
Comment GreenKube estime l’énergie et le carbone de Kubernetes.
GreenKube combine la télémétrie CPU et le contexte Kubernetes avec les profils de puissance des instances, l’intensité carbone du réseau et le PUE du centre de données. Il estime l’énergie des nœuds et le CO₂e opérationnel, répartit les résultats entre les workloads et peut inclure une estimation distincte de l’impact incorporé.
Aperçu de la méthode
Des données d’entrée aux estimations par workload.
La méthode suit trois étapes : estimer l’énergie du nœud à partir de l’utilisation CPU et d’un profil de puissance d’instance ; appliquer l’intensité carbone et le PUE pour calculer le CO₂e opérationnel ; puis répartir les résultats entre les workloads. Les données Boavizta facultatives apportent une composante distincte d’impact incorporé.
Prometheus fournit l’utilisation CPU ; les métadonnées Kubernetes des nœuds et des pods apportent le contexte nécessaire aux profils d’instances et à l’allocation des workloads.
Les impacts opérationnels et incorporés sont calculés séparément. OpenCost fournit une vue distincte de répartition des coûts, présentée avec les estimations d’énergie et de carbone.
Sources de données
Les entrées qui composent l’estimation.
La télémétrie CPU de Prometheus et les métadonnées Kubernetes forment la base du modèle opérationnel. Les fournisseurs d’intensité carbone, les profils d’instances et le PUE apportent le contexte géographique et celui des centres de données. Boavizta peut fournir des données de cycle de vie, tandis qu’OpenCost sert à la répartition distincte des coûts. Le tableau résume les rôles, disponibilités et replis documentés.
| Source | Rôle dans la méthode | Disponibilité et repli | Couverture et hypothèses |
|---|---|---|---|
| Prometheus | L’utilisation CPU est la donnée d’activité du modèle d’énergie opérationnelle. D’autres métriques peuvent être collectées sans entrer dans ce calcul. | La couverture dépend des données collectées et de la période choisie. Les valeurs par défaut du modèle sont signalées comme estimées avec leurs motifs. | Les lacunes d’échantillonnage affectent la couverture ; l’utilisation CPU sert à estimer la puissance à partir d’un profil d’instance. |
| API Kubernetes | Les métadonnées des nœuds et les spécifications des pods apportent le contexte des workloads et des instances pour les estimations et leur allocation. | Un contexte manquant ou non pris en charge peut limiter l’attribution ; consultez la documentation pour connaître les champs pris en charge. | Les nœuds partagés et la propriété incomplète affectent la répartition des résultats du nœud. |
| Electricity Maps | Fournisseur par défaut de l’intensité carbone, avec des facteurs dépendant du lieu et du temps. | Si les données du fournisseur sont indisponibles, GreenKube utilise les valeurs intégrées par zone ; en l’absence de valeur de zone, le repli global documenté est de 500 gCO₂e/kWh. | Le résultat dépend de la correspondance de zone et de la fraîcheur des données ; un facteur régional peut différer de l’électricité utilisée dans un centre de données donné. |
| Wattnet | Fournisseur alternatif facultatif d’intensité carbone ; la documentation indique 52 zones européennes à une résolution de 15 minutes. | Le choix du fournisseur et les identifiants dépendent de la configuration ; si les données manquent, suivez le comportement de repli documenté. | Sa couverture géographique, sa résolution temporelle et sa méthode documentées diffèrent de celles des autres fournisseurs. |
| Profils CCF intégrés et PUE | Les profils de puissance statiques des instances alimentent le modèle CPU ; les profils PUE par fournisseur représentent les frais généraux du site. | Pour une instance inconnue, les replis documentés sont un PUE de 1,3, 1 vCore, un minimum de 1 W/vCore et un maximum de 10 W/vCore. Le résultat est marqué comme estimé. | Les profils approchent la puissance des instances ; les profils PUE sont des paramètres propres au fournisseur. |
| API Boavizta | Entrée facultative d’impact incorporé sur le cycle de vie par type d’instance ; les résultats sont mis en cache et restent distincts de l’énergie opérationnelle. | En l’absence de données d’instance, le repli documenté est un impact incorporé de 100 kg et une durée de vie matérielle supposée de 4 ans. | La couverture et les hypothèses de durée de vie et d’allocation façonnent l’estimation de l’impact incorporé. |
| OpenCost | Entrée d’allocation des coûts pour leur visibilité, séparée des équations d’énergie et de carbone. | En l’absence de données OpenCost, le comportement documenté peut produire une valeur de coût égale à zéro. | Les coûts partagés et les règles d’allocation diffèrent de la facturation du fournisseur. |
Modèle d’énergie opérationnelle
Estimer l’énergie du nœud à partir de l’utilisation CPU.
Pour chaque nœud, le modèle interpole linéairement entre les puissances minimale et maximale du profil d’instance à partir de l’utilisation CPU. Il multiplie la puissance estimée par la durée d’observation pour calculer l’énergie, puis répartit l’estimation du nœud entre les workloads selon leur part d’utilisation CPU.
| Étape | Calcul | Interprétation |
|---|---|---|
| Puissance minimale et maximale | P_idle = min_watts × vCPUs ; P_max = max_watts × vCPUs | Les valeurs du profil sont des estimations par vCPU pour le type d’instance ou le profil de repli configuré. |
| Puissance du nœud | P_node = P_idle + (P_max − P_idle) × U | U est le ratio d’utilisation CPU entre 0 et 1 ; l’interpolation linéaire reste une approximation. |
| Énergie du nœud sur la période | E_node = P_node × durée_en_secondes | Le résultat est une énergie en joules pour la fenêtre d’observation choisie. |
| Allocation au pod | E_pod = (cpu_pod / cpu_total_node) × E_node | Répartit l’énergie estimée du nœud entre les workloads selon leur part d’utilisation CPU. |
L’intensité carbone et le PUE du centre de données sont appliqués à l’estimation d’énergie à l’étape suivante pour calculer le CO₂e opérationnel.
Calcul carbone
Convertir l’énergie en CO₂e opérationnel.
Le CO₂e opérationnel combine l’énergie modélisée, l’intensité carbone et le PUE du centre de données. Lorsque les données Boavizta sont disponibles, l’estimation facultative de l’impact incorporé est calculée séparément et ajoutée au total.
| Composante | Calcul documenté | Interprétation |
|---|---|---|
| CO₂e opérationnel | CO₂e_g = E_joules / 3 600 000 × intensité_gCO₂e_par_kWh × PUE | Utilise l’énergie estimée, le facteur d’intensité configuré ou le repli documenté, et le profil PUE. |
| Impact incorporé | (GWP_kg × 1 000 / durée_de_vie_heures) × (durée_pod_secondes / 3 600) × (CPU_pod / CPU_nœud) | Utilise les données d’instance Boavizta disponibles ; le repli documenté est de 100 kg de GWP et une durée de vie de 4 ans. |
| Total combiné | Estimation opérationnelle plus estimation incorporée lorsque cette dernière est disponible | Ajoute l’estimation de l’impact incorporé lorsqu’elle est disponible. |
Les profils PUE des fournisseurs apportent le facteur de frais généraux utilisé dans le calcul opérationnel.
Agrégation
Comment les données deviennent des estimations.
La télémétrie et les données des fournisseurs alimentent le modèle d’énergie du nœud, le calcul carbone et la répartition aux workloads. La répartition des coûts reste distincte.
Télémétrie Prometheus + contexte Kubernetes
Profil d’instance CCF + PUE fournisseur
Intensité réseau Electricity Maps / Wattnet
Données incorporées Boavizta si disponibles
↓
Normalisation des données disponibles
↓
Estimation énergie du nœud / CO₂e
↓
Allocation aux workloads
OpenCost → répartition des coûts séparée
L’utilisation CPU et les profils d’instances produisent l’estimation d’énergie. L’intensité carbone et le PUE la convertissent en CO₂e opérationnel ; les données Boavizta facultatives ajoutent l’impact incorporé. Le contexte Kubernetes et la part d’utilisation CPU servent à répartir les résultats aux workloads, tandis qu’OpenCost fournit une vue distincte des coûts.
Le tableau des sources récapitule les disponibilités et les replis documentés. Les références techniques ci-dessous détaillent la configuration des sources et leur implémentation.
Comportement de repli
Comment les entrées indisponibles sont traitées.
Chaque entrée prise en charge a un repli documenté ou un comportement défini en cas d’absence de données. Le fournisseur configuré et les motifs d’estimation indiquent le chemin utilisé.
- 01
Repli d’intensité carbone
Si l’API d’intensité carbone est indisponible, GreenKube utilise une valeur intégrée par zone ; sans valeur de zone, le repli global documenté est de 500 gCO₂e/kWh.
- 02
Profil d’instance inconnu
Les replis documentés sont un PUE de 1,3, 1 vCore, un minimum de 1 W/vCore et un maximum de 10 W/vCore. Les métriques portent is_estimated et estimation_reasons.
- 03
Données d’impact incorporé manquantes
Le repli Boavizta documenté est de 100 kg d’impact incorporé par instance avec une hypothèse de durée de vie matérielle de 4 ans ; le résultat reste modélisé.
- 04
Données d’allocation des coûts manquantes
En l’absence de données OpenCost, le comportement documenté peut produire une valeur de coût égale à zéro ; vérifiez la disponibilité des données avant d’interpréter cette valeur.
Exemple de calcul
Un calcul détaillé avec les valeurs de repli documentées.
Cet exemple associe le profil documenté d’instance inconnue, un PUE de 1,3 et une intensité globale de 500 gCO₂e/kWh à une utilisation CPU de 50 % pendant une heure pour illustrer le calcul.
| Étape | Entrées | Résultat |
|---|---|---|
| Puissance estimée du nœud | 1 W + (10 W − 1 W) × 0,5 | 5,5 W |
| Énergie sur une heure | 5,5 W × 3 600 secondes | 19 800 J = 0,0055 kWh |
| Estimation du CO₂e opérationnel | 0,0055 kWh × 500 gCO₂e/kWh × 1,3 PUE | 3,575 gCO₂e pour la période modélisée du nœud |
Le résultat opérationnel est de 3,575 gCO₂e pour la période illustrée du nœud. L’impact incorporé n’est pas inclus ; les valeurs des workloads sont réparties à partir de l’énergie du nœud selon la part d’utilisation CPU.
Références techniques
Explorer les détails d’implémentation.
La documentation technique détaille les équations, les sources prises en charge, la configuration des fournisseurs et les comportements de repli présentés sur cette page.
Consultez ces références pour examiner le comportement de l’implémentation et configurer les sources utilisées par un déploiement.
Limites
Périmètre des estimations et points de vigilance.
Ces limites précisent les entrées du modèle et la manière d’interpréter un résultat au regard de la couverture des sources.
Modèle énergétique fondé sur le CPU
L’énergie du nœud est estimée en interpolant l’utilisation CPU entre les valeurs minimale et maximale du profil d’instance. Il ne s’agit pas d’une lecture directe de la puissance du matériel, du nœud, du conteneur ou du pod ; la mémoire, le réseau, le disque et le GPU n’entrent pas dans le calcul énergétique actuel.
Allocation aux workloads
L’énergie et le CO₂e des workloads sont répartis à partir des estimations du nœud selon la part d’utilisation CPU. L’infrastructure partagée, la propriété incomplète, les lacunes d’échantillonnage, les hypothèses de profil, la fraîcheur des sources, la correspondance géographique et le PUE influent sur les résultats.
Sources d’intensité carbone
Les données des fournisseurs et les replis documentés ne représentent pas le mix électrique exact d’un site. Wattnet documente 52 zones européennes à une résolution de 15 minutes ; les autres fournisseurs diffèrent par leur couverture, fraîcheur et méthode. Une source absente ne signifie pas une énergie ou des émissions nulles.
Profils d’instances et PUE
Les profils d’instances approchent la puissance et les profils PUE des fournisseurs apportent les frais généraux du site. La documentation présente actuellement des valeurs PUE OVH contradictoires dans deux sections ; cette page ne publie donc pas de valeur propre à OVH.
Estimation de l’impact incorporé
La composante facultative utilise les données d’instance Boavizta ou le repli documenté de 100 kg sur quatre ans. Elle ne constitue pas un inventaire complet des services cloud, des étapes du cycle de vie ou des émissions d’une organisation.
Coûts et résultats observés
OpenCost est une entrée distincte de répartition des coûts ; en l’absence de données, une valeur nulle peut apparaître. Une réduction projetée ne démontre pas une baisse d’électricité ni des économies réalisées : comparez les signaux après changement et rapprochez les coûts de la facturation du fournisseur.