Référence de variable de fichier de configuration

Cette référence répertorie toutes les variables que vous pouvez spécifier pour fournir des options de configuration du cluster à la CLI Tanzu.

Pour définir ces variables dans un fichier de configuration YAML, laissez un espace entre les deux-points (:) et la valeur de variable. Par exemple :

CLUSTER_NAME: my-cluster

L'ordre des lignes dans le fichier de configuration n'a pas d'importance. Les options sont présentées ici par ordre alphabétique. Reportez-vous également à la section Priorité de la valeur de configuration ci-dessous.

Variables communes pour toutes les plates-formes cibles

Cette section répertorie les variables communes à toutes les plates-formes cibles. Ces variables peuvent s'appliquer aux clusters de gestion, aux clusters de charge de travail ou aux deux. Pour plus d'informations, reportez-vous à la section Configurer les informations de base de la création du cluster de gestion dans Créer un fichier de configuration de cluster de gestion.

Variable	Peut être définie dans…		Description
	YAML du cluster de gestion	YAML du cluster de charge de travail
APISERVER_EVENT_RATE_LIMIT_CONF_BASE64	✔	✔	Clusters basés sur une classe uniquement. Active et configure un contrôleur d'admission EventRateLimit pour modérer le trafic vers le serveur d'API Kubernetes. Définissez cette propriété en créant un fichier de configuration EventRateLimit config.yaml comme décrit dans la documentation de Kubernetes, puis en le convertissant en valeur de chaîne en exécutant base64 -w 0 config.yaml
CAPBK_BOOTSTRAP_TOKEN_TTL	✔	✖	Facultatif ; la valeur par défaut est 15m, 15 minutes. Valeur TTL du jeton de démarrage utilisé par kubeadm lors des opérations d'initialisation du cluster.
CLUSTER_API_SERVER_PORT	✔	✔	Facultatif ; la valeur par défaut est 6443. Cette variable est ignorée si vous activez NSX Advanced Load Balancer (vSphere). Pour remplacer le port du serveur d'API Kubernetes par défaut pour les déploiements avec NSX Advanced Load Balancer, définissez VSPHERE_CONTROL_PLANE_ENDPOINT_PORT.
CLUSTER_CIDR	✔	✔	Facultatif ; la valeur par défaut est 100.96.0.0/11. Plage CIDR à utiliser pour les espaces. Modifiez la valeur par défaut uniquement si la plage recommandée n'est pas disponible.
CLUSTER_NAME	✔	✔	Ce nom doit respecter les conditions requises en matière de nom d'hôte DNS, comme indiqué dans RFC 952 et modifié dans RFC 1123, et doit comporter 42 caractères ou moins. Pour les clusters de charge de travail, ce paramètre est remplacé par l'argument CLUSTER_NAME transmis à la commande tanzu cluster create. Pour les clusters de gestion, si vous ne spécifiez pas CLUSTER_NAME, un nom unique est généré.
CLUSTER_PLAN	✔	✔	Requis. Définissez cette variable sur dev, prod ou un plan personnalisé, comme illustré dans Nouveau plan nginx. Le plan dev déploie un cluster avec un nœud de plan de contrôle unique. Le plan prod déploie un cluster hautement disponible avec trois nœuds de plan de contrôle.
CNI	✖	✔	Facultatif ; la valeur par défaut est antrea. Interface réseau de conteneur. Ne remplacez pas la valeur par défaut pour les clusters de gestion. Pour les clusters de charge de travail, vous pouvez définir la variable CNI sur antrea, calico ou none. L'option calico n'est pas prise en charge sous Windows. Pour plus d'informations, reportez-vous à la section Déployer un cluster avec une CNI non définie par défaut. Pour personnaliser votre configuration Antrea, reportez-vous à la section Configuration de CNI Antrea ci-dessous.
CONTROLPLANE_CERTIFICATE_ROTATION_ENABLED	✔	✔	Facultatif ; la valeur par défaut est false. Définissez cette option sur true si vous souhaitez que les certificats de machine virtuelle du nœud du plan de contrôle soient renouvelés automatiquement avant leur expiration. Pour plus d'informations, reportez-vous à la section Renouvellement automatique du certificat de nœud du plan de contrôle.
CONTROLPLANE_CERTIFICATE_ROTATION_DAYS_BEFORE	✔	✔	Facultatif ; la valeur par défaut est 60. Si CONTROLPLANE_CERTIFICATE_ROTATION_ENABLED est true, définissez le nombre de jours avant la date d'expiration du certificat pour renouveler automatiquement les certificats de nœud de cluster. Pour plus d'informations, reportez-vous à la section Renouvellement automatique du certificat de nœud du plan de contrôle.
ENABLE_AUDIT_LOGGING	✔	✔	Facultatif ; la valeur par défaut est false. Journalisation d'audit pour le serveur d'API Kubernetes. Pour activer la journalisation d'audit, définissez la variable sur true. Tanzu Kubernetes Grid enregistre ces journaux dans /var/log/kubernetes/audit.log. Pour plus d'informations, reportez-vous à la section Journalisation d'audit. L'activation des audits Kubernetes peut entraîner des volumes de journaux très élevés. Pour gérer cette quantité, VMware recommande d'utiliser un redirecteur de journaux, tel que Fluent Bit.
ENABLE_AUTOSCALER	✖	✔	Facultatif ; la valeur par défaut est false. Si cette variable est définie sur true, vous devez définir des variables supplémentaires dans le tableau Mise à l'échelle automatique du cluster ci-dessous.
ENABLE_CEIP_PARTICIPATION	✔	✖	Facultatif ; la valeur par défaut est true. Définissez la variable sur false pour refuser de participer au programme d'amélioration du produit VMware. Vous pouvez également refuser ou accepter de participer au programme après le déploiement du cluster de gestion. Pour plus d'informations, reportez-vous aux sections Refuser ou accepter de participer au programme d'amélioration du produit (CEIP) de VMware dans Gérer la participation au CEIP et Programme d'amélioration du produit (CEIP).
ENABLE_DEFAULT_STORAGE_CLASS	✖	✔	Facultatif ; la valeur par défaut est true. Pour plus d'informations sur les classes de stockage, reportez-vous à la section Stockage dynamique.
ENABLE_MHC, etc.	✔	✔	Facultatif, reportez-vous à la section Contrôles de santé de la machine ci-dessous pour obtenir l'ensemble complet des variables MHC et leur fonctionnement. Pour les clusters de charge de travail créés par vSphere with Tanzu, définissez ENABLE_MHC sur false.
IDENTITY_MANAGEMENT_TYPE	✔	✖	Facultatif ; la valeur par défaut est none. Pour les clusters de gestion : Définissez oidc ou ldap pour activer cette variable, avec des paramètres OIDC ou LDAP supplémentaires requis, comme indiqué dans les tableaux Fournisseurs d'identité - OIDC et LDAP ci-dessous. Omettez cette variable ou définissez-la sur none pour désactiver la gestion des identités. Il est vivement recommandé d'activer la gestion des identités pour les déploiements de production. Remarque Vous n'avez pas besoin de configurer des paramètres OIDC ou LDAP supplémentaires dans le fichier de configuration des clusters de charge de travail.
INFRASTRUCTURE_PROVIDER	✔	✔	Requis. Définissez cette variable sur vsphere, aws, azure ou tkg-service-vsphere.
NAMESPACE	✖	✔	Facultatif ; défini par défaut sur default, pour déployer des clusters de charge de travail sur un espace de noms nommé default.
SERVICE_CIDR	✔	✔	Facultatif ; la valeur par défaut est 100.64.0.0/13. Plage CIDR à utiliser pour les services Kubernetes. Modifiez cette valeur uniquement si la plage recommandée n'est pas disponible.

Fournisseurs d'identité - OIDC

Si vous définissez IDENTITY_MANAGEMENT_TYPE: oidc, définissez les variables suivantes pour configurer un fournisseur d'identité OIDC. Pour plus d'informations, reportez-vous à la section Configurer la gestion des identités dans Créer un fichier de configuration de cluster de gestion.

Tanzu Kubernetes Grid s'intègre à OIDC à l'aide de Pinniped, comme décrit dans À propos de la gestion des identités et des accès.

Variable	Peut être définie dans…		Description
	YAML du cluster de gestion	YAML du cluster de charge de travail
CERT_DURATION	✔	✖	Facultatif ; la valeur par défaut est 2160h. Définissez cette variable si vous configurez Pinniped et Dex pour utiliser des certificats auto-signés gérés par cert-manager.
CERT_RENEW_BEFORE	✔	✖	Facultatif ; la valeur par défaut est 360h. Définissez cette variable si vous configurez Pinniped et Dex pour utiliser des certificats auto-signés gérés par cert-manager.
OIDC_IDENTITY_PROVIDER_CLIENT_ID	✔	✖	Requis. valeur client_id que vous obtenez de votre fournisseur OIDC. Par exemple, si votre fournisseur est Okta, connectez-vous à Okta, créez une application Web et sélectionnez les options d'informations d'identification du client afin d'obtenir un client_id et un secret.
OIDC_IDENTITY_PROVIDER_CLIENT_SECRET	✔	✖	Requis. valeur secret que vous obtenez de votre fournisseur OIDC. Ne codez pas cette valeur en Base64.
OIDC_IDENTITY_PROVIDER_GROUPS_CLAIM	✔	✖	Facultatif. nom de la réclamation de vos groupes. Il permet de définir le groupe d'un utilisateur dans la réclamation JWT (JSON Web Token). La valeur par défaut est groups.
OIDC_IDENTITY_PROVIDER_ISSUER_URL	✔	✖	Requis. Adresse IP ou DNS de votre serveur OIDC.
OIDC_IDENTITY_PROVIDER_SCOPES	✔	✖	Requis. Liste séparée par des virgules de portées supplémentaires à demander dans la réponse du jeton. Par exemple, "email,offline_access".
OIDC_IDENTITY_PROVIDER_USERNAME_CLAIM	✔	✖	Requis. Nom de votre réclamation de nom d'utilisateur. Il permet de définir le nom d'utilisateur d'un utilisateur dans la réclamation JWT. En fonction de votre fournisseur, entrez des réclamations telles que user_name, email ou code.
SUPERVISOR_ISSUER_URL	✔	✖	Ne pas modifier. Cette variable est automatiquement mise à jour dans le fichier de configuration lorsque vous exécutez la commande tanzu cluster create command.
SUPERVISOR_ISSUER_CA_BUNDLE_DATA_B64	✔	✖	Ne pas modifier. Cette variable est automatiquement mise à jour dans le fichier de configuration lorsque vous exécutez la commande tanzu cluster create command.

Fournisseurs d'identité - LDAP

Si vous définissez IDENTITY_MANAGEMENT_TYPE: ldap, définissez les variables suivantes pour configurer un fournisseur d'identité LDAP. Pour plus d'informations, reportez-vous à la section Configurer la gestion des identités dans Créer un fichier de configuration de cluster de gestion.

Tanzu Kubernetes Grid s'intègre à LDAP à l'aide de Pinniped, comme décrit dans À propos de la gestion des identités et des accès.

Variable	Peut être définie dans…		Description
	YAML du cluster de gestion	YAML du cluster de charge de travail
LDAP_BIND_DN	✔	✖	Facultatif. Nom unique d'un compte de service d'application. Le connecteur utilise ces informations d'identification pour rechercher des utilisateurs et des groupes. Non requis si le serveur LDAP fournit un accès pour l'authentification anonyme. Pour des raisons de sécurité, une version future de TKG nécessitera ce paramètre.
LDAP_BIND_PASSWORD	✔	✖	Facultatif. Mot de passe d'un compte de service d'application, si LDAP_BIND_DN est défini. Pour des raisons de sécurité, une version future de TKG nécessitera ce paramètre.
LDAP_GROUP_SEARCH_BASE_DN	✔	✖	Facultatif. Point à partir duquel démarrer la recherche LDAP. Par exemple, OU=Groups,OU=domain,DC=io.
LDAP_GROUP_SEARCH_FILTER	✔	✖	Facultatif. Filtre facultatif à utiliser par la recherche LDAP
LDAP_GROUP_SEARCH_GROUP_ATTRIBUTE	✔	✖	Facultatif. Attribut de l'enregistrement de groupe qui contient les informations sur l'utilisateur/membre. Par exemple, member.
LDAP_GROUP_SEARCH_NAME_ATTRIBUTE	✔	✖	Facultatif. Attribut LDAP qui contient le nom du groupe. Par exemple, cn.
LDAP_GROUP_SEARCH_USER_ATTRIBUTE	✔	✖	Facultatif. Attribut de l'enregistrement d'utilisateur qui est utilisé comme valeur de l'attribut d'appartenance de l'enregistrement de groupe. Par exemple, DNdistinguishedName. Le paramètre DN est sensible à la casse et doit toujours être en majuscules. Reportez-vous à la section Authentification via LDAP (Authentication Through LDAP) > Configuration dans la documentation de Dex.
LDAP_HOST	✔	✖	Requis. adresse IP ou DNS de votre serveur LDAP. Si le serveur LDAP écoute sur le port 636 par défaut, ce qui est la configuration sécurisée, vous n'avez pas besoin de spécifier le port. Si le serveur LDAP écoute sur un port différent, fournissez l'adresse et le port du serveur LDAP, sous la forme “host:port”.
LDAP_ROOT_CA_DATA_B64	✔	✖	Facultatif. Si vous utilisez un point de terminaison LDAPS, collez le contenu codé en base64 du certificat de serveur LDAP.
LDAP_USER_SEARCH_BASE_DN	✔	✖	Facultatif. Point à partir duquel démarrer la recherche LDAP. Par exemple, OU=Users,OU=domain,DC=io.
LDAP_USER_SEARCH_EMAIL_ATTRIBUTE	✔	✖	Facultatif. Attribut LDAP qui contient l’adresse e-mail. Par exemple, emailuserPrincipalName.
LDAP_USER_SEARCH_FILTER	✔	✖	Facultatif. filtre facultatif à utiliser par la recherche LDAP.
LDAP_USER_SEARCH_ID_ATTRIBUTE	✔	✖	Facultatif. Attribut LDAP qui contient l'ID d'utilisateur. Semblable à LDAP_USER_SEARCH_USERNAME.
LDAP_USER_SEARCH_NAME_ATTRIBUTE	✔	✖	Facultatif. Attribut LDAP qui contient le nom donné de l’utilisateur. Par exemple, givenName. Cette variable n’est pas exposée dans l’interface du programme d’installation.
LDAP_USER_SEARCH_USERNAME	✔	✖	Facultatif. Attribut LDAP qui contient l'ID d'utilisateur. Par exemple, uidsAMAccountName.

Configuration de nœuds

Configurez le plan de contrôle et les nœuds worker, ainsi que le système d'exploitation sur lequel les instances de nœud s'exécutent. Pour plus d'informations, reportez-vous à la section Configurer les paramètres de nœud dans Créer un fichier de configuration de cluster de gestion.

Variable	Peut être définie dans…		Description
	YAML du cluster de gestion	YAML du cluster de charge de travail
CONTROL_PLANE_MACHINE_COUNT	✔	✔	Facultatif. Déployez un cluster de charge de travail avec plus de nœuds de plan de contrôle que les plans dev et prod définissent par défaut. Le nombre de nœuds de plan de contrôle que vous spécifiez doit être impair.
CONTROL_PLANE_NODE_LABELS	✔	✔	Clusters basés sur une classe uniquement. Attribuez des étiquettes persistantes personnalisées aux nœuds de plan de contrôle, par exemple CONTROL_PLANE_NODE_LABELS: ‘key1=value1,key2=value2’. Pour configurer cette option dans un cluster hérité basé sur un plan, utilisez une superposition ytt comme décrit dans Étiquettes de nœud personnalisées. Les étiquettes de nœuds worker sont définies dans leur pool de nœuds, comme décrit dans Gérer les pools de nœuds de types de VM différents.
CONTROL_PLANE_NODE_SEARCH_DOMAINS	✔	✔	Clusters basés sur une classe uniquement. Configure les domaines de recherche .local pour les nœuds de cluster, par exemple CONTROL_PLANE_NODE_SEARCH_DOMAINS: corp.local. Pour configurer cela dans un cluster hérité basé sur un plan sur vSphere, utilisez une superposition ytt comme décrit dans Resolve.local Domain.
CONTROLPLANE_SIZE	✔	✔	Facultatif. Taille des machines virtuelles du nœud de plan de contrôle. Remplace les paramètres SIZE et VSPHERE_CONTROL_PLANE_. Reportez-vous à la section SIZE pour connaître les valeurs possibles.
OS_ARCH	✔	✔	Facultatif. Architecture du système d'exploitation de la machine virtuelle de nœud. La valeur par défaut et la seule option actuelle est amd64.
OS_NAME	✔	✔	Facultatif. Système d'exploitation de la machine virtuelle de nœud. La valeur par défaut est ubuntu pour Ubuntu LTS. Elle peut également être photon pour Photon OS sur vSphere ou amazon pour Amazon Linux sur AWS.
OS_VERSION	✔	✔	Facultatif. Version du système d'exploitation OS_NAME, ci-dessus. La valeur par défaut est 20.04 pour Ubuntu. Elle peut être 3 pour Photon sur vSphere et 2 pour Amazon Linux sur AWS.
SIZE	✔	✔	Facultatif. Taille des machines virtuelles des nœuds de plan de contrôle et worker. Remplace les paramètres VSPHERE_CONTROL_PLANE_* et VSPHERE_WORKER_*. Pour vSphere, définissez small, medium, large ou extra-large comme décrit dans la section Tailles de nœud prédéfinies. Pour AWS, définissez un type d'instance (par exemple, t3.small). Pour Azure, définissez un type d'instance (par exemple, Standard_D2s_v3).
WORKER_MACHINE_COUNT	✔	✔	Facultatif. Déployez un cluster de charge de travail avec plus de nœuds worker que les plans dev et prod définissent par défaut.
WORKER_NODE_SEARCH_DOMAINS	✔	✔	Clusters basés sur une classe uniquement. Configure les domaines de recherche .local pour les nœuds de cluster, par exemple CONTROL_PLANE_NODE_SEARCH_DOMAINS: corp.local. Pour configurer cela dans un cluster hérité basé sur un plan sur vSphere, utilisez une superposition ytt comme décrit dans Resolve.local Domain.
WORKER_SIZE	✔	✔	Facultatif. Taille des machines virtuelles du nœud worker. Remplace les paramètres SIZE et. Reportez-vous à la section SIZE pour connaître les valeurs possibles.
CUSTOM_TDNF_REPOSITORY_CERTIFICATE	✔	✔	(Version d'évaluation technique) Facultatif. Définissez si vous utilisez un serveur de référentiel tdnf personnalisé avec un certificat auto-signé, plutôt que le serveur de référentiel tdnf par défaut de Photon. Entrez le contenu du certificat codé en base64 du serveur de référentiel tdnf. La variable supprime tous les référentiels sous /etc/yum.repos.d/ et permet l'approbation du certificat par le nœud TKG.

Réglage de Kubernetes (clusters basés sur une classe uniquement)

Les serveurs d'API Kubernetes, les kubelets et d'autres composants exposent divers indicateurs de configuration pour le réglage, par exemple l'indicateur --tls-cipher-suites pour configurer des suites de chiffrement permettant de renforcer la sécurité, l'indicateur --election-timeout pour augmenter le délai d'expiration etcd dans un cluster volumineux, etc.

Important

Ces variables de configuration Kubernetes sont destinées aux utilisateurs avancés. VMware ne garantit pas la fonctionnalité des clusters configurés avec des combinaisons arbitraires de ces paramètres.

Variable	Peut être définie dans…		Description
	YAML du cluster de gestion	YAML du cluster de charge de travail
APISERVER_EXTRA_ARGS	✔	✔	Clusters basés sur une classe uniquement. Spécifiez les indicateurs kube-apiserver (kube-apiserver flags) au format « clé1=valeur1;clé2=valeur2 ». Par exemple, définissez des suites de chiffrement avec APISERVER_EXTRA_ARGS: “tls-min-version=VersionTLS12;tls-cipher-suites=TLS_RSA_WITH_AES_256_GCM_SHA384”
CONTROLPLANE_KUBELET_EXTRA_ARGS	✔	✔	Clusters basés sur une classe uniquement. Spécifiez les indicateurs kubelet (kubelet flags) du plan de contrôle au format « clé1=valeur1;clé2=valeur2 ». Par exemple, limitez le nombre d'espaces de plan de contrôle avec CONTROLPLANE_KUBELET_EXTRA_ARGS: “max-pods=50”
ETCD_EXTRA_ARGS	✔	✔	Clusters basés sur une classe uniquement. Spécifiez les indicateurs etcd (etcd flags) au format « clé1=valeur1;clé2=valeur2 ». Par exemple, si le cluster comprend plus de 500 nœuds ou si le stockage présente de mauvaises performances, vous pouvez augmenter heartbeat-interval et election-timeout avec ETCD_EXTRA_ARGS: “heartbeat-interval=300;election-timeout=2000”
KUBE_CONTROLLER_MANAGER_EXTRA_ARGS	✔	✔	Clusters basés sur une classe uniquement. Spécifiez les indicateurs kube-controller-manager (kube-controller-manager flags) au format « clé1=valeur1;clé2=valeur2 ». Par exemple, désactivez le profilage de performances avec KUBE_CONTROLLER_MANAGER_EXTRA_ARGS: “profiling=false”
KUBE_SCHEDULER_EXTRA_ARGS	✔	✔	Clusters basés sur une classe uniquement. Spécifiez les indicateurs kube-scheduler (kube-scheduler flags) au format « clé1=valeur1;clé2=valeur2 ». Par exemple, activez le mode d'accès à espace unique avec KUBE_SCHEDULER_EXTRA_ARGS: “feature-gates=ReadWriteOncePod=true”
WORKER_KUBELET_EXTRA_ARGS	✔	✔	Clusters basés sur une classe uniquement. Spécifiez les indicateurs kubelet (kubelet flags) worker au format « clé1=valeur1;clé2=valeur2». Par exemple, limitez le nombre d'espaces worker avec WORKER_KUBELET_EXTRA_ARGS: “max-pods=50”

Mise à l'échelle automatique du cluster

Les variables supplémentaires suivantes peuvent être configurées si ENABLE_AUTOSCALER est défini sur true. Pour plus d'informations sur la mise à l'échelle automatique du cluster, reportez-vous à la section Mettre à l'échelle des clusters de charge de travail.

Variable	Peut être définie dans…		Description
	YAML du cluster de gestion	YAML du cluster de charge de travail
AUTOSCALER_MAX_NODES_TOTAL	✖	✔	Facultatif ; la valeur par défaut est 0. Nombre total maximal de nœuds dans le cluster, à la fois worker et de plan de contrôle. Définit la valeur du paramètre de mise à l'échelle automatique du cluster max-nodes-total. La mise à l'échelle automatique du cluster ne tente pas de mettre à l'échelle votre cluster au-delà de cette limite. Si cette option est définie sur 0, la mise à l'échelle automatique du cluster prend des décisions de mise à l'échelle en fonction des paramètres de SIZE minimal et maximal que vous configurez.
AUTOSCALER_SCALE_DOWN_DELAY_AFTER_ADD	✖	✔	Facultatif ; la valeur par défaut est 10m. Définit la valeur du paramètre de mise à l'échelle automatique du cluster scale-down-delay-after-add. Durée pendant laquelle la mise à l'échelle automatique du cluster attend après une opération de montée en charge, puis reprend les analyses de réduction de charge.
AUTOSCALER_SCALE_DOWN_DELAY_AFTER_DELETE	✖	✔	Facultatif ; la valeur par défaut est 10s. Définit la valeur du paramètre de mise à l'échelle automatique du cluster scale-down-delay-after-delete. Durée pendant laquelle la mise à l'échelle automatique du cluster attend après la suppression d'un nœud, puis reprend les analyses de réduction de charge.
AUTOSCALER_SCALE_DOWN_DELAY_AFTER_FAILURE	✖	✔	Facultatif ; la valeur par défaut est 3m. Définit la valeur du paramètre de mise à l'échelle automatique du cluster scale-down-delay-after-failure. Durée pendant laquelle la mise à l'échelle automatique du cluster attend après l'échec d'une réduction de charge, puis reprend les analyses de réduction de charge.
AUTOSCALER_SCALE_DOWN_UNNEEDED_TIME	✖	✔	Facultatif ; la valeur par défaut est 10m. Définit la valeur du paramètre de mise à l'échelle automatique du cluster scale-down-unneeded-time. Durée pendant laquelle la mise à l'échelle automatique du cluster doit attendre avant de réduire la charge d'un nœud éligible.
AUTOSCALER_MAX_NODE_PROVISION_TIME	✖	✔	Facultatif ; la valeur par défaut est 15m. Définit la valeur du paramètre de mise à l'échelle automatique du cluster max-node-provision-time. Durée maximale pendant laquelle la mise à l'échelle automatique du cluster attend qu'un nœud soit provisionné.
AUTOSCALER_MIN_SIZE_0	✖	✔	Requis, toutes les instances IaaS. Nombre minimal de nœuds worker. La mise à l'échelle automatique du cluster ne tente pas de réduire le nombre de nœuds en dessous de cette limite. Pour les clusters prod sur AWS, AUTOSCALER_MIN_SIZE_0 définit le nombre minimal de nœuds worker dans la première zone de disponibilité. Si cette variable n'est pas définie, la valeur par défaut est WORKER_MACHINE_COUNT pour les clusters avec un seul nœud worker ou WORKER_MACHINE_COUNT_0 pour les clusters comportant plusieurs nœuds worker.
AUTOSCALER_MAX_SIZE_0	✖	✔	Requis, toutes les instances IaaS. Nombre maximal de nœuds worker. La mise à l'échelle automatique du cluster ne tente pas d'augmenter le nombre de nœuds au-delà de cette limite. Pour les clusters prod sur AWS, AUTOSCALER_MAX_SIZE_0 définit le nombre maximal de nœuds worker dans la première zone de disponibilité. Si cette variable n'est pas définie, la valeur par défaut est WORKER_MACHINE_COUNT pour les clusters avec un seul nœud worker ou WORKER_MACHINE_COUNT_0 pour les clusters comportant plusieurs nœuds worker.
AUTOSCALER_MIN_SIZE_1	✖	✔	Requis, utilisez cette variable uniquement pour les clusters prod sur AWS. Nombre minimal de nœuds worker dans la deuxième zone de disponibilité. La mise à l'échelle automatique du cluster ne tente pas de réduire le nombre de nœuds en dessous de cette limite. Si cette variable n'est pas définie, la valeur par défaut est WORKER_MACHINE_COUNT_1.
AUTOSCALER_MAX_SIZE_1	✖	✔	Requis, utilisez cette variable uniquement pour les clusters prod sur AWS. Nombre maximal de nœuds worker dans la deuxième zone de disponibilité. La mise à l'échelle automatique du cluster ne tente pas d'augmenter le nombre de nœuds au-delà de cette limite. Si cette variable n'est pas définie, la valeur par défaut est WORKER_MACHINE_COUNT_1.
AUTOSCALER_MIN_SIZE_2	✖	✔	Requis, utilisez cette variable uniquement pour les clusters prod sur AWS. Nombre minimal de nœuds worker dans la troisième zone de disponibilité. La mise à l'échelle automatique du cluster ne tente pas de réduire le nombre de nœuds en dessous de cette limite. Si cette variable n'est pas définie, la valeur par défaut est WORKER_MACHINE_COUNT_2.
AUTOSCALER_MAX_SIZE_2	✖	✔	Requis, utilisez cette variable uniquement pour les clusters prod sur AWS. Nombre maximal de nœuds worker dans la troisième zone de disponibilité. La mise à l'échelle automatique du cluster ne tente pas d'augmenter le nombre de nœuds au-delà de cette limite. Si cette variable n'est pas définie, la valeur par défaut est WORKER_MACHINE_COUNT_2.

Configuration du proxy

Si votre environnement a un accès restreint à Internet ou inclut des proxys, vous pouvez éventuellement configurer Tanzu Kubernetes Grid pour envoyer le trafic HTTP et HTTPS sortant depuis kubelet, containerd et le plan de contrôle vers vos proxys.

Tanzu Kubernetes Grid vous permet d'activer les proxys de la manière suivante :

• Pour le cluster de gestion et un ou plusieurs clusters de charge de travail
• Pour le cluster de gestion uniquement
• Pour un ou plusieurs clusters de charge de travail

Pour plus d'informations, reportez-vous à Configurer des proxys dans Créer un fichier de configuration de cluster de gestion.

Variable	Peut être définie dans…		Description
	YAML du cluster de gestion	YAML du cluster de charge de travail
TKG_HTTP_PROXY_ENABLED	✔	✔	Facultatif, pour envoyer le trafic HTTP(S) sortant du cluster de gestion vers un proxy, par exemple, dans un environnement à accès restreint à Internet, définissez cette variable sur true.
TKG_HTTP_PROXY	✔	✔	Facultatif, définissez cette variable si vous souhaitez configurer un proxy. Pour désactiver la configuration de votre proxy pour un cluster individuel, définissez cette variable sur "“. Cela s'applique uniquement lorsque TKG_HTTP_PROXY_ENABLED = true. URL de votre proxy HTTP, formatée comme suit : PROTOCOL://USERNAME:PASSWORD@FQDN-OR-IP:PORT, où : Requis. PROTOCOL est http. Facultatif. USERNAME et PASSWORD sont le nom d'utilisateur et le mot de passe de votre proxy HTTP. Incluez ces paramètres si le proxy nécessite une authentification. Requis. FQDN-OR-IP et PORT sont le nom de domaine complet ou l'adresse IP et le numéro de port de votre proxy HTTP. Par exemple, http://user:[email protected]:1234 ou http://myproxy.com:1234. Si vous définissez TKG_HTTP_PROXY, vous devez également définir TKG_HTTPS_PROXY.
TKG_HTTPS_PROXY	✔	✔	Facultatif, définissez cette variable si vous souhaitez configurer un proxy. Cela s'applique uniquement lorsque TKG_HTTP_PROXY_ENABLED = true. URL de votre proxy HTTPS. Vous pouvez définir cette variable sur la même valeur que TKG_HTTP_PROXY ou fournir une valeur différente. L'URL doit commencer par http://. Si vous définissez TKG_HTTPS_PROXY, vous devez également définir TKG_HTTP_PROXY.
TKG_NO_PROXY	✔	✔	Facultatif. Cela s'applique uniquement lorsque TKG_HTTP_PROXY_ENABLED = true. Un ou plusieurs CIDR réseau ou noms d'hôte qui doivent contourner le proxy HTTP(S), séparés par des virgules et répertoriés sans espaces ou caractères génériques (*). Répertoriez les suffixes de nom d'hôte sous la forme .example.com et non *.example.com. Par exemple, .noproxy.example.com,noproxy.example.com,192.168.0.0/24. En interne, Tanzu Kubernetes Grid ajoute localhost, 127.0.0.1, les valeurs de CLUSTER_CIDR et SERVICE_CIDR, .svc et .svc.cluster.local à la valeur que vous avez définie dans TKG_NO_PROXY. Il ajoute également votre CIDR azure VNET, 169.254.0.0/16 et 168.63.129.16 pour les déploiements dans Azure. Pour vSphere, vous devez ajouter manuellement le CIDR de VSPHERE_NETWORK, ce qui inclut l'adresse IP de votre point de terminaison de plan de contrôle, à TKG_NO_PROXY. Si vous définissez VSPHERE_CONTROL_PLANE_ENDPOINT sur un nom de domaine complet, ajoutez le nom de domaine complet et VSPHERE_NETWORK à TKG_NO_PROXY. Important : dans les environnements où Tanzu Kubernetes Grid s'exécute derrière un proxy, TKG_NO_PROXY permet aux machines virtuelles de cluster de communiquer directement avec l'infrastructure qui exécute le même réseau, derrière le même proxy. Cela peut inclure, sans s'y limiter, votre infrastructure, votre serveur OIDC ou LDAP, Harbor, VMware NSX et NSX Advanced Load Balancer (vSphere). Définissez TKG_NO_PROXY pour inclure tous les points de terminaison auxquels les clusters doivent accéder, mais qui ne sont pas accessibles par vos proxys.
TKG_PROXY_CA_CERT	✔	✔	Facultatif. Définissez cette variable si votre serveur proxy utilise un certificat auto-signé. Fournissez le certificat d'autorité de certification au format codé en base64 (par exemple, …TKG_PROXY_CA_CERT: “LS0t[]tLS0tLQ==””).
TKG_NODE_SYSTEM_WIDE_PROXY	✔	✔	(Version d'évaluation technique) Facultatif. Place les paramètres suivants dans /etc/environment et /etc/profile : export HTTP_PROXY=$TKG_HTTP_PROXY export HTTPS_PROXY=$TKG_HTTPS_PROXY export NO_PROXY=$TKG_NO_PROXY Lorsque les utilisateurs se connectent au nœud TKG via le protocole SSH et exécutent des commandes, celles-ci utilisent par défaut les variables définies. Les processus systemd ne sont pas affectés.

Configuration de CNI Antrea

Variables facultatives supplémentaires à définir si la variable CNI est définie sur antrea. Pour plus d'informations, reportez-vous à la section Configurer la CNI Antrea dans Créer un fichier de configuration de cluster de gestion.

Variable	Peut être définie dans…		Description
	YAML du cluster de gestion	YAML du cluster de charge de travail
ANTREA_DISABLE_UDP_TUNNEL_OFFLOAD	✔	✔	Facultatif ; la valeur par défaut est false. Définissez cette variable sur true pour désactiver le déchargement de la somme de contrôle UDP d'Antrea. La définition de cette variable sur true évite les problèmes connus avec les pilotes réseau de sous-couche et de carte réseau physique.
ANTREA_EGRESS	✔	✔	Facultatif ; la valeur par défaut est true. Activez cette variable pour définir l'adresse IP SNAT utilisée pour le trafic d'espace sortant du cluster. Pour plus d'informations, reportez-vous à la section Sortie dans la documentation Antrea.
ANTREA_EGRESS_EXCEPT_CIDRS	✔	✔	Facultatif. Les plages CIDR sortantes ne seront pas SNAT pour le trafic d'espace sortant. Incluez des guillemets (““). Par exemple, “10.0.0.0/6”.
ANTREA_ENABLE_USAGE_REPORTING	✔	✔	Facultatif ; la valeur par défaut est false. Active ou désactive les rapports d'utilisation (télémétrie).
ANTREA_FLOWEXPORTER	✔	✔	Facultatif ; la valeur par défaut est false. Définissez cette variable sur true pour la visibilité du flux réseau. L'exportateur de flux interroge périodiquement les flux conntrack et les exporte sous forme d'enregistrements de flux IPFIX. Pour plus d'informations, reportez-vous à la section Visibilité du flux réseau dans Antrea dans la documentation Antrea.
ANTREA_FLOWEXPORTER_ACTIVE_TIMEOUT	✔	✔	Facultatif ; la valeur par défaut est “60s”. Cette variable fournit le délai d'expiration de l'exportation du flux actif, qui est le délai d'expiration après lequel un enregistrement de flux est envoyé au collecteur pour les flux actifs. Incluez des guillemets (””). Remarque : les unités de temps valides sont ns, us (ou s), ms, s, m et h.
ANTREA_FLOWEXPORTER_COLLECTOR_ADDRESS	✔	✔	Facultatif. Cette variable fournit l'adresse du collecteur IPFIX. Incluez des guillemets (““). La valeur par défaut est “flow-aggregator.flow-aggregator.svc:4739:tls”. Pour plus d'informations, reportez-vous à la section Visibilité du flux réseau dans Antrea dans la documentation Antrea.
ANTREA_FLOWEXPORTER_IDLE_TIMEOUT	✔	✔	Facultatif ; la valeur par défaut est “15s”. Cette variable fournit le délai d'expiration de l'exportation du flux inactif, qui est le délai d'expiration après lequel un enregistrement de flux est envoyé au collecteur pour les flux inactifs. Incluez des guillemets (””). Remarque : les unités de temps valides sont ns, us (ou s), ms, s, m et h.
ANTREA_FLOWEXPORTER_POLL_INTERVAL	✔	✔	Facultatif ; la valeur par défaut est “5s”. Cette variable détermine la fréquence des connexions vidées du module conntrack par l'exportateur de flux. Incluez des guillemets (““). Remarque : les unités de temps valides sont ns, us (ou s), ms, s, m et h.
ANTREA_IPAM	✔	✔	Facultatif ; la valeur par défaut est false. Définissez cette variable sur true pour allouer des adresses IP à partir de pools d'adresses IP. L'ensemble souhaité de plages d'adresses IP, éventuellement avec des VLAN, est défini avec la CRD IPPool. Pour plus d'informations, reportez-vous à la section Capacités IPAM Antrea dans la documentation Antrea.
ANTREA_KUBE_APISERVER_OVERRIDE	✔	✔	Facultatif. Spécifiez l'adresse du serveur d'API Kubernetes. Pour plus d'informations, reportez-vous à la section Suppression de kube-proxy dans la documentation Antrea.
ANTREA_MULTICAST	✔	✔	Facultatif ; la valeur par défaut est false. Définissez cette variable sur true pour activer le trafic multidiffusion dans le réseau du cluster (entre les espaces) et entre le réseau externe et le réseau du cluster.
ANTREA_MULTICAST_INTERFACES	✔	✔	Facultatif. Noms de l'interface sur les nœuds utilisés pour transférer le trafic multidiffusion. Incluez des guillemets (””). Par exemple, “eth0”.
ANTREA_NETWORKPOLICY_STATS	✔	✔	Facultatif ; la valeur par défaut est true. Activez cette variable pour collecter des statistiques NetworkPolicy. Les données statistiques incluent le nombre total de sessions, de paquets et d'octets autorisés ou refusés par une NetworkPolicy.
ANTREA_NO_SNAT	✔	✔	Facultatif ; la valeur par défaut est false. Définissez cette variable sur true pour désactiver SNAT (Source Network Address Translation).
ANTREA_NODEPORTLOCAL	✔	✔	Facultatif ; la valeur par défaut est true. Définissez cette variable sur false pour désactiver le mode NodePortLocal. Pour plus d'informations, reportez-vous à la section NodePortLocal (NPL) dans la documentation Antrea.
ANTREA_NODEPORTLOCAL_ENABLED	✔	✔	Facultatif. Définissez cette variable sur true pour activer le mode NodePortLocal, comme décrit dans NodePortLocal (NPL) dans la documentation Antrea.
ANTREA_NODEPORTLOCAL_PORTRANGE	✔	✔	Facultatif ; la valeur par défaut est 61000-62000. Pour plus d'informations, reportez-vous à la section NodePortLocal (NPL) dans la documentation Antrea.
ANTREA_POLICY	✔	✔	Facultatif ; la valeur par défaut est true. Active ou désactive l'API de stratégie native Antrea, qui sont des CRD de stratégie spécifiques à Antrea. En outre, la mise en œuvre des stratégies réseau Kubernetes reste active lorsque cette variable est activée. Pour plus d'informations sur l'utilisation des stratégies réseau, reportez-vous à la section CRD de stratégie réseau Antrea dans la documentation Antrea.
ANTREA_PROXY	✔	✔	Facultatif ; la valeur par défaut est false. Active ou désactive AntreaProxy, afin de remplacer kube-proxy pour le trafic du service entre espace et ClusterIP, pour de meilleures performances et une latence inférieure. Notez que kube-proxy est toujours utilisé pour d'autres types de trafic de service. Pour plus d'informations sur l'utilisation des proxys, reportez-vous à la section AntreaProxy dans la documentation Antrea.
ANTREA_PROXY_ALL	✔	✔	Facultatif ; la valeur par défaut est false. Active ou désactive AntreaProxy afin de gérer tout le trafic de service, y compris le trafic NodePort, LoadBalancer et ClusterIP. Pour remplacer kube-proxy par AntreaProxy, ANTREA_PROXY_ALL doit être activé. Pour plus d'informations sur l'utilisation des proxys, reportez-vous à la section AntreaProxy dans la documentation Antrea.
ANTREA_PROXY_LOAD_BALANCER_IPS	✔	✔	Facultatif ; la valeur par défaut est true. Définissez cette variable sur false pour diriger le trafic d'équilibrage de charge vers l'équilibrage de charge externe.
ANTREA_PROXY_NODEPORT_ADDRS	✔	✔	Facultatif. Adresse IPv4 ou IPv6 pour NodePort. Incluez des guillemets (““).
ANTREA_PROXY_SKIP_SERVICES	✔	✔	Facultatif. Tableau de valeurs de chaîne qui peut être utilisé pour indiquer une liste de services qu'AntreaProxy doit ignorer. Le trafic vers ces services ne fera pas l'objet d'un équilibrage de charge. Incluez des guillemets (””). Par exemple, un ClusterIP valide (tel que 10.11.1.2) ou un nom de service avec un espace de noms (tel que kube-system/kube-dns) sont des valeurs valides. Pour plus d'informations, reportez-vous à la section Cas d'utilisation spécifiques dans la documentation Antrea.
ANTREA_SERVICE_EXTERNALIP	✔	✔	Facultatif ; la valeur par défaut est false. Définissez cette variable sur true pour permettre à un contrôleur d'allouer des adresses IP externes à partir d'une ressource ExternalIPPool pour les services de type LoadBalancer. Pour plus d'informations sur la mise en œuvre des services de type LoadBalancer, reportez-vous à la section Service de type LoadBalancer dans la documentation d'Antrea.
ANTREA_TRACEFLOW	✔	✔	Facultatif ; la valeur par défaut est true. Pour plus d'informations sur l'utilisation de Traceflow, reportez-vous au Guide de l'utilisateur de Traceflow dans la documentation Antrea.
ANTREA_TRAFFIC_ENCAP_MODE	✔	✔	Facultatif ; la valeur par défaut est “encap”. Définissez cette variable sur noEncap, hybrid ou NetworkPolicyOnly. Pour plus d'informations sur l'utilisation des modes de trafic NoEncap ou hybride, reportez-vous à la section Modes de trafic NoEncap et hybride d'Antrea dans la documentation Antrea. Remarque : les modes noEncap et hybrid nécessitent une configuration spécifique du réseau de nœud pour les empêcher de désactiver la communication entre les espaces entre les nœuds. Le mode noEncap n'est pris en charge que sur vSphere et peut désactiver la communication des espaces entre les nœuds. Ne définissez pas ANTREA_TRAFFIC_ENCAP_MODE sur noEncap dans les clusters pour lesquels les espaces doivent communiquer entre les nœuds.
ANTREA_TRANSPORT_INTERFACE	✔	✔	Facultatif. Nom de l'interface sur le nœud utilisé pour le tunneling ou le routage du trafic. Incluez des guillemets (““). Par exemple, “eth0”.
ANTREA_TRANSPORT_INTERFACE_CIDRS	✔	✔	Facultatif. CIDR réseau de l'interface sur le nœud qui est utilisé pour le tunneling ou le routage du trafic. Incluez des guillemets (””). Par exemple, “10.0.0.2/24”.

Contrôles de santé de la machine

Définissez les variables suivantes si vous souhaitez configurer les contrôles de santé de la machine pour les clusters de gestion et de charge de travail. Pour plus d'informations, reportez-vous à la section Configurer les contrôles de santé de la machine dans Créer un fichier de configuration de cluster de gestion. Pour plus d'informations sur l'exécution d'opérations de contrôle de santé de la machine après le déploiement du cluster, reportez-vous à la section Configurer les contrôles de santé de la machine pour les clusters de charge de travail.

Variable	Peut être définie dans…		Description
	YAML du cluster de gestion	YAML du cluster de charge de travail
ENABLE_MHC	✔	basé sur une classe : ✖ basé sur un plan : ✔	Facultatif, définissez cette variable sur true ou false pour activer ou désactiver le contrôleur MachineHealthCheck sur les nœuds de plan de contrôle et worker du cluster de gestion ou de charge de travail cible. Vous pouvez également laisser ce champ vide et définir ENABLE_MHC_CONTROL_PLANE et ENABLE_MHC_WORKER_NODE séparément pour les nœuds de plan de contrôle et worker. La valeur par défaut est vide. Le contrôleur assure la surveillance de la santé de la machine et la réparation automatique. Pour les clusters de charge de travail créés par vSphere with Tanzu, définissez la variable sur false.
ENABLE_MHC_CONTROL_PLANE	✔		Facultatif ; la valeur par défaut est true. Pour plus d'informations, reportez-vous au tableau ci-dessous.
ENABLE_MHC_WORKER_NODE	✔		Facultatif ; la valeur par défaut est true. Pour plus d'informations, reportez-vous au tableau ci-dessous.
MHC_MAX_UNHEALTHY_CONTROL_PLANE	✔	✖	Facultatif ; clusters basés sur une classe uniquement. Défini sur 100% par défaut. Si le nombre de machines défectueuses dépasse la valeur que vous avez définie, le contrôleur MachineHealthCheck n'effectue pas de correction.
MHC_MAX_UNHEALTHY_WORKER_NODE	✔	✖	Facultatif ; clusters basés sur une classe uniquement. Défini sur 100% par défaut. Si le nombre de machines défectueuses dépasse la valeur que vous avez définie, le contrôleur MachineHealthCheck n'effectue pas de correction.
MHC_FALSE_STATUS_TIMEOUT	✔	basé sur une classe : ✖ basé sur un plan : ✔	Facultatif ; la valeur par défaut est 12m. Durée pendant laquelle le contrôleur MachineHealthCheck autorise la condition Ready d'un nœud à rester False avant de considérer la machine comme défectueuse et de la recréer.
MHC_UNKNOWN_STATUS_TIMEOUT	✔		Facultatif ; la valeur par défaut est 5m. Durée pendant laquelle le contrôleur MachineHealthCheck autorise la condition Ready d'un nœud à rester Unknown avant de considérer la machine comme défectueuse et de la recréer.
NODE_STARTUP_TIMEOUT	✔		Facultatif ; la valeur par défaut est 20m. Durée pendant laquelle le contrôleur MachineHealthCheck attend qu'un nœud rejoigne un cluster avant de considérer la machine comme défectueuse et de la recréer.

Utilisez le tableau ci-dessous pour déterminer comment configurer les variables ENABLE_MHC, ENABLE_MHC_CONTROL_PLANE et ENABLE_MHC_WORKER_NODE.

Valeur de ENABLE_MHC	Valeur de ENABLE_MHC_CONTROL_PLANE	Valeur de ENABLE_MHC_WORKER_NODE	Correction du plan de contrôle activée ?	Correction du nœud worker activée ?
true / Vide	true/false/vide	true/false/vide	Oui	Oui
false	true/vide	true/vide	Oui	Oui
false	true/vide	false	Oui	Non
false	false	true/vide	Non	Oui

Configuration du registre d'images privé

Si vous déployez des clusters de gestion Tanzu Kubernetes Grid et des clusters Kubernetes dans des environnements qui ne sont pas connectés à Internet, vous devez configurer un référentiel d'images privé dans votre pare-feu et le remplir avec les images Tanzu Kubernetes Grid. Pour plus d'informations sur la configuration d'un référentiel d'images privé, reportez-vous à la section Préparer un environnement à accès restreint à Internet.

Variable	Peut être définie dans…		Description
	YAML du cluster de gestion	YAML du cluster de charge de travail
ADDITIONAL_IMAGE_REGISTRY_1, ADDITIONAL_IMAGE_REGISTRY_2, ADDITIONAL_IMAGE_REGISTRY_3	✔	✔	Charge de travail basée sur une classe et clusters de gestion autonomes uniquement. Adresses IP ou noms de domaine complets de trois registres privés approuvés au maximum, en plus du registre d'images principal défini par TKG_CUSTOM_IMAGE_REPOSITORY, pour que les nœuds de cluster de charge de travail y accèdent. Reportez-vous à la section Registres approuvés pour un cluster basé sur une classe.
ADDITIONAL_IMAGE_REGISTRY_1_CA_CERTIFICATE, ADDITIONAL_IMAGE_REGISTRY_2_CA_CERTIFICATE, ADDITIONAL_IMAGE_REGISTRY_3_CA_CERTIFICATE	✔	✔	Charge de travail basée sur une classe et clusters de gestion autonomes uniquement. Certificats d'autorité de certification au format codé en base64 de registres d'images privés configurés avec la valeur ADDITIONAL_IMAGE_REGISTRY- ci-dessus. Par exemple …ADDITIONAL_IMAGE_REGISTRY_1_CA_CERTIFICATE: “LS0t[]tLS0tLQ==”..
ADDITIONAL_IMAGE_REGISTRY_1_SKIP_TLS_VERIFY, ADDITIONAL_IMAGE_REGISTRY_2_SKIP_TLS_VERIFY, ADDITIONAL_IMAGE_REGISTRY_3_SKIP_TLS_VERIFY	✔	✔	Charge de travail basée sur une classe et clusters de gestion autonomes uniquement. Définissez cette variable sur true pour tous les registres d'images privés configurés avec la valeur ci-dessus qui utilisent un certificat auto-signé, mais pas ADDITIONAL_IMAGE_REGISTRY_CA_CERTIFICATE. Étant donné que le Webhook de connectivité Tanzu injecte le certificat d'autorité de certification Harbor dans les nœuds de cluster, _SKIP_TLS_VERIFY doit toujours être défini sur false lors de l'utilisation de Harbor.
TKG_CUSTOM_IMAGE_REPOSITORY	✔	✔	Requis si vous déployez Tanzu Kubernetes Grid dans un environnement à accès restreint à Internet. Fournissez l'adresse IP ou le nom de domaine complet du registre privé qui contient des images système TKG à partir desquelles les clusters démarrent, appelé registre d'images principal ci-dessous. Par exemple, custom-image-repository.io/yourproject.
TKG_CUSTOM_IMAGE_REPOSITORY_SKIP_TLS_VERIFY	✔	✔	Facultatif. Définissez cette variable sur true si votre registre d'images principal privé utilise un certificat auto-signé et que vous n'utilisez pas TKG_CUSTOM_IMAGE_REPOSITORY_CA_CERTIFICATE. Étant donné que le Webhook de connectivité Tanzu injecte le certificat d'autorité de certification Harbor dans les nœuds de cluster, TKG_CUSTOM_IMAGE_REPOSITORY_SKIP_TLS_VERIFY doit toujours être défini sur false lors de l'utilisation de Harbor.
TKG_CUSTOM_IMAGE_REPOSITORY_CA_CERTIFICATE	✔	✔	Facultatif. Définissez cette variable si votre registre d'images principal privé utilise un certificat auto-signé. Fournissez le certificat d'autorité de certification au format codé en base64, par exemple, …TKG_CUSTOM_IMAGE_REPOSITORY_CA_CERTIFICATE: “LS0t[]tLS0tLQ==”.

vSphere

Les options du tableau ci-dessous sont les options minimales que vous spécifiez dans le fichier de configuration de cluster lors du déploiement de clusters de charge de travail sur vSphere. La plupart de ces options sont les mêmes pour le cluster de charge de travail et le cluster de gestion que vous utilisez pour le déployer.

Pour plus d'informations sur les fichiers de configuration de vSphere, reportez-vous aux sections Configuration du cluster de gestion pour vSphere et Déployer des clusters de charge de travail pour vSphere.

Variable	Peut être définie dans…		Description
	YAML du cluster de gestion	YAML du cluster de charge de travail
DEPLOY_TKG_ON_VSPHERE7	✔	✔	Facultatif. Si vous effectuez un déploiement sur vSphere 7 ou 8, définissez cette variable sur true pour ignorer l'invite sur le déploiement sur vSphere 7 ou 8, ou sur false. Clusters de gestion sur vSphere with Tanzu.
ENABLE_TKGS_ON_VSPHERE7	✔	✔	Facultatif, si vous effectuez un déploiement vers vSphere 7 ou 8, définissez cette variable sur true pour être redirigé vers la page de l'interface utilisateur d'activation de vSphere with Tanzu, ou sur false. Clusters de gestion sur vSphere with Tanzu.
NTP_SERVERS	✔	✔	Clusters basés sur une classe uniquement. Configure le serveur NTP du cluster si vous déployez des clusters dans un environnement vSphere qui ne dispose pas de l'option DHCP 42, par exemple NTP_SERVERS: time.google.com. Pour configurer cette option dans un cluster hérité basé sur un plan, utilisez une superposition ytt comme décrit dans la section Configuration de NTP sans option DHCP 42 (vSphere).
TKG_IP_FAMILY	✔	✔	Facultatif. Pour déployer un cluster sur vSphere 7 ou 8 avec IPv6 pure, définissez cette variable sur ipv6. Pour la mise en réseau à double pile (expérimentale), reportez-vous à la section Clusters à double pile.
VIP_NETWORK_INTERFACE	✔	✔	Facultatif. Définissez cette variable sur eth0, eth1, etc. Nom de l'interface réseau (par exemple, une interface Ethernet). Défini sur eth0 par défaut.
VSPHERE_CONTROL_PLANE_DISK_GIB	✔	✔	Facultatif. Taille en gigaoctets du disque pour les machines virtuelles du nœud de plan de contrôle. Incluez des guillemets (““). Par exemple, "30".
VSPHERE_AZ_0, VSPHERE_AZ_1, VSPHERE_AZ_2	✔	✔	Facultatif Zones de déploiement sur lesquelles les déploiements de machines dans un cluster sont déployés. Pour plus d'informations, reportez-vous à la section Déployer des clusters de charge de travail sur plusieurs zones de disponibilité.
VSPHERE_CONTROL_PLANE_ENDPOINT	✔	✔	Requis pour Kube-Vip. Adresse IP virtuelle statique ou nom de domaine complet (FQDN) mappé à une adresse statique, pour les demandes d'API au cluster. Ce paramètre est requis si vous utilisez Kube-VIP pour votre point de terminaison de serveur d'API, tel que configuré en définissant AVI_CONTROL_PLANE_HA_PROVIDER sur false Si vous utilisez NSX Advanced Load Balancer, AVI_CONTROL_PLANE_HA_PROVIDER: true, vous pouvez : Laisser ce champ vide si vous n'avez pas besoin d'une adresse spécifique comme point de terminaison du plan de contrôle Définir cette adresse sur une adresse spécifique dans la plage réseau VIP du profil IPAM et ajouter manuellement l'adresse au pool d'adresses IP statiques. Définir ce champ sur un FQDN
VSPHERE_CONTROL_PLANE_ENDPOINT_PORT	✔	✔	Facultatif, définissez cette variable si vous souhaitez remplacer le port du serveur d'API Kubernetes pour les déploiements sur vSphere avec NSX Advanced Load Balancer. Le port par défaut est 6443. Pour remplacer le port du serveur d'API Kubernetes pour les déploiements sur vSphere sans NSX Advanced Load Balancer, définissez CLUSTER_API_SERVER_PORT.
VSPHERE_CONTROL_PLANE_MEM_MIB	✔	✔	Facultatif. Quantité de mémoire en mégaoctets pour les machines virtuelles du nœud de plan de contrôle. Incluez des guillemets (””). Par exemple, "2048".
VSPHERE_CONTROL_PLANE_NUM_CPUS	✔	✔	Facultatif. Nombre de CPU pour les machines virtuelles du nœud de plan de contrôle. Incluez des guillemets (““). La valeur doit être d'au moins 2. Par exemple, "2".
VSPHERE_DATACENTER	✔	✔	Requis. Nom du centre de données dans lequel déployer le cluster, tel qu'il apparaît dans l'inventaire vSphere. Par exemple, /MY-DATACENTER.
VSPHERE_DATASTORE	✔	✔	Requis. Nom de la banque de données vSphere que le cluster doit utiliser, tel qu'il apparaît dans l'inventaire vSphere. Par exemple, /MY-DATACENTER/datastore/MyDatastore.
VSPHERE_FOLDER	✔	✔	Requis. Nom d'un dossier de machine virtuelle existant dans lequel placer les machines virtuelles Tanzu Kubernetes Grid, tel qu'il apparaît dans l'inventaire vSphere. Par exemple, si vous avez créé un dossier nommé TKG, le chemin d'accès est /MY-DATACENTER/vm/TKG.
VSPHERE_INSECURE	✔	✔	Facultatif. Définissez cette variable sur true pour contourner la vérification de l'empreinte numérique. Si la valeur est false, définissez VSPHERE_TLS_THUMBPRINT.
VSPHERE_NETWORK	✔	✔	Requis. Nom d'un réseau vSphere existant à utiliser comme réseau de service Kubernetes, tel qu'il apparaît dans l'inventaire vSphere. Par exemple, VM Network.
VSPHERE_PASSWORD	✔	✔	Requis. Mot de passe du compte d'utilisateur vSphere. Cette valeur est codée en base64 lorsque vous exécutez tanzu cluster create.
VSPHERE_REGION	✖	✔	Facultatif. Balise pour la région dans vCenter, utilisée pour attribuer le stockage CSI dans un environnement comportant plusieurs centres de données ou clusters d'hôtes. Reportez-vous à la section Déployer un cluster avec des balises de région et de zone pour CSI.
VSPHERE_RESOURCE_POOL	✔	✔	Requis. Nom d'un pool de ressources existant dans lequel placer cette instance de Tanzu Kubernetes Grid, tel qu'il apparaît dans l'inventaire vSphere. Pour utiliser le pool de ressources racine d'un cluster, entrez le chemin d'accès complet. Par exemple, pour un cluster nommé cluster0 dans le centre de données MY-DATACENTER, le chemin d'accès complet est /MY-DATACENTER/host/cluster0/Resources.
VSPHERE_SERVER	✔	✔	Requis. Adresse IP ou nom de domaine complet de l'instance de vCenter Server sur laquelle vous souhaitez déployer le cluster de charge de travail.
VSPHERE_SSH_AUTHORIZED_KEY	✔	✔	Requis. Collez le contenu de la clé publique SSH que vous avez créée dans Déployer un cluster de gestion pour vSphere. Par exemple, …"ssh-rsa NzaC1yc2EA [] hnng2OYYSl+8ZyNz3fmRGX8uPYqw== [email protected]".
VSPHERE_STORAGE_POLICY_ID	✔	✔	Facultatif. Nom d'une stratégie de stockage de machine virtuelle pour le cluster de gestion, tel qu'il apparaît dans Stratégies et profils > Stratégies de stockage de machine virtuelle. Si la variable VSPHERE_DATASTORE est définie, la stratégie de stockage doit l'inclure. Sinon, le processus de création du cluster choisit une banque de données compatible avec la stratégie.
VSPHERE_TEMPLATE	✖	✔	Facultatif. Spécifiez le chemin d'accès à un fichier OVA si vous utilisez plusieurs images OVA personnalisées pour la même version de Kubernetes, en utilisant 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.
VSPHERE_TLS_THUMBPRINT	✔	✔	Requis si VSPHERE_INSECURE est false. Empreinte numérique du certificat vCenter Server. Pour plus d'informations sur l'obtention de l'empreinte numérique du certificat vCenter Server, reportez-vous à la section Obtenir les empreintes numériques du certificat vSphere. Cette valeur peut être ignorée si l'utilisateur souhaite utiliser une connexion non sécurisée en définissant VSPHERE_INSECURE sur true.
VSPHERE_USERNAME	✔	✔	Requis. Compte d'utilisateur vSphere, y compris le nom de domaine, avec les privilèges requis pour l'opération Tanzu Kubernetes Grid. Par exemple, [email protected].
VSPHERE_WORKER_DISK_GIB	✔	✔	Facultatif. Taille en gigaoctets du disque pour les machines virtuelles du nœud worker. Incluez des guillemets (””). Par exemple, "50".
VSPHERE_WORKER_MEM_MIB	✔	✔	Facultatif. Quantité de mémoire en mégaoctets pour les machines virtuelles du nœud worker. Incluez des guillemets (““). Par exemple, "4096".
VSPHERE_WORKER_NUM_CPUS	✔	✔	Facultatif. Nombre de CPU pour les machines virtuelles du nœud worker. Incluez des guillemets (””). La valeur doit être d'au moins 2. Par exemple, "2".
VSPHERE_ZONE	✖	✔	Facultatif. Balise pour la zone dans vCenter, utilisée pour attribuer le stockage CSI dans un environnement comportant plusieurs centres de données ou clusters d'hôtes. Reportez-vous à la section Déployer un cluster avec des balises de région et de zone pour CSI.

Équilibrage de charge Kube-VIP (version d'évaluation technique)

Pour plus d'informations sur la configuration de Kube-VIP en tant que service d'équilibrage de charge L4, reportez-vous à la section Équilibreur de charge Kube-VIP.

Variable	Peut être définie dans…		Description
	YAML du cluster de gestion	YAML du cluster de charge de travail
KUBEVIP_LOADBALANCER_ENABLE	✖	✔	Facultatif ; la valeur par défaut est false. Définissez cette variable sur true ou false. Active Kube-VIP en tant qu'équilibreur de charge pour les charges de travail. Si la variable est définie sur true, vous devez spécifier l'une des variables ci-dessous.
KUBEVIP_LOADBALANCER_IP_RANGES	✖	✔	Liste de plages d'adresses IP sans chevauchement à allouer pour une adresse IP de service de type LoadBalancer. Par exemple : 10.0.0.1-10.0.0.23,10.0.2.1-10.0.2.24.
KUBEVIP_LOADBALANCER_CIDRS	✖	✔	Liste de CIDR qui ne se chevauchent pas pour une adresse IP de service de type LoadBalancer. Par exemple : 10.0.0.0/24,10.0.2/24. Remplace le paramètre pour KUBEVIP_LOADBALANCER_IP_RANGES.

NSX Advanced Load Balancer

Pour plus d'informations sur le déploiement de NSX Advanced Load Balancer, reportez-vous à la section Installer NSX Advanced Load Balancer.

Variable	Peut être définie dans…		Description
	YAML du cluster de gestion	YAML du cluster de charge de travail
AVI_ENABLE	✔	✖	Facultatif ; la valeur par défaut est false. Définissez cette variable sur true ou false. Active NSX Advanced Load Balancer en tant qu'équilibrage de charge pour les charges de travail. Si la variable est true, vous devez définir les variables requises répertoriées dans la section NSX Advanced Load Balancer ci-dessous.
AVI_ADMIN_CREDENTIAL_NAME	✔	✖	Facultatif ; la valeur par défaut est avi-controller-credentials. Nom du secret Kubernetes qui contient le nom d'utilisateur et le mot de passe de l'administrateur du contrôleur NSX Advanced Load Balancer.
AVI_AKO_IMAGE_PULL_POLICY	✔	✖	Facultatif ; la valeur par défaut est IfNotPresent.
AVI_CA_DATA_B64	✔	✖	Requis. Contenu de l’autorité de certification du contrôleur utilisée pour signer le certificat du contrôleur. Il doit être codé en base64. Récupérez le contenu des certificats personnalisés non codés comme décrit dans la section Configuration du contrôleur Avi : certificat personnalisé.
AVI_CA_NAME	✔	✖	Facultatif ; la valeur par défaut est avi-controller-ca. Nom du secret Kubernetes qui détient l'autorité de certification du contrôleur NSX Advanced Load Balancer.
AVI_CLOUD_NAME	✔	✖	Requis. Le cloud que vous avez créé dans votre déploiement NSX Advanced Load Balancer. Par exemple, Default-Cloud.
AVI_CONTROLLER	✔	✖	Requis. Adresse IP ou nom d’hôte du contrôleur NSX Advanced Load Balancer.
AVI_CONTROL_PLANE_HA_PROVIDER	✔	✔	Requis. Définissez cette valeur sur true pour utiliser NSX Advanced Load Balancer comme point de terminaison du serveur d'API du plan de contrôle ou false pour utiliser Kube-Vip comme point de terminaison du plan de contrôle.
AVI_CONTROL_PLANE_NETWORK	✔	✖	Facultatif. Définit le réseau VIP du plan de contrôle du cluster de charge de travail. Utilisez cette variable lorsque vous souhaitez configurer un réseau VIP distinct pour les clusters de charge de travail. Ce champ est facultatif et, s'il est laissé vide, le même réseau que AVI_DATA_NETWORK sera utilisé.
AVI_CONTROL_PLANE_NETWORK_CIDR	✔	✖	Facultatif ; la valeur est définie par défaut sur le même réseau que AVI_DATA_NETWORK_CIDR. CIDR du sous-réseau à utiliser pour le plan de contrôle du cluster de charge de travail. Utilisez cette variable lorsque vous souhaitez configurer un réseau VIP distinct pour les clusters de charge de travail. Vous pouvez voir le CIDR de sous-réseau d'un réseau particulier dans la vue Infrastructure - Réseaux de l'interface NSX Advanced Load Balancer.
AVI_DATA_NETWORK	✔	✖	Requis. Nom du réseau sur lequel le sous-réseau IP flottant ou le pool d'adresses IP est attribué à un équilibrage de charge pour le trafic vers les applications hébergées sur des clusters de charge de travail. Ce réseau doit être présent dans la même instance de vCenter Server que le réseau Kubernetes utilisé par Tanzu Kubernetes Grid, que vous spécifiez dans la variable SERVICE_CIDR. Cela permet à NSX Advanced Load Balancer de détecter le réseau Kubernetes dans vCenter Server et de déployer et de configurer des moteurs de service.
AVI_DATA_NETWORK_CIDR	✔	✖	Requis. CIDR du sous-réseau à utiliser pour l'adresse IP virtuelle de l'équilibrage de charge. Cela provient de l'un des sous-réseaux configurés du réseau VIP. Vous pouvez voir le CIDR de sous-réseau d'un réseau particulier dans la vue Infrastructure - Réseaux de l'interface NSX Advanced Load Balancer.
AVI_DISABLE_INGRESS_CLASS	✔	✖	Facultatif ; la valeur par défaut est false. Désactivez la classe d'entrée.
AVI_DISABLE_STATIC_ROUTE_SYNC	✔	✖	Facultatif ; la valeur par défaut est false. Définissez cette variable sur true si les réseaux d'espace sont accessibles à partir du moteur de service NSX ALB.
AVI_INGRESS_DEFAULT_INGRESS_CONTROLLER	✔	✖	Facultatif ; la valeur par défaut est false. Utilisez AKO comme contrôleur d'entrée par défaut.
AVI_INGRESS_NODE_NETWORK_LIST	✔	✖	Spécifie le nom du réseau de groupe de ports dont font partie vos nœuds et le CIDR associé que la CNI alloue à chaque nœud pour que ce nœud l'attribue à ses espaces. Il est préférable de le mettre à jour dans le fichier AKODeploymentConfig (reportez-vous à la section Entrée L7 en mode ClusterIP), mais si vous utilisez le fichier de configuration du cluster, le format est semblable à : ‘[{“networkName”: “vsphere-portgroup”,“cidrs”: [“100.64.42.0/24”]}]’
AVI_INGRESS_SERVICE_TYPE	✔	✖	Facultatif. Spécifie si l'AKO fonctionne en mode ClusterIP, NodePort ou NodePortLocal. Défini sur NodePort par défaut.
AVI_INGRESS_SHARD_VS_SIZE	✔	✖	Facultatif. AKO utilise une logique de partitionnement pour les objets d'entrée de couche 7. Un service virtuel partitionné implique l'hébergement de plusieurs entrées non sécurisées ou sécurisées hébergées par une adresse IP virtuelle. Définissez cette variable sur LARGE, MEDIUM ou SMALL. La valeur par défaut est SMALL. Utilisez cette option pour contrôler le nombre de services virtuels de couche 7. Cela s'applique à la fois aux services virtuels sécurisés et non sécurisés, mais ne s'applique pas au relais.
AVI_LABELS	✔	✔	Facultatif. Lorsque cette variable est définie, NSX Advanced Load Balancer est activé uniquement sur les clusters de charge de travail qui disposent de cette étiquette. Incluez des guillemets (""). Par exemple, AVI_LABELS: “{foo: ‘bar’}”.
AVI_MANAGEMENT_CLUSTER_CONTROL_PLANE_VIP_NETWORK_CIDR	✔	✖	Facultatif. CIDR du sous-réseau à utiliser pour le plan de contrôle du cluster de gestion. Utilisez cette variable lorsque vous souhaitez configurer un réseau VIP distinct pour le plan de contrôle du cluster de gestion. Vous pouvez voir le CIDR de sous-réseau d'un réseau particulier dans la vue Infrastructure - Réseaux de l'interface NSX Advanced Load Balancer. Ce champ est facultatif et, s'il est laissé vide, le même réseau que AVI_DATA_NETWORK_CIDR sera utilisé.
AVI_MANAGEMENT_CLUSTER_CONTROL_PLANE_VIP_NETWORK_NAME	✔	✖	Facultatif. Définit le réseau d'adresses IP virtuelles du plan de contrôle du cluster de gestion. Utilisez cette variable lorsque vous souhaitez configurer un réseau VIP distinct pour le plan de contrôle du cluster de gestion. Ce champ est facultatif et, s'il est laissé vide, le même réseau que AVI_DATA_NETWORK sera utilisé.
AVI_MANAGEMENT_CLUSTER_SERVICE_ENGINE_GROUP	✔	✖	Facultatif. Spécifie le nom du groupe de moteurs de service qui doit être utilisé par AKO dans le cluster de gestion. Ce champ est facultatif et, s'il est laissé vide, le même réseau que AVI_SERVICE_ENGINE_GROUP sera utilisé.
AVI_MANAGEMENT_CLUSTER_VIP_NETWORK_NAME	✔	✖	Facultatif ; la valeur est définie par défaut sur le même réseau que AVI_DATA_NETWORK. Nom du réseau dans lequel vous attribuez un sous-réseau IP flottant ou un pool d'adresses IP à un équilibrage de charge pour le plan de contrôle du cluster de gestion et du cluster de charge de travail (si vous utilisez NSX ALB pour fournir la haute disponibilité du plan de contrôle). Ce réseau doit être présent dans la même instance de vCenter Server que le réseau Kubernetes utilisé par Tanzu Kubernetes Grid, que vous spécifiez dans la variable SERVICE_CIDR du cluster de gestion. Cela permet à NSX Advanced Load Balancer de détecter le réseau Kubernetes dans vCenter Server et de déployer et de configurer des moteurs de service.
AVI_MANAGEMENT_CLUSTER_VIP_NETWORK_CIDR	✔	✖	Facultatif ; la valeur est définie par défaut sur le même réseau que AVI_DATA_NETWORK_CIDR. CIDR du sous-réseau à utiliser pour l'adresse IP virtuelle du plan de contrôle du cluster de gestion et du cluster de charge de travail (si vous utilisez NSX ALB pour fournir la haute disponibilité du plan de contrôle). Cela provient de l'un des sous-réseaux configurés du réseau VIP. Vous pouvez voir le CIDR de sous-réseau d'un réseau particulier dans la vue Infrastructure - Réseaux de l'interface NSX Advanced Load Balancer.
AVI_NAMESPACE	✔	✖	Facultatif ; la valeur par défaut est “tkg-system-networking”. Espace de noms pour l'opérateur AKO.
AVI_NSXT_T1LR	✔	✖	Facultatif. Chemin du routeur T1 NSX que vous avez configuré pour votre cluster de gestion dans l'interface utilisateur du contrôleur AVI, sous NSX Cloud. Cela est nécessaire lorsque vous utilisez NSX Cloud sur votre contrôleur NSX ALB. Pour utiliser un autre T1 pour vos clusters de charge de travail, modifiez l'objet AKODeploymentConfig install-ako-for-all une fois le cluster de gestion créé.
AVI_PASSWORD	✔	✖	Requis. Mot de passe que vous avez défini pour l'administrateur du contrôleur lorsque vous l'avez déployé.
AVI_SERVICE_ENGINE_GROUP	✔	✖	Requis. Nom du groupe de moteurs de service. Par exemple, Default-Group.
AVI_USERNAME	✔	✖	Requis. Nom d'utilisateur de l'administrateur que vous avez défini pour l'hôte du contrôleur lorsque vous l'avez déployé.

Routage d'espace NSX

Ces variables configurent les espaces de charge de travail avec des adresses IP routables, comme décrit dans Déployer un cluster avec des espaces d'adresses IP routables. Toutes les variables sont des chaînes entre guillemets doubles (par exemple, "true").

Variable	Peut être définie dans…		Description
	YAML du cluster de gestion	YAML du cluster de charge de travail
NSXT_POD_ROUTING_ENABLED	✖	✔	Facultatif ; la valeur par défaut est “false”. Définissez cette variable sur “true” pour activer les espaces routables NSX avec les variables ci-dessous. Reportez-vous à la section Déployer un cluster avec des espaces d'adresses IP routables.
NSXT_MANAGER_HOST	✖	✔	Requis si NSXT_POD_ROUTING_ENABLED= “true”. Adresse IP de NSX Manager.
NSXT_ROUTER_PATH	✖	✔	Requis si NSXT_POD_ROUTING_ENABLED= “true”. Chemin du routeur T1 affiché dans NSX Manager.
Pour l'authentification par nom d'utilisateur/mot de passe dans NSX :
NSXT_USERNAME	✖	✔	Nom d'utilisateur pour la connexion à NSX Manager.
NSXT_PASSWORD	✖	✔	Mot de passe pour la connexion à NSX Manager.
Pour l'authentification à NSX à l'aide des informations d'identification et leur stockage dans un secret Kubernetes (définissez également NSXT_USERNAME et NSXT_PASSWORD ci-dessus) :
NSXT_SECRET_NAMESPACE	✖	✔	Facultatif ; la valeur par défaut est “kube-system”. Espace de noms avec le secret contenant le nom d'utilisateur et le mot de passe NSX.
NSXT_SECRET_NAME	✖	✔	Facultatif ; la valeur par défaut est “cloud-provider-vsphere-nsxt-credentials”. Nom du secret contenant le nom d'utilisateur et le mot de passe NSX.
Pour l'authentification par certificat dans NSX :
NSXT_ALLOW_UNVERIFIED_SSL	✖	✔	Facultatif ; la valeur par défaut est false. Définissez cette variable sur “true” si NSX utilise un certificat auto-signé.
NSXT_ROOT_CA_DATA_B64	✖	✔	Requis si NSXT_ALLOW_UNVERIFIED_SSL= “false”. Chaîne de certificat racine d'autorité de certification codée en base64 que NSX utilise pour l'authentification LDAP.
NSXT_CLIENT_CERT_KEY_DATA	✖	✔	Chaîne de fichier de clé de certificat codée en Base64 pour le certificat client local.
NSXT_CLIENT_CERT_DATA	✖	✔	Chaîne de fichier de certificat codé en Base64 pour le certificat client local.
Pour que l'authentification à distance à NSX avec VMware Identity Manager, sur VMware Cloud (VMC) :
NSXT_REMOTE_AUTH	✖	✔	Facultatif ; la valeur par défaut est false. Définissez cette variable sur “true” pour l'authentification à distance dans NSX avec VMware Identity Manager, sur VMware Cloud (VMC).
NSXT_VMC_AUTH_HOST	✖	✔	Facultatif ; la valeur par défaut est vide. Hôte d’authentification VMC.
NSXT_VMC_ACCESS_TOKEN	✖	✔	Facultatif ; la valeur par défaut est vide. Jeton d’accès d’authentification VMC.

Clusters compatibles GPU

Ces variables configurent des clusters de charge de travail compatibles GPU en mode relais PCI, comme décrit dans la section Déployer un cluster de charge de travail compatible GPU. Toutes les variables sont des chaînes entre guillemets doubles (par exemple, "true").

Variable	Peut être définie dans…		Description
	YAML du cluster de gestion	YAML du cluster de charge de travail
VSPHERE_CONTROL_PLANE_CUSTOM_VMX_KEYS	✔	✔	Définit des clés VMX personnalisées sur toutes les machines du plan de contrôle. Utilisez le format Key1=Value1,Key2=Value2. Reportez-vous à la section Déployer un cluster de charge de travail compatible GPU.
VSPHERE_CONTROL_PLANE_HARDWARE_VERSION	✔	✔	Version matérielle de la machine virtuelle du plan de contrôle avec le périphérique GPU en mode relais PCI. La version minimale requise est 17. Le format de la valeur est vmx-17, où les chiffres de fin correspondent à la version matérielle de la machine virtuelle. Pour connaître la prise en charge des fonctionnalités sur différentes versions matérielles, reportez-vous à la section Fonctions matérielles disponibles avec les paramètres de compatibilité de la machine virtuelle dans la documentation de vSphere.
VSPHERE_CONTROL_PLANE_PCI_DEVICES	✔	✔	Configure le relais PCI sur toutes les machines du plan de contrôle. Utilisez le format <vendor_id>:<device_id>. Par exemple, VSPHERE_WORKER_PCI_DEVICES: “0x10DE:0x1EB8”. Pour rechercher les ID de fournisseur et de périphérique, reportez-vous à la section Déployer un cluster de charge de travail compatible GPU.
VSPHERE_IGNORE_PCI_DEVICES_ALLOW_LIST	✔	✔	Définissez cette variable sur false si vous utilisez le GPU NVIDIA Tesla T4 et true si vous utilisez le GPU NVIDIA V100.
VSPHERE_WORKER_CUSTOM_VMX_KEYS	✔	✔	Définit des clés VMX personnalisées sur toutes les machines worker. Utilisez le format Key1=Value1,Key2=Value2. Pour obtenir un exemple, reportez-vous à la section Déployer un cluster de charge de travail compatible GPU.
VSPHERE_WORKER_HARDWARE_VERSION	✔	✔	Version matérielle de la machine virtuelle worker avec le périphérique GPU en mode relais PCI. La version minimale requise est 17. Le format de la valeur est vmx-17, où les chiffres de fin correspondent à la version matérielle de la machine virtuelle. Pour connaître la prise en charge des fonctionnalités sur différentes versions matérielles, reportez-vous à la section Fonctions matérielles disponibles avec les paramètres de compatibilité de la machine virtuelle dans la documentation de vSphere.
VSPHERE_WORKER_PCI_DEVICES	✔	✔	Configure le relais PCI sur toutes les machines worker. Utilisez le format <vendor_id>:<device_id>. Par exemple, VSPHERE_WORKER_PCI_DEVICES: “0x10DE:0x1EB8”. Pour rechercher les ID de fournisseur et de périphérique, reportez-vous à la section Déployer un cluster de charge de travail compatible GPU.
WORKER_ROLLOUT_STRATEGY	✔	✔	Facultatif. Configure la stratégie de déploiement MachineDeployment. La valeur par défaut est RollingUpdate. Si cette variable est définie sur OnDelete, les machines worker existantes seront alors supprimées lors des mises à jour, avant la création des machines worker de remplacement. Il est impératif de définir cette variable sur OnDelete si tous les périphériques PCI disponibles sont utilisés par les nœuds worker.

AWS

Les variables du tableau ci-dessous sont les options que vous spécifiez dans le fichier de configuration de cluster lors du déploiement de clusters de charge de travail sur AWS. Bon nombre de ces options sont les mêmes pour le cluster de charge de travail et le cluster de gestion que vous utilisez pour le déployer.

Pour plus d'informations sur les fichiers de configuration d'AWS, reportez-vous aux sections Configuration du cluster de gestion pour AWS et Fichiers de configuration du cluster AWS.

Variable	Peut être définie dans…		Description
	YAML du cluster de gestion	YAML du cluster de charge de travail
AWS_ACCESS_KEY_ID	✔	✔	Facultatif. ID de clé d’accès pour votre compte AWS. Il s'agit d'une option pour l'authentification à AWS. Reportez-vous à la section Configurer les informations d'identification du compte AWS. Utilisez uniquement AWS_PROFILE ou une combinaison de AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY, mais pas les deux.
AWS_CONTROL_PLANE_OS_DISK_SIZE_GIB	✔	✔	Facultatif. Taille de disque pour les nœuds du plan de contrôle. Remplace la taille de disque par défaut pour le type de machine virtuelle définie par CONTROL_PLANE_MACHINE_TYPE, SIZE ou CONTROLPLANE_SIZE.
AWS_LOAD_BALANCER_SCHEME_INTERNAL	✔	✔	Facultatif. Pour les clusters de gestion, le schéma d'équilibrage de charge est défini sur interne, empêchant ainsi l'accès depuis Internet. Pour les clusters de charge de travail, le cluster de gestion accède à l'équilibrage de charge du cluster de charge de travail en interne lorsqu'il partage un VPC ou qu'il est homologué. Reportez-vous à la section Utiliser l'équilibrage de charge interne pour le serveur d'API Kubernetes.
AWS_NODE_AZ	✔	✔	Requis. Nom de la zone de disponibilité AWS dans votre région choisie que vous souhaitez utiliser comme zone de disponibilité pour ce cluster de gestion. Les noms de zone de disponibilité sont identiques au nom de région AWS, avec un suffixe minuscule unique, tel que a, b ou c. Par exemple, us-west-2a. Pour déployer un cluster de gestion prod avec trois nœuds de plan de contrôle, vous devez également définir AWS_NODE_AZ_1 et AWS_NODE_AZ_2. Le suffixe de lettre dans chacune de ces zones de disponibilité doit être unique. Par exemple, us-west-2a, us-west-2b et us-west-2c.
AWS_NODE_OS_DISK_SIZE_GIB	✔	✔	Facultatif. Taille de disque des nœuds worker. Remplace la taille de disque par défaut pour le type de machine virtuelle définie par NODE_MACHINE_TYPE, SIZE ou WORKER_SIZE.
AWS_NODE_AZ_1 et AWS_NODE_AZ_2	✔	✔	Facultatif. Définissez ces variables si vous souhaitez déployer un cluster de gestion prod avec trois nœuds de plan de contrôle. Les deux zones de disponibilité doivent se trouver dans la même région que AWS_NODE_AZ. Pour obtenir plus d'informations, reportez-vous à la section AWS_NODE_AZ. Par exemple, us-west-2a, ap-northeast-2b, etc.
AWS_PRIVATE_NODE_CIDR_1	✔	✔	Facultatif. Si la plage recommandée de 10.0.2.0/24 n'est pas disponible, entrez une plage d'adresses IP différente au format CIDR. Lorsque Tanzu Kubernetes Grid déploie votre cluster de gestion, il crée ce sous-réseau dans AWS_NODE_AZ_1. Pour obtenir plus d'informations, reportez-vous à la section AWS_PRIVATE_NODE_CIDR.
AWS_PRIVATE_NODE_CIDR_2	✔	✔	Facultatif. Si la plage recommandée de 10.0.4.0/24 n'est pas disponible, entrez une plage d'adresses IP différente au format CIDR. Lorsque Tanzu Kubernetes Grid déploie votre cluster de gestion, il crée ce sous-réseau dans AWS_NODE_AZ_2. Pour obtenir plus d'informations, reportez-vous à la section AWS_PRIVATE_NODE_CIDR.
AWS_PROFILE	✔	✔	Facultatif. Profil d'informations d'identification AWS, géré par aws configure, que Tanzu Kubernetes Grid utilise pour accéder à son compte AWS. Il s'agit de l'option préférée pour l'authentification à AWS. Reportez-vous à la section Configurer les informations d'identification du compte AWS. Utilisez uniquement AWS_PROFILE ou une combinaison de AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY, mais pas les deux.
AWS_PUBLIC_NODE_CIDR_1	✔	✔	Facultatif. Si la plage recommandée de 10.0.3.0/24 n'est pas disponible, entrez une plage d'adresses IP différente au format CIDR. Lorsque Tanzu Kubernetes Grid déploie votre cluster de gestion, il crée ce sous-réseau dans AWS_NODE_AZ_1. Pour obtenir plus d'informations, reportez-vous à la section AWS_PUBLIC_NODE_CIDR.
AWS_PUBLIC_NODE_CIDR_2	✔	✔	Facultatif. Si la plage recommandée de 10.0.5.0/24 n'est pas disponible, entrez une plage d'adresses IP différente au format CIDR. Lorsque Tanzu Kubernetes Grid déploie votre cluster de gestion, il crée ce sous-réseau dans AWS_NODE_AZ_2. Pour obtenir plus d'informations, reportez-vous à la section AWS_PUBLIC_NODE_CIDR.
AWS_PRIVATE_SUBNET_ID	✔	✔	Facultatif. Si vous définissez AWS_VPC_ID pour utiliser un VPC existant, entrez l'ID d'un sous-réseau privé qui existe déjà dans AWS_NODE_AZ. Ce paramètre est facultatif. Si vous ne le définissez pas, tanzu management-cluster create identifie automatiquement le sous-réseau privé. Pour déployer un cluster de gestion prod avec trois nœuds de plan de contrôle, vous devez également définir AWS_PRIVATE_SUBNET_ID_1 et AWS_PRIVATE_SUBNET_ID_2.
AWS_PRIVATE_SUBNET_ID_1	✔	✔	Facultatif. ID d'un sous-réseau privé existant dans AWS_NODE_AZ_1. Si vous ne définissez pas cette variable, tanzu management-cluster create identifie automatiquement le sous-réseau privé. Pour obtenir plus d'informations, reportez-vous à la section AWS_PRIVATE_SUBNET_ID.
AWS_PRIVATE_SUBNET_ID_2	✔	✔	Facultatif. ID d'un sous-réseau privé existant dans AWS_NODE_AZ_2. Si vous ne définissez pas cette variable, tanzu management-cluster create identifie automatiquement le sous-réseau privé. Pour obtenir plus d'informations, reportez-vous à la section AWS_PRIVATE_SUBNET_ID.
AWS_PUBLIC_SUBNET_ID	✔	✔	Facultatif. Si vous définissez AWS_VPC_ID pour utiliser un VPC existant, entrez l'ID d'un sous-réseau public qui existe déjà dans AWS_NODE_AZ. Ce paramètre est facultatif. Si vous ne le définissez pas, tanzu management-cluster create identifie automatiquement le sous-réseau public. Pour déployer un cluster de gestion prod avec trois nœuds de plan de contrôle, vous devez également définir AWS_PUBLIC_SUBNET_ID_1 et AWS_PUBLIC_SUBNET_ID_2.
AWS_PUBLIC_SUBNET_ID_1	✔	✔	Facultatif. ID d'un sous-réseau public existant dans AWS_NODE_AZ_1. Si vous ne définissez pas cette variable, tanzu management-cluster create identifie automatiquement le sous-réseau public. Pour obtenir plus d'informations, reportez-vous à la section AWS_PUBLIC_SUBNET_ID.
AWS_PUBLIC_SUBNET_ID_2	✔	✔	Facultatif. ID d'un sous-réseau public existant dans AWS_NODE_AZ_2. Si vous ne définissez pas cette variable, tanzu management-cluster create identifie automatiquement le sous-réseau public. Pour obtenir plus d'informations, reportez-vous à la section AWS_PUBLIC_SUBNET_ID.
AWS_REGION	✔	✔	Requis. Nom de la région AWS dans laquelle déployer le cluster. Par exemple, us-west-2. Vous pouvez également spécifier les régions us-gov-east et us-gov-west dans AWS GovCloud. Si vous avez déjà défini une région différente en tant que variable d'environnement (par exemple, dans Déployer des clusters de gestion sur AWS), vous devez annuler la définition de cette variable d'environnement. Par exemple, us-west-2, ap-northeast-2, etc.
AWS_SECRET_ACCESS_KEY	✔	✔	Facultatif. Secret de clé d'accès pour votre compte AWS. Il s'agit d'une option pour l'authentification à AWS. Reportez-vous à la section Configurer les informations d'identification du compte AWS. Utilisez uniquement AWS_PROFILE ou une combinaison de AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY, mais pas les deux.
AWS_SECURITY_GROUP_APISERVER_LB	✔	✔	Facultatif. Groupes de sécurité personnalisés avec des règles personnalisées à appliquer au cluster. Reportez-vous à la section Configurer des groupes de sécurité personnalisés.
AWS_SECURITY_GROUP_BASTION
AWS_SECURITY_GROUP_CONTROLPLANE
AWS_SECURITY_GROUP_APISERVER_LB
AWS_SECURITY_GROUP_NODE
AWS_SESSION_TOKEN	✔	✔	Facultatif. Fournissez le jeton de session AWS accordé à votre compte si vous devez utiliser une clé d'accès temporaire. Pour plus d'informations sur l'utilisation de clés d'accès temporaires, reportez-vous à la section Présentation et obtention de vos informations d'identification AWS et fournissez le jeton de session pour votre compte AWS. Vous pouvez également spécifier des informations d'identification de compte en tant que variables d'environnement local ou dans votre chaîne de fournisseurs d'informations d'identification AWS par défaut.
AWS_SSH_KEY_NAME	✔	✔	Requis. Nom de la clé privée SSH que vous avez enregistrée dans votre compte AWS.
AWS_VPC_ID	✔	✔	Facultatif. Pour utiliser un VPC qui existe déjà dans votre région AWS sélectionnée, entrez l'ID du VPC, puis définissez AWS_PUBLIC_SUBNET_ID et AWS_PRIVATE_SUBNET_ID.
BASTION_HOST_ENABLED	✔	✔	Facultatif. Par défaut, cette option est définie sur "true" dans la configuration Tanzu Kubernetes Grid globale. Spécifiez "true" pour déployer un hôte bastion AWS ou "false" pour réutiliser un hôte bastion existant. Si aucun hôte bastion n'existe dans vos zones de disponibilité et que vous définissez AWS_VPC_ID pour utiliser un VPC existant, définissez BASTION_HOST_ENABLED sur "true".
CONTROL_PLANE_MACHINE_TYPE	✔	✔	Requis si une variable SIZE ou CONTROLPLANE_SIZE indépendante du cloud n'est pas définie. Type d'instance Amazon EC2 à utiliser pour les nœuds de plan de contrôle du cluster (par exemple, t3.small ou m5.large).
NODE_MACHINE_TYPE	✔	✔	Requis si une variable SIZE ou WORKER_SIZE indépendante du cloud n'est pas définie. Type d'instance Amazon EC2 à utiliser pour les nœuds worker du cluster (par exemple, t3.small ou m5.large).

Microsoft Azure

Les variables du tableau ci-dessous sont les options que vous spécifiez dans le fichier de configuration de cluster lors du déploiement de clusters de charge de travail sur Azure. Bon nombre de ces options sont les mêmes pour le cluster de charge de travail et le cluster de gestion que vous utilisez pour le déployer.

Pour plus d'informations sur les fichiers de configuration d'Azure, reportez-vous aux sections Configuration du cluster de gestion pour Azure et Fichiers de configuration du cluster Azure.

Variable	Peut être définie dans…		Description
	YAML du cluster de gestion	YAML du cluster de charge de travail
AZURE_CLIENT_ID	✔	✔	Requis. ID client de l'application pour l'instance de Tanzu Kubernetes Grid que vous avez enregistrée dans Azure.
AZURE_CLIENT_SECRET	✔	✔	Requis. Clé secrète client Azure définie dans Enregistrer une application Tanzu Kubernetes Grid sur Azure.
AZURE_CUSTOM_TAGS	✔	✔	Facultatif. Liste de balises séparées par des virgules à appliquer aux ressources Azure créées pour le cluster. Une balise est une paire clé-valeur (par exemple, “foo=bar, plan=prod”). Pour plus d'informations sur le balisage des ressources Azure, reportez-vous à la section Utiliser les balises pour organiser vos ressources Azure et la hiérarchie de gestion et Prise en charge des balises pour les ressources Azure dans la documentation Microsoft Azure.
AZURE_ENVIRONMENT	✔	✔	Facultatif ; la valeur par défaut est AzurePublicCloud. Les clouds pris en charge sont AzurePublicCloud, AzureChinaCloud, AzureGermanCloud et AzureUSGovernmentCloud.
AZURE_IDENTITY_NAME	✔	✔	Facultatif, définissez cette variable si vous souhaitez utiliser des clusters sur différents comptes Azure. Nom à utiliser pour l'objet AzureClusterIdentity que vous créez afin d'utiliser des clusters sur différents comptes Azure. Pour plus d'informations, reportez-vous à la section Clusters sur différents comptes Azure dans Déployer des clusters de charge de travail sur Azure.
AZURE_IDENTITY_NAMESPACE	✔	✔	Facultatif, définissez cette variable si vous souhaitez utiliser des clusters sur différents comptes Azure. Espace de noms pour votre objet AzureClusterIdentity que vous créez afin d'utiliser des clusters sur différents comptes Azure. Pour plus d'informations, reportez-vous à la section Clusters sur différents comptes Azure dans Déployer des clusters de charge de travail sur Azure.
AZURE_LOCATION	✔	✔	Requis. Nom de la région Azure dans laquelle déployer le cluster. Par exemple, eastus.
AZURE_RESOURCE_GROUP	✔	✔	Facultatif ; la valeur est définie par défaut sur le paramètre CLUSTER_NAME. Nom du groupe de ressources Azure que vous souhaitez utiliser pour le cluster. Doit être unique à chaque cluster. AZURE_RESOURCE_GROUP et AZURE_VNET_RESOURCE_GROUP sont identiques par défaut.
AZURE_SSH_PUBLIC_KEY_B64	✔	✔	Requis. Votre clé publique SSH, créée dans Déployer un cluster de gestion dans Microsoft Azure, convertie en base64 avec les nouvelles lignes supprimées. Par exemple, …c3NoLXJzYSBB [] vdGFsLmlv.
AZURE_SUBSCRIPTION_ID	✔	✔	Requis. ID d'abonnement de votre abonnement Azure.
AZURE_TENANT_ID	✔	✔	Requis. ID de locataire de votre compte Azure.
Mise en réseau
AZURE_CONTROL_PLANE_OUTBOUND_LB_FRONTEND_IP_COUNT	✔	✔	Facultatif ; la valeur par défaut est 1. Définissez cette variable pour ajouter plusieurs adresses IP frontales à l'équilibrage de charge du plan de contrôle dans des environnements avec un nombre élevé de connexions sortantes attendues.
AZURE_ENABLE_ACCELERATED_NETWORKING	✔	✔	Facultatif ; la valeur par défaut est true. Définissez cette variable sur false pour désactiver la mise en réseau accélérée Azure sur les machines virtuelles disposant de plus de 4 CPU.
AZURE_ENABLE_CONTROL_PLANE_OUTBOUND_LB	✔	✔	Facultatif. Définissez cette variable sur true si AZURE_ENABLE_PRIVATE_CLUSTER est définie sur true et que vous souhaitez activer une adresse IP publique sur l'équilibrage de charge sortant pour le plan de contrôle.
AZURE_ENABLE_NODE_OUTBOUND_LB	✔	✔	Facultatif. Définissez cette variable sur true si AZURE_ENABLE_PRIVATE_CLUSTER est définie sur true et que vous souhaitez activer une adresse IP publique sur l'équilibrage de charge sortant pour les nœuds worker.
AZURE_ENABLE_PRIVATE_CLUSTER	✔	✔	Facultatif. Définissez cette variable sur true pour configurer le cluster comme privé et utiliser un équilibrage de charge interne (ILB, Internal Load Balancer) Azure pour son trafic entrant. Pour plus d'informations, reportez-vous à la section Clusters privés Azure.
AZURE_FRONTEND_PRIVATE_IP	✔	✔	Facultatif. Définissez cette variable si AZURE_ENABLE_PRIVATE_CLUSTER est définie sur true et que vous souhaitez remplacer l'adresse d'équilibrage de charge interne par défaut de 10.0.0.100.
AZURE_NODE_OUTBOUND_LB_FRONTEND_IP_COUNT	✔	✔	Facultatif ; la valeur par défaut est 1. Définissez cette variable pour ajouter plusieurs adresses IP frontales à l'équilibrage de charge du nœud worker dans des environnements avec un nombre élevé de connexions sortantes attendues.
AZURE_NODE_OUTBOUND_LB_IDLE_TIMEOUT_IN_MINUTES	✔	✔	Facultatif ; la valeur par défaut est 4. Définissez cette variable pour spécifier le nombre de minutes pendant lesquelles les connexions TCP sortantes restent ouvertes via l'équilibrage de charge sortant du nœud worker.
AZURE_VNET_CIDR	✔	✔	Facultatif, définissez cette variable si vous souhaitez déployer le cluster sur un nouveau réseau virtuel et des sous-réseaux, puis remplacer les valeurs par défaut. Par défaut, AZURE_VNET_CIDR est défini sur 10.0.0.0/16, AZURE_CONTROL_PLANE_SUBNET_CIDR sur 10.0.0.0/24 et AZURE_NODE_SUBNET_CIDR sur 10.0.1.0/24.
AZURE_CONTROL_PLANE_SUBNET_CIDR
AZURE_NODE_SUBNET_CIDR
AZURE_VNET_NAME	✔	✔	Facultatif, définissez cette variable si vous souhaitez déployer le cluster sur un réseau virtuel existant et des sous-réseaux ou attribuer des noms à un nouveau réseau virtuel et à des sous-réseaux.
AZURE_CONTROL_PLANE_SUBNET_NAME
AZURE_NODE_SUBNET_NAME
AZURE_VNET_RESOURCE_GROUP	✔	✔	Facultatif ; la valeur est définie par défaut sur celle de AZURE_RESOURCE_GROUP.
VM du plan de contrôle
AZURE_CONTROL_PLANE_DATA_DISK_SIZE_GIB	✔	✔	Facultatif. Taille du disque de données et du disque du système d'exploitation, comme décrit dans la documentation Azure Rôles de disque pour les machines virtuelles du plan de contrôle en Go. Exemples : 128, 256. Les nœuds de plan de contrôle sont toujours provisionnés avec un disque de données.
AZURE_CONTROL_PLANE_OS_DISK_SIZE_GIB
AZURE_CONTROL_PLANE_MACHINE_TYPE	✔	✔	Facultatif ; la valeur par défaut est Standard_D2s_v3. Taille de machine virtuelle Azure pour les machines virtuelles du nœud du plan de contrôle, choisie pour correspondre aux charges de travail attendues. La configuration minimale requise pour les types d'instance Azure est de 2 CPU et de 8 Go de mémoire. Pour connaître les valeurs possibles, reportez-vous à l'interface du programme d'installation de Tanzu Kubernetes Grid.
AZURE_CONTROL_PLANE_OS_DISK_STORAGE_ACCOUNT_TYPE	✔	✔	Facultatif. Type de compte de stockage Azure pour les disques de machine virtuelle du plan de contrôle. Exemple : Premium_LRS.
Machines virtuelles du nœud worker
AZURE_ENABLE_NODE_DATA_DISK	✔	✔	Facultatif ; la valeur par défaut est false. Définissez cette variable sur true pour provisionner un disque de données pour chaque machine virtuelle de nœud worker, comme décrit dans la documentation Azure Rôles de disque.
AZURE_NODE_DATA_DISK_SIZE_GIB	✔	✔	Facultatif. Définissez cette variable si AZURE_ENABLE_NODE_DATA_DISK est définie sur true. Taille du disque de données, comme décrit dans la documentation Azure Rôles de disque pour les machines virtuelles worker en Go. Exemples : 128, 256.
AZURE_NODE_OS_DISK_SIZE_GIB	✔	✔	Facultatif. Taille du disque de système d'exploitation, comme décrit dans la documentation Azure Rôles de disque pour les machines virtuelles worker en Go. Exemples : 128, 256.
AZURE_NODE_MACHINE_TYPE	✔	✔	Facultatif. Taille de machine virtuelle Azure pour les machines virtuelles du nœud worker, choisie pour correspondre aux charges de travail attendues. La valeur par défaut est Standard_D2s_v3. Pour connaître les valeurs possibles, reportez-vous à l'interface du programme d'installation de Tanzu Kubernetes Grid.
AZURE_NODE_OS_DISK_STORAGE_ACCOUNT_TYPE	✔	✔	Facultatif. Définissez cette variable si AZURE_ENABLE_NODE_DATA_DISK est définie sur true. Type de compte de stockage Azure pour les disques de machine virtuelle worker. Exemple : Premium_LRS.

Priorité de la valeur de configuration

Lorsque la CLI Tanzu crée un cluster, elle lit les valeurs des variables répertoriées dans cette rubrique à partir de plusieurs sources. Si ces sources sont en conflit, elle résout les conflits dans l'ordre de priorité décroissant suivant :

Traitement des couches, classé par priorité décroissante	Source	Exemples
1. Variables de configuration du cluster de gestion définies dans l’interface du programme d’installation	Entrées dans l'interface du programme d'installation lancée par l'option –ui et écrites dans les fichiers de configuration du cluster. L'emplacement du fichier est défini par défaut sur /.config/tanzu/tkg/clusterconfigs/.
2. Variables de configuration de cluster définies dans votre environnement local	Définies dans le shell.	export AZURE_NODE_MACHINE_TYPE=Standard_D2s_v3
3. Variables de configuration de cluster définies dans la CLI Tanzu, avec tanzu config set env.	Définies dans le shell ; enregistrées dans le fichier de configuration de la CLI Tanzu global, /.config/tanzu/config.yaml.	tanzu config set env.AZURE_NODE_MACHINE_TYPE Standard_D2s_v3
4. Variables de configuration de cluster définies dans le fichier de configuration du cluster	Définies dans le fichier transmis à l'option –file de tanzu management-cluster create ou tanzu cluster create. Le fichier est défini par défaut sur ~/.config/tanzu/tkg/cluster-config.yaml.	AZURE_NODE_MACHINE_TYPE: Standard_D2s_v3
5. Valeurs de configuration par défaut d'usine	Définies dans providers/config_default.yaml. Ne modifiez pas ce fichier.	AZURE_NODE_MACHINE_TYPE: “Standard_D2s_v3”