Project Pacific
L’idée de Project Pacific a émergé avec la question suivante : Comment manager un environnement hétéroclite (VMs, Pods, Serverless functions, applications packagées …) d’une façon unique ?
La réponse de VMware a été d’utiliser Kubernetes, notamment grâce à l’essor des Operators.
VMware a développé un ensemble de CRD et d’operators afin d’étendre les capacités de k8s à l’ensemble des fonctionnalités de vCenter. Ainsi, grâce à Project Pacific, il est possible de créer des VMs (VMware avec des vmdk) via l’API Kubernetes.
Ils ont aussi étendu le concept de namespace aux ressources vCenters (qos, quotas, policy, access controls …).
Ce Kubernetes intégré aux ESXi (en tant que VM) est appelé le Supervisor Kubernetes Cluster et est principalement dédié aux Ops.
Afin de ne pas rentrer en conflit avec vCenter, Kubernetes utiliser DRS comme scheduler afin de spawner ses “Native Pods”, et la gestion des Pods à des Spherelet (Kubelet modifiés pour ESXi).
Ces premiers sont similaires au projet Kata Container (porté par la communauté OpenStack) ou VKE, mais portant directement des pods plutôt que des containers.
Afin d’éviter de donner l’accès aux développeurs à l’intégralité de vCenters, ceux-ci pourront déployer des clusters Kubernetes via le Supervisor Kubernetes Cluster (via un fichier yaml). Ces clusters pourront être des clusters PKS ou OpenShift par exemple.
Cette entrée de Kubernetes dans le mode vCenter impactera aussi le programme de certification vCenter.
Le Kubernetes Supervisor Cluster sera à l’image des masters gérés dans le cloud, toutes les fonctionnalités natives de Kubernetes ne seront pas forcément disponibles aux opérateurs et le cycle de vie de celui-ci sera découplé du cycle de vie de vCenter.
Bien entendu, des changements peuvent encore intervenir sur la solution, celle-ci étant encore en développement.
