Pas un événement particulier, plutôt une accumulation. Le coût mensuel qui grimpe sans qu'on s'en rende compte. 15€, puis 25€ parce qu'il faut plus de RAM, puis un deuxième VPS pour séparer les services. Au bout de deux ans, la facture totale fait réfléchir.

Il y avait aussi l'envie de toucher le matériel. De pouvoir débrancher physiquement une machine qui pose problème. De comprendre ce qui se passe au niveau hardware, pas seulement côté logiciel.

J'ai récupéré deux mini-PC : un HP EliteDesk 705 G5 avec 32 Go de RAM, et un ThinkCentre avec 16 Go. Des machines de bureau reconditionnées, rien d'extraordinaire. Elles sont posées dans un coin de mon appartement, branchées sur un switch, et font tourner un cluster Kubernetes.

J'aurais pu faire simple. Ubuntu Server, k3s, une installation en vingt minutes.

Mais j'ai choisi Talos Linux. C'est une distribution minimaliste conçue uniquement pour Kubernetes. Pas de SSH, pas de shell interactif, tout se pilote via une API. L'idée : si on ne peut pas se connecter manuellement, on ne peut pas faire de modifications non traçables. L'infrastructure devient immutable.

L'installation m'a pris du temps. Le problème, c'est qu'il faut apprendre l'outils talosctl, rien de bien compliqué mais c'est une chose de + à apprendre.

Mon cluster actuel : deux nodes sur les mini-PC, ArgoCD pour le déploiement GitOps, Rook/Ceph pour le stockage distribué, Traefik comme ingress controller, et kube-prometheus-stack pour le monitoring.

Installer un cluster, c'est une chose. Le rendre entièrement déclaratif et reproductible, c'en est une autre.

J'ai passé pas mal de temps sur ce sujet. La gestion des secrets avec Sealed Secrets demande un processus de bootstrap bien pensé. L'ordre de déploiement des composants compte : Rook/Ceph doit être opérationnel avant que les applications qui en dépendent ne tentent de monter leurs volumes. Les dépendances entre services créent des cas limites qu'on ne prévoit pas toujours.

Aujourd'hui, mes manifests Kubernetes sont versionnés dans un dépôt Git. ArgoCD surveille ce dépôt et synchronise automatiquement le cluster. Je pousse un commit, l'état du cluster se met à jour. En théorie, je pourrais tout reconstruire en moins d'une heure. Je n'ai pas encore testé cette hypothèse en conditions réelles.

À côté du cluster Kubernetes, j'ai Proxmox qui fait tourner quelques services dans des LXC. SonarQube pour l'analyse de code, n8n pour l'automatisation, Vaultwarden pour les mots de passe. Des trucs qui n'ont pas forcément besoin d'être orchestrés par Kubernetes mais que je veux garder chez moi.

C'est d'ailleurs en installant SonarQube que j'ai contribué au projet Proxmox VE Helper-Scripts (anciennement tteck/Proxmox, maintenant hébergé sous community-scripts/ProxmoxVE). Ces scripts permettent d'installer des services dans des conteneurs LXC en une seule commande. J'ai proposé un script pour simplifier le déploiement de SonarQube.

J'ai également packagé kubeseal pour le channel nonguix sur Guix. C'est ma deuxième contribution, après avoir travaillé sur le packaging de Discord pour mon usage personnel. Une aventure qui m'a confronté aux problèmes de RUNPATH, aux crashs ICU, et aux fichiers .desktop qui refusaient de s'installer correctement.

Pour l'instant mes contributions Guix restent modestes. J'aimerais en faire plus, proposer d'autres packages, peut-être contribuer au channel principal. C'est un écosystème que j'apprécie et où je veux m'investir davantage.

Le cluster sert à plusieurs choses.

Des tests, principalement. Je peux monter un environnement, essayer une configuration risquée, observer ce qui casse. Sans conséquences sur quoi que ce soit de critique.

De l'hébergement personnel. Les services habituels : gestionnaire de mots de passe, bloqueur de publicités DNS, quelques applications que je préfère ne pas confier à des tiers.

Et surtout, un environnement miroir de ce que je fais en entreprise. Je suis en alternance comme ingénieur DevOps/infrastructure dans une société de transport. On utilise la même stack en production : Talos, ArgoCD, Rook/Ceph, Traefik. Pouvoir expérimenter chez moi avant d'intervenir sur l'infrastructure de production, c'est un avantage concret.

Je ne sais pas vraiment. Le setup actuel me convient.

J'ai un serveur Debian à côté pour les services qui n'ont pas besoin de Kubernetes, exposé via Cloudflare Tunnel. Ça fonctionne, c'est stable, je n'y touche plus.

Peut-être que j'ajouterai du stockage supplémentaire un jour. Peut-être que je migrerai vers autre chose. Pour l'instant, ces deux mini-PC font ce que je leur demande, et c'est suffisant.