Aller au contenu principal
Retour au blog

Blog

REX Kube-Green : comment nous avons réduit notre facture Kubernetes et notre empreinte carbone

La gestion des coûts liés à l’infrastructure (et par extension de l’empreinte carbone), est devenu un enjeu central pour toutes les équipes techniques. Dans de nombreux contextes clients, nous faisons face à un problème: les clusters Kubernetes hors-production hébergés sur le cloud tournent à vide la majeure partie du temps tout en nous coûtant le même montant et en dépensant les mêmes ressources.

En faisant le calcul, nous comptons 168 heures dans une semaine. Durant cette semaine de 168 heures, un environnement de développement, de staging ou de test ne sera exploité, sauf cas exceptionnel, qu’entre 40 et 50 heures maximum (les horaires de bureau). Donc, plus de 70% du temps, nous payons et nous consommons de l'énergie pour des ressources qui ne sont pas sollicitées. Une seule solution : éteindre ces ressources. Mais comment faire pour automatiser cette extinction et faciliter au maximum son déploiement et son maintien ? Il existe une solution qui s’en sort très bien : Kube-Green

C'est quoi Kube-Green exactement ?

Kube-Green est un opérateur Kubernetes open source qui fait partie de la CNCF (Cloud Native Computing Foundation). Son rôle est d'être l’interrupteur on/off de vos ressources kubernetes quand vous ne les utilisez pas. Pour atteindre son objectif, Kube-Green s’intègre nativement à l’api via une CRD (Custom Resource Definition) : SleepInfo.

Le fonctionnement de Kube-Green s’explique en 3 étapes :

  1. L'extinction : À l'heure d’extinction configurée, l’opérateur kube-green va intercepter l’état des déployments ciblé, va sauvegarder le nombres de réplicas en mémoire puis va forcer ce nombre à 0 (Il est aussi possible de suspendre les CronJobs et les StatefulSets).

  2. L'impact infrastructure : C'est ici que la magie opère. En passant les replicas à 0, le Cluster Autoscaler de Kubernetes détecte ce changement et va donc automatiquement détruire les VM associées et libérer les ressources .

  3. Le réveil : À l'heure de réveil configurée, l’opérateur kube-green va restaurer le nombre de repliqua initial et les environnement éteint seront de nouveaux opérationnels.

Cas concret : Déployer Kube-Green via Terraform

Contexte de ce déploiement : couper une liste précise de namespaces applicatifs en semaine, à partir de 20h00 jusqu'à 08h00 le lendemain puis, totalement éteint du vendredi soir au lundi matin. Dans cet exemple, nous ajoutant en plus une sécurité via la variable de nom de cluster qui nous sert à exclure explicitement le cluster de prod dans le cas ou le déploiement des différents environnements se fait via le même projet.

Le pré-requis : Cert-manager

Quand on envoie une requête SleepInfo, Kubernetes demande d'abord à Kube-Green de la valider via un système qu'on appelle un "Admission Webhook". Dans ce cas, Kubernetes exige un certificat (TLS) pour sécuriser cet échange. Il est donc nécessaire de passer par cert-manager et de le déployer dans notre kubernetes avant de déployer kube-green pour qu’il puisse gérer automatiquement et de manière transparente ces certificats. Sans ça, Kube-Green ne peut pas fonctionner.

Exemple de code Terraform

Voici un exemple de déploiement avec Terraform, en isolant le déploiement de l'opérateur et sa configuration.
(Petite précision : le count sert ici uniquement à exclure le cluster de prod. Il n’est donc pas forcément nécessaire dans toutes les configurations mais reste intéressant à prendre en compte)

kube-green.tf :

# 1. On crée le namespace pour Kube-Green, en excluant explicitement la prod via le count

resource "kubernetes_namespace" "kube_green" {
  count = var.cluster != "nom-du-cluster-prod" ? 1 : 0 
  metadata {
    name = "kube-green" 
  }
}

# 2. Déploiement de l'opérateur via Helm

resource "helm_release" "kube_green" {
  count = var.cluster != "nom-du-cluster-prod" ? 1 : 0 
  depends_on = [
    kubernetes_namespace.kube_green,
# On s'assure que cert-manager est prêt pour les webhooks
# (il faut s’assurer qu’il est bien déployé avant)
    helm_release.cert_manager
  ]
  name = "kube-green" 
  repository = "https://kube-green.github.io/helm-charts/" 
  chart = "kube-green" 
  namespace = kubernetes_namespace.kube_green[0].metadata[0].name 
  version = "0.7.1"

# L’opérateur n’as pas besoin d'énormément de ressources pour fonctionner

set {
    name = "jobs.resources.requests.cpu" 
    value = "10m" 
  }
 set {
    name = "jobs.resources.requests.memory" 
    value = "32Mi" 
  }
}

# 3. La règle SleepInfo sur nos namespaces cibles

# Nous pouvons réunir différents namespace dans une boucle pour éviter de multiplier le code

resource "kubernetes_manifest" "sleep_info" {
  # On boucle sur les namespaces qu'on veut couper, toujours hors prod
  for_each = var.cluster != "nom-du-cluster-prod" ? toset([
    "namespace-dev-1",
    "namespace-dev-2",
    "outils-internes"
  ]) : toset([]) 

  depends_on = [helm_release.kube_green] 

  manifest = {
    apiVersion = "kube-green.com/v1alpha1" 
    kind = "SleepInfo" 
    metadata = {
      name = "horaires-de-bureau" 
      namespace = each.value 
    }
    spec = {
      weekdays = "1-5"          # Actif du lundi au vendredi
      sleepAt = "20:00"         # Extinction à 20h00
      wakeUpAt = "08:00"        # Réveil à 08h00
      timeZone = "Europe/Paris" # On se cale sur le fuseau horaire local
      suspendCronJobs = true    # On coupe aussi les CronJobs
    }
  }
}

Peut-on rallumer nos environnement en cas de besoin ?

Avec cette configuration, on peut se poser LA question : est-il possible de rallumer nos environnements de manière exceptionnelle ?

Kube-Green déclenche l'extinction l'heure pile configurée dans le sleepAt. Si besoin, vous pouvez allumer vos applications manuellement.

Pour réveiller un déploiement spécifique, un simple kubectl suffit :

kubectl scale deployment <nom-du-deployment> \
  --replicas=<nombre-de-pods> \
  -n <votre-namespace>

Et si vous voulez réveiller tous les déploiements de votre namespace d'un coup pour retrouver l'environnement complet :

kubectl scale deployment --all \
  --replicas=<nombre-de-pods> \
  -n <votre-namespace>

Les fonctionnalités supplémentaires

La documentation de Kube-Green propose des options qui permettent de mieux ciblés les extinctions et des les monitorer :

  • ExcludeRef / IncludeRef : Le paramètre ExcludeRef permet d’exclure certaines ressources précises d’un namespace si celles-ci doivent continuer à tourner. IncludeRef permet d’inclure des ressources (notamment avec l’utilisation des labels décrits plus bas). Ça nous offre plus de précision et de controle sur ce que l’ont souhaite eteindre

  • Le ciblage par Labels : Il est possible d’utiliser matchLabels pour regrouper précisément les pods qui doivent s'éteindre. Cela offre une grande flexibilité de configuration (par exemple, ajouter simplement un label kube-green: enable sur les manifestes d'applications non critiques).

  • Les métriques Prometheus : IL est possible de suivre le temps exact d’extinctions via l’import des données, exposées nativement par kube-green, directement dans Grafana.

Résultats concrets suite à notre mise en place de la solution

Côté finances, l'impact à été immédiat sur notre facture. Sur un mois plein, comparé à un autre mois de référence avec un usage similaire, on constate une chute nette de 57 % sur nos requêtes vCPU et 58 % sur la mémoire, soit une réduction globale de 52 % sur le coût total du cluster. L'économie n'atteint pas l'intégralité des 64 % de temps de veille théorique, tout simplement parce qu'il reste les frais incompressibles de gestion du cluster (dans notre cas GKE autopilot) et le socle minimal de pods système qui tourne en continu. Mais avec plus de la moitié de la facture effacée chaque mois, le résultat est parfaitement au rendez-vous.

Dans le détail, les chiffres illustrent clairement l'impact des fenêtres de mise en veille :

  • Ressources de calcul : les requêtes vCPU chutent de 57 % et les requêtes mémoire (RAM) de 58 %.

  • Jours ouvrés (extinction nocturne) : la consommation journalière passe d'environ 18,60 €/jour en août à 12,60 €/jour, soit un gain net de 32 % chaque jour de semaine.

  • Week-ends (extinction complète) : la consommation s'effondre à 6,08 €/jour contre 18,60 €/jour auparavant, générant 67 % d'économie du vendredi soir au lundi matin.

  • Talon incompressible : ce plancher résiduel de 6 €/jour correspond strictement aux frais de management GKE et aux composants d'infrastructure système indispensables (agents réseau, stockage CSI, métriques).

Calcul d’économie carbone

Pour objectiver les gains environnementaux en l'absence de sondes matérielles sur GKE Autopilot, nous nous appuyons sur le CO2 Calculator officiel de kube-green. Ce modèle théorique repose sur une empreinte moyenne estimée à 11 kg CO2eq / an par pod (base d'un serveur cloud vert de 2 CPU hébergeant 15 pods, émettant 160 kg CO2eq/an) :

[table]

Sur notre cluster, l'application de ce créneau d'extinction de 108 heures par semaine permet d'éviter l'émission de ∼142 kg CO2eq par an (soit près de 12 kg CO2eq évités chaque mois), tout en réduisant directement notre facture de calcul de plus de 50 %.

Kube-Green est un vrai "quick win" technique. C'est une solution simple et rapide à déployer (notamment via Terraform) qui ne demande quasiment aucune maintenance au quotidien. Le gain est immédiat : la chute des consommations de calcul et les économies financières se voient dès la première facture cloud. De quoi conjuguer sobriété numérique et optimisation budgétaire en un minimum d'efforts.

Lien vers la doc officielle : https://kube-green.dev/docs/getting-started/ (s'ouvre dans un nouvel onglet)

Écrit par Nicolas - Green Nerds