Venez plonger dans le projet Pacific !
Nous donnons suite à l’introduction sur Project Pacific que vous pouvez retrouver sur le lien suivant :
Aujourd’hui nous avons essayé de comprendre encore plus la composition des briques de base de Project Pacific : Supervisor Cluster & Guest Cluster.
Rien de mieux que d’entamer ce topic par la fameuse citation « Kubernetes is a platform for creating other platforms » rappelé ce matin par Joe Beda lors de la keynote.
Effectivement, le Supervisor Cluster va amener une nouvelle vision du Workload dans un environnement vSphere.
Traditionnellement, la notion de workload faisait référence à une machine virtuelle ou une vApp. La nouveauté, dans Projet Pacific, est qu’un workload peut être une VM, un Guest Cluster Kubernetes ou un « Native Pod ». Pour arriver à cette fin, rien de mieux que d’utiliser une couche fondée sur Kubernetes.
Le Supervisor Cluster assurera aussi le contrôle et la gestion des workload en suivant une topologie intelligemment calquée de celle d’un cluster Kubernetes Vanilla sauf que les agents « Kubelet » seront remplacés par leurs homologues vSphere appelés « Spherelet ».
Comme le montre le schéma, l’agent « Workload Platform Service » jouera le rôle de négociateur et traducteur entre l’environnement vSphere et la nouvelle plateforme kubernetes.
Une autre légère transformation sur la composition du Master Node sur le superviseur par l’ajout d’un agent d’authentification « Authentication Proxy » et les plugins d’interfaçages réseaux et stockage.
Dans ce contexte, VMware a annoncé que seul NSX-T est supporté en CNI.
Le VM Operator est une autre composante clé dans l’écosystème. Son rôle sera de permettre la création, contrôle et gestion des VMs.
De cette manière, Project Pacific offre la possibilité aux différentes formes d’abstraction et de virtualisation d’harmonieusement coexister dans le groupement logique appelé « Namespaces ».
Maintenant, il est facile de deviner que les Guest Clusters sont simplement le cluster Kubernetes à consommer par les Devs. La différence par rapport à PKS est que le Cluster API prendra le relais sur BOSH Director pour le provisioning et la mise en état désiré des Guest Clusters.
Un autre facteur intéressant : grâce à la mise en place d’un système d’authentification bien adapté au contexte Kubernetes et nativement intégré dans l’environnement vSphere, la gestion d’utilisateur sur le Supervisor Cluster et le Guest Cluster est agile et facile à administrer.
Contrairement au Supervisor Cluster, les Guest Clusters porterons la version upstream kubernetes. Ainsi, les développeurs pourront toujours profiter des dernières mises à jour et des nouvelles fonctionnalités sur leur release de choix.
Cette nouvelle approche d’intégration Kubernetes sur l’environnement vSphere donnera plus d’agilité et de flexibilité aux Ops et garantira une expérience Kubernetes Vanilla pour les développeurs.
Si Project Pacific vous intéresse, vous pouvez participer au Beta Test en visitant le lien suivant : https://www.vmware.com/learn/291851_vSphere_Beta_Reg.html
