KubeVM Service : Broadcom pilote les VM ESX depuis Kubernetes

Dans la plupart des boîtes, les VMs et les workloads Kubernetes vivent dans deux mondes séparés : les pods passent par GitOps et Argo CD, les VMs passent par un ticket, un script PowerCLI ou Terraform à la main. Le 22 octobre 2026, Broadcom a publié sur le blog VMware Cloud Foundation un billet signé Daniel Koeck, Technical Product Manager, qui propose de faire disparaître cette frontière — pas en migrant les VMs vers des conteneurs, mais en les pilotant depuis l’API Kubernetes tout en les laissant tourner directement sur ESX.

KubeVM Service : ce que ça change concrètement

L’idée centrale, c’est la gestion déclarative : au lieu d’enchaîner des commandes PowerCLI étape par étape, tu décris l’état final voulu — ressources, OS, état d’alimentation — et un contrôleur de réconciliation fait converger la réalité vers cette déclaration en continu, exactement comme un Deployment Kubernetes classique. La différence avec un vrai pod : la VM ne tourne pas dans un conteneur sur un nœud worker, elle reste une VM ESX normale, visible dans vCenter avec ses limites de resource pool, ses politiques de stockage et ses règles DRS appliquées comme d’habitude.

Techniquement, ça se traduit par une ressource personnalisée Kubernetes, VirtualMachine, dans le groupe d’API kube-vm.io/v1alpha1 :

apiVersion: kube-vm.io/v1alpha1
kind: VirtualMachine
metadata:
  name: analytics-gpu-workstation
  namespace: data-science-team
spec:
  className: gpu-accelerated-large
  imageName: "ubuntu-24-04-cuda-12"
  powerState: PoweredOn
  bootstrap:
    cloudInit:
      rawCloudConfig:
        secretName: dev-workstation-bootstrap

Le champ className pointe vers une classe de VM que les admins ont définie à l’avance (CPU, RAM, GPU) et une politique de stockage vCenter (vSAN, NVMe). Le bootstrap passe par cloud-init classique — clés SSH, hostname, réseau, paquets — avec les secrets dans des Secrets Kubernetes et le reste dans des ConfigMaps. Côté gouvernance, le RBAC Kubernetes limite les droits par namespace, des quotas matériels évitent qu’une équipe monopolise les ressources, et des politiques d’expiration (via spec, métadonnées, ou Kyverno/OPA) permettent d’arrêter ou supprimer automatiquement les VMs temporaires — un sandbox d’agent IA qui vit 48h, typiquement.

Ce qui coexiste, et ce qui ne change pas

Pas de migration forcée : les VMs déclaratives et les VMs classiques gérées depuis vCenter cohabitent sur les mêmes clusters, réseaux et stockages. Broadcom précise même qu’une VM existante peut être intégrée à la gestion déclarative sans changement d’IP ni interruption. C’est un point important, parce que ça positionne KubeVM Service comme une couche de contrôle additionnelle plutôt que comme un remplacement — tu ne jettes rien de ce qui tourne déjà.

Les cas d’usage mis en avant sont précis : sandboxes d’agents IA à cycle de vie court, postes de travail data science avec GPU, et passthrough matériel pour accélérateurs. Rien, pour l’instant, sur des workloads de production classiques type serveur applicatif ou base de données — ce qui suggère que Broadcom vise d’abord les usages où le provisionnement à la demande via API a le plus de valeur, pas le remplacement du provisionnement VM traditionnel partout.

Le bémol qu’il faut garder en tête : c’est une v1alpha1

Le groupe d’API kube-vm.io/v1alpha1 ne laisse aucun doute : on est à un stade très précoce. L’article de Broadcom ne donne ni date de disponibilité générale, ni liste d’OS supportés, ni limites de scalabilité, ni modèle de tarification. Pour une fonctionnalité qui touche à la gestion de VMs en production, ce flou n’est pas anodin — à ce stade, c’est une démonstration de direction stratégique plus qu’un produit prêt à adopter.

Et la question qu’on peut se poser sans détour : est-ce que ça vaut vraiment le coup de superposer une couche Kubernetes à un provisionnement VM qui fonctionne déjà très bien avec le provider Terraform vSphere ? Pour une équipe plateforme déjà 100 % GitOps sur Kubernetes, avec des devs qui ne veulent plus jamais ouvrir vCenter, la réponse est probablement oui — un seul kubectl apply pour tout, VMs et pods compris. Pour une équipe infra classique qui maîtrise déjà PowerCLI ou Terraform et n’a pas de cluster Kubernetes à côté de ses VMs, ça ajoute une dépendance technique (API server, RBAC, CRD) pour un bénéfice qui reste à démontrer en dehors des cas d’usage GPU/agents IA.

Dans le contexte de l’ère post-Broadcom

Ce lancement s’inscrit dans une tendance qu’on suit depuis notre comparatif VMware/Hyper-V/Azure Local après la crise des licences Broadcom : Broadcom cherche à donner de nouvelles raisons de rester sur VMware Cloud Foundation plutôt que de migrer vers Proxmox, Nutanix ou Hyper-V, en misant sur des intégrations que les alternatives n’ont pas encore. KubeVM Service va dans ce sens — c’est un argument de différenciation technique, pas juste une réponse à la pression tarifaire. Reste à voir si l’écosystème Kubernetes autour (Argo CD, Flux, portails type Backstage) suit au même rythme que l’API elle-même.

FAQ

KubeVM Service remplace-t-il vCenter ?

Non. Les VMs créées via KubeVM Service restent visibles et gérables dans vCenter normalement — c’est une couche de pilotage additionnelle via l’API Kubernetes, pas un remplacement de la console d’administration.

Faut-il convertir ses VMs existantes pour les utiliser avec KubeVM Service ?

Non, Broadcom indique qu’une VM existante peut être intégrée à la gestion déclarative sans migration ni changement d’IP.

Est-ce disponible en production aujourd’hui ?

L’API est en version v1alpha1, sans date de GA annoncée — à tester en lab avant d’envisager une mise en production.

En pratique

Si tu as déjà un cluster Kubernetes avec GitOps en place et des besoins réguliers de VMs à cycle de vie court (sandboxes, postes GPU), garde un œil sur ce projet et teste-le en lab dès qu’un accès y est possible — mais ne prévois pas de bascule de ton provisionnement VM de production dessus avant une version stabilisée au-delà de l’alpha.