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 permet d'unifier deux mondes historiquement séparés, sans réécrire vos charges legacy en conteneurs.
Ce hub est le point d'entrée d'un parcours complet : comprendre l'architecture, installer KubeVirt (même sur un lab sans /dev/kvm), créer et exploiter des VM, puis aborder stockage, réseau, live migration et écosystème. Version de référence : v1.8. Public : intermédiaire à avancé, à l'aise avec kubectl.
Aller droit au but
Section intitulée « Aller droit au but »Au terme de ce parcours, vous saurez
Section intitulée « Au terme de ce parcours, vous saurez »- Expliquer l'architecture de KubeVirt (virt-operator, virt-controller, virt-handler, virt-launcher) et ses CRDs.
- Installer KubeVirt via l'opérateur, y compris en émulation logicielle sur un cluster de lab.
- Créer une VM avec un manifeste, la démarrer, y accéder en console et en SSH, l'exposer via un Service.
- Provisionner des disques avec CDI (import d'images cloud) et gérer le stockage persistant.
- Migrer à chaud une VM entre nœuds et la sauvegarder (snapshots, Velero).
- Situer KubeVirt face à Harvester, OpenShift Virtualization et aux hyperviseurs classiques.
Le parcours de formation
Section intitulée « Le parcours de formation »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.
| 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 |
Pourquoi KubeVirt en 2026
Section intitulée « Pourquoi KubeVirt en 2026 »Beaucoup d'organisations ont un pied dans chaque monde : des conteneurs pour le nouveau, des machines virtuelles pour l'existant (bases de données, appliances, OS Windows, logiciels non conteneurisables). Maintenir deux plateformes en parallèle, deux équipes, deux chaînes d'outils, coûte cher.
| 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 K8s |
| Migration cloud = 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.
KubeVirt face aux alternatives
Section intitulée « KubeVirt face aux alternatives »KubeVirt est le moteur ; plusieurs produits le packagent différemment.
- KubeVirt upstream (ce parcours) : la brique CNCF, à assembler soi-même sur un cluster existant. Contrôle total, montée en compétence maximale.
- OpenShift Virtualization : la distribution supportée par Red Hat de KubeVirt, intégrée à OpenShift. Même moteur, support commercial et console intégrée.
- Harvester : une HCI clé en main (hyperconvergée) bâtie sur KubeVirt, Longhorn et Rancher. Pour qui veut une appliance de virtualisation, pas un cluster à composer.
- Hyperviseurs classiques (Proxmox, oVirt, vSphere) : plus simples si vous n'avez que des VM et pas de Kubernetes. KubeVirt gagne dès que vous voulez unifier VM et conteneurs.
Ma position : commencez par KubeVirt upstream pour comprendre le moteur ; choisissez Harvester si vous voulez une plateforme prête à l'emploi, ou OpenShift Virtualization si vous avez déjà OpenShift et un besoin de support.
Ce que ce parcours couvre (et ne couvre pas)
Section intitulée « Ce que ce parcours couvre (et ne couvre pas) »- Couvre : l'installation, le cycle de vie des VM, le stockage CDI, le réseau, la live migration, la sauvegarde, et le positionnement écosystème.
- Ne couvre pas en profondeur : l'administration d'un cluster Kubernetes de production (voir le parcours Kubernetes), le stockage distribué sous-jacent (CSI, Longhorn, Ceph), et le design réseau CNI avancé, traités dans leurs sections propres.
Nouveautés v1.6 à v1.8
Section intitulée « Nouveautés v1.6 à v1.8 »KubeVirt évolue vite ; cette section suit les jalons récents.
- v1.6 (2025-07) : stratégie de rollout
LiveUpdatepar défaut (rupture),InstancetypeReferencePolicyen GA, DRA pour GPU. - v1.7 (2025-11) : live migration décentralisée (entre namespaces et clusters), évacuation annulable, retrait de l'API instancetype
v1alpha. - v1.8 (2026-03) : couche d'abstraction multi-hyperviseur, attestation Intel TDX (confidential computing), backup incrémental via Changed Block Tracking, et suppression des anciens bindings réseau macvtap et SLIRP.