Monter un Kubernetes chez soi, ce n'est pas taper trois commandes trouvées sur un blog. C'est d'abord décider où passent les flux, qui distribue les adresses, qui résout les noms, et où atterrissent les données. Cet article ouvre une série consacrée à un lab complet : trois nœuds K3S en haute disponibilité, du stockage répliqué, un équilibreur de charge et un reverse-proxy — le tout sur une seule machine physique.
Ce que l'on cherche à obtenir
L'objectif n'est pas un démonstrateur qui affiche « hello world ». C'est une infrastructure cohérente, dont on comprend chaque pièce : ce qui est déployé, pourquoi, et comment les composants interagissent. Concrètement, le lab doit permettre de :
- déployer un cluster Kubernetes en haute disponibilité, sans point de défaillance unique ;
- exposer des applications de façon standardisée, sans bricoler une règle réseau par service ;
- gérer du stockage persistant réparti sur plusieurs nœuds ;
- et surtout débrancher un nœud pour voir ce qui se passe — c'est tout l'intérêt d'un lab.
Le plan d'ensemble
Cinq machines virtuelles sur un réseau interne dédié, plus une passerelle qui fait la jonction avec le reste du monde.
Tout tient sur un hôte Ubuntu 24.04 équipé de KVM et libvirt. Cinq machines virtuelles y vivent :
- une passerelle — deux interfaces réseau : une vers le réseau de la maison et Internet, une vers le réseau interne du lab. Elle route, fait du NAT, distribue les adresses en DHCP et résout les noms en DNS ;
- trois nœuds Kubernetes (kube-01, kube-02, kube-03) — 2 vCPU, 4 Gio de mémoire, un disque système et un second disque dédié au stockage distribué ;
- un poste client, pour tester les services comme le ferait un utilisateur, depuis l'intérieur du lab.
Deux réseaux virtuels seulement : le réseau NAT par défaut de libvirt, qui sert d'accès Internet à la passerelle, et un réseau interne 192.168.50.0/24 sur lequel discutent toutes les machines du lab. L'hôte y a lui-même une patte, ce qui permet d'administrer les VM directement.
Trois décisions qui structurent tout le reste
1. Les services d'infrastructure restent hors du cluster
DHCP, DNS et routage vivent sur une machine dédiée, pas dans Kubernetes. C'est la pratique recommandée, et la raison est simple : si le DNS du lab tournait dans le cluster, un cluster en panne deviendrait un cluster impossible à diagnostiquer. On ne met pas les clés de la maison à l'intérieur de la maison.
2. Les trois nœuds font tout
Chaque nœud est à la fois control-plane (il héberge l'API Kubernetes), membre du datastore etcd (il stocke l'état du cluster) et worker (il exécute les applications). Sur un lab à trois machines, séparer les rôles n'apporterait rien et coûterait des ressources.
Le point important est le quorum : etcd a besoin de la majorité de ses membres pour fonctionner, soit deux nœuds sur trois. Perdre un nœud ne perturbe donc ni le cluster ni ses données de configuration. Perdre deux nœuds, si — et c'est exactement pour cela qu'on monte trois machines et non deux.
3. Un second disque par nœud, réservé aux données
Chaque nœud a un disque système et un disque de 20 Gio monté sur /opt/data, exclusivement destiné au stockage distribué. Mélanger les données applicatives et le système sur le même volume est la garantie qu'un jour, un volume qui se remplit emportera le nœud avec lui.
Le trajet d'une requête, du navigateur au conteneur
Une fois l'ensemble en place, accéder à une application du lab suit toujours le même chemin :
- l'utilisateur demande application.cluster.labk3s.ev1 ;
- le DNS wildcard de la passerelle résout ce nom — et tous ses voisins — vers une adresse IP unique ;
- MetalLB fait vivre cette adresse sur le réseau, portée par l'un des trois nœuds ;
- Traefik reçoit la requête, lit le nom d'hôte demandé et la route vers le bon service ;
- le conteneur accède à ses données via un volume Longhorn, répliqué sur les trois nœuds.
Chacune de ces briques fait l'objet d'un article de la série. L'ordre n'est pas décoratif : on ne peut pas installer proprement les nœuds sans DHCP et DNS, ni exposer un service sans adresse stable, ni prétendre à la haute disponibilité sans stockage répliqué.
Le matériel nécessaire
Rien d'extravagant : une machine capable de faire tourner cinq VM, soit environ 10 vCPU cumulés, 20 Gio de mémoire et 150 Gio de disque. Un ordinateur de bureau récent suffit. Le lab décrit ici tourne sur un poste Ubuntu de travail, à côté de tout le reste.
Le pas à pas détaillé est sur le wiki
Cet article ne remplace pas la documentation : il en explique les choix. L'intégralité de la démarche — commandes, sorties d'écran, vérifications et captures — est publiée sur mon wiki, dans la section Datacenter / Cluster K3S. Pages correspondant à cet article :
La série « Lab Kubernetes maison »
Cet article fait partie d'une série qui monte, pas à pas, un cluster Kubernetes complet sur une seule machine physique :