Le green IT, c’est bien. Travailler sur sa façon de concevoir et d’utiliser des logiciels en ayant en tête les questions d’environnement et de développement durable, on commence à comprendre l’idée. Quand bien même ça n’apparait pas toujours dans les critères principaux du développement ou du déploiement d’une solution, le sujet se répand et aujourd’hui la plupart des personnes qui travaillent dans le domaine de l’ingénierie logicielle connaissent ce principe (pour ce qui est d’avoir des convictions sur le sujet, c’est propre à chaque individu, en tout cas ça met un peu de temps à faire consensus). En parallèle, on constate également une utilisation croissante des services de Cloud Computing, qui permettent en général de faire des économies sur les coûts d’hébergement et d’apporter de nouvelles fonctionnalités aussi bien aux équipes de développement, qu’aux organisations qui s’en servent.
Problème : bien souvent, ces solutions Cloud sont une boîte noire et au-delà de la facture correspondant aux ressources utilisées, il est à minima difficile d’en savoir plus sur la façon dont fonctionnent les fournisseurs de service Cloud, notamment sur le sujet du green IT. Parce que oui, si vous passez des heures à retravailler et limiter vos requêtes, que vos fonctionnalités sont sobres mais que l’hébergement Cloud que vous utilisez a pour principale source d’énergie une centrale à charbon, c’est pour le moins dommage. De même, si vos instances sont montées en permanence alors qu’elles connaissent des périodes de moindre utilisation (voire d’absence totale), on perd un peu de l’intérêt du green IT. Et enfin, il n’est pas toujours facile de se faire entendre sur ces questions, surtout quand les objectifs (de sprint, de produit, de politique d’entreprise) sont plus focalisés sur la performance économique que sur la préservation de la planète.
Aujourd’hui, l’objectif est donc d’aborder ces différents sujets. D’une part, comment améliorer la consommation de ressources d’un cluster Cloud et de l’autre, comment adapter les KPI traditionnels, prisés par les directions financières, afin de les mettre au service d’une cause plus grande.
« C’est pas Versailles ici », ou comment optimiser son Cloud
Si la lecture du titre de cette partie vous a rappelé des souvenirs ou que vous vous êtes vous-même surpris ou surprise à prononcer ces mots, ces quelques paragraphes devraient vous parler. En effet, alors qu’on éteint la lumière lorsqu’on quitte une pièce, comment justifier de laisser des ressources informatiques allumées en continu, même lorsqu’elles ne sont pas utilisées ? Prenons l’exemple de vos environnements de recette et de développement : en dehors des heures de bureau, y a-t-il le moindre intérêt à les faire fonctionner, si ce n’est brûler (littéralement) du gaz et remplir les poches de Google et Amazon ? Des améliorations concrètes et rapides sont donc faciles à aller chercher (dans un premier temps). C’est le service que propose Kube-green, plug-in rapide à mettre en place (en 30 minutes c’est largement fait) et diablement efficace. Dans l’exemple qu’on trouve dans leur documentation, la mise en place d’une gestion très simple d’un cluster permet de réduire de près de 30% les émissions de gaz à effet de serre (GES) et jusqu’à 37% sur un cluster plus important. Rendez-vous compte : cela fait plus d’un tiers d’économie en quelques réglages.
Remarque : le calcul de l’empreinte carbone se base sur un article rédigé par GoClimate et qui donne des estimations en fonction du type d’hébergement choisi.
OK, qu’est-ce que ça donne concrètement ?
Pour le tester, j’ai démarré un cluster Kubernetes en local, sur lequel j’ai créé un namespace, au sein duquel j’ai déployé une API, un front et une base de données. Ensuite, il m’a de lancer cette commande :
kubectl apply -f https://github.com/kube-green/kube-green/releases/latest/download/kube-green.yaml
Après quelques secondes, Kube-green était déployé dans mon cluster, au niveau global. J’ai ensuite appliqué ce fichier, dans le même namespace où j’ai déployé mes applications.
apiVersion: kube-green.com/v1alpha1 kind: SleepInfo metadata: name: sleep-test Namespace: app-example spec: weekdays: "*" sleepAt: "*:*/5" wakeUpAt: "*:*/7"
Dans celui-ci est écrit que je souhaite scale down tous les déploiements de ce namespace, tous les jours, à chaque 5ème minute de chaque heure et de la même manière, scale up à chaque 7ème minute (l’exemple n’a pas vraiment de sens, il s’agit là plutôt d’illustrer la syntaxe, il y a évidemment d’autres manières de configurer cette partie). On peut décider d’ignorer certaines ressources, ou de stopper également ou uniquement des cronjobs. Vous pouvez trouver ces informations dans la doc de Kube-green, que l’on peut remercier pour sa clarté. Si on observe les Pods du namespace ,on voit bien qu’ils se coupent et s’allument comme désiré :
Certes, cette solution n’est qu’un début, mais pourquoi ne pas aller plus loin ? On peut imaginer répliquer ce système pour ajouter les jours fériés, les pauses-repas, et ensuite en production, en adaptant le nombre de nœuds disponibles en fonction de l’activité prévue.
Il existe encore d’autres solutions, comme KEDA, qui permettent d’être encore plus flexible dans les choix de scalabilité. Cet outil, en plus de reprendre les fonctionnalités de Kube-green, permet d’allumer et d’éteindre nos composants Kubernetes en suivant des métriques que vous pouvez personnaliser à volonté, au lieu de vous baser sur des métriques classiques, comme le niveau d’activité du CPU ou de la RAM. On peut imaginer scale sur un indicateur qui mesure le trafic, ou bien qui va chercher des informations en base de données. Par exemple une quantité de data à intégrer, ou encore une métrique personnalisée qui remonterait la consommation en euros (ou en CO2 😉) pour les limiter. KEDA est certes plus compliqué à mettre en place et à tester mais il vaut le coup qu’on s’y intéresse.
C’est bien beau vos histoires mais comment je vends ça moi ?
Ce qui est certain c’est qu’aujourd’hui les directions financières ont un objectif sur les questions d’argent plutôt que sur celles de la biodiversité ou de la sobriété énergétique (et en même temps, tant qu’on les appellera des directions financières…). C’est pour ça qu’il va falloir ruser : plutôt que de mentionner la diminution du bilan carbone de votre application, il vaudra toujours mieux mettre en avant la baisse de la facture de votre infrastructure (forcément, si on utilise moins de ressources, on émet moins de GES et on paie moins cher). En revanche, pour donner un objectif à vos équipes sensibles à ces questions, d’autres outils existent et notamment Kube Carbon.
Introduit en 2019 par Adam Hevenor, cet outil permet facilement de générer des courbes et des métriques suivant les émissions de GES de votre activité. Dans un article partagé sur Medium, il détaille son calcul de manière à faire le lien entre volume d’opérations informatiques et émission de gaz à effet de serre. La méthodologie n’est pas parfaite, et certains chiffres mériteraient sans doute d’être revus (la publication date déjà d’octobre 2019), mais elle explore néanmoins les différentes questions qui se posent à l’heure où l’usage du Cloud se démocratise. Quelle est l’empreinte carbone des services Cloud de Google ou d’Amazon ? Les deux vous répondront qu’ils sont neutres en carbone mais ce tour de passe-passe n’est possible que grâce à l’achat de crédits carbone et autres compensations, le tout sans avoir la moindre transparence concernant les volumes d’équivalent CO2 produits. C’est d’ailleurs la conclusion de l’article d’Adam qui appelle de ses vœux les grands du Cloud à plus de transparence sur ces questions (d’ailleurs ils pourraient intégrer à leur service le même type de graphes de façon native). Surtout, dans une période qui appelle à la sobriété, tout ce qu’il n’est pas nécessaire de compenser est bon à prendre.
Kube Carbon a donc cet avantage de fournir une vision chiffrée de votre impact carbone, avec pour objectif de devenir un indicateur important pour l’ensemble des acteurs.
OK, vous pouvez me refaire un topo pratique aux petits oignons comme pour Kube-green ?
Kube Carbon, techniquement, se résume à un dashboard Grafana, qui, dans l’état, ne fait que prendre des métriques, les transformer et nous les afficher. Ce qu’il faut retenir c’est la réflexion qu’a eu Adam Hevenor autour de ces indicateurs. Pour mieux me rendre compte de ce que cela représente, j’ai quand même déployé Prometheus, Grafana et importé ce dashboard.
Toujours sur mon cluster k8s local, j’ai exécuté ces commandes :
// create dedicated namespace and switch to it k create ns prometheus kubens prometheus // helm install for prometheus & grafana helm repo add prometheus-community https://prometheus-community.github.io/helm-charts helm repo update helm install prometheus prometheus-community/prometheus helm repo add grafana https://grafana.github.io/helm-charts helm repo update // Expose grafana svc to local access kubectl expose service grafana --type=NodePort --target-port=3000 --name=grafana-ext // Get svc port for access
// Get secret data to log in grafana
k get secret grafana -o jsonpath="{.data.admin-password}" | base64 --decode ; echoMaintenant qu’on a une stack Prometheus / Grafana qui fonctionne, on peut y accéder pour la paramétrer.
On peut remplir l’url de Prometheus avec son url de service Kubernetes, service:port comme http://prometheus-server:80
Il ne nous reste plus qu’à importer le dashboard de Kube Carbon qu’on retrouve ici. Nous n’avons besoin que de son ID.
On se rend dans Grafana, dans la partie dashboard puis Nouveau/New
Et on vient importer notre dashboard.
Et nous voici avec le dashboard pensé par son auteur pour évaluer le bilan carbone des ressources que nous utilisons. On trouve un résumé des métriques et des valeurs utilisées pour celles-ci dans son calcul.
Ensuite nous avons un résumé de notre consommation totale, et un détail par Pod.
Avec ces quelques manipulations, nous voilà déjà avec un outil qui commence à donner une idée de notre consommation. Pour rappel, le plus intéressant dans ces éléments, ce sont les choix au niveau des données en entrée et la formule que l’outil applique :
sum(container_cpu_usage_seconds_total * (.001/$flops_per_watt*$carbon_per_watt*$clock_speed)) / 1000000000
On note déjà une baisse à un instant précis, qui coïncide avec le moment où s’est appliqué mon fichier SleepInfo de Kube green, j’ai donc voulu remonter d’un cran au niveau de mon namespace de test, ce qui m’a amené à dupliquer la visualisation et faire les modifications nécessaires, pour aboutir à ce résultat :
On voit encore plus l’impact de la mise en place de Kube green au niveau de ce namespace, ça donne une idée de ce qu’il serait possible de faire en travaillant plus finement. Vu la flexibilité qu’offrent Grafana et Prometheus, on peut très bien imaginer adapter ce dashboard à nos besoins et mettre à jour les indicateurs de base avec les nouvelles informations à notre disposition (encore faut-il qu’elles soient fournies, que ce soit Scaleway, GCP ou Amazon, aucune information précise n’est trouvable à ce sujet, pas même une estimation).
On peut imaginer un dashboard par fournisseur Cloud par exemple, avec ses propres informations en entrée, variabiliser les dashboards selon des tags ou des labels propres à nos besoins, pour mieux identifier qui consomme ou non.
