Kubernetes ou vSphere 7 : lequel choisir pour exécuter les applications ?
Le système de VMware intègre désormais les rouages de Kubernetes pour exécuter des containers, tandis que Kubernetes dispose de KubeVirt pour exécuter des machines virtuelles. En revanche, les outils divergent.
Suite à l’annonce par VMware de la disponibilité générale de vSphere 7, les administrateurs informatiques ont désormais une idée bien plus précise de l’intégration entre vSphere et Kubernetes. Pourtant, choisir d’exécuter ses applications via Kubernetes seul ou via VMware vSphere qui l’englobe, est une problématique qui est loin d’être tranchée. Le choix de l’un ou de l’autre repose en réalité sur les impératifs des entreprises en matière d’administration système.
Les administrateurs qui disposent d’un grand nombre d’applications en machines virtuelles et envisagent d’en exécuter autant que faire se peut, au sein de containers, tireront parti d’une infrastructure Kubernetes, administrable par les outils natifs de Kubernetes, dont KubeVirt, qui permet d’exécuter de véritables VMs parmi des containers. Ceux qui envisagent plutôt d’ajouter des containers à leur environnement sans avoir à reconstruire l’existant basé sur des VMs, trouveront vSphere 7 plus avantageux.
Côté cloud, les deux choix sont possibles pour les entreprises qui se lancent dans les projets hybrides, soit des applications qui s’exécutent à cheval entre des sites physiques et des ressources en ligne. VMware a en effet annoncé l’extensibilité de ses clusters vSphere aux ressources de tous les principaux fournisseurs cloud, notamment AWS et Azure. AWS propose ainsi VMware Cloud on AWS, mais aussi son propre environnement Kubernetes, Elastic Kubernetes Service (EKS). Idem chez Azure, qui propose à la fois un service VMware Cloud on Azure et un service Kubernetes maison, Azure Container Service (AKS).
En ce qui le concerne, Google a récemment fait l’acquisition de CloudSimple, qui fournit une connexion VMware, tant à son propre cloud GCP qu’à celui d’Azure. Google déclare considérer qu’un Kubernetes chef d’orchestre – sous le nom d’Anthos, en ce qui le concerne –, préfigure l’avenir. Et sa vision comprend l’administration par Anthos de containers hébergés sous vSphere.
VSphere 7 : plutôt pour des containers qui s’ajoutent aux machines virtuelles
VMware propose d’optimiser le fonctionnement des containers en les traitant au niveau de l’hyperviseur, comme les VMs. Pour ce faire, l’éditeur fait de la paravirtualisation, un procédé technique grâce auquel le container devient l’égal de la VM, et qui lui permettrait de fonctionner avec 20 % de performances en plus, comparé à l’exécution directe du même container sur un serveur physique.
Parallèlement, vSphere offre toujours la possibilité d’exécuter des containers par-dessus une VM. Tanzu Mission Control administre la mécanique de gestion des containers de VMware, tandis que Tanzu Kubernetes Grid constitue la distribution Kubernetes de VMware avec des extensions qui s’intègrent à vSphere.
Les utilisateurs choisiront Tanzu Mission Control ou d’autres services, par exemple Google Anthos, pour administrer des containers exécutés au sein de pods CRX (Container Runtime ESXi). Les administrateurs ont demandé à VMware si ces pods sont compatibles Kubernetes ; la réponse est oui, à quelques exceptions près liées à la sécurité.
VMware a pris la décision de rationaliser le déploiement et l’administration de Kubernetes, en désignant comme couche sous-jacente de Tanzu la plate-forme VMware Cloud Foundation (VCF).
Si CRX fait partie du noyau vSphere Kernel, aucun administrateur n’a pour autant accès à la plate-forme de containers, à moins de disposer d’une licence et d’un déploiement VCF. VMware déclare qu’il s’agit là d’un argument commercial solide pour Tanzu, car il garantit une homogénéité et une simplicité opérationnelles.
Kubernetes seul : plutôt pour que toutes les applications soient en mode cloud
Reste que, selon les architectes, les containers constitueraient le degré d’abstraction idéal pour déployer des applications censées fonctionner en cloud hybride, que ces applications soient conçues pour le web – l’instance pour laquelle les containers ont été créés – ou pour le datacenter – le format par essence des machines virtuelles. Netflix a démontré certains avantages d’une telle exécution 100 % en containers : les applications monolithiques deviennent aussi faciles à intégrer et à déployer que les applications web.
Le choix d’exécuter soit des containers dans des VM, soit des applications en mode VM monolithique parmi des containers relève donc de la conception architecturale.
Les containers constituent tout bonnement une autre forme de virtualisation. D’un point de vue purement conceptuel, les administrateurs peuvent exécuter une application monolithique en VM parmi des containers, grâce à des modules spécifiques, dont KubeVirt. Précisons que toutes les applications ne sont en effet pas convertibles en container. Les administrateurs pourraient en particulier se trouver face à des appliances applicatives tierces impossibles à adapter à ce format. Pour parvenir à les intégrer, KubeVirt fournit un mécanisme qui exécute ces appliances sous la forme de vraies machines virtuelles, avec une période de rétention plus longue que celle des containers, lesquels sont plutôt jugés instances « jetables » au premier incident.
Si VMware garantit aux administrateurs que les containers et VMs sont identiques dans vSphere, une comparaison similaire est moins aisée pour les applications web et les applications monolithiques côté Kubernetes. En effet, Kubernetes reste un produit d’orchestration que les administrateurs utilisent essentiellement pour les containers. En théorie, Kubernetes peut certes gérer des ressources informatiques autres que les containers et, en l’occurrence, les couches d’infrastructures généralement associées aux machines virtuelles (comme des volumes-disque, des cartes réseau…).
Toutefois, dès lors que le système de containers est utilisé en tant que couche de virtualisation principale, son abstraction empêche les outils d’administration des machines virtuelles de faire le lien entre des ressources physiques et leurs noms logiques. Il reste possible de passer par une mise en réseau supplémentaire, ce que permet KubeVirt.
Pour gérer la mise en réseau, KubeVirt exploite l’architecture réseau et les plug-ins de Kubernetes, plutôt que des ressources logiques de l’hyperviseur, dont la technologie vSwitch. Les outils doivent, par conséquent, basculer vers une administration réseau selon des espaces de noms Kubernetes. Ce qui n’est pas nécessairement mauvais ; il s’agit simplement d’un changement global de mode de fonctionnement, passant d’un modèle axé sur les VMs à un autre qui exploite les containers.
