Ce que les tutoriels n’enseignent pas
Les tutoriels Kubernetes montrent comment déployer une application qui fonctionne. Ils montrent rarement ce qui se passe quand ça casse — et comment raisonner pour trouver la cause.
Ce homelab a été, avant tout, une école de débogage et de résilience. Voici les leçons les plus importantes.
1. Les contraintes matérielles sont un avantage pédagogique
Sur AWS, un pod qui consomme trop de mémoire provoque au pire une note de facturation plus élevée. Sur un RPi 8 Go partagé entre etcd, le kube-apiserver et une dizaine de pods, un pod OOM-killed entraîne une cascade d’erreurs.
Cette contrainte force une discipline qui fait défaut dans le cloud : comprendre réellement ce que consomme chaque composant. Après ce projet, les resources.requests et resources.limits ne sont plus des champs optionnels — ce sont les premières choses que je configure.
2. Le GitOps n’est pas un outil, c’est une discipline
ArgoCD peut être configuré en 20 minutes. Comprendre ce que signifie “Git est la source de vérité” prend beaucoup plus longtemps.
La vraie valeur du GitOps n’est pas l’automatisation — c’est l’auditabilité. Quand quelque chose casse, l’historique Git répond à “qu’est-ce qui a changé et quand ?”. Cette question est souvent la première dans un incident de production.
J’ai appris à jamais modifier manuellement une ressource gérée par ArgoCD. Pas parce que c’est interdit, mais parce que ça casse le modèle mental : si la réalité du cluster diverge de Git, plus rien n’est fiable.
3. Le stockage distribué est le problème le plus difficile
Longhorn a été la source du plus grand nombre d’incidents de ce homelab. Les volumes dégradés, les répliques qui ne se reconstruisent pas, les performances I/O inattendues — ces problèmes n’ont pas de solution simple.
La leçon principale : toujours tester la récupération, pas seulement la résilience. Il ne suffit pas que Longhorn promette 2 répliques. Il faut simuler la perte d’un nœud et vérifier que les volumes se reconstruisent effectivement sur un autre nœud dans un délai acceptable.
4. La sécurité doit être intégrée dès le départ
Sealed Secrets et Cloudflare Tunnel sont deux exemples de sécurité “by design” — pas rajoutés après coup.
Essayer de retrofitter la gestion des secrets après avoir commité des credentials en clair est une opération coûteuse (rotation de tous les credentials, audit de l’historique Git). Partir avec kubeseal dès le premier jour coûte 30 minutes d’installation. La différence de coût est asymétrique.
5. La complexité opérationnelle a un coût réel
Ce homelab m’a donné une appréciation profonde de la complexité opérationnelle. Maintenir 6 nœuds, 15 services, des backups, du monitoring et de la sécurité en dehors des heures de travail a plusieurs fois consommé des week-ends entiers.
La vraie compétence n’est pas de déployer ces services — c’est de faire des arbitrages : quand l’automatisation vaut l’investissement, quand la simplicité vaut mieux que la fonctionnalité, quand accepter une dette technique est raisonnable.
6. Ce qui se transfère directement au monde professionnel
Ces 5 mois m’ont exposé à des défis concrets que l’on retrouve dans des environnements cloud professionnels :
- Incident response : diagnostiquer et résoudre des pannes sous pression, avec des logs et des métriques imparfaits
- Infrastructure as Code : tout versionner, rien de manuel
- HA et résilience : concevoir pour la panne, pas juste pour le cas nominal
- Observabilité : metrics, logs, alerting — sans ça, l’exploitation à l’aveugle
- Sécurité : secrets management, zero-trust networking, RBAC minimal
Aucun certificat n’enseigne ces compétences aussi efficacement que les résoudre sur du matériel réel, seul, à 23 h, avec un cluster qui ne répond plus.
Ce que je ferais différemment
Un load-balancer pour le control-plane dès le départ : pointer KUBECONFIG vers un seul master est fragile. Un keepalived VIP ou un MetalLB L2 Advertisement devant les 3 masters serait plus robuste.
Documenter en temps réel : les incidents les plus instructifs ont été partiellement perdus parce que je les ai résolus sans noter la cause racine. Ce blog est en partie une correction de cette erreur.
Commencer par le monitoring : installer VictoriaMetrics et Grafana avant les applications. Déboguer des problèmes de démarrage sans métriques est inutilement difficile. Les métriques auraient diagnostiqué plusieurs problèmes en quelques minutes plutôt qu’en heures.