Lorsque vSphere with Tanzu est activé sur un cluster vSphere, il crée un plan de contrôle Kubernetes à l'intérieur de la couche d'hyperviseur. Cette couche contient des objets spécifiques qui permettent d'exécuter des charges de travail Kubernetes dans ESXi.
Un cluster pour lequel vSphere with Tanzu est activé est appelé un Cluster superviseur. Elle s'exécute au-dessus d'une couche SDDC qui se compose d'ESXi pour les calculs, NSX-T Data Center ou la mise en réseau vSphere, ainsi que vSAN ou une autre solution de stockage partagé. Le stockage partagé est utilisé pour les volumes persistants des Espaces vSphere, les machines virtuelles exécutées dans le Cluster superviseur et les espaces d'un cluster Tanzu Kubernetes. Après la création d'un Cluster superviseur, en tant qu'administrateur vSphere vous pouvez créer des espaces de noms dans le Cluster superviseur appelés Espace de noms vSphere. En tant qu'ingénieur DevOps vous pouvez exécuter des charges de travail composées de conteneurs s'exécutant dans des Espaces vSphere et créer des clusters Tanzu Kubernetes.
- Machine virtuelle de plan de contrôle Kubernetes. Trois machines virtuelles de plan de contrôle Kubernetes au total sont créées sur les hôtes faisant partie du Cluster superviseur. Les trois machines virtuelles du plan de contrôle sont équilibrées en charge, car chacune d'elles dispose de sa propre adresse IP. En outre, une adresse IP flottante est attribuée à l'une des machines virtuelles. vSphere DRS détermine le placement exact des machines virtuelles du plan de contrôle sur les hôtes ESXi et les migre lorsque cela est nécessaire. vSphere DRS est également intégré au planificateur Kubernetes sur les machines virtuelles du plan de contrôle, de sorte que le DRS détermine le placement des Espaces vSphere. Lorsque, en tant qu'ingénieur DevOps, vous planifiez une Espace vSphere, la demande passe par le workflow Kubernetes normal, puis par DRS, qui prend la décision de placement finale.
- Spherelet. Un processus supplémentaire appelé Spherelet est créé sur chaque hôte. Il s'agit d'un kubelet qui est porté en mode natif sur ESXi et permet à l'hôte ESXi de faire partie du cluster Kubernetes.
- Container Runtime Executive (CRX). CRX est semblable à une machine virtuelle dans la perspective de Hostd et de vCenter Server. CRX inclut un noyau Linux paravirtualisé qui fonctionne en synergie avec l'hyperviseur. CRX utilise les mêmes techniques de virtualisation matérielle que les machines virtuelles et il fait l'objet d'une limite de machine virtuelle. Une technique de démarrage direct est utilisée, ce qui permet à l'invité Linux de CRX de lancer le processus d'initialisation principal sans passer par l'initialisation du noyau. Cela permet à des Espaces vSphere de démarrer presque aussi rapidement que des conteneurs.
- L'API de cluster et le Service VMware Tanzu™ Kubernetes Grid™ sont des modules qui s'exécutent sur le Cluster superviseur et permettent le provisionnement et la gestion de clusters Tanzu Kubernetes. Le module Service de machine virtuelle est responsable du déploiement et de l'exécution des machines virtuelles autonomes et des machines virtuelles qui constituent les clusters Tanzu Kubernetes.
Espace de noms vSphere
Un Espace de noms vSphere définit les limites des ressources pour lesquelles des Espaces vSphere et des clusters Tanzu Kubernetes créés à l'aide du Service Tanzu Kubernetes Grid peuvent s'exécuter. Lors de sa création initiale, l'espace de noms dispose de ressources illimitées au sein du Cluster superviseur. En tant qu'administrateur vSphere vous pouvez définir des limites pour le CPU, la mémoire, le stockage, ainsi que le nombre d'objets Kubernetes qui peuvent s'exécuter dans l'espace de noms. Un pool de ressources est créé pour chaque espace de noms dans vSphere. Les limitations de stockage sont représentées sous forme de quotas de stockage dans Kubernetes.
Pour fournir à l'ingénieur DevOps un accès aux espaces de noms, en tant qu'administrateur vSphere vous attribuez l'autorisation aux utilisateurs ou aux groupes d'utilisateurs disponibles dans une source d'identité associée à vCenter Single Sign-On.
Une fois qu'un espace de noms est créé et configuré avec des limites de ressources et d'objets, ainsi qu'avec des stratégies d'autorisations et de stockage, en tant qu'ingénieur DevOps vous pouvez accéder à l'espace de noms pour exécuter des charges de travail Kubernetes et créer des clusters Tanzu Kubernetes à l'aide du Service Tanzu Kubernetes Grid.
Clusters Tanzu Kubernetes
Un cluster Tanzu Kubernetes est une distribution complète du logiciel open source Kubernetes qui est assemblée, signée et prise en charge par VMware. Dans le contexte de vSphere with Tanzu, vous pouvez utiliser le Service Tanzu Kubernetes Grid pour provisionner des clusters Tanzu Kubernetes sur Cluster superviseur. Vous pouvez appeler l'API du Service Tanzu Kubernetes Grid de manière déclarative à l'aide de kubectl et d'une définition YAML.
Cluster superviseur configuré avec la pile de mise en réseau vSphere
Un Cluster superviseur configuré avec la pile de mise en réseau vSphere prend uniquement en charge l'exécution de clusters Tanzu Kubernetes créés à l'aide du Service Tanzu Kubernetes Grid. Le cluster prend également en charge le Service réseau vSphere et le service de stockage.
Un Cluster superviseur configuré avec la pile de mise en réseau vSphere ne prend pas en charge les Espaces vSphere. Par conséquent, le composant Spherelet n'est pas disponible dans ce Cluster superviseur et les espaces Kubernetes s'exécutent uniquement dans des clusters Tanzu Kubernetes. Un Cluster superviseur configuré avec la pile de mise en réseau vSphere ne prend pas non plus en charge le Registre Harbor, car le service est utilisé uniquement avec les Espaces vSphere.
Un Espace de noms vSphere créé sur un cluster configuré avec la pile de mise en réseau vSphere ne prend pas non plus en charge l'exécution des Espaces vSphere, mais uniquement les clusters Tanzu Kubernetes.
