This site will be decommissioned on December 31st 2024. After that date content will be available at techdocs.broadcom.com.

 

Configuration du cluster de gestion pour Microsoft Azure

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 Azure et le mettre à jour. Vous pouvez également créer un tout nouveau fichier en utilisant un modèle vide.

Important

Tanzu Kubernetes Grid v2.4.x est la dernière version de TKG qui prend en charge la création de clusters de gestion TKG autonomes sur Azure. La possibilité de créer des clusters de gestion TKG autonomes sur Azure sera supprimée dans Tanzu Kubernetes Grid version v2.5.

À partir de maintenant, VMware vous recommande d'utiliser Tanzu Mission Control pour créer des clusters Azure AKS natifs au lieu de créer des clusters de gestion TKG sur Azure. Pour plus d'informations sur la création de clusters Azure AKS natifs avec Tanzu Mission Control, reportez-vous à la section Gestion du cycle de vie des clusters Azure AKS de la documentation de Tanzu Mission Control.

Pour plus d'informations, reportez-vous à la section Obsolescence des clusters de gestion et de charge de travail TKG sur AWS et Azure des Notes de mise à jour de VMware Tanzu Kubernetes Grid v2.4.

Modèle de configuration du cluster de gestion

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

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: azure
# CLUSTER_API_SERVER_PORT:
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

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

# SIZE:
# CONTROLPLANE_SIZE:
# WORKER_SIZE:
# AZURE_CONTROL_PLANE_MACHINE_TYPE: "Standard_D2s_v3"
# AZURE_NODE_MACHINE_TYPE: "Standard_D2s_v3"
# OS_NAME: ""
# OS_VERSION: ""
# OS_ARCH: ""
# AZURE_CONTROL_PLANE_DATA_DISK_SIZE_GIB : ""
# AZURE_CONTROL_PLANE_OS_DISK_SIZE_GIB : ""
# AZURE_CONTROL_PLANE_MACHINE_TYPE : ""
# AZURE_CONTROL_PLANE_OS_DISK_STORAGE_ACCOUNT_TYPE : ""
# AZURE_ENABLE_NODE_DATA_DISK : ""
# AZURE_NODE_DATA_DISK_SIZE_GIB : ""
# AZURE_NODE_OS_DISK_SIZE_GIB : ""
# AZURE_NODE_MACHINE_TYPE : ""
# AZURE_NODE_OS_DISK_STORAGE_ACCOUNT_TYPE : ""

#! ---------------------------------------------------------------------
#! Azure configuration
#! ---------------------------------------------------------------------

AZURE_ENVIRONMENT: "AzurePublicCloud"
AZURE_TENANT_ID:
AZURE_SUBSCRIPTION_ID:
AZURE_CLIENT_ID:
AZURE_CLIENT_SECRET:
AZURE_LOCATION:
AZURE_SSH_PUBLIC_KEY_B64:
# AZURE_RESOURCE_GROUP: ""
# AZURE_VNET_RESOURCE_GROUP: ""
# AZURE_VNET_NAME: ""
# AZURE_VNET_CIDR: ""
# AZURE_CONTROL_PLANE_SUBNET_NAME: ""
# AZURE_CONTROL_PLANE_SUBNET_CIDR: ""
# AZURE_NODE_SUBNET_NAME: ""
# AZURE_NODE_SUBNET_CIDR: ""
# AZURE_CUSTOM_TAGS : ""
# AZURE_ENABLE_PRIVATE_CLUSTER : ""
# AZURE_FRONTEND_PRIVATE_IP : ""
# AZURE_ENABLE_ACCELERATED_NETWORKING : ""

#! ---------------------------------------------------------------------
#! 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: ""

Paramètres de connexion Azure

Spécifiez les informations sur votre compte Azure et la région dans laquelle vous souhaitez déployer le cluster.

Par exemple :

AZURE_ENVIRONMENT: "AzurePublicCloud"
AZURE_TENANT_ID: b39138ca-[...]-d9dd62f0
AZURE_SUBSCRIPTION_ID: 3b511ccd-[...]-08a6d1a75d78
AZURE_CLIENT_ID: <encoded:M2ZkYTU4NGM[...]tZmViZjMxOGEyNmU1>
AZURE_CLIENT_SECRET: <encoded:bjVxLUpIUE[...]EN+d0RCd28wfg==>
AZURE_LOCATION: westeurope
AZURE_SSH_PUBLIC_KEY_B64: c3NoLXJzYSBBQUFBQjN[...]XJlLmNvbQ==

Configurer les tailles de nœud

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

Après avoir créé le cluster de gestion, les types d'instance des machines de nœud sont définis dans les options AZURE_CONTROL_PLANE_MACHINE_TYPE et AZURE_NODE_MACHINE_TYPE. Par défaut, ces paramètres sont également utilisés pour les clusters de charge de travail. La configuration minimale est de 2 CPU et de 8 Go de mémoire. La liste des types d'instance compatibles varie selon les régions.

AZURE_CONTROL_PLANE_MACHINE_TYPE: "Standard_D2s_v3"
AZURE_NODE_MACHINE_TYPE: "Standard_D2s_v3"

Vous pouvez remplacer ces paramètres à l'aide des options SIZE, CONTROLPLANE_SIZE et WORKER_SIZE. Pour créer un cluster de charge de travail 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. Définissez cette variable sur Standard_D2s_v3, Standard_D4s_v3, et ainsi de suite. Pour plus d'informations sur les instances de nœud pour Azure, reportez-vous à la section Tailles des machines virtuelles dans Azure.

SIZE: Standard_D2s_v3

Pour créer un cluster de charge de travail 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: Standard_D2s_v3
WORKER_SIZE: Standard_D4s_v3

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

SIZE: Standard_D2s_v3
WORKER_SIZE: Standard_D4s_v3

Déployer un cluster avec des sous-réseaux de nœud personnalisés

Pour spécifier des sous-réseaux personnalisés (plages d'adresses IP) pour les nœuds d'un cluster, définissez les variables comme suit avant de créer le cluster. Vous pouvez les définir en tant que variables d'environnement avant d'exécuter la commande tanzu cluster create ou les inclure dans le fichier de configuration du cluster que vous transmettez avec l'option --file.

Pour spécifier un sous-réseau personnalisé (plage d'adresses IP) pour le nœud de plan de contrôle dans un cluster :

  • Sous-réseau déjà défini dans Azure : Définissez AZURE_CONTROL_PLANE_SUBNET_NAME sur le nom du sous-réseau.
  • Créer un sous-réseau : Définissez AZURE_CONTROL_PLANE_SUBNET_NAME sur le nom du nouveau sous-réseau et définissez éventuellement AZURE_CONTROL_PLANE_SUBNET_CIDR sur une plage CIDR dans le réseau virtuel Azure configuré.
    • Si vous omettez AZURE_CONTROL_PLANE_SUBNET_CIDR, un CIDR est généré automatiquement.

Pour spécifier un sous-réseau personnalisé pour les nœuds worker dans un cluster, définissez les variables d'environnement AZURE_NODE_SUBNET_NAME et AZURE_NODE_SUBNET_CIDR en suivant les mêmes règles que pour le nœud de plan de contrôle ci-dessus.

Par exemple :

AZURE_CONTROL_PLANE_SUBNET_CIDR: 10.0.0.0/24
AZURE_CONTROL_PLANE_SUBNET_NAME: my-cp-subnet
AZURE_NODE_SUBNET_CIDR: 10.0.1.0/24
AZURE_NODE_SUBNET_NAME: my-worker-subnet
AZURE_RESOURCE_GROUP: my-rg
AZURE_VNET_CIDR: 10.0.0.0/16
AZURE_VNET_NAME: my-vnet
AZURE_VNET_RESOURCE_GROUP: my-rg

Tâches suivantes

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

Important

Si vous déployez pour la première fois un cluster de gestion sur Azure avec une nouvelle version de Tanzu Kubernetes Grid (la version v2.4, par exemple), assurez-vous que vous avez accepté la licence d'image de base pour cette version. Pour plus d'informations, reportez-vous à la section Accepter la licence d'image de base dans Préparer le déploiement des clusters de gestion sur Microsoft Azure.

check-circle-line exclamation-circle-line close-line
Scroll to top icon