Faire tourner des machines virtuelles dans Kubernetes n’est plus une expérimentation : trois plateformes couvrent ce créneau en octobre 2026. KubeVirt, projet hébergé à la CNCF, est arrivé en version 1.9 avec la prise en charge de Kubernetes 1.36 et une API Sysprep pour les VM Windows. Harvester, l’hyperconvergé open source de SUSE, publie sa version 1.9 cette automne sur une cadence semestrielle tenue. OpenShift Virtualization, l’offre entreprise de Red Hat construite sur KubeVirt, accompagne les migrations VMware avec son Migration Toolkit for Virtualization (MTV). Ce comparatif date les faits, nomme les usages où chacune tient la route, et recense les limites que les argumentaires marketing passent sous silence.
Pourquoi la virtualisation rejoint Kubernetes en 2026
Le moteur de ce mouvement est connu des lecteurs du site : le rapprochement de VMware par Broadcom et ses conséquences tarifaires. Les estimations publiées au premier semestre 2026 situent la hausse des coûts VMware entre 2 et 10 fois selon les profils de licence (analyse de gocorptech du 9 octobre 2026), et une comparaison des plates-formes de cloud privé publiée le 22 mai 2026 par aenix recense les chemins de migration réalistes, KubeVirt en tête pour les organisations déjà équipées en Kubernetes.
Trois pressions convergent :
- économique : les abonnements VMware VCF/VVF pondèrent le budget sur 3 à 5 ans, ce qui rend tout scénario open source immédiatement lisible en TCO ;
- technique : les équipes qui ont déjà industrialisé Kubernetes (GitOps, CI/CD, observabilité) veulent gérer leurs VM avec les mêmes outils plutôt qu’avec une console d’hyperviseur supplémentaire ;
- organisationnelle : la pénurie d’administrateurs VMware certifiés pousse à mutualiser les compétences sur des piles open source.
Le contexte tarifaire et contractuel détaillé est couvert par notre article sur l’évolution du licensing VMware sous Broadcom ; ce qui change ici, c’est que la réponse ne vient plus seulement des hyperviseurs classiques. Notre comparatif des hyperviseurs 2026 montre où se situe le marché traditionnel — ce guide s’intéresse à la couche au-dessus, celle où le plan de contrôle de la virtualisation devient un plan de contrôle Kubernetes.
KubeVirt : des VM dans Kubernetes, à la CNCF
KubeVirt est le socle commun des trois solutions. Le principe : une VM est représentée par une ressource Kubernetes (VirtualMachine), et son exécution est assurée par un pod lanceur qui embarque libvirt et QEMU. Le cluster existant — stockage via les classes de volumes, réseau via le CNI, ordonnancement via le scheduler — reste le substrat.
L’année 2026 a été chargée côté fonctionnalités. La version 1.8, annoncée le 25 mars 2026, a introduit deux nouveautés de fond côté stockage : le volume ContainerPath et la sauvegarde incrémentale par CBT (changed block tracking), qui permet enfin de sauvegarder uniquement les blocs modifiés depuis la passe précédente — une brique que les sauvegardes VM attendaient depuis longtemps. La version 1.9, suivie d’une 1.9.1 vérifiée sur GitHub le 12 octobre 2026, est construite pour Kubernetes 1.36 et 1.35 et ajoute la prise en charge de Sysprep dans l’API : la spécialisation des VM Windows se pilote désormais comme n’importe quelle autre ressource du cluster, sans intervention dans l’invité. Le KubeVirt Summit 2026, événement virtuel de la CNCF d’octobre 2026, a confirmé les axes en cours : sauvegarde et restauration des VM, améliorations réseau et stockage.
Ce qui distingue KubeVirt d’un hyperviseur classique tient en un point : il n’apporte aucun plan de gestion matériel, pas de stockage intégré, pas d’interface unique. Tout s’installe au-dessus d’un cluster Kubernetes que vous possédez déjà, avec ses choix de CNI (Multus pour les interfaces secondaires), de CSI et de topologie. C’est sa force pour les plateformes équipes, et sa barrière pour les structures sans culture Kubernetes — une différence de nature qu’il faut avoir en tête avant tout chiffrage.
Harvester : l’hyperconvergence open source de SUSE
Harvester répond précisément à la barrière précédente. C’est une distribution HCI complète, installable sur des serveurs bare metal, qui assemble Kubernetes, KubeVirt pour les VM et Longhorn pour le stockage répliqué en blocs. L’administrateur n’a pas à construire le cluster : il installe Harvester sur chaque nœud et obtient une console unique pour gérer VM, volumes et réseaux.
La version 1.9 est la branche actuelle : la documentation officielle (v1.9, actualisée le 15 octobre 2026) la désigne comme dernière version stable, la 1.9.0 étant référencée mi-octobre 2026 et une 1.9.1-rc4 publiée le 21 octobre 2026 en pré-version non prise en charge pour les montées de version. SUSE tient une cadence d’une version mineure tous les quatre mois (avril, août, décembre), avec des correctifs tous les deux mois — un rythme à intégrer dans la politique de maintenance du parc.
Côté écosystème, l’intégration Rancher est activée par défaut depuis Rancher v2.6.1 : un cluster Harvester apparaît comme une ressource pilotable depuis Rancher, ce qui permet de provisionner des VM depuis le même point que les clusters Kubernetes « normaux ». Pour une équipe déjà outillée SUSE/Rancher, c’est l’argument massue ; pour les autres, c’est simplement une option de gestion, jamais une dépendance — Harvester fonctionne seul.
Sur le terrain, Harvester se compare directement à une offre comme vSAN ou à un couple Proxmox VE + Ceph, avec un positionnement tarifaire agressif puisque la couche virtualisation est open source. Sa limite tient au rayon de l’écosystème : moins d’intégrateurs, moins de réponses sur les forums, et une maturité de la console qui reste en retrait de vCenter ou même de l’interface Proxmox.
OpenShift Virtualization : la voie entreprise de Red Hat
OpenShift Virtualization est la version « produit » de KubeVirt : Red Hat prend le projet, l’intègre dans OpenShift, et le soutient avec un cycle de vie supporté. L’argument de vente n’est pas la nouveauté technique — les mécanismes sont ceux de KubeVirt — mais la continuité d’exploitation : un cluster OpenShift héberge conteneurs, VM et fonctions réseau avec les mêmes procédures de mise à jour, les mêmes politiques de sécurité et le même support éditeur.
Les repères 2026 : OpenShift 4.21 est en disponibilité générale depuis février 2026 (rebasing Kubernetes 1.34, correctifs 4.21.26 expédiés en juillet 2026 selon Red Hat), suivi de la branche 4.2x rebasée sur Kubernetes 1.35 avec CRI-O 1.35. Côté virtualisation proprement dite, la 4.20 apporte en Technology Preview l’injection et l’éjection de CD-ROM virtuels — détail pratique pour les procédures d’installation d’invités.
Le deuxième pilier est la migration. Le Migration Toolkit for Virtualization (MTV), documenté en version 2.10, s’installe comme un opérateur OpenShift et orchestre des migrations à froid (VM arrêtée) ou à chaud (réplication pendant l’exécution, bascule finale) depuis vSphere. Son socle open source, le projet Forklift, est utilisable hors Red Hat. Exploiter OpenShift sérieusement en production, cela ressemble beaucoup aux contraintes décrites par la communauté anglophone autour des opérations OpenShift au quotidien — le guide de maximo-users.net sur le déploiement et l’exploitation d’OpenShift illustre bien ce que « faire tourner » signifie au-delà du déploiement initial.
Le prix de cette sérénité : un abonnement Red Hat, un footprint plus lourd qu’un cluster Kubernetes nu, et une courbe d’apprentissage OpenShift non négligeable pour les équipes qui n’en ont pas l’habitude.
Tableau comparatif
| Critère | KubeVirt | Harvester | OpenShift Virtualization |
|---|---|---|---|
| Nature | Projet CNCF, à installer soi-même | Distribution HCI SUSE, appliance bare metal | Produit Red Hat intégré à OpenShift |
| Version repère (oct. 2026) | 1.9 / 1.9.1, Kubernetes 1.36 | 1.9, cadence mineure tous les 4 mois | Branche OpenShift 4.2x, K8s 1.35 |
| Point fort 2026 | Sauvegarde incrémentale CBT (v1.8), Sysprep (v1.9) | Console unique HCI, intégration Rancher native | Support éditeur, MTV 2.10 pour migrations VMware |
| Support | Communauté CNCF | SUSE (abonnement) | Red Hat (abonnement) |
| Prérequis | Cluster Kubernetes existant | Serveurs bare metal | Cluster OpenShift |
| Écueil principal | Tout reste à assembler | Écosystème plus étroit | Coût et complexité OpenShift |
| Usage cible | Plateformes équipes déjà en K8s | PME/ETI voulant du HCI open source | Grandes organisations sous contrat Red Hat |
Migrer depuis VMware : les outils de conversion
Le nerf de la guerre reste le franchissement du pas : importer un parc de VM existant. Trois approches se distinguent.
La première est celle des outils de conversion Kubernetes. Forklift/MTV inventorie les VM via l’API vCenter, mappe les réseaux vSphere vers des NetworkAttachmentDefinition Kubernetes, et convertit les disques VMDK vers des volumes persistants. La migration à froid convient aux machines peu critiques ; la migration à chaud réplique les deltas pendant que la VM tourne, à condition d’accepter l’outillage de synchronisation finale. Le NetApp Shift toolkit, documenté le 13 juillet 2026, montre l’évolution de l’écosystème : il orchestre le provisionnement de stockage via Trident CSI pendant la migration, sans opération manuelle de copie de disques.
La seconde approche est la migration classique vers un hyperviseur, puis une éventuelle remontée vers Kubernetes plus tard. Notre guide pratique pour migrer une VM de VMware vers Proxmox couvre ce chemin en détail — qm importdisk, conversion des formats, pilotes invité. Elle reste souvent la plus rapide pour un parc hétérogène, et elle découple la décision d’hyperviseur de la décision d’orchestrateur.
La troisième dimension, souvent oubliée, est économique : convertir des VM ne supprime pas le besoin de chiffrer le TCO avant/après. Notre comparatif du coût total de possession VMware vs Proxmox sur 5 ans fournit la méthode (licences, support, formation, temps d’administration) applicable tel quel à un scénario Kubernetes.
Quelle plateforme pour quel usage ?
La réponse dépend moins des fonctionnalités que de la maturité Kubernetes de l’équipe.
- Vous exploitez déjà Kubernetes en production, avec des équipes plateformes : KubeVirt est le choix cohérent. Vous ajoutez une brique à une pile maîtrisée plutôt que d’introduire un nouvel hyperviseur ; la sauvegarde CBT de la 1.8 et le Sysprep de la 1.9 comblent les deux derniers trous fonctionnels majeurs.
- Vous voulez remplacer un HCI propriétaire (vSAN, Nutanix) sans monter en compétence Kubernetes : Harvester est le point d’entrée le plus direct, à condition de valider l’écosystème local (intégrateurs, pièces détachées de compétences).
- Vous êtes engagé chez Red Hat, ou la conformité/support prime sur le coût : OpenShift Virtualization avec MTV est le chemin de moindre résistance politique — c’est d’ailleurs le scénario que Red Hat vend explicitement aux déçus de Broadcom.
- Vous n’avez aucune de ces bases : commencez par un hyperviseur classique. L’état de l’art de Proxmox VE en 2026 documente la plateforme la plus aboutie de ce marché, et la prise en main Kubernetes proprement dite trouvera son complément dans le guide conteneurisation et Kubernetes pour développeurs d’industrie-du-futur.tv.
Les limites à connaître avant de se lancer
Trois zones d’ombre reviennent dans tous les retours d’expérience 2026, et elles pèsent plus que les benchmarks.
Le réseau. Faire passer le trafic d’une VM dans un CNI Kubernetes ajoute une indirection (Multus, annotations réseau, policies) que les équipes réseau traditionnelles ne lisent pas d’instinct. Les performances SR-IOV ou DPDK se configurent, mais exigent une connaissance du plan de contrôle Kubernetes que la plupart des équipes VM n’ont pas encore.
Le stockage. Entre les classes de volumes, les snapshots CSI et les volumes spécifiques à KubeVirt (ContainerPath en 1.8), la surface de configuration est plus large qu’un datastore VMFS. Sans politique de classes claire, les VM finissent éparpillées sur des tiers de stockage hétérogènes, et la sauvegarde reste à orchestrer (CBT ou non) avec des outils extérieurs à la plateforme.
La montée de version croisée. Kubernetes avance trois fois par an, KubeVirt suit, Harvester impose son calendrier quadrimestriel, et OpenShift son train 4.x. Chaque combinaison hyperviseur-orchestrateur doit être validée avant montée en production — un travail permanent que les petites équipes sous-estiment systématiquement. C’est exactement le genre de charge cachée que notre comparatif de TCO sur cinq ans chiffre à plusieurs postes.
En résumé
KubeVirt, Harvester et OpenShift Virtualization ne remplacent pas les hyperviseurs classiques : ils les complètent là où Kubernetes est déjà le centre de gravité. En octobre 2026, KubeVirt 1.9 a comblé ses derniers trous fonctionnels (CBT, Sysprep), Harvester 1.9 a confirmé sa régularité de publication et OpenShift Virtualization a industrialisé la migration VMware via MTV 2.10. La question à se poser n’est pas « laquelle est la meilleure » mais « quelle est la maturité Kubernetes de mon équipe » — et pour tout le reste, les guides de fond du site prolongent celui-ci.