Avant de parler de Kubernetes, il faut des machines. Sur un lab maison, on ne les achète pas : on les crée. C'est le rôle de KVM et de libvirt, la pile de virtualisation standard sous Linux — celle qui fait tourner une bonne partie des clouds publics, et qui est déjà dans votre noyau.
KVM, libvirt, QEMU : qui fait quoi
Ces trois noms reviennent toujours ensemble et désignent trois choses différentes.
- KVM (Kernel-based Virtual Machine) est un module du noyau Linux. Il transforme le noyau en hyperviseur en s'appuyant sur les instructions de virtualisation du processeur. C'est lui qui fait qu'une machine virtuelle exécute son code directement sur le processeur, à pleine vitesse, au lieu d'être émulée.
- QEMU fournit tout le reste : la carte réseau virtuelle, le contrôleur disque, l'écran, le clavier. Sans KVM, QEMU sait tout émuler — lentement. Avec KVM, il ne s'occupe plus que des périphériques.
- libvirt est la couche d'administration : une bibliothèque, un démon et des outils qui donnent un vocabulaire commun — définir une machine, la démarrer, l'arrêter, créer un réseau virtuel, gérer des disques. C'est à libvirt que l'on parle au quotidien, pas à QEMU.
Une image mentale utile : KVM est le moteur, QEMU la carrosserie, libvirt le tableau de bord.
Vérifier que la machine sait virtualiser
grep -Eoc '(vmx|svm)' /proc/cpuinfo # > 0 : virtualisation matérielle disponible
vmx pour Intel, svm pour AMD. Si le compteur renvoie zéro, la fonction est probablement désactivée dans le BIOS/UEFI — c'est le cas le plus fréquent.
Installer la pile
sudo apt install -y qemu-kvm libvirt-daemon-system virtinst virt-manager sudo usermod -aG libvirt,kvm "$USER" # puis se déconnecter/reconnecter
Quatre paquets, quatre rôles : l'hyperviseur, le démon d'administration, l'outil en ligne de commande virt-install, et l'interface graphique virt-manager — pratique pour suivre une installation à l'écran.
L'ajout aux groupes libvirt et kvm évite d'avoir à passer par sudo pour chaque opération. Il ne prend effet qu'à la reconnexion : c'est le piège classique du premier jour.
Les réseaux virtuels : la partie qu'on néglige
virsh net-list --all
Libvirt fournit d'office un réseau default en NAT : les VM sortent vers Internet, mais ne sont pas joignables depuis l'extérieur. Parfait pour une machine isolée, insuffisant pour un lab.
Pour le lab, on ajoute un réseau interne dédié — ici lan_interne_infra, en 192.168.50.0/24 — sur lequel toutes les machines se parlent. Deux propriétés le rendent intéressant :
- il est sans DHCP libvirt : c'est notre propre passerelle qui distribuera les adresses, comme sur un vrai réseau ;
- l'hôte y possède une adresse, ce qui permet d'administrer les VM en SSH sans passer par la passerelle.
Créer une machine virtuelle
Deux étapes : les disques, puis la machine.
Un disque système, un disque de données, une interface sur le réseau interne : la commande décrit toute la machine.
Le format qcow2 mérite un mot : il n'occupe sur le disque que ce qui est réellement écrit — un disque déclaré de 20 Gio en occupe deux au départ — et sait gérer des instantanés. C'est le format par défaut, et il n'y a en pratique aucune raison d'y renoncer.
Dans la commande virt-install, les options qui comptent :
--diskrépété : un disque système et un disque de données, ce dernier étant réservé au stockage distribué (voir l'article Longhorn) ;--network network=lan_interne_infra: la machine ne voit que le réseau du lab. La passerelle, elle, en aura deux ;--os-variant: indique à libvirt le système invité, ce qui règle automatiquement les bons pilotes et paramètres matériels ;--noautoconsole: la commande rend la main immédiatement ; on suit l'installation depuisvirt-managerou en console.
Les commandes du quotidien
virsh list --all # machines définies et leur état virsh start kube-01 # démarrer virsh shutdown kube-01 # arrêt propre (ACPI) virsh console kube-01 # console série (Ctrl+] pour sortir) virsh domifaddr kube-01 # adresses IP vues par libvirt virsh autostart kube-01 # démarrage automatique avec l'hôte virsh undefine kube-01 # supprimer la définition (le disque reste)
Et pour les instantanés, l'arme absolue du lab :
virsh snapshot-create-as kube-01 avant-manip --disk-only --atomic virsh snapshot-list kube-01
Prendre un instantané avant chaque manipulation risquée transforme un lab en terrain d'expérimentation sans conséquence. C'est la principale différence entre apprendre sur des machines virtuelles et apprendre sur du matériel.
Un mot sur l'organisation
Une arborescence dédiée par projet — un répertoire pour les disques, un pour les scripts, un pour les captures — évite de retrouver six mois plus tard un fichier test2.qcow2 de 20 Gio dont personne ne sait s'il est encore utile. Sur un lab qui vit, c'est du temps gagné.
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 :