Homelab Kubernetes production-like

Résumé

Un cluster Kubernetes de laboratoire construit avec les mêmes exigences qu’une plateforme de production : haute disponibilité du plan de contrôle, stockage répliqué, réseau observable, déploiements reproductibles et sauvegardes testées.

Contexte

Les environnements de test jetables ne révèlent jamais les vrais problèmes d’exploitation. Les pannes intéressantes — un volume qui répond mal, un certificat qui n’est pas renouvelé, une sonde qui ment — n’apparaissent qu’au bout de plusieurs semaines de fonctionnement continu.

Ce cluster tourne donc en permanence et héberge des services réellement utilisés, ce qui rend chaque incident instructif.

Objectifs

• Reconstruire l’intégralité du cluster depuis Git, sans étape manuelle.
• Tenir la perte d’un nœud complet sans interruption de service.
• Disposer de métriques et de logs exploitables avant d’en avoir besoin.
• Éprouver des pratiques transposables en production.

Contraintes

• Trois nœuds physiques seulement, donc aucune marge pour du gaspillage.
• Budget électrique limité : les ressources doivent rester mesurées.
• Aucune dépendance à un service cloud payant pour le fonctionnement de base.

Architecture

Proxmox VE fournit la couche de virtualisation. Chaque hyperviseur héberge un nœud de plan de contrôle et un nœud worker, ce qui donne un quorum etcd à trois membres réparti sur trois machines physiques distinctes.

Talos Linux remplace une distribution généraliste : pas de shell, pas de gestionnaire de paquets, une API déclarative et une surface d’attaque très réduite. La configuration des nœuds est un fichier YAML versionné.

Cilium assure le réseau des pods et remplace kube-proxy. Hubble donne une visibilité sur les flux, ce qui transforme le débogage réseau d’une séance de tcpdump en une lecture de graphe.

Implémentation

Le provisionnement des machines virtuelles est décrit en Terraform. La configuration Talos est générée puis appliquée par un script idempotent. À partir de là, tout passe par Argo CD : le bootstrap installe uniquement Argo CD, qui installe ensuite le reste.

Difficultés rencontrées

Le premier obstacle a été le stockage. Un volume répliqué qui subit une coupure d’entrées/sorties pendant une écriture peut laisser une base de données dans un état illisible, alors même que le pod reste marqué comme sain.

Le second a été l’ordonnancement des dépendances : Argo CD ne garantit pas l’ordre entre applications distinctes, ce qui casse tout déploiement supposant qu’un secret existe déjà.

Solutions

Les sondes de vivacité ont été dissociées des sondes de disponibilité, et une vérification fonctionnelle a été ajoutée là où un simple 200 OK masquait une panne réelle. Ce point a fait l’objet d’un article détaillé.

Pour l’ordonnancement, les vagues de synchronisation Argo CD couvrent les dépendances d’infrastructure, et les services qui exigent un secret bloquent leur démarrage sur un conteneur d’initialisation plutôt que de redémarrer en boucle.

Résultats

• Reconstruction complète du cluster en moins d’une heure, sans intervention.
• Perte d’un hyperviseur absorbée sans coupure des services répliqués.
• Sauvegardes restaurées lors d’exercices planifiés, pas seulement configurées.

Améliorations possibles

• Bascule complète sur l’API Gateway à la place des ressources Ingress.
• Chaos engineering léger pour éprouver les sondes de façon systématique.
• Réduction de l’empreinte mémoire de la pile d’observabilité.