Partie 20 — Bilan du projet : un cluster K3s sur Raspberry Pi
Mars 2026
Le chemin parcouru
Ce qui a commencé comme "je vais mettre mon site perso sur un Raspberry Pi" est devenu un vrai cluster Kubernetes de production, avec du GitOps, du monitoring, des alertes, un VPN, de la domotique, un gestionnaire de mots de passe, et un globe 3D qui affiche les connexions en temps réel.
Récapitulons les grandes étapes.
Le début
On m'a toujours parlé de Kubernetes comme la bête noire du DevOps, n'ayant pas énormément de connaissance sur les technologies de conteneurisation et infra je ne m'y étais donc jamais penché, mais avec les années, deux choses m'ont toujours intéressé dans le domaine de l'informatique :
- la sécurité réseau
- L'infra système
Donc avec les années je me suis pas mal investi sur du pentest avec TryhackMe ou rootme tant bien que mal mais je me suis toujours régalé à faire ça à mon petit niveau. En parallèle je m'amusais à me créer un site depuis une Raspberry, un Home Assistant avec une autre Raspberry, dès que je voulais tester un logiciel ou une techno je le faisais toujours sur un Docker, avec le temps j'ai pu réussir à comprendre la philosophie qui tourne ce monde de l'infra.
La raison de ce grand pas en avant
Dans mon entourage j'ai beaucoup de personnes qui travaillent dans ce milieu, j'ai donc eu la chance de pouvoir parler avec eux, et m'ont beaucoup aidé à avancer. Au début quand je parlais de Kubernetes on me disait que c'était encore trop compliqué pour moi (ils avaient raison), maintenant que les années ont passées je me suis motivé à passer le pas. Donc j'en ai parlé à nouveau, et à ma grande surprise toutes les personnes avec qui j'en parlais m'ont clairement dit de foncer.
On m'a même conseillé et donné des exemples de ce que je pouvais faire, la majorité de mon plan sur tout ce projet m'a été donné par un ami.
La phase de recherche et achat
Arrivé chez moi, j'ai commencé à regarder le matériel nécessaire pour faire tourner un cluster minimal avec K3s, j'ai acheté ma première Raspberry de 8 Go pour l'utiliser comme master, ce qu'il me restait à faire était de formater toutes mes Raspberry pour les installer comme agent ou master K3s avec un OS propre, j'ai acheté un rack pour toutes les avoir au même endroit.
Je me souviens de l'excitation que j'avais de pouvoir installer K3s, mais je devais patienter le temps de recevoir la Raspberry master et aussi le temps de m'installer les OS proprement. Ça m'a également permis de me remettre à utiliser Ansible, que je n'avais presque jamais utilisé jusque là.
Chaque jour que j'avançais là dessus me rendait toujours plus impatient.
L'IA dans ce projet
Évidemment, nous sommes dans une ère où l'IA est partout, j'aurais pu ne pas l'utiliser mais j'avais un objectif clair avec.
Pour apprendre comment fonctionnait Kubernetes j'avais trois options :
- La documentation, les forums etc... | Mais le projet aurait été brouillon
- Les formations | Pratique avec une petite certif à la clé mais juste des exos donnés et pas forcément un projet personnel
- L'IA | Avec une utilisation comme professeur
Je penchais vers les deux derniers points, les formations me paraissaient plus intéressantes car j'avais peur d'utiliser l'IA d'une mauvaise façon et ne rien apprendre.
Au final avec pas mal de discussions avec des amis, des discussions avec l'IA, j'ai vite compris que si je me cadrais suffisamment bien et que je donnais des ordres clairs je pouvais vite progresser avec cette dernière.
Donc je suis allé sur claude.ai et je lui ai expliqué mon projet, mon niveau et mon objectif de vouloir apprendre le plus possible sans qu'il ne fasse quoi que ce soit.
Du coup il m'a donné un plan entier avec plusieurs phases et le temps dans chaque phase. J'ai pu me faire un planning avec une estimation de temps en travaillant 1h par soir et 4h par week-end.
Ensuite je lui ai donné les instructions :
- Une documentation explicative de ce que nous allons faire dans cette séance qu'il me fallait lire dans la journée, comme ça je pouvais poser mes questions sur ce que je ne comprenais pas, et pendant la séance, j'apprenais avec la doc qu'il m'avait faite et en cherchant en complément sur internet, il était là pour m'aiguiller mais pas pour faire à ma place, chaque erreur il m'expliquait ce que c'était.
Et puis chaque fin de semaine pour faire un suivi de l'avancement et pour savoir si j'avais bien compris, Claude me faisait un questionnaire et il me notait sur mes réponses, chaque erreur était suivie d'explications et parfois une question ratée d'une des semaines avant était réutilisée dans les semaines d'après.
Maintenant on passe sur le planning avec les phases données dans le plan.
Phase 1 — Le site Flask sur K3s
Le point de départ : 4 pages HTML servies par un script Python. La destination : un cluster K3s de 5 Raspberry Pi avec Helm, Ingress, certificats Let's Encrypt.
Une fois terminé, je voyais le site fonctionner, sachant qu'il était sur K3s et voyant en plus qu'il était plus réactif qu'avant, me confortait sur mon envie de continuer.
Phase 2 — ArgoCD et le GitOps
L'installation d'ArgoCD a été un tournant. Plus de kubectl apply manuel — un git push et tout se déploie automatiquement.
Quand j'ai réalisé à quel point GitOps était vraiment puissant en terme de rapidité et de gain de temps, de voir les choses se faire automatiquement sous mes yeux, c'était incroyable pour moi car je n'en avais jamais entendu parler avant. Ça a changé totalement ma vision de voir les choses.
Phase 3 — CI/CD avec GitHub Actions
Tests automatiques, lint, build Docker multi-arch (amd64 + arm64), push sur Docker Hub, mise à jour automatique du tag image dans le repo Helm — tout le pipeline sans intervention.
Je pense que les phases 2 et 3 ont été pour moi les plus satisfaisantes de tout mon projet. De voir qu'avec un simple commit toute une infra qui se teste et qui s'installe toute seule c'était éblouissant, surtout de savoir que j'étais capable de faire ça.
Il y en a eu des galères pour le faire fonctionner mais le résultat en valait le coup.
Phase 4 — Home Assistant et Passbolt
Deux services très différents. Home Assistant pour la domotique (Zigbee, Bluetooth, capteurs), Passbolt pour les mots de passe — migré depuis le NAS vers K3s.
Avec Passbolt j'avais souvent des soucis, je venais de l'installer sur mon NAS avec un Docker, mais comme je trafiquais pas mal sur mon NAS, je me retrouvais avec pas mal d'ennuis, parfois sans comprendre pourquoi Passbolt tombait, le Docker ne se relançait pas bien, je me retrouvais souvent bloqué car je n'étais pas chez moi et je n'avais plus mes mots de passe, la migration a été assez stressante car me connaissant j'étais persuadé que ça ne fonctionnerait pas comme je le voulais, mais au final ça s'est bien passé, le passage à la production a été un succès, j'étais content de moi.
Phase 5 — Le arr-stack et le VPN
La stack média avec Gluetun (ProtonVPN WireGuard)... Le pattern sidecar avec tous les containers qui partagent le tunnel VPN.
Le sidecar a été un élément assez compliqué à comprendre pour moi mais en même temps quelque chose de plutôt surprenant sur le fonctionnement, j'ai beaucoup aimé apprendre la philosophie derrière un sidecar.
La configuration de ce dernier a été éprouvante mais au bout d'un moment ça a fini par fonctionner, j'ai éprouvé une grande satisfaction.
Phase 6 — Monitoring complet
Prometheus, Grafana, AlertManager, Loki, Promtail, GeoIP, exporters en pagaille — la visibilité totale sur le cluster.
Dans le passé j'avais déjà installé Grafana, c'était complexe pour afficher un graphique et juste pour récupérer les données d'un appareil. Cette fois-ci je m'y suis pris d'une autre façon : lire des docs, et voir les outils qui contenaient déjà toutes les infos que je voulais récupérer. La partie graphique ensuite, il fallait juste prendre le temps de trouver les bonnes métriques, bon j'ai toujours beaucoup de mal avec Grafana mais là tout fonctionne, je n'y touche plus. Ensuite l'ajout des alertes sur Discord. Arrivé ici j'étais content de tout le chemin que j'avais accompli.
Le globe 3D et la carte des connexions
Réutiliser les logs nginx enrichis GeoIP pour créer une page publique avec un globe terrestre 3D et des arcs animés. Du monitoring transformé en vitrine.
J'avais vu ça sur internet il y a quelques années et j'ai toujours voulu faire pareil, à un moment j'avais envie de faire une pause sur mon planning, après 3 mois de projet il me fallait respirer, du coup j'en ai profité pour me faire des petits projets annexes comme refaire mon PC avec Arch Linux, me créer une clé USB avec une partition chiffrée et une autre avec un OS portable (en l'occurrence BlackArch) et à ce moment là j'ai eu ce souvenir qui m'est revenu : faire une page web qui répertorie toutes les connexions de mon serveur provenant de partout dans le monde.
C'est la partie la plus captivante pour moi et aussi pour les gens à qui j'ai montré ça.
Le dashboard QNAP et les alertes NAS
Le monitoring étendu au NAS via SNMP. Les alertes Discord séparées par salon — le cluster sur un canal, le NAS sur #fonas.
Maintenant je peux voir tout mon réseau local sous contrôle dans un seul endroit, et je peux le voir à n'importe quel moment.
Les galères mémorables
- Le Promtail qui consommait 590m CPU et que j'ai dû augmenter 3 fois
- Le pihole-exporter qui splittait le mot de passe sur les virgules
- Les builds Docker multi-arch ARM qui prenaient une éternité
- Le certificat wildcard qui ne se propageait pas
- Les disques USB du rpi4-worker2 avec les I/O errors Realtek
- Le blog Ghost qui redémarrait sans arrêt sans que je puisse le savoir (pas encore de monitoring)
- Le site Flask qui mettait 15 secondes à charger pour au final planter
J'en ai eu bien d'autres mais celles-ci étaient les plus marquantes pour moi.
Les moments de fierté
- Le lancement de Ansible pour installer et mettre à jour toutes mes RPi
- Le premier
git pushqui déclenche toute la chaîne CI/CD → ArgoCD → déploiement - La création de ce blog en faisant un script pour envoyer mes docs déjà préparés sur mon PC dans les brouillons ici
- La migration Passbolt
- La première alerte Discord reçue sur le téléphone
- Le dashboard cluster-overview avec tous les nœuds au vert
- De voir la stabilité de mon cluster après une semaine sans aucune alerte Discord
Les compétences acquises
En partant d'un niveau débutant, ce projet a couvert :
| Domaine | Technologies | Évolution |
|---|---|---|
| Conteneurisation | Docker, multi-arch builds | Meilleure compréhension |
| Orchestration | Kubernetes (K3s), Helm, namespaces, RBAC | Acquisition des bases |
| GitOps | ArgoCD, app-of-apps pattern | Acquisition des bases |
| CI/CD | GitHub Actions, pipelines multi-étapes | Acquisition des bases |
| Monitoring | Prometheus, Grafana, Loki, Promtail, AlertManager | Meilleure compréhension |
| Réseau | Ingress, cert-manager, DNS, VPN WireGuard, SNMP | Connaissances plus approfondies |
| Sécurité | SealedSecrets, Let's Encrypt, Cloudflare DNS-01 | Connaissances plus approfondies |
| Infrastructure | Ansible, Raspberry Pi, SSD, stockage | Connaissances plus approfondies |
| Frontend | Globe.gl, Leaflet, WebGL, Flask | Acquisition des bases |
Le cluster aujourd'hui
Cluster K3s — 5 Raspberry Pi
├── rpi4-master (8 Go)
│ ├── ArgoCD, Prometheus, Grafana, AlertManager
│ ├── VPN Pod
│ └── Passbolt, cert-manager, Reflector
├── rpi4-worker (8 Go)
│ └── Pi-hole (DNS + DHCP)
├── rpi4-worker2 (8 Go)
│ ├── Loki (logs)
│ ├── Home Assistant
│ └── autobrr
├── rpi3-worker1 (1 Go)
│ └── home-fonta.fr (Flask)
└── rpi3-worker2 (1 Go)
└── (workloads légers)
Services exposés :
├── home-fonta.fr (site + globe 3D)
├── grafana.home-fonta.fr
├── argocd.home-fonta.fr
├── homeassistant.home-fonta.fr
├── passbolt.home-fonta.fr
├── plex.home-fonta.fr (proxy NAS)
└── *.home-fonta.fr (wildcard cert)
Monitoring :
├── 7 dashboards Grafana
├── 12 alertes → Discord (2 salons)
├── Loki + Promtail (logs + GeoIP)
└── SNMP exporter (NAS QNAP)
Et après ?
Le projet est arrivé à maturité. Le cluster tourne, les alertes préviennent, les dashboards montrent tout. Mais une idée germe...
Vers un cluster auto-géré ?
Et si le cluster pouvait se diagnostiquer et se réparer tout seul ?
L'idée : un agent IA qui tourne dans le cluster, reçoit les alertes d'AlertManager, analyse le problème avec kubectl et les logs Loki, propose un fix, le déploie sur une branche git séparée via ArgoCD, surveille pendant 24h, et merge automatiquement si tout est stable. Le tout avec une notification Discord à chaque étape. Sauf si le fix est jugé trop dangereux pour la santé du cluster, l'agent me ferait une notification sur Discord (pourquoi pas par SMS) en me proposant le fix et j'aurais juste à valider ou pas avant qu'il n'agisse.
Je me suis rapproché du protocole MCP comme beaucoup de monde, et j'y ai vu quelque chose qui pouvait m'intéresser tout en apprenant comment le protocole fonctionne.
Les briques sont déjà là : AlertManager sait notifier, ArgoCD sait déployer depuis n'importe quelle branche, le monitoring sait valider que tout va bien. Il manque le cerveau au milieu — un agent qui connecte tout ça.
J'ai encore plein de petits projets en tête, que je publierai ici régulièrement, et quand j'aurai bien fait mûrir ce gros projet, je me lancerai.
Voilà la fin de ce projet, j'en suis très fier, j'ai avancé plus que je ne l'aurais imaginé, je me rapproche de plus en plus de mes objectifs, et je suis plus motivé que jamais.