Mesurer la consommation énergétique de vos applications sur Kubernetes

La mesure de la consommation énergétique des applications est un sujet d’actualité, d’une part pour en prendre conscience et d’autre part pour pouvoir l’optimiser. Dans cet article, nous allons présenter Scaphandre, un outil open source répondant à cette problématique de mesure, et son utilisation dans un contexte Kubernetes Kosmos.

Présentation de Scaphandre

Scaphandre est un projet open source sous licence Apache 2.0 qui a gagné en popularité avec plus de 1.3k stars sur GitHub fin 2023. Cet outil est créé et maintenu par @bpetit ainsi que d’autres contributeurs. Il est écrit en Rust.

Scaphandre a pour objectif d’initier la collaboration entre les sociétés de la tech et les enthousiastes du sujet autour d’un moyen simple, robuste, léger et clair de mesurer la consommation énergétique dans le but de prendre des décisions éclairées. (Source)

Pour cela, Scaphandre accède aux fichiers de métriques localisés dans /sys/class/powercap, /proc/stats et /proc/{PID}/stats. Cela lui donne accès à la consommation instantanée du serveur et la répartition par processus. Pour plus d’informations, veuillez consulter la documentation du projet.

En plus de la collecte des mesures, l'un des points forts de Scaphandre est sa capacité à exposer des métriques Prometheus. Cela permet de s’intégrer parfaitement à la stack d’observabilité. Voici le dashboard exemple du projet :

Dashboard exemple du projet Scaphandre

Sur ce dashboard, nous visualisons la puissance électrique consommée par les processus de la machine sur laquelle Scaphandre est installé, ainsi que sa conversion en quantité d’énergie consommée sur des intervalles de temps.

Pour résumer, Scaphandre offre les fonctionnalités suivantes :

• Récupération de la consommation du serveur en watt par le biais de capteurs,
• Répartition de cette consommation sur les processus tournant sur le serveur,
• Exportation des métriques sur un port au format Prometheus (parmi d’autres).

Cependant, Scaphandre vient avec quelques contraintes, liées, notamment, aux capteurs implémentés : 

• La compatibilité des capteurs avec les machines hôtes.
• Le scope de composants (RAM/CPU) observés diffère en fonction des capteurs, et des machines utilisées.
• Les capteurs ont besoin d'accéder à des fichiers système dans /proc/ et /sys/. Cet accès n’est possible que sur les machines qui vous appartiennent généralement, surtout pour /sys/, sauf si votre cloud provider partage les métriques de l’hyperviseur aux instances, grâce à la propagation des métriques.

Installation sur le cluster Kubernetes

Pour utiliser Scaphandre dans un contexte Kubernetes, nous avons besoin d’un cluster qui répond aux contraintes que nous venons d’évoquer. Nous avons utilisé la solution Kosmos de Scaleway qui nous permet de facilement créer un cluster Kubernetes avec un nœud Elastic Metal qui permettra à Scaphandre d’obtenir les mesures.

Prérequis

Afin de pouvoir déployer Scaphandre dans un environnement Kubernetes Scaleway, vous devez avoir coché ces prérequis :

• Disposer d’un cluster Kosmos
  • How to create a Kubernetes Kosmos cluster
• Disposer d’un ou plusieurs nœuds Elastic Metal server compatible Scaphandre
  • Compatibilité du noeud avec Scaphandre
  • How to create an Elastic Metal server
• Le ou les nœuds Elastic Metal server sont liés au cluster Kosmos par un groupe de nœuds multi-cloud.
  • Ajouter un noeud externe dans un groupe de noeuds multi-cloud
• Disposer d’un environnement local pour effectuer des opérations :
  • Outils
    • Git
    • Helm
  • Moyens
    • Connexion Kube-api-server (kubeconfig) au cluster Kosmos.
    • Droits étendus sur le cluster.

Workarounds

Pour notre POC, nous avons utilisé la branche développement de Scaphandre, nous avons dû effectuer des actions manuelles afin de contourner des issues ouvertes sur le projet :

• La chart Helm de Scaphandre ne permet pas encore de spécifier des labels additionnels sur l’objet ServiceMonitor, ce qui pose un problème avec la kube-prometheus-stack déployée en mode “par défaut” :
  • Pull request ouverte
  • Solution : Rajouter le label release: kube-prometheus-stack à la main sur l’objet déployé, ou dans la Chart avant déploiement.

Manifeste de l’objet ServiceMonitor avec le label “release: kube-prometheus-stack”

• L’option –containers de Scaphandre ne fonctionne pas dans notre contexte.
  • But : Cette option permet d’ajouter des labels sur les métriques Prometheus permettant d’identifier l’origine des métriques dans un contexte Kubernetes (namespace, nom du nœud, nom du pod) 
  • Solution : Attendre une correction de l’Issue pour accéder à la fonctionnalité.

• NodeAffinity pas encore supportée dans la Chart actuelle.
  • Solution : Optionnel, détaillée dans un paragraphe suivant.

Déployer Kube Prometheus Stack

Premièrement, il nous faut une pile d’observabilité sur le cluster. Nous allons utiliser  kube-prometheus-stack qui simplifie grandement l’accès à prometheus et grafana :

helm repo add prometheus-community 
https://prometheus-community.github.io/helm-charts
helm repo update
helm install kube-prometheus-stack 
prometheus-community/kube-prometheus-stack --namespace observability

Déployer Scaphandre

Ensuite nous déploierons Scaphandre dans notre cluster via la Chart du projet : 

git clone https://github.com/hubblo-org/scaphandre
git switch dev
cd scaphandre
helm install scaphandre helm/scaphandre \
--set serviceMonitor.enabled=true \
--set serviceMonitor.namespace=observability \
--set serviceMonitor.interval=30s \
--namespace observability

Déployer une application à monitorer

Pour réaliser nos tests, nous avons besoin d’une application pour mesurer sa consommation, idéalement avec plusieurs pods pour avoir de belles visualisations. Nous avons choisi de déployer dans le cluster l’application microservice démo de Google online boutique.

[Optionnel] Déployer Scaphandre uniquement sur certains nœuds.

Peut-être n’aurez vous pas besoin de déployer Scaphandre sur tous vos nœuds ? ; 

Cas : 

• Pour les Nœuds ne répondant pas aux prérequis,
• Par souhait d’utiliser uniquement quelques nœuds pour monitorer avec Scaphandre. 

Cette partie optionnelle répond à ce type de besoin.

En utilisant le même principe que décrit ici, vous pouvez labelliser le nœud Scaleway dédié de cette manière : 

kubectl get nodes 

Identifiez les nœuds répondant aux prérequis puis appliquez un label :

kubectl label nodes scw-k8s-metal-pool-metal-{ID} powercap_rapl=true

Cette labellisation vous permet de conditionner le déploiement de Scaphandre et de vos applications à surveiller.

Pour Scaphandre, en fonction de la version actuelle, vous pourriez avoir à rajouter également la sélection de nœuds dans le template du DaemonSet de la Helm chart avant de faire le déploiement.

Suggestion de changement pour l’objet DaemonSet de Scaphandre

Vous aurez à faire le même type de manipulation pour toutes les applications que vous souhaitez mettre sous le radar de Scaphandre, en utilisant : 

• NodeSelector
• NodeAffinity (sur le label du nœud)
• PodAffinity (sur la présence d’un pod Scaphandre)

Mesure de la consommation énergétique

Maintenant que nous avons notre contexte Kube Scaphandre fonctionnel, avec notre stack d’observabilité et notre application témoin, nous pouvons passer à l’objectif de cet article : tenter de “mesurer” la consommation énergétique de notre application.

Les métriques de Scaphandre

Tout d’abord, faisons une mise au point sur les deux métriques principales exposées par Scaphandre : scaph_host_power_microwatts et scaph_process_power_consumption_microwatts.

La première donne en temps réel la puissance en watt consommée par la machine. La seconde donne la puissance en watt en temps réel pour chaque processus, il y a une valeur par PID de la machine. 

Enrichir les métriques avec les prises en compte du PUE 

Ces données brutes ne reflètent pas directement la puissance nécessaire pour faire fonctionner le CPU. Pour essayer de coller le plus possible à la réalité, nous multiplions les métriques Scaphandre par le PUE (Power Usage Effectivness, ratio entre la puissance totale consommée par le datacenter et la partie qui est effectivement consommée par les systèmes informatiques). Nous obtenons alors une mesure de la puissance consommée par notre serveur et les processus tournant dessus relativement proche de la réalité.

Visualisation sur Grafana

Les mesures que nous avons sont sous forme de métriques Prometheus, nous pouvons donc facilement les visualiser sur Grafana :

1ère ligne : Puissance consommée par l'application

2ème ligne : Énergie consommée par l'application sur différents intervalles de temps

Sur cette première visualisation, nous montrons l’évolution de la puissance consommée en Watt par notre application onlineboutique. De cette mesure de puissance, nous pouvons obtenir l’énergie en watt-heure sur différents intervalles de temps.

Scaphandre s’il est déployé avec l’option –containers et qu'il est installé sur un nœud Kubernetes, enrichi ses métriques avec le nom et le namespace du pod, ce qui rend très facile le filtrage par namespace ou pod. Ici, nous visualisons la puissance consommée par chaque pod du namespace onlineboutique.

Puissance consommée par chaque pod du namespace onlineboutique

Ces visualisations sont très intéressantes et permettent d’extraire pas mal d’informations : le micro-service qui consomme le plus, l’impact des pics de charges, l’évolution suite à une release, et d’autres.

Les émissions équivalent CO₂

Pour aller plus loin, il est connu qu’un des premiers gestes GreenOps à mettre en place est de faire tourner les processus lourds (comme des entraînements ML ou des migrations databases) à des moments de la journée où l’électricité à une faible intensité carbone (gCO₂eq/kWh). C’est le principe des heures creuses et des heures pleines que nous connaissons tous. Il est possible de rajouter cette notion dans notre dashboard de mesure de la consommation de notre application. Nous rajoutons une métrique Prometheus de l’intensité carbone de la France, grâce à l’API d’ElectricityMaps et en multipliant cette métrique avec la métrique de Scaphandre (avec la prise en compte de PUE), nous obtenons l’équivalent CO₂ de notre application. Le code utilisé pour créer la métrique d’intensité carbone peut être trouvée dans ce référentiel. On remarque par exemple qu’à consommation électrique constante, les émissions d’équivalent CO₂ ne sont pas constantes et varient en fonction de l’intensité carbone.

1ère ligne : Intensité carbone récupérée sur le site ElectricityMaps

2ème ligne : Consommation (électrique et CO2eq) de l’application onlineboutique

Pour sensibiliser les équipes, nous pourrions même continuer les équivalences en parlant en heures de lampe allumée ou en km de voitures parcourus.

Limitation de la mesure

La mesure de la consommation énergétique d’une application est complexe et nous sommes arrivés à des métriques qui sont satisfaisantes pour nous, elles n’en restent pas moins limitées sur certains points. 

Tout d’abord au niveau des métriques exposées par Scaphandre. Scaphandre utilise des fichiers de métriques qui mettent à disposition les mesures du capteur RAPL (Running Average Power Limit). Ce capteur est le plus communément utilisé, mais présente des limitations comme expliqué dans cet article de Boavizta qui compare une mesure au niveau châssis et la mesure du capteur RAPL au niveau système. La plus grosse limitation étant que RAPL ne prend en compte que le CPU et donc omet la consommation des autres composants : SSDs, GPUs, etc.

Ensuite au niveau de notre prise en compte du PUE. Le PUE (Power Usage Effectivness) est une mesure au niveau du datacenter et ne représente pas nécessairement le ratio entre la puissance totale consommée et celle effectivement consommée par le CPU de notre serveur.

Conclusion

Après avoir expérimenté Scaphandre, nous trouvons que ce projet répond bien à la promesse de départ, à savoir mesurer la consommation énergétique des applications sur Kubernetes. Nous avons essayé de montrer à travers nos différentes visualisations que son utilisation permet d’intégrer la notion de consommation énergétique, à la fois pour sensibiliser, mais aussi pour orienter les prises de décisions qui visent à réduire cette consommation.

À ce jour, Scaphandre vient avec des contraintes fortes pour pouvoir fonctionner. Notamment l’accès au capteur RAPL. Celui-ci n’étant pas propagé, par défaut, d’un hyperviseur aux machines virtuelles ; les instances des clouds providers ne peuvent pas utiliser les métriques. Nous ne pouvons qu’espérer qu’un travail conjoint entre les clouds providers et le projet Scaphandre permettra à l’avenir d’accéder aux métriques depuis des instances virtualisées. Pour que celà arrive, chez Scaleway, vous pouvez up-voter cette feature request.

Scaphandre est un projet open source qui sert la transparence énergétique par l’observabilité. Le projet est ouvert aux contributeurs sous plusieurs formes, visualisez le guide de contribution à votre disposition, ne sous-estimez pas votre impact 🙂

Retrouvez cet article en anglais sur le blog de Scaleway.