Configuration du cluster de gestion pour vSphere

Pour créer un fichier de configuration de cluster, vous pouvez copier un fichier de configuration existant d'un déploiement précédent sur vSphere et le mettre à jour. Vous pouvez également créer un tout nouveau fichier en utilisant un modèle vide.

Modèle de configuration du cluster de gestion

Le modèle ci-dessous inclut toutes les options pertinentes pour le déploiement de clusters de gestion sur vSphere. Vous pouvez copier ce modèle et l'utiliser pour déployer des clusters de gestion sur vSphere.

Pour plus d'informations sur la mise à jour des paramètres communs à toutes les plates-formes cibles, reportez-vous à la section Créer un fichier de configuration de cluster de gestion.
Pour plus d'informations sur toutes les variables de fichier de configuration, reportez-vous à la Référence de variable du fichier de configuration.
Pour obtenir des exemples de configuration des paramètres vSphere, reportez-vous aux sections sous le modèle.

Les marques de commentaire sont supprimées pour les options obligatoires. Elles sont ajoutées pour les paramètres facultatifs. Les valeurs par défaut sont incluses le cas échéant.

#! ---------------------------------------------------------------------
#! Basic cluster creation configuration
#! ---------------------------------------------------------------------

CLUSTER_NAME:
CLUSTER_PLAN: dev
INFRASTRUCTURE_PROVIDER: vsphere
# CLUSTER_API_SERVER_PORT: # For deployments without NSX Advanced Load Balancer
ENABLE_CEIP_PARTICIPATION: true
ENABLE_AUDIT_LOGGING: true
CLUSTER_CIDR: 100.96.0.0/11
SERVICE_CIDR: 100.64.0.0/13
# CAPBK_BOOTSTRAP_TOKEN_TTL: 30m

#! ---------------------------------------------------------------------
#! vSphere configuration
#! ---------------------------------------------------------------------

VSPHERE_SERVER:
VSPHERE_USERNAME:
VSPHERE_PASSWORD:
VSPHERE_DATACENTER:
VSPHERE_RESOURCE_POOL:
VSPHERE_DATASTORE:
VSPHERE_FOLDER:
VSPHERE_NETWORK: VM Network
# VSPHERE_CONTROL_PLANE_ENDPOINT: # Required for Kube-Vip
# VSPHERE_CONTROL_PLANE_ENDPOINT_PORT: 6443
VIP_NETWORK_INTERFACE: "eth0"
# VSPHERE_TEMPLATE:
VSPHERE_SSH_AUTHORIZED_KEY:
# VSPHERE_STORAGE_POLICY_ID: ""
VSPHERE_TLS_THUMBPRINT:
VSPHERE_INSECURE: false
DEPLOY_TKG_ON_VSPHERE7: false
ENABLE_TKGS_ON_VSPHERE7: false

#! ---------------------------------------------------------------------
#! Node configuration
#! ---------------------------------------------------------------------

# SIZE:
# CONTROLPLANE_SIZE:
# WORKER_SIZE:
# OS_NAME: ""
# OS_VERSION: ""
# OS_ARCH: ""
# VSPHERE_NUM_CPUS: 2
# VSPHERE_DISK_GIB: 40
# VSPHERE_MEM_MIB: 4096
# VSPHERE_MTU:
# VSPHERE_CONTROL_PLANE_NUM_CPUS: 2
# VSPHERE_CONTROL_PLANE_DISK_GIB: 40
# VSPHERE_CONTROL_PLANE_MEM_MIB: 8192
# VSPHERE_WORKER_NUM_CPUS: 2
# VSPHERE_WORKER_DISK_GIB: 40
# VSPHERE_WORKER_MEM_MIB: 4096

#! ---------------------------------------------------------------------
#! VMware NSX specific configuration for enabling NSX routable pods
#! ---------------------------------------------------------------------

# NSXT_POD_ROUTING_ENABLED: false
# NSXT_ROUTER_PATH: ""
# NSXT_USERNAME: ""
# NSXT_PASSWORD: ""
# NSXT_MANAGER_HOST: ""
# NSXT_ALLOW_UNVERIFIED_SSL: false
# NSXT_REMOTE_AUTH: false
# NSXT_VMC_ACCESS_TOKEN: ""
# NSXT_VMC_AUTH_HOST: ""
# NSXT_CLIENT_CERT_KEY_DATA: ""
# NSXT_CLIENT_CERT_DATA: ""
# NSXT_ROOT_CA_DATA: ""
# NSXT_SECRET_NAME: "cloud-provider-vsphere-nsxt-credentials"
# NSXT_SECRET_NAMESPACE: "kube-system"

#! ---------------------------------------------------------------------
#! NSX Advanced Load Balancer configuration
#! ---------------------------------------------------------------------

AVI_ENABLE: false
AVI_CONTROL_PLANE_HA_PROVIDER: false
# AVI_NAMESPACE: "tkg-system-networking"
# AVI_DISABLE_INGRESS_CLASS: true
# AVI_AKO_IMAGE_PULL_POLICY: IfNotPresent
# AVI_ADMIN_CREDENTIAL_NAME: avi-controller-credentials
# AVI_CA_NAME: avi-controller-ca
# AVI_CONTROLLER:
# AVI_USERNAME: ""
# AVI_PASSWORD: ""
# AVI_CLOUD_NAME:
# AVI_SERVICE_ENGINE_GROUP:
# AVI_NSXT_T1LR: # Required for NSX ALB deployments on NSX Cloud.
# AVI_MANAGEMENT_CLUSTER_SERVICE_ENGINE_GROUP:
# AVI_DATA_NETWORK:
# AVI_DATA_NETWORK_CIDR:
# AVI_MANAGEMENT_CLUSTER_VIP_NETWORK_NAME:
# AVI_MANAGEMENT_CLUSTER_VIP_NETWORK_CIDR:
# AVI_CA_DATA_B64: ""
# AVI_LABELS: ""
# AVI_DISABLE_STATIC_ROUTE_SYNC: true
# AVI_INGRESS_DEFAULT_INGRESS_CONTROLLER: false
# AVI_INGRESS_SHARD_VS_SIZE: ""
# AVI_INGRESS_SERVICE_TYPE: ""
# AVI_INGRESS_NODE_NETWORK_LIST: ""

#! ---------------------------------------------------------------------
#! Image repository configuration
#! ---------------------------------------------------------------------

# TKG_CUSTOM_IMAGE_REPOSITORY: ""
# TKG_CUSTOM_IMAGE_REPOSITORY_CA_CERTIFICATE: ""

#! ---------------------------------------------------------------------
#! Proxy configuration
#! ---------------------------------------------------------------------

# TKG_HTTP_PROXY: ""
# TKG_HTTPS_PROXY: ""
# TKG_NO_PROXY: ""

#! ---------------------------------------------------------------------
#! Machine Health Check configuration
#! ---------------------------------------------------------------------

ENABLE_MHC:
ENABLE_MHC_CONTROL_PLANE: true
ENABLE_MHC_WORKER_NODE: true
MHC_UNKNOWN_STATUS_TIMEOUT: 5m
MHC_FALSE_STATUS_TIMEOUT: 12m

#! ---------------------------------------------------------------------
#! Identity management configuration
#! ---------------------------------------------------------------------

IDENTITY_MANAGEMENT_TYPE: "none"

#! Settings for IDENTITY_MANAGEMENT_TYPE: "oidc"
# CERT_DURATION: 2160h
# CERT_RENEW_BEFORE: 360h
# OIDC_IDENTITY_PROVIDER_CLIENT_ID:
# OIDC_IDENTITY_PROVIDER_CLIENT_SECRET:
# OIDC_IDENTITY_PROVIDER_GROUPS_CLAIM: groups
# OIDC_IDENTITY_PROVIDER_ISSUER_URL:
# OIDC_IDENTITY_PROVIDER_SCOPES: "email,profile,groups,offline_access"
# OIDC_IDENTITY_PROVIDER_USERNAME_CLAIM: email

#! The following two variables are used to configure Pinniped JWTAuthenticator for workload clusters
# SUPERVISOR_ISSUER_URL:
# SUPERVISOR_ISSUER_CA_BUNDLE_DATA:

#! Settings for IDENTITY_MANAGEMENT_TYPE: "ldap"
# LDAP_BIND_DN:
# LDAP_BIND_PASSWORD:
# LDAP_HOST:
# LDAP_USER_SEARCH_BASE_DN:
# LDAP_USER_SEARCH_FILTER:
# LDAP_USER_SEARCH_ID_ATTRIBUTE: dn
# LDAP_USER_SEARCH_NAME_ATTRIBUTE:
# LDAP_GROUP_SEARCH_BASE_DN:
# LDAP_GROUP_SEARCH_FILTER:
# LDAP_GROUP_SEARCH_NAME_ATTRIBUTE: dn
# LDAP_GROUP_SEARCH_USER_ATTRIBUTE: dn
# LDAP_ROOT_CA_DATA_B64:

#! ---------------------------------------------------------------------
#! Antrea CNI configuration
#! ---------------------------------------------------------------------

# ANTREA_NO_SNAT: true
# ANTREA_NODEPORTLOCAL: true
# ANTREA_NODEPORTLOCAL_ENABLED: true
# ANTREA_NODEPORTLOCAL_PORTRANGE: 61000-62000
# ANTREA_TRAFFIC_ENCAP_MODE: "encap"
# ANTREA_PROXY: true
# ANTREA_PROXY_ALL: true
# ANTREA_PROXY_LOAD_BALANCER_IPS: false
# ANTREA_PROXY_NODEPORT_ADDRS:
# ANTREA_PROXY_SKIP_SERVICES: ""
# ANTREA_POLICY: true
# ANTREA_TRACEFLOW: true
# ANTREA_DISABLE_UDP_TUNNEL_OFFLOAD: false
# ANTREA_ENABLE_USAGE_REPORTING: false
# ANTREA_EGRESS: true
# ANTREA_EGRESS_EXCEPT_CIDRS: ""
# ANTREA_FLOWEXPORTER: false
# ANTREA_FLOWEXPORTER_COLLECTOR_ADDRESS: "flow-aggregator.flow-aggregator.svc:4739:tls"
# ANTREA_FLOWEXPORTER_POLL_INTERVAL: "5s"
# ANTREA_FLOWEXPORTER_ACTIVE_TIMEOUT: "5s"
# ANTREA_FLOWEXPORTER_IDLE_TIMEOUT: "15s"
# ANTREA_IPAM: false
# ANTREA_KUBE_APISERVER_OVERRIDE: ""
# ANTREA_MULTICAST: false
# ANTREA_MULTICAST_INTERFACES: ""
# ANTREA_NETWORKPOLICY_STATS: true
# ANTREA_SERVICE_EXTERNALIP: true
# ANTREA_TRANSPORT_INTERFACE: ""
# ANTREA_TRANSPORT_INTERFACE_CIDRS: ""

Configuration générale vSphere

Fournissez des informations pour permettre à Tanzu Kubernetes Grid de se connecter à vSphere et pour désigner les ressources que Tanzu Kubernetes Grid peut utiliser.

Mettez à jour les paramètres VSPHERE_SERVER, VSPHERE_USERNAME et VSPHERE_PASSWORD avec l'adresse IP ou le nom de domaine complet de l'instance de vCenter Server et les informations d'identification à utiliser pour se connecter.
Fournissez les chemins d'accès complets au centre de données vSphere, au pool de ressources, aux banques de données et au dossier dans lequel déployer le cluster de gestion :
- VSPHERE_DATACENTER: /<MY-DATACENTER>
- VSPHERE_RESOURCE_POOL: /<MY-DATACENTER>/host/<CLUSTER>/Resources
- VSPHERE_DATASTORE: /<MY-DATACENTER>/datastore/<MY-DATASTORE>
- VSPHERE_FOLDER: /<MY-DATACENTER>/vm/<FOLDER>.
Selon le fournisseur HA pour l'API du plan de contrôle du cluster, définissez la variable VSPHERE_CONTROL_PLANE_ENDPOINT ou laissez ce champ vide :
- Kube-VIP : Définissez cette variable sur une adresse IP virtuelle statique ou sur un nom de domaine complet (FQDN) mappé à l'adresse VIP.
- NSX Advanced Load Balancer : Laissez ce champ vide, sauf si vous devez spécifier un point de terminaison. Si c'est le cas, utilisez une adresse statique dans la plage réseau VIP du profil IPAM que vous avez ajoutée manuellement au pool d'adresses IP statiques ou un nom de domaine complet mappé à l'adresse statique.
Spécifiez un réseau et une interface réseau dans VSPHERE_NETWORK et VIP_NETWORK_INTERFACE.
Vous pouvez éventuellement supprimer les marques de commentaire et mettre à jour VSPHERE_TEMPLATE pour spécifier le chemin d'accès à un fichier OVA si vous utilisez plusieurs images OVA personnalisées pour la même version de Kubernetes. Utilisez le format /MY-DC/vm/MY-FOLDER-PATH/MY-IMAGE. Pour plus d'informations, reportez-vous à la section Déployer un cluster avec une image OVA personnalisée du document Création et gestion des clusters de charge de travail TKG 2.3 avec la CLI Tanzu.
Fournissez votre clé SSH dans l'option VSPHERE_SSH_AUTHORIZED_KEY. Pour plus d'informations sur l'obtention d'une clé SSH, reportez-vous à la section Préparer le déploiement des clusters de gestion pour vSphere.
Fournissez l'empreinte numérique TLS dans la variable VSPHERE_TLS_THUMBPRINT ou définissez la variable VSPHERE_INSECURE: true pour ignorer la vérification de l'empreinte numérique.
Vous pouvez éventuellement supprimer les marques de commentaire pour VSPHERE_STORAGE_POLICY_ID et spécifier le nom d'une stratégie de stockage pour les machines virtuelles que vous avez configurées sur vCenter Server à utiliser par le cluster de gestion.

Par exemple :

#! ---------------------------------------------------------------------
#! vSphere configuration
#! ---------------------------------------------------------------------

VSPHERE_SERVER: 10.185.12.154
VSPHERE_USERNAME: [email protected]
VSPHERE_PASSWORD: <encoded:QWRtaW4hMjM=>
VSPHERE_DATACENTER: /dc0
VSPHERE_RESOURCE_POOL: /dc0/host/cluster0/Resources/tanzu
VSPHERE_DATASTORE: /dc0/datastore/sharedVmfs-1
VSPHERE_FOLDER: /dc0/vm/tanzu
VSPHERE_NETWORK: "VM Network"
VSPHERE_CONTROL_PLANE_ENDPOINT: 10.185.11.134
VIP_NETWORK_INTERFACE: "eth0"
VSPHERE_TEMPLATE: /dc0/vm/tanzu/my-image.ova
VSPHERE_SSH_AUTHORIZED_KEY: ssh-rsa AAAAB3[...]tyaw== [email protected]
VSPHERE_TLS_THUMBPRINT: 47:F5:83:8E:5D:36:[...]:72:5A:89:7D:29:E5:DA
VSPHERE_INSECURE: false
VSPHERE_STORAGE_POLICY_ID: "My storage policy"

Configurer les tailles de nœud

La CLI Tanzu crée les nœuds individuels des clusters de gestion et des clusters de charge de travail en fonction des paramètres que vous fournissez dans le fichier de configuration. Sur vSphere, vous pouvez configurer toutes les machines virtuelles de nœud pour avoir les mêmes configurations prédéfinies, définir différentes configurations prédéfinies pour les nœuds de plan de contrôle et worker, ou personnaliser les configurations des nœuds. À l'aide de ces paramètres, vous pouvez créer des clusters qui ont des nœuds avec des configurations différentes des nœuds de cluster de gestion. Vous pouvez également créer des clusters dans lesquels les nœuds du plan de contrôle et les nœuds worker ont des configurations différentes.

Tailles de nœud prédéfinies

La CLI Tanzu fournit les configurations prédéfinies suivantes pour les nœuds de cluster :

small : 2 CPU, 4 Go de mémoire, disque de 20 Go
medium : 2 CPU, 8 Go de mémoire, disque de 40 Go
large : 4 CPU, 16 Go de mémoire, disque de 40 Go
extra-large : 8 CPU, 32 Go de mémoire, disque de 80 Go

Pour créer un cluster dans lequel toutes les machines virtuelles du plan de contrôle et du nœud worker ont la même taille, spécifiez la variable SIZE. Si vous définissez la variable SIZE, tous les nœuds seront créés avec la configuration que vous avez définie.

SIZE: "large"

Pour créer un cluster dans lequel les machines virtuelles du plan de contrôle et du nœud worker sont différentes, spécifiez les options CONTROLPLANE_SIZE et WORKER_SIZE.

CONTROLPLANE_SIZE: "medium"
WORKER_SIZE: "extra-large"

Vous pouvez combiner les options CONTROLPLANE_SIZE et WORKER_SIZE avec l'option SIZE. Par exemple, si vous spécifiez SIZE: "large" avec WORKER_SIZE: "extra-large", les nœuds du plan de contrôle seront définis sur large et les nœuds worker seront définis sur extra-large.

SIZE: "large"
WORKER_SIZE: "extra-large"

Tailles de nœud personnalisées

Vous pouvez personnaliser la configuration des nœuds plutôt que d'utiliser les configurations prédéfinies.

Pour utiliser la même configuration personnalisée pour tous les nœuds, spécifiez les options VSPHERE_NUM_CPUS, VSPHERE_DISK_GIB et VSPHERE_MEM_MIB.

VSPHERE_NUM_CPUS: 2
VSPHERE_DISK_GIB: 40
VSPHERE_MEM_MIB: 4096

Pour définir différentes configurations personnalisées pour les nœuds de plan de contrôle et les nœuds worker, spécifiez les options VSPHERE_CONTROL_PLANE_* et VSPHERE_WORKER_*.

VSPHERE_CONTROL_PLANE_NUM_CPUS: 2
VSPHERE_CONTROL_PLANE_DISK_GIB: 20
VSPHERE_CONTROL_PLANE_MEM_MIB: 8192
VSPHERE_WORKER_NUM_CPUS: 4
VSPHERE_WORKER_DISK_GIB: 40
VSPHERE_WORKER_MEM_MIB: 4096

Vous pouvez remplacer ces paramètres à l'aide des options SIZE, CONTROLPLANE_SIZE et WORKER_SIZE.

Configurer NSX Advanced Load Balancer

Important
Les variables de configuration AVI_DISABLE_INGRESS_CLASS, AVI_DISABLE_STATIC_ROUTE_SYNC et AVI_INGRESS_DEFAULT_INGRESS_CONTROLLER ne fonctionnent pas dans TKG v2.3. Pour définir l'un de ces éléments sur true, sa valeur non définie par défaut, reportez-vous à la solution décrite dans la section Problème connu Certaines variables de configuration ALB NSX ne fonctionnent pas dans les notes de mise à jour.

Pour utiliser NSX Advanced Load Balancer, vous devez d'abord le déployer dans votre environnement vSphere. Reportez-vous à la section Installer NSX Advanced Load Balancer. Après avoir déployé NSX Advanced Load Balancer, configurez un cluster de gestion vSphere pour utiliser l'équilibrage de charge.

Par exemple :

AVI_ENABLE: true
AVI_CONTROL_PLANE_HA_PROVIDER: true
AVI_NAMESPACE: "tkg-system-networking"
AVI_DISABLE_INGRESS_CLASS: true
AVI_AKO_IMAGE_PULL_POLICY: IfNotPresent
AVI_ADMIN_CREDENTIAL_NAME: avi-controller-credentials
AVI_CA_NAME: avi-controller-ca
AVI_CONTROLLER: 10.185.10.217
AVI_USERNAME: "admin"
AVI_PASSWORD: "<password>"
AVI_CLOUD_NAME: "Default-Cloud"
AVI_SERVICE_ENGINE_GROUP: "Default-Group"
AVI_NSXT_T1LR:""
AVI_DATA_NETWORK: nsx-alb-dvswitch
AVI_DATA_NETWORK_CIDR: 10.185.0.0/20
AVI_MANAGEMENT_CLUSTER_VIP_NETWORK_NAME: ""
AVI_MANAGEMENT_CLUSTER_VIP_NETWORK_CIDR: ""
AVI_CA_DATA_B64: LS0tLS1CRU[...]UtLS0tLQo=
AVI_LABELS: ""
AVI_DISABLE_STATIC_ROUTE_SYNC: true
AVI_INGRESS_DEFAULT_INGRESS_CONTROLLER: false
AVI_INGRESS_SHARD_VS_SIZE: ""
AVI_INGRESS_SERVICE_TYPE: ""
AVI_INGRESS_NODE_NETWORK_LIST: ""

Par défaut, le cluster de gestion et tous les clusters de charge de travail qu'il gère utilisent l'équilibrage de charge. Pour plus d'informations sur la configuration des variables de NSX Advanced Load Balancer, reportez-vous à la section NSX Advanced Load Balancer de la Référence de variable du fichier de configuration.

NSX Advanced Load Balancer en tant que fournisseur de point de terminaison de plan de contrôle

Vous pouvez utiliser NSX ALB en tant que fournisseur de point de terminaison de plan de contrôle dans Tanzu Kubernetes Grid. Le tableau suivant décrit les différences entre NSX ALB et Kube-Vip, qui est le fournisseur de point de terminaison de plan de contrôle par défaut dans Tanzu Kubernetes Grid.

	Kube-Vip	NSX ALB
Envoie le trafic à	Nœud de plan de contrôle unique	Nœuds de plan de contrôle multiples
Nécessite la configuration de l'adresse IP virtuelle du point de terminaison	Oui	Non Attribue une adresse IP virtuelle à partir du pool d'adresses IP statiques NSX ALB

Configurer les espaces routables NSX

Si votre environnement vSphere utilise NSX, vous pouvez le configurer pour mettre en œuvre des espaces routables ou NO_NAT.

Remarque
Les espaces routables NSX sont une fonctionnalité expérimentale dans cette version. Des informations sur l'implémentation d'espaces routables NSX seront bientôt ajoutées à cette documentation.

#! ---------------------------------------------------------------------
#! NSX specific configuration for enabling NSX routable pods
#! ---------------------------------------------------------------------

# NSXT_POD_ROUTING_ENABLED: false
# NSXT_ROUTER_PATH: ""
# NSXT_USERNAME: ""
# NSXT_PASSWORD: ""
# NSXT_MANAGER_HOST: ""
# NSXT_ALLOW_UNVERIFIED_SSL: false
# NSXT_REMOTE_AUTH: false
# NSXT_VMC_ACCESS_TOKEN: ""
# NSXT_VMC_AUTH_HOST: ""
# NSXT_CLIENT_CERT_KEY_DATA: ""
# NSXT_CLIENT_CERT_DATA: ""
# NSXT_ROOT_CA_DATA: ""
# NSXT_SECRET_NAME: "cloud-provider-vsphere-nsxt-credentials"
# NSXT_SECRET_NAMESPACE: "kube-system"

Configurer pour IPv6

Pour configurer un cluster de gestion qui prend en charge IPv6 dans un environnement de mise en réseau IPv6 :

Préparez l'environnement comme décrit dans la section (Facultatif) Définir des variables et des règles pour IPv6.
Définissez les variables suivantes dans le fichier de configuration pour le cluster de gestion.
- Définissez TKG_IP_FAMILY sur ipv6.
- Définissez VSPHERE_CONTROL_PLANE_ENDPOINT sur une adresse IPv6 statique.
- (Facultatif) Définissez CLUSTER_CIDR and SERVICE_CIDR. Les valeurs par défaut sont fd00:100:64::/48 et fd00:100:96::/108 respectivement.

Configurer plusieurs zones de disponibilité

Vous pouvez configurer un cluster de gestion ou de charge de travail qui exécute des nœuds dans plusieurs zones de disponibilité, comme décrit dans la section Exécution de clusters sur plusieurs zones de disponibilité

Conditions requises

Objets vSphere pour les zones de disponibilité, créés et balisés comme décrit dans la section Préparer des régions et des zones de disponibilité dans vSphere.
Un fichier vsphere-zones.yaml contenant les définitions d'objets Domaine de pannes et Zone de déploiement pour les zones de disponibilité, créé comme décrit dans la section Créer des objets FailureDomain et DeploymentZone dans Kubernetes. Vous transmettez ce fichier à l'option --az-file lorsque vous créez le cluster de gestion.

Pour configurer un cluster avec des nœuds déployés sur plusieurs zones de disponibilité :

Définissez VSPHERE_REGION et VSPHERE_ZONE sur la région et les catégories de balises de région, k8s-region et k8s-zone.
- Ces variables configurent également la topologie CSI ; reportez-vous à la section Déployer un cluster avec des balises de région et de zone pour CSI.
Définissez VSPHERE_AZ_0, VSPHERE_AZ_1 et VSPHERE_AZ_2 avec les noms des objets VsphereDeploymentZone sur lesquels les machines doivent être déployées.
- L'objet VsphereDeploymentZone associé à VSPHERE_AZ_0 est le VSphereFailureDomain dans lequel le déploiement de machine se terminant par md-0 est déployé. De la même manière, VSPHERE_AZ_1 est le VSphereFailureDomain dans lequel le déploiement de machine se terminant par md-1 est déployé et VSPHERE_AZ_2 est le VSphereFailureDomain dans lequel le déploiement de la machine se terminant par md-2 est déployé
- Si l'une des configurations de zone de disponibilité n'est pas définie, ce déploiement de machine est déployé sans VSphereFailureDomain
WORKER_MACHINE_COUNT définit le nombre total de nœuds worker pour le cluster. Le nombre total de nœuds worker est distribué par permutation circulaire selon le nombre de zones de disponibilité spécifiées.
VSPHERE_AZ_CONTROL_PLANE_MATCHING_LABELS définit des étiquettes de sélecteur clé/valeur pour les zones de disponibilité dans lesquelles les nœuds de plan de contrôle de cluster peuvent se déployer.
- Définissez cette variable si VSPHERE_REGION et VSPHERE_ZONE sont définis.
- Les étiquettes doivent exister dans les ressources VSphereDeploymentZone que vous créez.
- Ces étiquettes vous permettent de spécifier toutes les zones de disponibilité dans une région et un environnement sans avoir à les répertorier individuellement, par exemple : "region=us-west-1,environment=staging".

Pour obtenir la liste complète des options que vous devez spécifier lors du déploiement de clusters sur vSphere, reportez-vous à la section Référence de variable de fichier de configuration.

Configurer l'IPAM de nœud

TKG prend en charge l'IPAM de nœud dans le cluster pour les clusters de gestion autonomes sur vSphere et les clusters de charge de travail basés sur une classe qu'ils gèrent. Pour obtenir plus d'informations et les limitations actuelles, reportez-vous à la section IPAM de nœud du document Création et gestion de clusters de charge de travail TKG 2.3 avec la CLI Tanzu.

Vous ne pouvez pas déployer un cluster de gestion avec l'IPAM de nœud directement à partir de l'interface du programme d'installation. Vous devez le déployer à partir d'un fichier de configuration. Toutefois, vous pouvez créer le fichier de configuration en exécutant l'interface du programme d'installation, en cliquant sur Vérifier la configuration (Review Configuration) > Exporter la configuration (Export Configuration), puis en modifiant le fichier de configuration, généré comme décrit ci-dessous.

Pour déployer un cluster de gestion qui utilise l'IPAM dans le cluster pour ses nœuds :

Comme condition préalable, collectez les adresses IP des serveurs de noms à utiliser pour les nœuds worker et de plan de contrôle du cluster. Cela est nécessaire, car les nœuds de cluster ne recevront plus de serveurs de noms via DHCP pour résoudre les noms dans vCenter.
Modifiez le fichier de configuration du cluster de gestion pour inclure des paramètres semblables aux suivants, comme décrit dans le tableau IPAM de nœud de la Référence de variable de fichier de configuration :
```
MANAGEMENT_NODE_IPAM_IP_POOL_GATEWAY: "10.10.10.1"
MANAGEMENT_NODE_IPAM_IP_POOL_ADDRESSES: "10.10.10.2-10.10.10.100,10.10.10.105"
MANAGEMENT_NODE_IPAM_IP_POOL_SUBNET_PREFIX: "24"
CONTROL_PLANE_NODE_NAMESERVERS: "10.10.10.10,10.10.10.11"
WORKER_NODE_NAMESERVERS: "10.10.10.10,10.10.10.11"
```
CONTROL_PLANE_NODE_NAMESERVERS et WORKER_NODE_NAMESERVERS correspondent aux adresses des serveurs de noms à utiliser. Vous pouvez spécifier un serveur de noms unique ou deux serveurs de noms séparés par des virgules. Vous pouvez avoir besoin de plusieurs serveurs de noms dans les environnements qui nécessitent une redondance. Dans ce cas, une VM de nœud n'utilisera qu'un seul serveur de noms à la fois et les serveurs de noms secondaires sont utilisés si la résolution du premier serveur de noms échoue. Vous pouvez également spécifier plusieurs serveurs de noms pour modifier indépendamment les serveurs de noms pour les nœuds worker et de plan de contrôle respectivement, afin de contrôler la résolution des services sur les différents types de nœuds.

Configurer la MTU de nœud de cluster

Pour configurer l'unité de transmission maximale (MTU) pour les nœuds de clusters de gestion et de charge de travail nœud, définissez la variable VSPHERE_MTU. La définition de VSPHERE_MTU s'applique aux clusters de gestion et aux clusters de charge de travail.

Si elle n'est pas spécifiée, la MTU du nœud vSphere par défaut est de 1 500. La valeur maximale est de 9 000. Pour plus d'informations sur les MTU, reportez-vous à la section À propos de la mise en réseau vSphere de la documentation de vSphere 8.

Clusters de gestion sur vSphere with Tanzu

Sur vSphere 7 et vSphere 8, vSphere with Tanzu inclut un superviseur intégré qui fonctionne comme cluster de gestion et fournit une meilleure expérience qu'un cluster de gestion autonome. Le déploiement d'un cluster de gestion Tanzu Kubernetes Grid vers vSphere 7 ou vSphere 8 lorsque le superviseur n'est pas présent est pris en charge, mais l'option préférée consiste, si possible, à activer vSphere with Tanzu et à utiliser le superviseur. Azure VMware Solution ne prend pas en charge le cluster superviseur, vous devez donc déployer un cluster de gestion. Pour plus d'informations, reportez-vous à la section Superviseur vSphere with Tanzu en tant que cluster de gestion.

Si vSphere with Tanzu est activé, l'interface du programme d'installation indique que vous pouvez utiliser le service TKG comme moyen préféré pour exécuter des charges de travail Kubernetes, auquel cas vous n'avez pas besoin d'un cluster de gestion autonome. Il présente un choix :

Configurer vSphere with Tanzu ouvre vSphere Client de sorte que vous pouvez configurer votre superviseur comme décrit dans la section Configuration et gestion d'un superviseur dans la documentation de vSphere 8.
Déployer le cluster de gestion TKG (Deploy TKG Management Cluster) vous permet de continuer à déployer un cluster de gestion, pour vSphere 7 ou vSphere 8, et comme requis pour Azure VMware Solution.

Tâches suivantes

Une fois que vous avez terminé la mise à jour du fichier de configuration du cluster de gestion, créez le cluster de gestion en suivant les instructions dans la section Déployer des clusters de gestion à partir d'un fichier de configuration.