Volta : une plateforme Kubernetes construite de zéro sur OpenStack

Le problème

L’infrastructure cloud cache son coût physique. Un pod qui consomme 40 W ressemble exactement à un pod qui en consomme 4 : même tableau de bord, même coche verte, même ligne de facture noyée dans un agrégat. La capacité finit dimensionnée à l’intuition, et « il faudrait optimiser ça » reste une opinion, parce que ce qu’on optimise n’est jamais mesuré.

Volta comble cet écart à petite échelle. Le projet construit une plateforme complète à partir de rien, puis y ajoute le signal qui manque à la plupart des plateformes : les watts et les grammes de CO2eq attribués à chaque charge, à côté de ce qu’elle coûte réellement.

Deux contraintes

• Tout se détruit et se reconstruit. Une étape qui ne survit pas à un cycle complet de destruction et de reconstruction n’est pas finie.
• Chaque mesure annonce sa marge d’erreur. Une consommation mesurée dans une machine virtuelle est une estimation, et le dépôt le dit partout où il en rapporte une.

Où en est le projet

La plateforme tourne : réseau privé derrière un routeur, trois nœuds dans trois zones de disponibilité joignables par un bastion, cluster k3s amorcé par OpenTofu, entrée HTTPS par un répartiteur de charge Octavia, Traefik et cert-manager, et Argo CD qui livre chaque service du cluster depuis le dépôt.

En cours : l’observabilité, avec Prometheus et Grafana. Suivront les sauvegardes Velero, prouvées par une vraie restauration, puis la seconde phase : la consommation de chaque pod, un modèle carbone, et une optimisation mesurée avant et après.

Quelques décisions

Chaque décision importante est consignée dans un ADR, avec les options écartées et pourquoi. En voici quelques-unes.

• OpenTofu plutôt que Terraform : licence MPL-2.0, et soutenu par la documentation d’Infomaniak.
• k3s autogéré plutôt que Kubernetes managé : l’amorçage du cluster fait partie de ce que le dépôt démontre.
• Un membre etcd par zone de disponibilité : perdre une zone coûte un membre, pas le quorum, pour moins d’une milliseconde de latence.
• Un bastion comme seule porte : aucun nœud n’a d’adresse publique, et la machine exposée ne fait pas partie du cluster.
• L’état dans Swift, chiffré, sans verrou : la couche S3 de la plateforme refuse l’écriture conditionnelle qu’un verrou demande ; des plans enregistrés et le versionnement en tiennent lieu.
• OpenTofu hors du cluster, Argo CD dedans : chaque ressource a un seul propriétaire, et les quatre valeurs qui franchissent la ligne sont listées au même endroit.

Ce qui a cassé

Le dépôt place cette partie au-dessus de la liste des fonctionnalités : la façon dont une plateforme tombe et se relève en dit plus sur elle que ce qu’elle fait un bon jour. Trois exemples.

Un verrou que la plateforme ne peut pas prendre. Avec le verrouillage de l’état activé, la planification échouait avant de commencer. OpenTofu prend ce verrou par une écriture conditionnelle, et Swift 2.30.1, qui sert l’API S3 ici, répond à toute écriture conditionnelle par 501 NotImplemented. Swift l’accepte à partir de la version 2.36.0 ; d’ici là, l’état n’a pas de verrou, et un ADR dit ce qui en tient lieu.

Une application qui ne devenait jamais saine. Le site répondait et son certificat était émis, mais Argo CD voyait toujours la démo en cours de déploiement. Argo CD ne déclare un Ingress sain que si son statut porte une adresse, et celui-ci n’en portait aucune : Traefik la recopie de son propre Service, de type NodePort, alors que l’adresse vit sur le répartiteur Octavia, hors du cluster. Traefik publie désormais lui-même l’adresse publique stable.

Un cluster auto-réparé qui laissait un changement manuel en place. Passée à la main à trois réplicas, la démo y restait, auto-réparation activée. Son manifeste ne déclarait aucun nombre de réplicas : Kubernetes en avait rempli un, et Argo CD n’impose que ce que le manifeste déclare. Le manifeste en déclare un désormais, et la même commande est défaite.