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.
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.
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: ""
Fournissez des informations pour permettre à Tanzu Kubernetes Grid de se connecter à vSphere et pour désigner les ressources que Tanzu Kubernetes Grid peut utiliser.
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>.
VSPHERE_CONTROL_PLANE_ENDPOINT
ou laissez ce champ vide :
VSPHERE_NETWORK
et VIP_NETWORK_INTERFACE
.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.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.VSPHERE_TLS_THUMBPRINT
ou définissez la variable VSPHERE_INSECURE: true
pour ignorer la vérification de l'empreinte numérique.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"
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.
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 Gomedium
: 2 CPU, 8 Go de mémoire, disque de 40 Golarge
: 4 CPU, 16 Go de mémoire, disque de 40 Goextra-large
: 8 CPU, 32 Go de mémoire, disque de 80 GoPour 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"
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
.
ImportantLes variables de configuration
AVI_DISABLE_INGRESS_CLASS
,AVI_DISABLE_STATIC_ROUTE_SYNC
etAVI_INGRESS_DEFAULT_INGRESS_CONTROLLER
ne fonctionnent pas dans TKG v2.3. Pour définir l'un de ces éléments surtrue
, 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.
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 |
Si votre environnement vSphere utilise NSX, vous pouvez le configurer pour mettre en œuvre des espaces routables ou NO_NAT
.
RemarqueLes 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"
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.
TKG_IP_FAMILY
sur ipv6
.VSPHERE_CONTROL_PLANE_ENDPOINT
sur une adresse IPv6 statique.CLUSTER_CIDR and SERVICE_CIDR
. Les valeurs par défaut sont fd00:100:64::/48
et fd00:100:96::/108
respectivement.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
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é :
VSPHERE_REGION
et VSPHERE_ZONE
sur la région et les catégories de balises de région, k8s-region
et k8s-zone
.
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.
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é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.
VSPHERE_REGION
et VSPHERE_ZONE
sont définis.VSphereDeploymentZone
que vous créez."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.
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.
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.
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.
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.