KubeVirt : faire tourner des VM dans Kubernetes

KubeVirt fait tourner des machines virtuelles comme des ressources Kubernetes natives, à côté de vos conteneurs, dans le même cluster. Chaque VM s'exécute dans un pod, pilotée par des CRDs (VirtualMachine, VirtualMachineInstance), et bénéficie du scheduling, du réseau et du stockage de Kubernetes. C'est le projet CNCF qui unifie deux mondes historiquement séparés, sans réécrire vos charges existantes en conteneurs. Ce hub ouvre un parcours qui va de l'architecture à l'exploitation : concepts, installation (même sans /dev/kvm), création de VM, stockage, réseau, migration à chaud et écosystème. Version de référence : KubeVirt v1.8. Public : intermédiaire à avancé, à l'aise avec kubectl.

Comment KubeVirt fait-il tourner une VM dans Kubernetes ?

KubeVirt ajoute au cluster cinq composants et deux ressources personnalisées, puis exécute chaque machine virtuelle dans un pod dédié appelé virt-launcher. Le processus QEMU de la VM tourne à l'intérieur de ce pod, donc dans les cgroups, le namespace réseau et le stockage que Kubernetes lui attribue : c'est ce qui rend une VM administrable avec les mêmes outils qu'un conteneur.

Les composants se répartissent les rôles. virt-operator installe et met à jour l'ensemble. virt-api expose l'API agrégée qui reçoit les commandes (console, VNC, migration). virt-controller réconcilie l'état voulu des VM et orchestre les opérations comme la migration à chaud. virt-handler est un DaemonSet, donc un agent par nœud, qui traduit cet état en actions sur le libvirt local. virt-launcher, enfin, est créé à la demande, un par VM en cours d'exécution.

Côté modèle de données, deux objets se répondent et leur distinction est la source de confusion la plus fréquente : la ressource VirtualMachine décrit l'état stable et désiré de la machine, alors que VirtualMachineInstance représente l'instance en cours d'exécution, éphémère, celle qui reçoit une adresse IP. Arrêter une VM détruit la seconde sans toucher à la première. Le détail complet se trouve dans Architecture et concepts.

Peut-on tester KubeVirt sans serveur bare-metal ?

Oui : KubeVirt bascule QEMU en émulation logicielle avec le champ useEmulation: true, ce qui permet un lab complet sur un poste sans /dev/kvm. C'est le cas d'une machine virtuelle imbriquée, d'un ordinateur portable dont le BIOS n'expose pas la virtualisation matérielle, ou d'un runner d'intégration continue.

Le réglage se pose dans la ressource KubeVirt qui pilote l'installation, sous spec.configuration.developerConfiguration. QEMU passe alors en mode TCG, qui traduit les instructions au lieu de les exécuter directement sur le processeur : le démarrage d'une VM se compte en minutes plutôt qu'en secondes, mais toutes les fonctions du parcours restent utilisables sur un simple cluster k3d ou minikube. En production, on revient évidemment à la virtualisation matérielle. La procédure complète, y compris le symptôme d'une VMI bloquée en Scheduling quand l'émulation manque, est détaillée dans Installer KubeVirt.

Que contient le parcours KubeVirt, et où en est-il ?

Le parcours va du socle conceptuel aux opérations avancées. Les modules cœur (1 à 8) suffisent à exploiter KubeVirt en pratique ; les extensions (9 à 12) couvrent le matériel, Windows et l'écosystème. Trois modules sont publiés à ce jour, les autres sont en cours d'écriture : le tableau indique l'état réel de chacun, pour que vous sachiez ce qui est disponible avant de vous lancer.

Module	Sujet	Niveau	Statut
1	Architecture et concepts (VM, VMI, virt-*)	débutant	Disponible
2	Installer KubeVirt (lab en émulation)	débutant	Disponible
3	Créer et gérer une VM (runStrategy, cloud-init, accès)	débutant	Disponible
4	instancetypes et preferences	intermédiaire	À venir
5	Images et stockage avec CDI	intermédiaire	À venir
6	Réseau : masquerade, bridge, exposer via Service	intermédiaire	À venir
7	Live migration	intermédiaire	À venir
8	Snapshots, clones et sauvegarde	intermédiaire	À venir
9	VM Windows	avancé	À venir
10	Performance et matériel (GPU, hugepages, CPU dédié)	avancé	À venir
11	Réseau avancé (Multus, passt, SR-IOV)	avancé	À venir
12	Écosystème et migration (MTV, Harvester, CAPK)	intermédiaire	À venir

Les prérequis sont réels : un cluster Kubernetes fonctionnel et l'aise avec kubectl. KubeVirt exige des pods privilégiés pour virt-handler, ce que k3d et k3s autorisent par défaut mais qu'un cluster durci refusera tant que le namespace kubevirt n'aura pas été explicitement autorisé.

Pourquoi utiliser KubeVirt plutôt que deux plateformes séparées ?

Parce que maintenir un hyperviseur et un cluster Kubernetes en parallèle revient à payer deux fois le réseau, le stockage, le RBAC et la chaîne d'outils. Beaucoup d'organisations ont un pied dans chaque monde : des conteneurs pour les nouvelles applications, des machines virtuelles pour l'existant, bases de données, appliances, systèmes Windows et logiciels non conteneurisables.

Sans KubeVirt	Avec KubeVirt
Un hyperviseur (VMware, Proxmox) et un cluster Kubernetes, gérés séparément	Une seule plateforme : VM et conteneurs dans le même cluster
Deux modèles de réseau, de stockage, de RBAC	Le réseau, le stockage et le RBAC de Kubernetes, partagés
VM pilotées par une console propriétaire	VM pilotées en GitOps comme n'importe quelle ressource Kubernetes
Migration cloud native = tout réécrire en conteneurs	On déplace les VM telles quelles, on conteneurise ensuite à son rythme

Le contexte a accéléré l'intérêt : les bouleversements tarifaires côté VMware poussent de nombreuses équipes à chercher une sortie, et faire tourner leurs VM sur Kubernetes en est une, sans jeter le modèle VM. Je le défends comme une voie de transition réaliste : on ne conteneurise pas une appliance Windows du jour au lendemain, mais on peut déjà la rapatrier dans le cluster et lui appliquer les mêmes pratiques que le reste, à commencer par la déclaration en YAML et la revue de changement.

KubeVirt, OpenShift Virtualization ou Harvester : lequel choisir ?

KubeVirt est le moteur, les deux autres sont des produits qui l'empaquettent avec un niveau de service différent. Le choix se joue sur ce que vous voulez assembler vous-même et sur le support dont vous avez besoin.

KubeVirt upstream (ce parcours) : la brique CNCF, à installer sur un cluster existant. Contrôle total, montée en compétence maximale, aucune console fournie.
OpenShift Virtualization : la distribution supportée par Red Hat de KubeVirt, intégrée à OpenShift. Même moteur, avec support commercial et console intégrée.
Harvester : une infrastructure hyperconvergée clé en main bâtie sur KubeVirt, Longhorn et Rancher. Pour qui veut une appliance de virtualisation, pas un cluster à composer.
Hyperviseurs classiques (Proxmox VE, oVirt, vSphere) : plus simples si vous n'avez que des VM et pas de Kubernetes. KubeVirt ne devient intéressant qu'à partir du moment où vous voulez unifier VM et conteneurs.

Ma position : commencez par KubeVirt upstream pour comprendre le moteur, parce que c'est lui qui tourne dans les trois cas. Choisissez ensuite Harvester si vous voulez une plateforme prête à l'emploi, ou OpenShift Virtualization si vous exploitez déjà OpenShift et avez besoin d'un support éditeur.

Ce que ce parcours couvre, et ce qu'il ne couvre pas

Un parcours qui annonce son périmètre évite les déceptions. Celui-ci se concentre sur KubeVirt lui-même et suppose que le cluster est déjà là, opéré par ailleurs.

Couvert : l'installation par l'opérateur, le cycle de vie des VM, le stockage via CDI, le réseau, la migration à chaud, la sauvegarde et le positionnement dans l'écosystème.
Non couvert en profondeur : l'administration d'un cluster Kubernetes de production, traitée dans le parcours Kubernetes ; le stockage distribué sous-jacent (CSI, Longhorn, Ceph) ; le design réseau CNI avancé. Ces sujets ont leurs propres sections, et les mélanger ici rendrait le parcours illisible.

Quelles sont les nouveautés de KubeVirt v1.6 à v1.8 ?

KubeVirt publie plusieurs versions mineures par an, et certaines changent le comportement par défaut : il faut lire les notes avant de mettre à jour. Les trois dernières apportent chacune une évolution structurante, dont une rupture à connaître.

v1.6 (2025-07) : la stratégie de rollout LiveUpdate devient le défaut, ce qui constitue une rupture de comportement ; InstancetypeReferencePolicy passe en GA ; DRA arrive pour les GPU.
v1.7 (2025-11) : migration à chaud décentralisée, entre namespaces et entre clusters ; évacuation annulable ; retrait de l'API instancetype v1alpha.
v1.8 (2026-03) : couche d'abstraction multi-hyperviseur, attestation Intel TDX pour le confidential computing, sauvegarde incrémentale via Changed Block Tracking, et suppression des anciens bindings réseau macvtap et SLIRP.

Les deux points à surveiller lors d'une montée de version sont donc le passage en LiveUpdate et la disparition de macvtap et SLIRP : une VM qui s'appuyait sur l'un de ces bindings ne démarrera plus après la mise à jour.

À retenir

KubeVirt exécute des machines virtuelles comme des objets Kubernetes, dans un pod virt-launcher qui héberge le processus QEMU.
Cinq composants portent le service : virt-operator, virt-api, virt-controller, virt-handler (un par nœud) et virt-launcher (un par VM active).
La ressource VirtualMachine décrit l'état désiré, VirtualMachineInstance l'exécution en cours, éphémère et porteuse de l'adresse IP.
Sans /dev/kvm, useEmulation: true fait tourner un lab complet en mode TCG, plus lent mais fonctionnel.
Trois modules sur douze sont publiés à ce jour : concepts, installation et création de VM.
KubeVirt n'a d'intérêt que si vous voulez unifier VM et conteneurs ; avec des VM seules, un hyperviseur classique reste plus simple.

Prochaines étapes

Architecture et concepts Les cinq composants, les CRDs et le cycle de vie d'une VM.

Installer KubeVirt L'opérateur, le mode émulation et la vérification du déploiement.

Créer et gérer une VM runStrategy, cloud-init, console et accès SSH.

La virtualisation KVM Le moteur qui exécute réellement les VM, sous KubeVirt comme ailleurs.

Orchestrer avec Kubernetes Le parcours du cluster, prérequis à toute exploitation de KubeVirt.

Panorama de la virtualisation Situer KubeVirt parmi les autres familles d'hyperviseurs.