VMware crée un Workload Conformance Working Group au sein de la communauté Kubernetes, chargé de définir le comportement des applications sur Kubernetes. Par ailleurs, l’entreprise fait don de son VM API à la CNCF Sandbox.
VMware veut que les applications cloud natives fonctionnent de manière prévisible dans tous les environnements Kubernetes. L’entreprise lance donc un nouveau groupe de travail au sein de la communauté Kubernetes, le Workload Conformance Working Group. Celui-ci doit élaborer une norme commune sur le fonctionnement des workloads sur Kubernetes.
Les partisans des logiciels cloud natifs affirment depuis longtemps que leur approche rend les applications portables d’un environnement Kubernetes à l’autre. Selon VMware, ce n’est pas toujours le cas dans les clouds hybrides.
Pourquoi une norme pour les workloads
Prashanth Shenoy, VP of product marketing au sein de la division VMware Cloud Foundation de Broadcom, explique à The Register que la norme est nécessaire en partie parce que les applications conditionnées pour les clouds publics ne fonctionnent pas toujours correctement dans les clouds hybrides. Cela concerne aussi d’autres fournisseurs de clouds hybrides, comme Nutanix et Red Hat. Tous trois vendent des outils pour construire et exécuter une pile que les utilisateurs peuvent déployer aussi bien sur une infrastructure on-premises que dans le cloud public.
Le groupe de travail souligne qu’il existe déjà des tests pour le cluster lui-même (Certified Kubernetes) et pour déterminer si un cluster peut gérer des workloads d’IA et de ML (Kubernetes AI Conformance). Pour les workloads eux-mêmes, il n’existe rien de comparable. Les administrateurs de clusters vérifient donc encore chaque application à la main avant d’effectuer une maintenance ou de mettre à niveau Kubernetes. Les administrateurs d’applications se voient poser les mêmes questions par chaque environnement.
Une spécification commune assortie de tests reproductibles doit offrir un point de départ identique aux deux groupes. Shenoy s’attend à ce que les éditeurs d’applications soutiennent cette approche, car ils souhaitent conditionner leur logiciel une seule fois et le faire fonctionner partout.
Pas encore d’exigences concrètes
L’initiative en est encore à un stade très précoce. La première étape consiste à déterminer quels workloads et quels comportements la spécification couvrira. Il s’agit de la sécurité, de la résilience face aux perturbations, de l’utilisation des ressources, du réseau, du stockage, de l’utilisation des API et de l’observability. Le groupe n’a pas encore défini d’exigences spécifiques ni déterminé comment il les testera.
Une règle est déjà fixée : chaque exigence recevra un test objectif qu’un programme de test pourra exécuter. La spécification ne contiendra donc rien de subjectif.
VM API à la CNCF
Cette semaine, VMware a également annoncé qu’il confiait son VM API à la Cloud Native Computing Foundation (CNCF) Sandbox. La CNCF gère Kubernetes et héberge déjà KubeVirt, un outil permettant de créer et de gérer des machines virtuelles dans un cluster Kubernetes. Grâce au VM API, les utilisateurs de Kubernetes créent des machines virtuelles qui tournent notamment sur des hyperviseurs, dont ESXi de VMware lui-même.
VMware avait déjà intégré Kubernetes dans vSphere en 2020 avec vSphere with Kubernetes, dans le cadre de vSphere 7. Ces premières tentatives n’ont pas rencontré le succès escompté. L’entreprise opte aujourd’hui pour une autre approche afin d’intégrer pleinement les machines virtuelles dans Kubernetes.
Les développeurs préfèrent généralement écrire pour des conteneurs, tandis que les administrateurs font souvent tourner ces conteneurs dans des machines virtuelles légères. Les deux méthodes de travail continueront donc à coexister, aussi parce que les organisations exécutent de nouvelles applications en conteneurs à côté de machines virtuelles existantes. On ne sait rien du moment où le VM API quittera la Sandbox.