Architecture et concepts de KubeVirt (VM, VMI, virt-*)

KubeVirt ne réinvente pas la virtualisation : il réutilise KVM/QEMU (via libvirt), la même pile que les hyperviseurs Linux classiques, et l'expose comme des ressources Kubernetes. Le pari est simple : déléguer à Kubernetes tout ce qu'il sait déjà faire (scheduling, réseau, stockage, RBAC) et n'ajouter que la couche virtualisation. Ce guide pose le modèle mental avant la pratique. Public : débutant à intermédiaire.

Ce que vous allez apprendre

Situer les composants virt-* et leur rôle.
Distinguer VirtualMachine, VirtualMachineInstance et VMIReplicaSet.
Comprendre le modèle une VM = un pod.
Savoir ce que KubeVirt délègue à Kubernetes.

Qu'est-ce que KubeVirt

KubeVirt est une extension de Kubernetes (un ensemble de contrôleurs et de CRDs) qui permet de définir, démarrer et gérer des machines virtuelles aux côtés des conteneurs. Chaque VM tourne dans un pod : le processus QEMU de la VM s'exécute à l'intérieur d'un conteneur standard, ordonnancé par le scheduler Kubernetes comme n'importe quelle charge.

L'analogie utile : Kubernetes est le chef d'orchestre, KubeVirt lui apprend à diriger un nouvel instrument (la VM) sans changer de partition. La VM hérite alors du réseau de pods, du stockage par PVC et du RBAC du cluster.

Pourquoi ce modèle change la donne

Sans KubeVirt, VM et conteneurs vivent sur deux plateformes distinctes : un hyperviseur d'un côté, un cluster de l'autre, avec deux modèles de réseau, de stockage et de droits. Avec KubeVirt, les deux partagent la même plateforme et les mêmes pratiques : on décrit une VM en YAML, on la versionne en Git, on l'audite avec les mêmes outils que le reste du cluster. C'est ce qui en fait une voie de migration réaliste pour des charges qu'on ne peut pas conteneuriser du jour au lendemain.

Les composants

L'opérateur installe cinq composants, visibles dans le namespace kubevirt :

kubectl get pods -n kubevirt
# virt-operator-...     (x2)   installe et met à jour KubeVirt
# virt-api-...                 point d'entrée API (API agrégée)
# virt-controller-...  (x2)    cycle de vie des VM/VMI, orchestration migration
# virt-handler-...             agent par nœud (DaemonSet), pilote libvirt

virt-operator : déploie et met à jour tous les autres composants (rolling update sans coupure).
virt-api : étend l'API Kubernetes (API agrégée) pour les ressources et sous-ressources KubeVirt (console, VNC, migration).
virt-controller : contrôleur cluster-wide qui réconcilie l'état désiré des VM et orchestre les opérations comme la live migration.
virt-handler : un DaemonSet, donc un agent par nœud, qui traduit l'état voulu en actions sur le libvirt local du nœud.
virt-launcher : créé à la demande, un par VM en cours. Il fournit le pod qui héberge le processus QEMU et une instance libvirt locale au conteneur. Quand la VM tourne, un pod virt-launcher-<vm> apparaît à côté d'elle.

Les CRDs : VM, VMI, VMIReplicaSet

Trois ressources structurent l'usage, du plus stable au plus éphémère.

VirtualMachine (VM) : la définition stable et déclarative. Elle survit aux redémarrages, porte le runStrategy et les opérations start/stop/restart. C'est l'objet que vous versionnez.
VirtualMachineInstance (VMI) : l'instance en cours d'exécution, créée quand la VM démarre. Éphémère : si elle s'arrête, la VM (stable) peut la recréer. C'est la VMI qui reçoit une IP et tourne dans un virt-launcher.
VirtualMachineInstanceReplicaSet (VMIRS) : gère un groupe de VMI identiques, à la manière d'un ReplicaSet de pods. Utile pour des flottes de VM sans état.

Ressource	Rôle	Durée de vie
`VirtualMachine`	Définition, cycle de vie	Persistante
`VirtualMachineInstance`	Exécution réelle (a une IP)	Éphémère
`VMIReplicaSet`	Flotte de VMI similaires	Persistante

Ce que KubeVirt délègue à Kubernetes

C'est le corollaire de l'architecture : KubeVirt n'apporte pas son propre réseau ni son propre stockage.

Réseau : la VM utilise le réseau de pods (CNI), avec des modes de binding (masquerade, bridge) et Multus pour des interfaces multiples.
Stockage : les disques s'appuient sur des PVC et le CSI du cluster ; CDI peuple ces disques à partir d'images.
Ordonnancement et droits : scheduler, affinités, quotas et RBAC de Kubernetes s'appliquent tels quels.

Sécurité par défaut

Depuis les versions récentes, le pod virt-launcher tourne en non-root, ce qui réduit la surface d'attaque d'une VM compromise. Le trafic entre composants est protégé, et l'accès aux VM (console, VNC, SSH) passe par l'API agrégée, soumise au RBAC. La sécurité fine (SELinux, seccomp) se règle au niveau du cluster et de la configuration KubeVirt.

Pièges courants

Confondre VM et VMI : on édite la VirtualMachine (stable) ; la VMI reflète l'exécution et se recrée.
Attendre un réseau ou un stockage KubeVirt : il n'y en a pas, ce sont ceux de Kubernetes (CNI, CSI).
Oublier que la VM est un pod : les limites de ressources, les affinités et les politiques réseau du cluster s'appliquent à la VM.

À retenir

KubeVirt réutilise KVM/QEMU via libvirt et l'expose en ressources Kubernetes.
Cinq composants : virt-operator, virt-api, virt-controller, virt-handler, virt-launcher (un par VM active).
La VirtualMachine est stable, la VMI est l'exécution éphémère (avec IP), le VMIRS gère une flotte.
Une VM tourne dans un pod (virt-launcher) et hérite du réseau, du stockage et du RBAC de Kubernetes.
KubeVirt délègue réseau et stockage à Kubernetes (CNI, CSI, CDI).

Prochaines étapes

Le hub KubeVirt

Installer KubeVirt

Créer et gérer une VM

La virtualisation KVM