Ce laboratoire a pour objectif de mettre en œuvre une plateforme Kubernetes on‑premise réaliste, à échelle réduite, en s’appuyant sur des choix techniques proches de ceux rencontrés en environnement de production.
L’ambition n’est pas de proposer un simple démonstrateur fonctionnel, mais bien de construire une infrastructure cohérente, permettant de comprendre ce qui est déployé, pourquoi cela l’est, et comment chaque composant interagit avec les autres.
Le LAB vise ainsi à :
Dans ce cadre, le LAB mettra en œuvre les briques Kubernetes suivantes :
L’architecture du LAB repose sur une séparation volontaire et claire des responsabilités, inspirée des bonnes pratiques observées en production.
Une machine dédiée joue le rôle de passerelle d’infrastructure réseau, tandis que le cœur de la plateforme est constitué d’un cluster Kubernetes K3s à trois nœuds, configuré en haute disponibilité. Le stockage persistant est assuré par Longhorn, une solution de stockage distribuée native Kubernetes. Enfin, l’exposition des services applicatifs s’appuie sur un Ingress associé à une résolution DNS par wildcard.
Longhorn est une solution de stockage bloc distribuée, conçue spécifiquement pour Kubernetes. Elle permet de fournir des volumes persistants répliqués sur plusieurs nœuds du cluster, garantissant la continuité des données même en cas de défaillance matérielle.
L’Ingress, quant à lui, constitue le point d’entrée logique des flux HTTP/HTTPS vers le cluster. Il permet d’exposer plusieurs applications derrière une seule adresse IP, en s’appuyant sur des noms de domaine et des règles de routage.
Le LAB est hébergé sur un hôte de virtualisation KVM/libvirt existant. Toutes les machines virtuelles du LAB reposent sur le système d’exploitation Ubuntu Linux 24.04 LTS, choisi pour sa stabilité et son adéquation aux environnements serveurs.
Chaque machine virtuelle Kubernetes est configurée avec deux disques distincts :
Deux réseaux virtuels sont utilisés :
default) permettant l’accès au LAN habituel et à Internet,Une machine virtuelle dédiée assure le rôle de passerelle du LAB. Ce choix permet de maintenir les services d’infrastructure critiques en dehors du cluster Kubernetes, conformément aux pratiques recommandées.
Cette passerelle fournit :
labk3s.ev1,Le wildcard DNS *.cluster.labk3s.ev1 est résolu vers l’adresse IP exposée par le cluster Kubernetes, garantissant un accès uniforme à l’ensemble des services applicatifs.
Le cluster Kubernetes constitue le cœur fonctionnel du LAB. Il est composé de trois nœuds, tous installés sous Ubuntu 24.04 LTS et participant pleinement au fonctionnement du cluster.
Chaque nœud remplit simultanément trois rôles :
Le cluster est déployé en mode haute disponibilité. Le plan de contrôle est réparti sur les trois nœuds, évitant tout point de défaillance unique.
K3s intègre un etcd embarqué, distribué sur les trois nœuds. Etcd stocke l’état du cluster (objets Kubernetes, configurations, secrets) et fonctionne selon un mécanisme de quorum.
Le cluster nécessite la présence d’au moins deux nœuds sur trois pour rester opérationnel. La perte d’un nœud n’entraîne donc ni arrêt du cluster ni perte de données de configuration.
L’exposition des services applicatifs repose sur deux composants complémentaires.
MetalLB fournit une implémentation du type LoadBalancer dans un environnement on‑premise. Il attribue au cluster une adresse IP stable (192.168.50.250) annoncée sur le réseau interne en mode Layer 2. En cas de défaillance du nœud porteur, l’annonce IP est automatiquement reprise par un autre nœud.
Traefik agit comme Ingress Controller. Il reçoit le trafic HTTP/HTTPS arrivant sur l’adresse IP fournie par MetalLB et le redirige vers les services Kubernetes appropriés, en fonction des noms de domaine demandés.
Cette combinaison permet d’exposer plusieurs applications via une seule adresse IP, de manière propre et extensible.
Dans Kubernetes, un PersistentVolumeClaim (PVC) est une demande de stockage émise par une application. Longhorn répond à ces demandes en créant dynamiquement des volumes persistants, sans intervention manuelle.
Chaque volume Longhorn est configuré avec trois réplicas, un par nœud du cluster. Les écritures sont synchronisées entre les réplicas, garantissant la cohérence des données. En cas de perte d’un nœud, les deux réplicas restants assurent la continuité du service.
Longhorn permet de créer des snapshots des volumes, représentant un état figé des données à un instant donné. Ces snapshots peuvent être utilisés pour :
La restauration consiste à réattacher un volume à partir d’un snapshot existant, sans impact sur le reste du cluster.
Lorsqu’un utilisateur accède à une application hébergée sur le LAB, le flux est le suivant :
L’utilisateur interroge un nom de domaine du type application.cluster.labk3s.ev1.
Le DNS wildcard résout ce nom vers l’adresse IP du cluster.
MetalLB fournit cette adresse IP au niveau réseau.
Traefik reçoit la requête et la route vers le service Kubernetes correspondant.
Le pod applicatif accède à ses données via un volume Longhorn répliqué sur les trois nœuds.