Lorsque vous activez vSphere IaaS control plane sur des clusters vSphere et qu'ils deviennent des Superviseurs, le plan de contrôle Kubernetes est créé à 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.

Figure 1. Architecture générale de Superviseur

Le diagramme montre l'architecture de haut niveau vSphere IaaS control plane, avec Tanzu Kubernetes Grid en haut, le Superviseur au centre, puis ESXi, la mise en réseau et le stockage en bas, et l'instance de vCenter Server qui gère cet ensemble.

Architecture avec Tanzu Kubernetes Grid en haut, le superviseur au centre, ESXi, la mise en réseau et le stockage en bas. L'instance de vCenter Server gère cet ensemble.

Un Superviseur s'exécute au-dessus d'une couche SDDC qui se compose d'ESXi pour les calculs, de NSX ou de la mise en réseau VDS, ainsi que de vSAN ou d'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 Superviseur et les espaces d'un cluster Tanzu Kubernetes Grid. Après la création d'un Superviseur, en tant qu'administrateur vSphere, vous pouvez créer des Espaces de noms vSphere dans le Superviseur. 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, déployer des machines virtuelles via le service de machine virtuelle et créer des clusters Tanzu Kubernetes Grid.

Vous pouvez déployer un Superviseur sur trois zones vSphere pour fournir une haute disponibilité au niveau du cluster qui protège vos charges de travail Kubernetes contre les pannes au niveau du cluster. Une zone vSphere est mappée à un cluster vSphere que vous pouvez configurer en tant que domaine de panne indépendant. Dans un déploiement à trois zones, les trois clusters vSphere deviennent un seul Superviseur. Vous pouvez également déployer un Superviseur sur un cluster vSphere, ce qui créera automatiquement une zone vSphere et la mappera au cluster, sauf si vous utilisez un cluster vSphere déjà mappé à une zone. Dans un déploiement de cluster unique, le Superviseur ne dispose que de la haute disponibilité au niveau de l'hôte fournie par vSphere HA.

Figure 2. Architecture d'un superviseur de trois zones

Architecture avec trois zones, dans laquelle les clusters TKG s'exécutent au-dessus de l'Espace de noms vSphere, se trouvant au-dessus d'un Superviseur, déployés sur trois zones vSphere.

Sur un Superviseur de trois zones, vous pouvez exécuter des charges de travail sur des clusters Tanzu Kubernetes Grid et des machines virtuelles créés à l'aide du service de machine virtuelle. Un Superviseur de trois zones dispose des composants suivants :

  • VM du plan de contrôle du Superviseur. Au total, trois machines virtuelles de plan de contrôle du Superviseur sont créées sur le Superviseur. Dans un déploiement à trois zones, une machine virtuelle de plan de contrôle réside sur chaque zone. Les trois machines virtuelles du plan de contrôle du Superviseur 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 et une 5e adresse IP est réservée à des fins de correction. vSphere DRS détermine le placement exact des machines virtuelles du plan de contrôle sur les hôtes ESXi faisant partie du Superviseur et les migre lorsque cela est nécessaire.
  • Tanzu Kubernetes Grid et API de cluster. Modules s'exécutant sur le Superviseur et qui permettent le provisionnement et la gestion de clusters Tanzu Kubernetes Grid.
  • Service de machine virtuelle. Module responsable du déploiement et de l'exécution des machines virtuelles autonomes et des machines virtuelles qui constituent les clusters Tanzu Kubernetes Grid.

Dans un Superviseur de trois zones, un pool de ressources d'espace de noms est créé sur chaque cluster vSphere mappé à une zone. L'espace de noms s'étend sur les trois clusters vSphere de chaque zone. Les ressources utilisées pour l'espace de noms d'un Superviseur de trois zones sont prises à partir des trois clusters vSphere sous-jacents en parties égales. Par exemple, si vous dédiez 300 MHz de CPU, 100 MHz sont prélevés sur chaque cluster vSphere.

Figure 3. Architecture de superviseur à cluster unique

Un zone Superviseur à une zone, avec l'opérateur de machine virtuelle, l'API du cluster, Tanzu Kubernetes Grid, les machines virtuelles du plan de contrôle et les modules Spherelet.

Un Superviseur déployé sur un cluster vSphere unique dispose également de trois machines virtuelles de plan de contrôle, qui résident sur la partie hôtes ESXi du cluster. Sur un Superviseur à cluster unique, vous pouvez exécuter des Espaces vSphere en plus des clusters Tanzu Kubernetes Grid et des machines virtuelles. vSphere DRS est intégré au planificateur Kubernetes sur les machines virtuelles du plan de contrôle du Superviseur, 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.

En raison de la prise en charge de la Espace vSphere, un Superviseur à cluster unique dispose des composants supplémentaires suivants :

  • 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.
  • Composant 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.