KubeVirt en 2026 : faire tourner des VMs dans Kubernetes en prod

Broadcom a vidé la salle. Depuis 2024, l'écosystème virtualisation s'est repeuplé de candidats sérieux pour reprendre les workloads VMware. Proxmox a absorbé la majorité des SMB et du mid-market. OpenStack reste l'option lourde des opérateurs télécom. Et KubeVirt, longtemps considéré comme un projet de geeks Kubernetes, est devenu une cible crédible pour les équipes qui veulent unifier VMs et conteneurs sur la même couche d'orchestration.

L'argument n'est pas marketing. KubeVirt v1.8 a été annoncé à KubeCon EU 2026, aligné sur Kubernetes 1.35, et l'équipe Portworx a publié des chiffres concrets : plus de 5 000 VMs en prod chez un client, et un framework de tests qui valide jusqu'à 8 000 VMs sur cluster. Ce n'est plus un POC.

Reste à savoir si KubeVirt a sa place dans votre infra, ou s'il faut rester sur du Proxmox bien tranquille. La réponse dépend de trois choses : votre maturité Kubernetes, la nature de vos workloads VM, et la stack stockage/réseau que vous êtes prêt à opérer.

• Pourquoi KubeVirt revient sur la table
• Architecture : ce que KubeVirt fait vraiment
• KubeVirt v1.8 : les évolutions de 2026
• Cas d'usage où ça marche en prod
• KubeVirt vs Proxmox vs OpenShift Virtualization
• Pièges et prérequis côté ops
• Migrer depuis VMware : la mécanique réelle

Le contexte est connu. Broadcom a multiplié les coûts de licence VMware, supprimé les SKU perpétuels, regroupé des bundles peu flexibles. Les DSI cherchent une sortie. Trois familles de réponses émergent.

Proxmox VE, c'est la voie pragmatique. KVM, ZFS, GUI propre, cluster Corosync, migration v2v à coups de qemu-img convert. On bascule vite, l'équipe est productive en deux semaines. Sur ces sujets on a déjà publié un comparatif Proxmox vs VMware et un retour de migration concrète.

OpenStack reste l'option des gros. Lourd, multi-projet (Nova, Neutron, Cinder, Keystone), TCO réel élevé en run.

KubeVirt prend une troisième voie. Plutôt que de remplacer un hyperviseur par un autre, on remplace l'orchestrateur de virtualisation par celui qu'on opère déjà pour les conteneurs : Kubernetes. Les VMs deviennent des objets VirtualMachine, gérés par kubectl, intégrés au RBAC, monitorés par Prometheus, sauvegardés par Velero ou Kasten. Pour une équipe Kubernetes mature, le coût marginal d'ajout des VMs est faible. Pour une équipe qui n'a jamais opéré K8s en prod, c'est l'inverse.

KubeVirt ajoute trois CRD principaux à Kubernetes : VirtualMachine, VirtualMachineInstance, DataVolume. Le virt-controller réconcilie les VirtualMachines en VirtualMachineInstances, le virt-handler (DaemonSet) gère les VMs au niveau noeud, et chaque VMI tourne dans un Pod qui contient un processus qemu-kvm encapsulé.

En prod, ça donne ça :

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: pgsql-legacy
spec:
  running: true
  template:
    spec:
      domain:
        cpu:
          cores: 4
          dedicatedCpuPlacement: true
        memory:
          guest: 8Gi
        devices:
          disks:
            - name: rootdisk
              disk:
                bus: virtio
          interfaces:
            - name: default
              bridge: {}
      networks:
        - name: default
          pod: {}
      volumes:
        - name: rootdisk
          dataVolume:
            name: pgsql-legacy-root

Le pod hôte a cpuset et memory limit qui matchent ce qu'on a déclaré côté spec.domain. Le scheduler Kubernetes place le pod, KVM démarre la VM dedans. Le réseau passe soit par le CNI Pod natif (limité), soit par Multus + bridge ou OVN pour exposer la VM sur un VLAN du DC, comme on le fait sur du Proxmox avec du SDN VXLAN. Le stockage repose sur un StorageClass qui sait faire du RWX block (Longhorn, Rook/Ceph, OpenEBS, Portworx).

Côté ops, ça veut dire qu'on doit opérer un cluster Kubernetes solide avant de penser KubeVirt. Pas de raccourci. Voir notre intro Kubernetes pour les bases, et le guide HA cluster pour la production.

La version 1.8 sortie début 2026 apporte quatre changements structurants.

Hypervisor Abstraction Layer (HAL). Jusqu'ici KubeVirt collait à KVM. Le HAL introduit une couche qui permet d'utiliser d'autres backends, notamment du Cloud Hypervisor ou des hyperviseurs spécialisés pour le confidential computing. Concrètement, on peut imaginer faire tourner des VMs avec attestation TEE (Intel TDX, AMD SEV-SNP) dans le même cluster que les VMs classiques.

Live update des Network Attachment Definitions. Avant, modifier une NAD imposait de redémarrer la VM. Avec v1.8, on peut faire évoluer la conf réseau sans interruption. Pour une équipe qui gère des VMs base de données ou applicatives 24/7, c'est non négociable. Le virt-controller est aussi découplé des NAD, ce qui clarifie les responsabilités.

ContainerPath volume. Un nouveau type de volume qui mappe un chemin du conteneur directement comme device pour la VM. Utile pour exposer des binaires, des datasets en lecture seule, ou des images partagées sans dupliquer le stockage.

Changed Block Tracking (CBT). Le truc qu'on attendait. Avant v1.8, faire des sauvegardes incrémentales propres demandait du tooling externe (Velero + plugin spécifique, Kasten K10, ou snapshots côté StorageClass). CBT rend la sauvegarde incrémentale agnostique du backend. Pour une stratégie 3-2-1 sur K8s, ça change la donne.

Côté scale, le framework de tests est passé de 5 000 à 8 000 VMs simulées, avec validation des operations en parallèle (live migration, snapshot, backup). Ça reste du test synthétique, mais l'asymptote remonte.

Quatre scénarios où on a vu KubeVirt tenir la route.

Modernisation legacy lift-and-shift. Une appli métier en VM Linux qu'on ne veut pas containeriser tout de suite, mais qu'on veut sortir de vSphere. On bascule la VM telle quelle dans KubeVirt, on la met derrière un Service Kubernetes, on l'embarque dans le pipeline GitOps. Le code n'est pas touché. Les containers viennent après, brique par brique.

Cohabitation VM + conteneurs sur un cluster edge. K3s ou K0s en bord de site, avec des VMs Windows ou des appliances Linux qui doivent tourner localement (capteurs, contrôleurs industriels). Voir notre article sur l'infrastructure edge avec K3s pour le pattern. KubeVirt s'insère naturellement dans cette stack.

GPU-acceleré pour ML. Avec le device plugin NVIDIA, on partage des GPU entre pods et VMs. Pour une équipe data qui veut isoler des notebooks dans des VMs avec accès GPU, le mécanisme est éprouvé. C'est cousin de Proxmox GPU passthrough, avec l'avantage d'une orchestration unifiée.

Dev/test à la demande. Un dev déclare sa VM dans un manifeste, un controller la provisionne, le runner CI la consomme, le scheduler la détruit. Plus de "qui a oublié sa VM Vagrant qui consomme 16 Go". Pour les workflows légers, Firecracker microVM reste plus rapide, mais KubeVirt a l'avantage de l'écosystème K8s complet.

Là où KubeVirt déçoit : si vos workloads sont 100% VMs lourdes avec besoins clusters complexes (Oracle RAC, SQL Server AlwaysOn) et zéro besoin Kubernetes, restez sur Proxmox ou Nutanix. Pas de mauvais outil, juste un mauvais usage.

Le verdict côté ops : si votre équipe fait déjà du Kubernetes en prod et veut éviter une stack parallèle pour la virtu, KubeVirt vaut l'investigation. Si votre équipe sort de VMware sans expérience K8s, Proxmox est le défaut raisonnable. OpenShift Virtualization a un sens si vous avez déjà un contrat Red Hat consolidé.

Le piège classique : démarrer KubeVirt sur un cluster K8s fragile. Si votre etcd flanche, vos VMs aussi. Si votre CNI a des bugs, le réseau VM hérite. KubeVirt amplifie les défauts du substrat.

Quelques points de contrôle avant de passer en prod :

• Nodes bare metal ou nested virtu propre. Faire tourner KubeVirt sur des VMs sans nested virtualization activée donne du KVM logiciel, lent et instable.
• CPU pinning et NUMA. Pour les workloads sensibles, activer dedicatedCpuPlacement et configurer le topologyManager du kubelet sur single-numa-node.
• Storage avec ReadWriteMany block. Indispensable pour la live migration. Longhorn, Rook/Ceph RBD, ou Portworx. Voir notre guide Longhorn.
• CNI compatible Multus. Calico ou Cilium en CNI principal, Multus pour exposer des VLANs DC aux VMs.
• Resource quotas explicites. Une VM qui démarre prend ses ressources d'un coup. Sans quota namespace, un manifeste fou peut saturer un noeud.
• Monitoring spécifique. Les métriques kubevirt_* exposées par virt-handler doivent rentrer dans Prometheus. Sans ça, on ne voit pas les ralentissements VMI avant que les apps gueulent.

Côté sauvegarde, CBT v1.8 simplifie l'incrémental, mais une stratégie complète demande quand même un orchestrateur (Velero, Kasten K10). Et surtout : restauration testée. Une sauvegarde non restaurée n'est pas une sauvegarde.

Le projet forklift (KubeVirt MTV chez Red Hat) automatise la conversion. Le flux est le suivant :

1. Inventory vSphere via vCenter API. Récupération des VMs, disques, réseaux, mappings.
2. Mapping des networks vSphere vers les NetworkAttachmentDefinitions K8s. Le mapping est explicite, pas magique.
3. Conversion des disques VMDK vers le format natif (qcow2 ou raw selon le storage). Conversion via virt-v2v.
4. Création des objets VirtualMachine correspondants dans K8s.
5. Démarrage et tests applicatifs.

Sur le terrain, deux écueils.

D'abord, le réseau. Les VLANs de prod doivent être joignables depuis les noeuds K8s, ce qui n'est pas toujours le cas si le cluster K8s est sur un fabric différent. Anticiper la conf trunk côté top-of-rack.

Ensuite, les drivers Windows. Les VMs Windows VMware utilisent VMware Tools et drivers VMXNET3. À la conversion, on injecte les drivers VirtIO Windows, on désinstalle VMware Tools, on adapte le boot. C'est mécanique mais demande un script propre. La doc upstream KubeVirt et les playbooks Red Hat MTV couvrent le cas.

Côté ops, on recommande une bascule par lots applicatifs (un service métier complet, pas une VM isolée), avec rollback prévu vers vSphere tant que la prod ne tourne pas en stable depuis deux semaines. Le coût d'un rollback à J+30 est exponentiel.

Sur les migrations de virtualisation qu'on opère pour nos clients, le diagnostic d'aptitude KubeVirt vs Proxmox prend une à deux semaines : audit du parc, charge réelle, compétences équipe, contraintes de conformité. Quand le verdict est "KubeVirt + Proxmox en parallèle, selon les workloads", on cadre les deux. Si vous envisagez de sortir de VMware et que la décision n'est pas tranchée, on peut auditer votre cible technique et chiffrer le run avant que vous engagiez les budgets.

• KubeVirt.io - Documentation officielle : référence pour les CRDs, l'installation et les patterns architecturaux.
• GitHub kubevirt/kubevirt : code source, releases, issues actives.
• KubeVirt v1.8 Brings Multi-Hypervisor Support and Confidential Computing - InfoQ : analyse des nouveautés HAL et confidential computing.
• Production-ready KubeVirt architecture for VMs on Kubernetes - Spectrocloud : retour terrain sur déploiement scale.
• Migrating VMware to Kubernetes with KubeVirt and Portworx : retour de migration enterprise documenté.
• Nutanix to add KubeVirt support - The Register : signal de maturité écosystème.