Explore 2026 : Broadcom confirme l’ouverture de VCF aux serveurs ARM

Intégrer les processeurs ARM avec toutes les fonctions de VCF

Dilpreet Bindra insiste pour dire que, non, les ingénieurs de Broadcom ne se sont pas simplement contentés de livrer VCF avec des binaires au format ARM de Kubernetes : « nous avons dû intégrer dans la console d’administration toutes les caractéristiques de ces serveurs. Mais il n’y a pas que cela. Il a aussi fallu développer tout le nécessaire pour que ces serveurs Nvidia se connectent à notre stockage vSAN, sur notre réseau NSX. Pour qu’ils soient comme une VM de VCF en somme », dit notre interlocuteur.

À ce propos, une autre préversion a été discrètement dévoilée lors de la conférence Explore 2026, celle d’une version de vSAN partageant sur le réseau un stockage objet prêt à l’emploi, sans avoir besoin d’en installer un soi-même par-dessus les unités virtuelles en mode bloc du système.

« Nous proposions déjà avec vSAN un système de fichiers prêt à l’emploi, qui pouvait convenir pour tous les usages. Et que nous avons d’ailleurs adapté à la version ARM de VKS. Mais nous pensons que le mode objet va prendre une importance capitale dans tous les déploiements d’IA, car il permet d’indexer plus facilement les données qu’une entreprise veut soumettre à ses agents », lance Dilpreet Bindra, sans préciser s’il s’agit d’une demande formulée par son partenaire Nvidia.

« Le stockage objet est plus efficace pour stocker les données vectorielles, mais aussi les KV-Caches », ajoute-t-il, en faisant référence à cette fonctionnalité de rechargement rapide des historiques de conversation sur laquelle Nvidia insiste bien plus que les autres fabricants de puces accélératrices d’IA.

Le véritable enjeu : imposer VKS, le Kubernetes maison

Dilpreet Bindra préfère ne pas s’aventurer à donner une date de disponibilité officielle pour KVS en version ARM et vSAN étendu avec le mode objet.

« Leur lancement sera bientôt. Mais nous avons encore fort à faire pour que les fonctionnalités de haut niveau de VCF soient pleinement compatibles avec eux. Je pense à la haute disponibilité, au déplacement chiffré à la volée des applicatifs avec vMotion, à la reprise après sinistre et à toutes les autres fonctions entièrement automatisées qui font de VCF un produit en avance sur ses concurrents », argumente le directeur de l’ingénierie.

En vérité, il s’agit autant pour Broadcom d’apporter à VCF de nouvelles fonctionnalités au bénéfice de l’IA que d’assurer à sa sous-partie VKS des capacités similaires à celles de l’hyperviseur ESX. « Un exemple de développement important qui vient juste d’arriver à maturité dans VKS est celui du tiering mémoire », dit Dilpreet Bindra, en pointant la faculté qu’avait déjà ESX de piocher de la mémoire de travail depuis la capacité disponible sur des SSD NVMe, plutôt que depuis des barrettes de DRAM qui valent plus cher.

« Tel que nous l’avons développé, notre tiering mémoire ne souffre de pratiquement aucun ralentissement. Pouvoir en faire bénéficier Kubernetes signifie que vous allez pouvoir exécuter vos agents en containers avec toute la mémoire dont ils ont besoin pour délivrer leur puissance. Et, ce, sans avoir dû acheter autant de barrettes de DRAM, dont les prix sont prohibitifs dans le cadre de la pénurie actuelle des mémoires », se félicite-t-il.

VKS plus performant, mais uniquement grâce à ESX

Tous ces efforts pourraient suggérer que Broadcom prépare un cluster VCF qui saurait fonctionner avec seulement VKS, c’est-à-dire seulement des containers Kubernetes directement exécutés sur des serveurs physiques. Sans ne plus devoir passer par la couche de virtualisation ESX, dont on imagine qu’elle fait office de goulet d’étranglement. C’est d’ailleurs cette voie que vient de proposer Nutanix, le concurrent historique de VMware.  

Dilpreet Bindra dément formellement cette hypothèse. « Nous avons des clients qui font cela actuellement : exécuter des applications en containers par-dessus un Kubernetes quelconque qui est lui-même directement exécuté sur des serveurs physiques. Ils nous témoignent que les performances observées sont moins bonnes qu’avec VCF ! Qu’ils ont besoin d’acheter davantage de ressources matérielles pour obtenir les mêmes résultats que sous VCF ! »

« Ce que je veux dire, c’est que notre hyperviseur ESX n’est pas à l’heure actuelle un goulet d’étranglement. Au contraire ! C’est un moteur de répartition des flux d’exécution hors pair, meilleur que n’importe quel autre hyperviseur ou, donc, n’importe quel orchestrateur », argumente-t-il.

Broadcom pourrait tout aussi bien déporter le code de répartition des flux d’ESX dans VKS. Mais une raison pour laquelle le fournisseur ne veut sans doute pas prendre cette voie est que, contrairement à ESX, il tient à conserver une approche Open source de son orchestrateur Kubernetes.

« Nous voulons que les utilisateurs puissent comparer exactement la même chose entre ce qu’ils exécutent sur VCF et ce qu’ils exécutent sur une autre plateforme. Donc, pour le promouvoir, nous contribuons désormais davantage au code de Kubernetes, nous partageons tous les développements autour de VKS avec la communauté, c’est-à-dire avec la fondation CNCF », conclut-il, en donnant l’exemple récent de codes pour Velero, un des principaux outils de sauvegarde des clusters Kubernetes.

De fait, pour que VKS soit plus efficace que les autres Kubernetes sur processeurs ARM, il faudra donc bien que Broadcom finisse par porter ESX sur ARM.