Examinez la configuration système requise pour la configuration de vSphere with Tanzu sur un cluster vSphere à l'aide de la pile de mise en réseau NSX-T Data Center.

Limites de configuration maximales pour les clusters vSphere with Tanzu

VMware fournit des limites de configuration dans l'outil Valeurs maximales de configuration VMware.

Pour les limites de configuration spécifiques à vSphere with Tanzu, notamment les Clusters superviseurs et les clusters Tanzu Kubernetes, sélectionnez vSphere > vSphere 7.0 > vSphere with Kubernetes > VMware Tanzu Kubernetes Grid Service for vSphere et cliquez sur Afficher les limites ou suivez ce lien.

Configuration requise pour un cluster de gestion, Edge et de domaine de la charge de travail

Vous pouvez déployer vSphere with Tanzu avec des fonctions combinées de gestion, Edge et de gestion de la charge de travail sur un cluster vSphere unique.
Tableau 1. Conditions requises minimales de calcul pour le cluster de gestion, Edge et de gestion de la charge de travail
Système Taille de déploiement minimale CPU Mémoire Stockage
vCenter Server 7.0 Petite 2 16 Go 290 Go
Hôtes ESXi 7.0 3 hôtes ESXi avec 1 adresse IP statique par hôte.

Si vous utilisez vSAN : 3 hôtes ESXi avec au moins 2 cartes réseau physiques par hôte constituent le minimum. Cependant, 4 hôtes ESXi sont recommandés pour garantir la résilience lors d'une application de correctifs et d'une mise à niveau.

Les hôtes doivent être joints dans un cluster sur lequel vSphere DRS et HA sont activés. vSphere DRS doit être en mode Entièrement automatisé ou Partiellement automatisé.

Attention : Ne désactivez pas vSphere DRS après avoir configuré le Cluster superviseur. L'activation de DRS est obligatoire pour exécuter des charges de travail sur le Cluster superviseur. La désactivation de DRS entraîne la rupture de vos clusters Tanzu Kubernetes.
8 64 Go par hôte Non applicable
NSX Manager Moyen 6 24 Go 300 Go
NSX Edge 1 Grande 8 32 Go 200 Go
NSX Edge 2 Grande 8 32 Go 200 Go
Machines virtuelles de plan de contrôle Kubernetes 3 4 16 Go 16 Go

Topologie avec cluster de gestion et Edge, et cluster de gestion de la charge de travail séparés

Vous pouvez déployer vSphere with Tanzu dans deux clusters, un cluster pour les fonctions de gestion et Edge, et un autre dédié à la gestion de la charge de travail,

Tableau 2. Conditions requises minimales de calcul pour le cluster de gestion et Edge
Système Taille de déploiement minimale CPU Mémoire Stockage
vCenter Server 7.0 Petite 2 16 Go 290 Go
Hôtes ESXi 7.0 2 hôtes ESXi 8 64 Go par hôte Non applicable
NSX Manager Moyen 6 24 Go 300 Go
NSX Edge 1 Grande 8 32 Go 200 Go
NSX Edge 2 Grande 8 32 Go 200 Go
Tableau 3. Conditions requises minimales de calcul pour le cluster de gestion de la charge de travail
Système Taille de déploiement minimale CPU Mémoire Stockage
Hôtes ESXi 7.0 3 hôtes ESXi avec 1 adresse IP statique par hôte.

Si vous utilisez des hôtes vSAN : 3 hôtes ESXi disposant d'au moins 2 cartes réseau physiques par hôte constituent le minimum ; cependant, il est recommandé de disposer de 4 hôtes ESXi pour garantir la résilience pendant les correctifs et les mises à niveau.

Les hôtes doivent être joints dans un cluster sur lequel vSphere DRS et HA sont activés. vSphere DRS doit être en mode entièrement automatisé.

Attention : Ne désactivez pas vSphere DRS après avoir configuré le Cluster superviseur. L'activation de DRS est obligatoire pour exécuter des charges de travail sur le Cluster superviseur. La désactivation de DRS entraîne la rupture de vos clusters Tanzu Kubernetes.
8 64 Go par hôte Non applicable
Machines virtuelles de plan de contrôle Kubernetes 3 4 16 Go 16 Go

Spécifications réseau

Quelle que soit la topologie que vous mettez en œuvre pour la gestion de la charge de travail Kubernetes dans vSphere, votre déploiement doit répondre aux exigences de mise en réseau répertoriées dans le tableau ci-dessous.
Note : Vous ne pouvez pas créer de clusters IPv6 avec un Cluster superviseur sous vSphere 7 ou enregistrer des clusters IPv6 dans Tanzu Mission Control.
Composant Quantité minimale Configuration requise
Adresses IP statiques pour les machines virtuelles du plan de contrôle Kubernetes Bloc de 5 Bloc de 5 adresses IP statiques consécutives à attribuer aux machines virtuelles du plan de contrôle Kubernetes dans le Cluster superviseur.
Réseau de gestion du trafic 1 Réseau de gestion routable vers les hôtes ESXi, l'instance de vCenter Server et le serveur DHCP. Le réseau doit pouvoir accéder à un registre de conteneur et disposer d'une connectivité Internet si le registre de conteneur se trouve sur le réseau externe. Le registre de conteneur doit pouvoir être résolu via DNS et le paramètre de sortie décrit ci-dessous doit pouvoir l'atteindre.
Serveur NTP et DNS 1 Serveur DNS et serveur NTP pouvant être utilisés pour l'instance de vCenter Server.
Note : Configurez NTP sur tous les hôtes ESXi, les systèmes vCenter Server et les instances de NSX Manager.
Serveur DHCP 1 Facultatif. Configurez un serveur DHCP pour acquérir automatiquement des adresses IP pour la gestion. Le serveur DHCP doit prendre en charge les identificateurs de client et fournir des serveurs DNS compatibles, des domaines de recherche DNS et un serveur NTP.
Registre d'images 1 Accès à un registre pour le service.
Sous-réseau du réseau de gestion 1
Le sous-réseau utilisé pour le trafic de gestion entre les hôtes ESXi et vCenter Server, les dispositifs NSX et le plan de contrôle Kubernetes. La taille du sous-réseau doit être la suivante :
  • Une adresse IP par adaptateur VMkernel hôte.
  • Une adresse IP du dispositif vCenter Server Appliance.
  • Une ou quatre adresses IP pour NSX Manager. Quatre lors de l'exécution du clustering de NSX Manager de 3 nœuds et d'une adresse IP virtuelle (VIP).
  • 5 adresses IP pour le plan de contrôle Kubernetes. 1 pour chacun des 3 nœuds, 1 pour l'adresse IP virtuelle, 1 pour le déploiement de la mise à niveau du cluster.
Note : Le réseau de gestion et le réseau de charge de travail doivent se trouver sur des sous-réseaux différents. L'attribution du même sous-réseau aux réseaux de gestion et aux réseaux de charge de travail n'est pas prise en charge et peut entraîner des erreurs système et des problèmes.
VLAN du réseau de gestion 1 ID de VLAN du sous-réseau du réseau de gestion.
VLAN 3 Ces adresses IP de VLAN sont les adresses IP des points de terminaison de tunnel (TEP). Le TEP de l'hôte ESXi et les TEP Edge doivent être routables.
Les adresses IP de VLAN sont requises pour les éléments suivants :
  • VTEP d'hôte ESXi
  • VTEP Edge utilisant l'adresse IP statique
  • Passerelle de niveau 0 et liaison montante pour le nœud de transport.
Note : Le VTEP d'hôte ESXi et le VTEP Edge doivent avoir une taille de MTU supérieure à 1 600.

Les hôtes ESXi et les nœuds NSX-T Edge servent de points de terminaison de tunnel et une adresse IP de point de terminaison de tunnel (TEP) est attribuée à chaque hôte et à chaque nœud Edge.

Comme les adresses IP des TEP pour les hôtes ESXi créent un tunnel de superposition avec des adresses IP de TEP sur les nœuds Edge, les adresses IP de VLAN doivent être routables.

Un VLAN supplémentaire est requis pour fournir une connectivité Nord-Sud à la passerelle de niveau 0.

Les pools d'adresses IP peuvent être partagés entre clusters. Cependant, le pool d'adresses IP de superposition d'hôte/VLAN ne doit pas être partagé avec le pool d'adresses IP/VLAN de superposition Edge.

Note : Si les TEP hôtes et les TEP Edge utilisent des cartes réseau physiques différentes, ils peuvent utiliser le même VLAN.
Adresse IP de liaison montante de niveau 0 Adresses IP privées /24 Sous-réseau IP utilisé pour la liaison montante de niveau 0. Les conditions requises pour l'adresse IP de la liaison montante de niveau 0 sont les suivantes :
  • 1 adresse IP, si vous n'utilisez pas de redondance Edge.
  • 4 adresses IP, si vous utilisez BGP et une redondance Edge, 2 adresses IP par dispositif Edge.
  • 3 adresses IP, si vous utilisez des routes statiques et une redondance Edge.

L'adresse IP, le sous-réseau et la passerelle de la gestion Edge, l'adresse IP, le sous-réseau et la passerelle de liaison montante doivent être uniques.
MTU de réseau physique 1 600 La taille de MTU doit être 1 600 ou une valeur supérieure sur n'importe quel réseau transportant du trafic de superposition.
Plage CIDR de l'Espace vSphere Adresses IP privées /23 Plage CIDR privée qui fournit les adresses IP pour les Espaces vSphere. Ces adresses sont également utilisées pour les nœuds de cluster Tanzu Kubernetes.
Vous devez spécifier une plage CIDR unique d' Espace vSphere pour chaque cluster.
Note : La plage CIDR d' Espace vSphere et la plage CIDR des adresses de service Kubernetes ne doivent pas se chevaucher.
Plage CIDR des services Kubernetes Adresses IP privées /16 Plage CIDR privée pour attribuer des adresses IP aux services Kubernetes. Vous devez spécifier une plage CIDR de services Kubernetes unique pour chaque Cluster superviseur.
Plage CIDR de sortie Adresses IP statiques /27 Annotation CIDR privée pour déterminer l'adresse IP de sortie des services Kubernetes. Une seule adresse IP de sortie est attribuée à chaque espace de noms dans le Cluster superviseur. L'adresse IP de sortie est l'adresse que les entités externes utilisent pour communiquer avec les services dans l'espace de noms. Le nombre d'adresses IP de sortie limite le nombre de stratégies de sortie dont peut disposer le Cluster superviseur.
La valeur minimale est un CIDR d'au moins/27. Par exemple, 10.174.4.96/27
Note : Les adresses IP de sortie et les adresses IP d'entrée ne doivent pas chevaucher.
CIDR d'entrée Adresses IP statiques /27 Plage CIDR privée à utiliser pour les adresses IP d'entrée. L'entrée vous permet appliquer des stratégies de trafic aux demandes entrant dans le Cluster superviseur en provenance de réseaux externes. Le nombre d'adresses IP d'entrée limite le nombre d'entrées dont dispose le cluster.
La valeur minimale est un CIDR d'au moins /27.
Note : Les adresses IP de sortie et les adresses IP d'entrée ne doivent pas chevaucher.