🖥️ KubeVirt : faire tourner des machines virtuelles dans Kubernetes

📚 Introduction

Ton infra est passée à Kubernetes. Les applications sont en conteneurs, la CI construit des images, Argo CD synchronise le cluster sur Git. Et puis il reste ça : une VM Windows pour un logiciel métier, une appliance réseau livrée en qcow2, un vieux serveur applicatif dont personne n’a plus les sources. Elle tourne sur un hyperviseur à part, avec sa propre console, ses propres sauvegardes et ses propres droits d’accès.

Deux plateformes à maintenir pour une seule plateforme de charges de travail. C’est exactement le problème que KubeVirt attaque : plutôt que de containeriser cette VM de force, il la fait entrer dans le cluster telle quelle, décrite en YAML et pilotée par kubectl.

Le projet est entré à la CNCF en septembre 2019 et est passé en incubation le 19 avril 2022. La version stable au moment où j’écris est la v1.9.0, sortie fin juillet 2026 et construite pour Kubernetes v1.36.

🔎 Comment une VM devient-elle une ressource Kubernetes ?

Par des CRD et un pod, essentiellement. KubeVirt enregistre de nouveaux types dans l’API — VirtualMachine, VirtualMachineInstance, VirtualMachineInstanceMigration — puis fait tourner chaque machine dans un pod ordinaire nommé virt-launcher, qui encapsule libvirtd et QEMU.

Cette encapsulation est tout l’intérêt du projet. Le scheduler place la VM comme il placerait un pod. Les requests et limits s’appliquent. Le RBAC vaut pour la VM comme pour le reste. Et le manifeste de la machine se commit à côté des Deployments.

Autour de ce pod, l’opérateur installe trois composants dans le namespace kubevirt : virt-api pour l’API et les webhooks, virt-controller pour la logique de cycle de vie, et virt-handler, un DaemonSet qui pilote les VM sur chaque noeud, aux côtés du kubelet.

🚀 Installer KubeVirt

L’installation se fait en deux manifestes : l’opérateur, puis la ressource personnalisée qui lui dit de se déployer.

export VERSION=$(curl -s https://storage.googleapis.com/kubevirt-prow/release/kubevirt/kubevirt/stable.txt)
kubectl create -f "https://github.com/kubevirt/kubevirt/releases/download/${VERSION}/kubevirt-operator.yaml"
kubectl create -f "https://github.com/kubevirt/kubevirt/releases/download/${VERSION}/kubevirt-cr.yaml"
 
kubectl -n kubevirt wait kv kubevirt --for condition=Available

Il faut ensuite virtctl, le CLI qui fait ce que kubectl ne sait pas faire sur une VM : démarrer, ouvrir une console série, brancher un écran VNC. Il s’installe aussi en plugin kubectl via krew.

kubectl krew install virt

Côté prérequis, l’apiserver doit tourner avec --allow-privileged=true, et les noeuds ont tout intérêt à exposer KVM — virt-host-validate le vérifie. Sur un cluster k3s de dev sans virtualisation imbriquée, l’émulation logicielle dépanne via spec.configuration.developerConfiguration.useEmulation: true dans la CR. C’est lent. Pour du test d’API, ça suffit.

🧱 VirtualMachine et VirtualMachineInstance

Deux objets, une nuance qui compte. Le VirtualMachineInstance est la machine qui tourne : la supprimer, c’est l’éteindre pour de bon, sans possibilité de la relancer. Le VirtualMachine est l’objet durable qui décrit la machine et son état souhaité ; c’est lui qui fabrique un VMI quand on démarre, et lui qu’on versionne.

Voici le manifeste d’exemple du guide officiel, dans sa forme minimale :

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: testvm
spec:
  runStrategy: Halted
  template:
    metadata:
      labels:
        kubevirt.io/size: small
        kubevirt.io/domain: testvm
    spec:
      domain:
        devices:
          disks:
            - name: containerdisk
              disk:
                bus: virtio
          interfaces:
            - name: default
              masquerade: {}
        resources:
          requests:
            memory: 64M
      networks:
        - name: default
          pod: {}
      volumes:
        - name: containerdisk
          containerDisk:
            image: quay.io/kubevirt/cirros-container-disk-demo

runStrategy: Halted crée la machine sans la démarrer. Le reste se pilote au CLI :

virtctl start testvm
virtctl console testvm    # ctrl+] pour sortir
virtctl pause vm testvm
virtctl stop testvm

Le containerDisk utilisé ici embarque l’image disque dans une image de conteneur : pratique pour une démo, éphémère par nature. Pour une VM qui doit garder son état, on passe par un PVC alimenté par CDI (Containerized Data Importer), le projet frère qui importe une image qcow2 depuis une URL, un registre ou un upload local dans un DataVolume.

export TAG=$(curl -s -o /dev/null -w %{redirect_url} https://github.com/kubevirt/containerized-data-importer/releases/latest)
export VERSION=$(echo ${TAG##*/})
kubectl create -f https://github.com/kubevirt/containerized-data-importer/releases/download/$VERSION/cdi-operator.yaml
kubectl create -f https://github.com/kubevirt/containerized-data-importer/releases/download/$VERSION/cdi-cr.yaml

🧰 Instance types, préférences et réseau

Recopier le même bloc CPU/mémoire dans quinze manifestes n’a aucun intérêt. KubeVirt propose pour ça deux paires de CRD : VirtualMachineInstancetype (et sa variante cluster) fige les ressources — CPU, mémoire, GPU, périphériques hôte —, tandis que VirtualMachinePreference décrit les choix préférés de topologie et de périphériques. La différence est nette : ce que fixe un instance type ne peut pas être surchargé dans la VM, ce que suggère une préférence, si.

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: example-vm
spec:
  instancetype:
    kind: VirtualMachineInstancetype
    name: example-instancetype
  preference:
    kind: VirtualMachinePreference
    name: example-preference
  runStrategy: Always

Côté réseau, la VM se branche par défaut sur le réseau du pod. Le binding masquerade est celui que recommande la documentation : la machine reçoit une adresse interne cachée derrière du NAT, ce qui évite les frictions avec les solutions tierces que provoque le binding bridge. Pour un VLAN dédié ou une seconde carte, Multus attache des réseaux secondaires, à raison d’une interface déclarée par réseau.

🎯 Migration à chaud et snapshots

C’est là que le pari devient intéressant : la migration à chaud, activée par défaut depuis longtemps, déplace un VMI d’un noeud à l’autre pendant que la charge continue de tourner.

virtctl migrate vmi-fedora
virtctl migrate-cancel vmi-fedora

La même chose se déclare en YAML, ce qui la rend automatisable comme le reste :

apiVersion: kubevirt.io/v1
kind: VirtualMachineInstanceMigration
metadata:
  name: migration-job
spec:
  vmiName: vmi-fedora

Les sauvegardes suivent la même logique avec le groupe d’API snapshot.kubevirt.io, qui s’appuie sur les VolumeSnapshot du driver CSI sous-jacent. Si l’agent invité QEMU est présent, le contrôleur gèle les systèmes de fichiers avant la capture, ce qui donne un instantané nettement plus propre.

apiVersion: snapshot.kubevirt.io/v1beta1
kind: VirtualMachineSnapshot
metadata:
  name: snap-larry
spec:
  source:
    apiGroup: kubevirt.io
    kind: VirtualMachine
    name: larry

Et puisque tout ça reste du YAML dans l’API Kubernetes, une VM se déploie en GitOps et se surveille avec la stack Prometheus habituelle. Un seul jeu d’outils pour les deux mondes.

⚠️ Quelques précautions

• Le stockage décide de ce que tu pourras faire. La migration à chaud exige des volumes en ReadWriteMany, et les snapshots demandent un StorageClass couvert par un VolumeSnapshotClass. Un cluster monté sur du local-path ne fera ni l’un ni l’autre.
• Le feature gate Snapshot doit être ajouté à la liste des feature gates de la CR KubeVirt pour que l’API snapshot réponde. Sans VolumeSnapshotClass, la sauvegarde se limite à la configuration de la VM.
• Le binding bridge bloque la migration à chaud, tout comme les ports 49152-49153 s’ils ne sont pas joignables dans le pod virt-launcher. Le choix du binding réseau n’est pas qu’une affaire de connectivité.
• KubeVirt n’est pas une plateforme de virtualisation clé en main. Pas d’interface web, pas d’inventaire, pas d’assistant de création. C’est une API. Si tu cherches l’équivalent d’un Proxmox VE, regarde plutôt Harvester ou OpenShift Virtualization, qui posent une couche produit par-dessus.
• La v1.9 active par défaut tous les feature gates en bêta. Bonne nouvelle pour l’ergonomie, point de vigilance lors d’une montée de version : relis les notes de release avant de mettre à jour un cluster en production.

🎉 Conclusion

KubeVirt ne rend pas les VM plus modernes, et ce n’est pas son ambition. Il supprime la seconde plateforme. Ton hyperviseur, ton ordonnanceur, ton RBAC et ton pipeline de déploiement deviennent les mêmes pour un conteneur et pour une machine complète, ce qui vaut surtout quand la migration vers les conteneurs s’étale sur des années et qu’il faut bien opérer les deux en attendant.

Le prix à payer est réel : des exigences de stockage plus strictes qu’un hyperviseur classique, une couche de plus à diagnostiquer, et une ergonomie qui suppose d’être déjà à l’aise avec l’API Kubernetes. Sur un cluster déjà en place et déjà maîtrisé, c’est un bon marché.

🔗 Liens utiles

• Site officiel de KubeVirt
• Guide utilisateur — installation
• Architecture de KubeVirt
• Instance types et préférences
• Migration à chaud
• Containerized Data Importer (CDI)
• Notes de release
• Page projet KubeVirt sur le site de la CNCF
• Harvester, la distribution HCI bâtie sur KubeVirt