KubeVirt : faire tourner des VM dans Kubernetes

10 min

Par Stéphane Robert mis à jour le 15 octobre 2026

Améliorer cette page

Que voulez-vous signaler ?

L’issue s’ouvre déjà remplie avec le titre et l’adresse de cette page.

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 et se pilote par des CRDs (VirtualMachine, VirtualMachineInstance), c'est-à-dire des types d'objets que KubeVirt ajoute à l'API de Kubernetes. Le projet CNCF unifie ainsi deux mondes historiquement séparés, sans réécrire vos charges existantes en conteneurs. Ce module facultatif, « Des VM dans Kubernetes », couvre l'architecture, l'installation (même sans /dev/kvm) et la création d'une première VM. Version de référence : KubeVirt v1.9 (v1.9.1). Public : à l'aise avec kubectl, les pods et les manifestes.

Pourquoi ce module vient après les fondamentaux de la virtualisation

Ce module est facultatif et se place en dernier, parce qu'il réutilise tout ce qui précède. Il suppose que vous savez ce qu'est une machine virtuelle, ce qui distingue un hyperviseur de type 1 d'un hyperviseur de type 2 et que KVM est le moteur de virtualisation du noyau Linux, présenté dans KVM : qu'est-ce que c'est ?. KubeVirt ne remplace pas ce moteur : il le pilote depuis Kubernetes.

Il suppose aussi les bases de Kubernetes, qui ne sont pas réexpliquées ici : pods, manifestes YAML, kubectl et namespaces. Si ces notions sont nouvelles, le parcours Kubernetes les enseigne, et vous pouvez revenir à ce module ensuite sans rien perdre du reste de la formation.

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 : la VM est nettement plus lente qu'avec la virtualisation matérielle, mais toutes les fonctions du module 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.

Comment les leçons du module s'enchaînent-elles ?

Le module suit l'ordre naturel d'un premier contact : comprendre, installer, utiliser. Trois leçons suivent cette introduction, et chacune réutilise le vocabulaire de la précédente.

Architecture et concepts pose le vocabulaire : les cinq composants virt-*, les CRDs et le cycle de vie d'une VM. La section précédente de cette page en donne un aperçu, la leçon le détaille.
Installer KubeVirt sur un cluster de lab déploie l'opérateur, active l'émulation logicielle et vérifie le résultat avec une première VM minuscule.
Créer et gérer une VM avec KubeVirt écrit un manifeste complet, pilote le démarrage avec runStrategy et virtctl, injecte cloud-init et ouvre la console et SSH.

Le fil est simple : les concepts expliquent ce que vous installez, l'installation fournit le cluster prêt et la dernière leçon s'en sert. Il faut un cluster Kubernetes fonctionnel pour les deux dernières. KubeVirt exige des pods privilégiés pour virt-handler, ce que k3d et k3s autorisent par défaut mais qu'un cluster durci refuse tant que le namespace kubevirt n'est pas 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 module) : 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.

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

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 quatre 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.
v1.9 (2026-07) : toutes les feature gates en Beta sont activées par défaut (dont Template, qui déploie les composants virt-template-*), compression zstd de la migration à chaud, VMExport en GA, cgroup v1 déprécié (retrait prévu en 1.10).

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.
Le module compte trois leçons après cette introduction : concepts, installation et création de VM, dans cet ordre.
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.