Kubernetes sur bare metal : une infra résiliente à 100€/mois

Quand un client m'a demandé de passer d'un simple Docker Compose sur une machine unique à une infrastructure haute disponibilité, la question s'est posée naturellement : cloud public ou bare metal ? La réponse m'a surpris moi-même. En 2 à 3 jours, avec l'aide de l'IA, j'ai monté un cluster Kubernetes de 3 machines capable de survivre au crash d'un serveur physique. Le tout pour environ 100€ par mois.

La stack en un coup d'œil

L'équivalent sur GCP coûte plus de 1000€ par mois, hors frais de réseau. Pour beaucoup de scale-ups, le calcul financier va devenir de plus en plus difficile à ignorer.

Talos : traiter ses serveurs comme du bétail

L'analogie est connue dans le monde de l'infrastructure : vos serveurs sont-ils des animaux de compagnie (pets) ou du bétail (cattle) ? Un pet, c'est un serveur qu'on bichonne, qu'on configure à la main, qu'on répare quand il tombe malade. Perdre un pet, c'est un drame. Du bétail, en revanche, c'est interchangeable : si un individu disparaît, on en remet un autre à la place sans sourciller.

Talos Linux pousse cette philosophie à l'extrême. C'est un OS immutable, entièrement dédié à l'exécution de Kubernetes. Pas de SSH, pas de shell, pas de package manager. Toute la configuration se fait via une API déclarative. Si un nœud pose problème, on ne le répare pas : on le remplace. C'est un changement de mentalité fondamental pour des équipes habituées à se connecter en SSH pour diagnostiquer un problème en production. Mais c'est aussi un gain de robustesse considérable : moins de surface d'attaque, moins de dérive de configuration, moins de "ça marchait sur mon serveur".

L'aspect sécurité est d'ailleurs un argument de poids. Talos n'expose que le strict minimum en externe. Pas de ports ouverts inutiles, pas de services superflus qui tournent en arrière-plan. Pour un SRE ou une équipe qui porte la casquette DevOps, c'est une base saine sur laquelle construire. Et pour un CTO qui doit justifier ses choix d'infrastructure auprès d'investisseurs ou dans une due diligence, une surface d'attaque minimale est un argument qui pèse.

Kubernetes : la haute disponibilité accessible

Le besoin initial de mon client était simple : ne plus dépendre d'une seule machine. Avec Docker Compose sur un serveur unique, le moindre crash — qu'il soit matériel ou logiciel — signifie une interruption de service. Avec un cluster Kubernetes de 3 nœuds, si un serveur tombe, les conteneurs sont automatiquement redéployés sur les nœuds restants. C'est le principe même de l'orchestration.

Ce qui a changé par rapport à il y a quelques années, c'est l'accessibilité. Je ne suis pas SRE de formation. J'en ai fait un peu il y a une dizaine d'années et j'ai remis les mains dedans récemment, mais je ne me considère clairement pas comme un expert. Pourtant, en 2 à 3 jours, le cluster était opérationnel. L'IA a joué un rôle déterminant dans cette rapidité : elle m'a permis de résoudre des problèmes de configuration que j'aurais mis des heures à diagnostiquer seul, de comprendre des concepts que je maîtrisais mal, et de produire des fichiers de configuration corrects du premier coup dans la majorité des cas.

Je ne conseillerais pas à des néophytes complets de pousser ce genre d'infrastructure en production avec uniquement le soutien de l'IA. Il faut un minimum de bagage pour comprendre ce qu'on fait, pour identifier quand l'IA se trompe, et pour debugger les cas limites qu'elle ne couvre pas. Mais pour des développeurs qui ont une appétence pour l'infrastructure et un peu d'expérience, l'IA change véritablement la donne. Des compétences qui nécessitaient auparavant un profil SRE dédié deviennent accessibles à des profils plus généralistes.

ArgoCD : le GitOps comme prolongement naturel

Quand on adopte la philosophie cattle vs pets avec Talos, supprimer les kubectl apply manuels devient une évidence. Si l'infrastructure est déclarative et jetable, le déploiement applicatif doit l'être aussi. C'est exactement ce que fait ArgoCD : il surveille un repository Git et synchronise automatiquement l'état du cluster avec ce qui est décrit dans le code.

Concrètement, chaque déploiement passe par un commit. Pas de connexion au cluster, pas de commande manuelle, pas de "j'ai appliqué un hotfix en prod sans le versionner". Tout est dans Git, tout est traçable, tout est reproductible. Si un environnement part en fumée, on recrée le cluster Talos et ArgoCD resynchronise tout depuis le repository. Rien ne se perd.

ArgoCD est en train de devenir un incontournable dans cet écosystème, et ce n'est pas un hasard. Il s'inscrit parfaitement dans une logique où l'infrastructure et les applications sont traitées comme du code. Pour des équipes qui pratiquent déjà la revue de code sur leurs applications, étendre cette pratique au déploiement est un pas naturel. Un nouveau service à déployer ? C'est une Pull Request. Un rollback ? C'est un revert Git.

Pour qui ça fait sens

Cette stack n'est pas pour tout le monde. Un Docker Compose sur un VPS à 20€ par mois reste le bon choix pour la majorité des startups en phase de lancement. Il ne faut pas basculer vers Kubernetes par effet de mode ou par anticipation excessive.

En revanche, dès que la haute disponibilité devient un vrai besoin — parce que vos clients paient pour un SLA, parce que votre produit ne tolère pas l'interruption, ou parce que vous préparez une montée en charge — l'alternative bare metal mérite d'être sérieusement étudiée. Le rapport qualité-prix est devenu difficile à battre : 3 serveurs physiques avec 192 Go de RAM et une vingtaine de CPU pour 100€ par mois chez OVH, là où un cloud public facture facilement 10 fois plus pour des performances équivalentes.

L'IA ne fait qu'accélérer cette tendance. Ce qui nécessitait une équipe infra dédiée devient réalisable par une équipe plus réduite, à condition qu'elle ait les fondamentaux. Ce n'est pas une raison pour se passer de compétences SRE à terme — c'est une raison pour ne plus reporter indéfiniment la mise en place d'une vraie infrastructure résiliente.