Quand VMware décide que finalement Kubernetes et vSphere feront chambre commune

Quand VMware décide que finalement Kubernetes et vSphere feront chambre commune

Supposons que Kubernetes soit une plate-forme logicielle – un produit créé par une startup et ensuite livré à la communauté des utilisateurs de centres de données avec des frais de licence pour un minimum de 50 utilisateurs. Supposons maintenant, toujours de manière hypothétique, que la startup ait été acquis par VMware. Le premier produit issu de cette acquisition n’aurait pas pu être très différent de la preview de “Project Pacific” présenté aux participants de VMworld 2019 à San Francisco.

Certes, la dernière version de Kubernetes est en grande partie le produit d’un type d’innovation que seule la communauté open-source peut cultiver. Mais si vous faites un tour à VMworld, même rapide, vous rencontrerez probablement Joe Beda et Craig McLuckie, deux des trois créateurs de Kubernetes, aujourd’hui ingénieurs employés par VMware.

Et la vedette du show de cette année était la forme la plus évoluée de vSphere, la plate-forme qui héberge une grande majorité des charges de travail des centres de données de part le monde, et désormais en voie de transformation vers une distribution Kubernetes à part entière.

Bientôt vSphere arborera des extensions de ressources personnalisées qui permettront à son propre moteur Kubernetes de continuer à gérer les machines virtuelles que vSphere a toujours gérées. Oui, vous avez bien lu. Au lieu d’étendre vSphere pour intégrer Kubernetes, VMware réorganise son propre Kubernetes, et ce pour qu’il se comporte et fonctionne comme vSphere.

Kubernetes pourrait bien devenir l’initiative open-source la plus réussie de l’histoire, surpassant même Linux. Oui, VMware ne possède pas Kubernetes. Mais si vSphere atteint cet objectif, est-ce que cela aura de l’importance pour les entreprises utilisant vSphere ? Si Bill Gates et Steve Ballmer dirigeaient toujours Microsoft, ils s’inclineraient devant Pat Gelsinger, le PDG de VMware.

“Nous ne nous voyons pas dans ce que l’on pourrait appeler l’espace de la plate-forme applicative” déclarait Kit Colbert, le vice-président et directeur technique de VMware, lors de ce même évènement, trois ans auparavant. “Et si nous pouvions gérer des machines virtuelles à l’aide de l’interface Kubernetes ?” s’est interrogé Kit Colbert le 2 septembre dernier, de manière rhétorique. Bref, c’est un retournement complet de situation. Et de stratégie.

“Il y aura plus d’applications provisionnées au cours des cinq prochaines années qu’il n’y en a eu au cours des 40 dernières années” a-t-il déclaré à son auditoire. “C’est assez étonnant, non ? Nous parlons de centaines de millions de charges de travail. Et ces charges de travail seront très différentes de ce qu’elles ont toujours été. Elles seront beaucoup plus nombreuses, plus petites, plus distribuées, plus centrées sur les données, utilisant toutes sortes de nouvelles capacités telles que l’intelligence artificielle. La nature de l’application change fondamentalement.”

Moins de quatre minutes après sa présentation, Kit Colbert a présenté une diapositive décrivant clairement vSphere comme une plate-forme d’applications, non pas exclue de l’espace de la plate-forme d’applications, mais plutôt propriétaire de celle-ci. Le pivot est complet.

Embrasser ou être embrassé

Une plate-forme conteneurisée peut fonctionner dans n’importe quel centre de données et a toujours été capable de le faire. Un grand nombre d’entreprises ont déployé de telles plates-formes sous l’enceinte protégée d’une machine virtuelle (VM) de première génération. VMware a aidé de nombreux clients à faire tourner Kubernetes (ou Docker Swarm, ou n’importe quel orchestrateur) dans une machine virtuelle, le tout géré par vSphere. S’il y a un problème de sécurité avec les conteneurs, il est complètement éliminé par la couche d’isolation entre les VM collectives et l’hyperviseur.

Pourquoi cela ne suffit-il pas ? Pourquoi cette coexistence n’est-elle pas suffisante pour convenir aux développeurs de logiciels ? Voici ce que nous ont dit des gens qui ont vécu cette situation eux-mêmes :

L’avantage en termes de performances est perdu

Les gains de vitesse que le déploiement d’une plate-forme de conteneurs en tant qu’infrastructure de base a permis aux entreprises sont réduits puisque l’hébergement de cette plate-forme est délégué à un hyperviseur.

Vous ne pouvez pas construire de microservices avec cette configuration

Dans un environnement de microservices à grande échelle, les conteneurs représentant des instances de fonctions peuvent être augmentés ou réduits en fonction du trafic et de la demande. Ce niveau d’évolutivité nécessite un réseau très fonctionnel et adaptable, ce qui est difficile à réaliser dans une situation de superposition sur la couche réseau.

Ce n’est pas une bonne façon pour automatiser le déploiement de logiciels et la gestion du cycle de vie

L’un des grands avantages des applications et services conteneurisés est leur facilité de déploiement et de gestion, grâce à des plates-formes adaptées à la construction d’images conteneurisées directement autour du code source fonctionnel. Il s’agit du système d’intégration continue et de livraison continue (ou “déploiement”, dans les deux cas CI/CD) que vous connaissez peut-être. Dans ce cas aussi, ce gain est perdu.

En 2014, en réponse à une conférence d’analystes de Gartner qui s’interrogeait sur la question de savoir si les machines virtuelles constituaient une technologie en voie de disparition, Kit Colbert a rédigé un article de blog dans lequel il a faisait valoir les avantages d’utiliser un environnement de conteneur tel que Docker dans une machine virtuelle.

Les conteneurs ne sont pas du tout mauvais disait Kit Colbert, mais les environnements qui les géraient à l’époque n’avaient pas fait leurs preuves. “L’utilisation de conteneurs à l’intérieur de machines virtuelles, écrivait-il, apporte tous les avantages bien connus des machines virtuelles : les propriétés éprouvées d’isolation et de sécurité, … plus la mobilité, la mise en réseau virtuelle dynamique, le stockage défini par logiciel et le vaste écosystème d’outils tiers construits sur des machines virtuelles.”

Kit Colbert ne niait pas que les entreprises utiliseraient des conteneurs dans leur infrastructure numérique ; la seule question était de savoir comment.

L’année suivante, alors que les différents contributeurs à la plate-forme de cloud computing hybride OpenStack exprimaient leur appréhension à l’idée que des plates-formes de conteneurs comme Docker et Kubernetes puissent monter en puissance, VMware a curieusement plongé les deux pieds dedans.

L’entreprise a commencé par créer sa propre distribution Linux appelée Photon, que certains ont vue comme une opportunité pour VMware d’injecter plus tard une sorte d’agent orienté vSphère dans les conteneurs Linux.

C’est ce qui s’est produit immédiatement avec l’introduction de ce que la société a appelé vSphere Integrated Containers (VIC). Étrangement, toute explication technique du CIV dépendait de l’ingénieur VMware sur lequel vous tombiez. Comme me l’a dit l’ingénieur responsable du projet pour The New Stack, la première entrée de VMware dans la conteneurisation a été un système de contrôle des images de la première génération de machines virtuelles et des images de conteneurs Docker, grâce à une réingénierie de Docker pour reconnaître la première comme si elle était la seconde.

Les conteneurs ressemblaient à des VMs pour vSphere parce que le système VIC ajoutait quelques éléments de VM au composant. Les développeurs utilisant Docker, et théoriquement les opérateurs utilisant vSphere, ne remarqueraient pas beaucoup de différence, voire aucune. Kubernetes n’était pas sur le radar de l’équipe du CIV à ce moment-là.

Cependant, comme l’ont reconnu à l’époque les ingénieurs et les chefs de produits de VMware, le système qui en a résulté n’était pas tout à fait adapté aux microservices – l’environnement optimal pour la conteneurisation, où les applications monolithiques sont remplacées par des quantités dynamiques et évolutives de fonctions réparties.

Ailleurs sur le campus VMware, à peu près au même moment, les ingénieurs construisaient le deuxième effort d’intégration. Il s’agissait du projet Photon, qui construirait une plate-forme de gestion séparée pour les conteneurs — pas vSphere ou un add-on vSphere — dont l’hôte serait l’hyperviseur traditionnel, pas le système d’exploitation Linux.

Théoriquement, cela résoudrait l’une des objections les plus crédibles des vétérans des centres de données aux environnements de conteneurs de l’époque : la capacité latente pour un conteneur hébergé sur un OS Linux d’accéder aux systèmes de fichiers de tous les autres conteneurs hébergés par ce même OS. Et comme l’affirme une autre théorie, un environnement Project Photon pourrait être orchestré par Kubernetes, parce que les images de conteneurs ne différeraient ni par leur structure ni par leur format de celles qu’elles auraient normalement dû avoir.

CIV et Photon partagent la même thèse sous-jacente : aucune entreprise n’a une raison commerciale viable de vouloir abandonner sa plate-forme de VM. Certes, VMware, qui s’appuie sur une telle plate-forme pour son gagne-pain, n’a pas envie d’inventer une raison.

Mais si un nouveau moyen de déployer des applications était de conquérir de nouveaux clients d’entreprise que VMware n’avait pas encore exploités, la croissance de vSphere pourrait s’en trouver ralentie. La coexistence ne peut donc pas être la seule vertu justifiant une plate-forme hybride vSphere + Kubernetes, surtout si la somme de ces parties est inférieure à l’un ou l’autre ensemble.

En 2017, VMware a adopté une approche différente : la société a permis à sa société sœur de l’époque, Pivotal, d’introduire son Pivotal Container Service (PKS) basé sur le cloud sur sa scène du VMworld. Il s’agissait d’une plate-forme conteneurisée de déploiement et de gestion d’applications construite autour d’un projet différent qui avait été incubé pour Cloud Foundry, initialement appelé Kubo.

L’idée était de créer une voie d’automatisation pour la prochaine génération de déploiement cloud native – une façon de passer du développement à la mise en production de façon contrôlée, le tout dans Google Cloud. Déjà, VMware parlait de Photon et de VIC au passé, et de la coexistence comme une vertu qui ne doit pas être confinée à un seul environnement. Plus tard, VMware attachera sa propre marque à PKS, et plus tôt cette année, rachètera Pivotal.

La voie à suivre

“Il y a quelques années, nous avons eu l’intuition que Kubernetes pourrait être plus que ce que l’on en pensait alors” a expliqué Jared Rosoff, directeur senior de la gestion des produits VMware pour Project Pacific, lors d’une session VMworld 2019 le 5 septembre dernier.

Le dernier mouvement de VMware en direction de Kubernetes est en fait un grand pas en arrière dans la direction dans laquelle elle s’était initialement dirigée.

Project Pacific est un retour à l’ancienne stratégie : embrasser et étendre. Oui, il s’agissait d’une acquisition, principalement celle du fabricant de plates-formes Kubernetes Heptio en novembre 2018, où VMware a obtenu les services de Joe Beda. Mais c’était une manœuvre assez furtive, plus furtive en tout cas que l’acquisition de Sun Microsystems par Oracle une décennie plus tôt.

Ce que Jared Rosoff semble apprécier le plus chez Kubernetes, c’est la façon dont il permet l’émergence d’un concept dans le centre de données : un concept où l’opérateur écrit un script qui déclare l’état optimal de l’infrastructure et où le système fait de son mieux pour accommoder cet état souhaité. L’expression populaire qui résume cela est infrastructure-as-code, bien qu’il soit remarquable que Jared Rosoff se soit abstenu de prononcer cette expression.

“Kubernetes a cette idée de l’état désiré” explique Jared Rosoff. “Fondamentalement, il y a un plan de contrôle d’état désiré. Et il y a une base de données, où je donne un document qui dit : “C’est l’état souhaité de mon système”, et il y a des contrôleurs qui se connectent à cette base de données, et qui conduisent continuellement l’infrastructure vers cet état souhaité. Ce modèle est en fait construit dans Kubernetes, comme un modèle généralisé.”

Ce n’est peut-être pas évident pour tout le monde de savoir de quoi parle Jared Rosoff, alors revenons-en encore une fois à cette question : un cluster Kubernetes est un assemblage de serveurs, regroupés pour faire de la place pour les conteneurs et les données qu’ils utiliseront.

A l’époque où le logiciel était installé au niveau de base du serveur (le “bare metal”), la configuration de ce serveur était évidente. Si vous aviez besoin de le changer, quelqu’un devait le démonter à l’aide d’un tournevis pour ajouter des DIMMs et un disque dur plus gros.

Mais avec un cluster de serveurs, c’est une toute autre paire de manches. Il s’agit d’une part de serveurs physiques sur site et d’autre part de serveurs virtuels basés sur le cloud public. Sa configuration collective est un ensemble de variables. Il est concevable que ces variables finissent par être fixées à n’importe quelle somme des besoins en ressources de chaque application, quelle qu’elle soit.

Dans un monde plus parfait encore, cependant, cette configuration est quelque chose qu’un administrateur informatique peut spécifier explicitement. Kubernetes recherche ces modèles, et bien que l’un des moyens d’y accéder soit par le biais d’un portail basé sur un navigateur (ou comme l’appelle AWS, “Wizard”) avec lequel un administrateur remplit des formulaires, les opérateurs expérimentés de Kubernetes (oui, de telles personnes existent désormais) préfèrent saisir des déclarations dans un script, et les insérer dans une ligne de commande.

L’outil en ligne de commande de Kubernetes s’appelle kubectl (prononcé “koob – cuddle”), et c’est le composant qui manquait le plus à tous les ingénieurs VMware jusqu’à présent.

Jared Rosoff a exposé la vision de son équipe sur un outil unique qui ressemble à du vSphere basée sur un portail, que les spécialistes de l’IT ont appris à connaître, mais qui inclut également kubectl. Il fonctionnerait exactement comme l’outil sur lequel les ingénieurs d’orchestration de conteneurs en sont venus à s’appuyer, bien que par le biais d’un mécanisme d’extension que les contributeurs de Kubernetes, et non les ingénieurs VMware, ont intégré dans leur propre système, il orchestrerait également efficacement les environnements virtuels pilotés par des machines.

Aujourd’hui, ESXi est l’hôte sous-jacent de toutes les machines virtuelles VMware. Plusieurs serveurs virtuels peuvent être regroupés par le vCenter de VMware, dans ce qui se nomme un cluster VC. Dans l’environnement Project Pacific (encore en cours de développement, d’où le terme “Project”), l’agent de contrôle que Kubernetes injecte normalement dans chaque nœud de serveur, appelé kubelet, est injecté dans ESXi comme un processus natif, non virtualisé. Le résultat est ce que Jared Rosoff a appelé un spherelet — un équivalent de cluster VC au kubelet dans un cluster Kubernetes.

Kubernetes perçoit chaque spherelet comme un kubelet. Ainsi, non seulement vSphere a une vision plus large de deux mondes, mais kubectl l’a aussi.

“Jamais auparavant il n’y avait eu d’interface directe avec vSphere” remarque Jared Rosoff “qu’un développeur pouvait vraiment utiliser de manière significative pour accéder en libre-service aux ressources. C’était toujours un add-on que je devais déployer sur vCenter, un système en couches. Cela signifie qu’en tant que développeur, je peux envoyer une requête directement au système et lui demander de déployer des ressources.”

Ce que CIV avait permis comme mécanisme d’extension à un environnement de conteneurs, a expliqué le chef de produit, Pacific le passe directement dans le noyau de son mécanisme orchestrateur, pour ce qu’il appelle un CRX. Comme un VMX qui exécute une machine virtuelle sur un hyperviseur, le CRX exécute un conteneur sur le même hyperviseur.

Cela signifie que le même isolement de processus accordé à une VM, qui est la clé de son niveau relatif de sécurité, peut être atteint de la même manière par un conteneur.

L’orchestrateur qui perçoit les spherelets dans ESXi, ainsi qu’ailleurs dans le système, et qui considère vSphere comme une plate-forme Kubernetes, est ce que Pacific appelle le cluster superviseur. Ceci permet de distinguer l’orchestrateur derrière Pacific d’un certain nombre d’autres orchestrateurs créés par les utilisateurs de vSphere pour des applications orientées client, sur un plan séparé où les ressources d’infrastructure ne sont pas accessibles.

A ce niveau supérieur, les conteneurs gérés par Kubernetes et les VM traditionnelles sont définis dans leurs propres espaces de noms (namespaces). La manière dont Kubernetes a intentionnellement à l’origine conçu un espace de noms, est une façon abstraite de représenter ce qu’il orchestre, les conteneurs n’étant qu’un exemple.

Maintenant que les machines virtuelles en représentent une autre, le diagramme de Jared Rosoff laisse ouvert un troisième espace de noms pour des composants tels que Microsoft SQL Server, la base de données Apache Cassandra, et le framework de machine learning TensorFlow. De tels composants pourraient être activés par le biais d’un mécanisme de Kubernetes appelé contrôleurs.

“Il y a un énorme catalogue d’opérateurs sur le marché” dit Jared Rosoff. “Bases de données, messagerie et middleware. Nous avons testé des opérateurs avec des outils tels que TensorFlow pour l’intelligence artificielle et le ML. Toutes ces choses que nous pouvons maintenant exécuter en tant qu’extensions du plan de contrôle du superviseur. Ce sera un domaine très puissant à surveiller, car cela signifie que VMware, l’écosystème des partenaires et même votre propre entreprise peuvent créer ces extensions qui fonctionnent nativement dans le plan de contrôle de vSphere, et être présentées comme des objets à vos développeurs, et apparaître comme des objets dans vCenter.”

infrastructure-as-code, ou pas ?

A l’intérieur des limites de VMworld, avec sa vSphere et maintenant ses spherelets, on a souvent l’impression que l’infrastructure ESX s’est étendue à l’infini dans toutes les directions. Mais quelque chose a donné un coup de fouet à VMware, le ramenant à l’objectif d’intégration complète de vSphere qu’il semblait éviter l’année dernière encore, lorsque le PDG Pat Gelsinger déclarait à son auditoire que le meilleur endroit pour diriger Kubernetes était dans une VM.

Mais l’invocation par Jared Rosoff du mécanisme d’état désiré, associée à l’absence manifeste de l’expression “infrastructure-as-code”, suggère une présence mystérieuse dans cette absence. Cette semaine à Seattle, une entreprise dont vous avez peut-être entendu parler une ou deux fois, HashiCorp, a tenu sa propre conférence de trois jours. HashiCorp produit une sorte de système d’orchestration d’infrastructure appelé Terraform. Son but est de permettre aux opérateurs de déclarer l’état optimal de leurs centres de données à l’aide de scripts.

Terraform et vSphere n’ont pas été évoqués ensemble dans les conversations des analystes. Après tout, ils peuvent travailler ensemble de manière interactive, non seulement en coexistant mais aussi en collaborant, vSphere servant de fournisseur de ressources pour le système d’approvisionnement de Terraform. Mais Terraform interagit également avec Kubernetes, ce qui signifie que HashiCorp habite un espace dans le centre de données que VMware préférerait que le projet Pacific occupe.

Lundi dernier, HashiCorp a annoncé une extension de son partenariat avec Microsoft, permettant aux clusters équipés de son service Consul d’être provisionnés sur Azure. C’est le type et le niveau de partenariat qui nous font réaliser que VMware n’entre pas dans une nouvelle ère avec son dernier mouvement vers Kubernetes.

Le projet Pacific pourrait devenir presque tout ce dont VMware aurait pu rêver s’il avait envisagé d’acquérir Kubernetes quatre ou cinq ans auparavant. Mais VMware aura aussi acquis autre chose : une concurrence acharnée. Il ne sera pas capable de contenir ce fait dans une couche isolée d’abstraction pendant très longtemps.

Article “VMware finally decides Kubernetes and vSphere should share a room” traduit et adapté par ZDNet.fr

Leave a Reply

Discover more from Ultimatepocket

Subscribe now to keep reading and get access to the full archive.

Continue reading