Fichiers de configuration du cluster AWS

Cette rubrique explique comment utiliser un fichier de configuration plat ou une spécification d'objet de style Kubernetes pour configurer un cluster de charge de travail Tanzu Kubernetes Grid (TKG) avant de le déployer sur Amazon Web Services (AWS) avec un cluster de gestion autonome.

Pour obtenir des informations générales sur la configuration des clusters de charge de travail à l'aide de fichiers de configuration et de spécifications d'objets, reportez-vous à la section Fichiers de configuration et spécifications d'objet.

Pour utiliser les fonctionnalités de cluster de charge de travail spécifiques à AWS qui nécessitent une configuration en dehors du fichier de configuration ou de la spécification d'objet du cluster, reportez-vous à la section Clusters sur AWS.

Important
Tanzu Kubernetes Grid v2.4.x est la dernière version de TKG qui prend en charge la création de clusters de charge de travail TKG sur AWS. La possibilité de créer des clusters de charge de travail TKG sur AWS 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 AWS EKS natifs au lieu de créer des clusters de charge de travail TKG sur AWS. Pour plus d'informations sur la création de clusters AWS EKS natifs avec Tanzu Mission Control, reportez-vous à la section Gestion du cycle de vie des clusters AWS EKS 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.

Présentation

Pour configurer un cluster de charge de travail avant de le déployer sur AWS, créez un fichier de configuration de cluster ou un fichier de spécification d'objet de style Kubernetes. Lorsque vous transmettez l'un de ces fichiers à l'option -f de tanzu cluster create, la CLI Tanzu utilise les informations de configuration définies dans le fichier pour se connecter à votre compte AWS et créer les ressources que le cluster utilisera. Par exemple, vous pouvez spécifier les tailles des machines virtuelles de nœud de plan de contrôle et worker, distribuer les nœuds entre les zones de disponibilité et partager des VPC entre les clusters.

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

Remarque
Pour améliorer la sécurité dans un environnement à locataires multiples AWS, déployez les clusters de charge de travail sur un compte AWS différent de celui utilisé pour déployer le cluster de gestion. Pour déployer des clusters de charge de travail sur plusieurs comptes AWS, reportez-vous à la section Clusters sur différents comptes AWS.

Créer un fichier de configuration

Pour créer un fichier de configuration de cluster, vous pouvez utiliser le modèle dans la section Modèle de cluster de travail ci-dessous. Après avoir créé le fichier de configuration, passez à la section Créer des clusters de charge de travail.

Modèle de cluster de charge de travail

Le modèle ci-dessous inclut toutes les options pertinentes pour le déploiement de clusters de charge de travail sur AWS. Vous pouvez copier ce modèle et le mettre à jour pour déployer des clusters de charge de travail sur AWS.

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.

À l'exception des options décrites dans les sections sous le modèle, la manière dont vous configurez les variables des clusters de charge de travail spécifiques à AWS est identique pour les clusters de gestion et les clusters de charge de travail. Pour plus d'informations sur la configuration des variables, reportez-vous aux sections Déployer des clusters de gestion à partir d'un fichier de configuration et Configuration du cluster de gestion pour AWS.

#! ---------------------------------------------------------------------
#! Cluster creation basic configuration
#! ---------------------------------------------------------------------

#! CLUSTER_NAME:
CLUSTER_PLAN: dev
NAMESPACE: default
# CLUSTER_API_SERVER_PORT:
CNI: antrea

#! ---------------------------------------------------------------------
#! Node configuration
#! AWS-only MACHINE_TYPE settings override cloud-agnostic SIZE settings.
#! ---------------------------------------------------------------------

# SIZE:
# CONTROLPLANE_SIZE:
# WORKER_SIZE:
CONTROL_PLANE_MACHINE_TYPE: t3.large
NODE_MACHINE_TYPE: m5.large
# NODE_MACHINE_TYPE_1: ""
# NODE_MACHINE_TYPE_2: ""
# CONTROL_PLANE_MACHINE_COUNT: 1
# WORKER_MACHINE_COUNT: 1
# WORKER_MACHINE_COUNT_0:
# WORKER_MACHINE_COUNT_1:
# WORKER_MACHINE_COUNT_2:

#! ---------------------------------------------------------------------
#! AWS Configuration
#! ---------------------------------------------------------------------

AWS_REGION:
# AWS_LOAD_BALANCER_SCHEME_INTERNAL: false
AWS_NODE_AZ: ""
# AWS_NODE_AZ_1: ""
# AWS_NODE_AZ_2: ""
# AWS_VPC_ID: ""
# AWS_PRIVATE_SUBNET_ID: ""
# AWS_PUBLIC_SUBNET_ID: ""
# AWS_PUBLIC_SUBNET_ID_1: ""
# AWS_PRIVATE_SUBNET_ID_1: ""
# AWS_PUBLIC_SUBNET_ID_2: ""
# AWS_PRIVATE_SUBNET_ID_2: ""
# AWS_VPC_CIDR: 10.0.0.0/16
# AWS_PRIVATE_NODE_CIDR: 10.0.0.0/24
# AWS_PUBLIC_NODE_CIDR: 10.0.1.0/24
# AWS_PRIVATE_NODE_CIDR_1: 10.0.2.0/24
# AWS_PUBLIC_NODE_CIDR_1: 10.0.3.0/24
# AWS_PRIVATE_NODE_CIDR_2: 10.0.4.0/24
# AWS_PUBLIC_NODE_CIDR_2: 10.0.5.0/24
# AWS_SECURITY_GROUP_APISERVER_LB: ""
# AWS_SECURITY_GROUP_BASTION: ""
# AWS_SECURITY_GROUP_CONTROLPLANE: ""
# AWS_SECURITY_GROUP_LB: ""
# AWS_SECURITY_GROUP_NODE: ""
# AWS_IDENTITY_REF_KIND: ""
# AWS_IDENTITY_REF_NAME: ""
# AWS_CONTROL_PLANE_OS_DISK_SIZE_GIB: 80
# AWS_NODE_OS_DISK_SIZE_GIB: 80
AWS_SSH_KEY_NAME:
BASTION_HOST_ENABLED: true

#! ---------------------------------------------------------------------
#! Common configuration
#! ---------------------------------------------------------------------

# TKG_CUSTOM_IMAGE_REPOSITORY: ""
# TKG_CUSTOM_IMAGE_REPOSITORY_SKIP_TLS_VERIFY: false
# TKG_CUSTOM_IMAGE_REPOSITORY_CA_CERTIFICATE: ""

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

ENABLE_AUDIT_LOGGING: false
ENABLE_DEFAULT_STORAGE_CLASS: true

CLUSTER_CIDR: 100.96.0.0/11
SERVICE_CIDR: 100.64.0.0/13

# OS_NAME: ""
# OS_VERSION: ""
# OS_ARCH: ""

#! ---------------------------------------------------------------------
#! Autoscaler configuration
#! ---------------------------------------------------------------------

ENABLE_AUTOSCALER: false
# AUTOSCALER_MAX_NODES_TOTAL: "0"
# AUTOSCALER_SCALE_DOWN_DELAY_AFTER_ADD: "10m"
# AUTOSCALER_SCALE_DOWN_DELAY_AFTER_DELETE: "10s"
# AUTOSCALER_SCALE_DOWN_DELAY_AFTER_FAILURE: "3m"
# AUTOSCALER_SCALE_DOWN_UNNEEDED_TIME: "10m"
# AUTOSCALER_MAX_NODE_PROVISION_TIME: "15m"
# AUTOSCALER_MIN_SIZE_0:
# AUTOSCALER_MAX_SIZE_0:
# AUTOSCALER_MIN_SIZE_1:
# AUTOSCALER_MAX_SIZE_1:
# AUTOSCALER_MIN_SIZE_2:
# AUTOSCALER_MAX_SIZE_2:

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

# ANTREA_NO_SNAT: false
# ANTREA_DISABLE_UDP_TUNNEL_OFFLOAD: false
# ANTREA_TRAFFIC_ENCAP_MODE: "encap"
# ANTREA_EGRESS_EXCEPT_CIDRS: ""
# ANTREA_NODEPORTLOCAL_ENABLED: true
# ANTREA_NODEPORTLOCAL_PORTRANGE: 61000-62000
# ANTREA_PROXY_ALL: false
# ANTREA_PROXY_NODEPORT_ADDRS: ""
# ANTREA_PROXY_SKIP_SERVICES: ""
# ANTREA_PROXY_LOAD_BALANCER_IPS: false
# ANTREA_FLOWEXPORTER_COLLECTOR_ADDRESS: "flow-aggregator.flow-aggregator.svc:4739:tls"
# ANTREA_FLOWEXPORTER_POLL_INTERVAL: "5s"
# ANTREA_FLOWEXPORTER_ACTIVE_TIMEOUT: "30s"
# ANTREA_FLOWEXPORTER_IDLE_TIMEOUT: "15s"
# ANTREA_KUBE_APISERVER_OVERRIDE:
# ANTREA_TRANSPORT_INTERFACE:
# ANTREA_TRANSPORT_INTERFACE_CIDRS: ""
# ANTREA_MULTICAST_INTERFACES: ""
# ANTREA_MULTICAST_IGMPQUERY_INTERVAL: "125s"
# ANTREA_TUNNEL_TYPE: geneve
# ANTREA_ENABLE_USAGE_REPORTING: false
# ANTREA_ENABLE_BRIDGING_MODE: false
# ANTREA_DISABLE_TXCHECKSUM_OFFLOAD: false
# ANTREA_DNS_SERVER_OVERRIDE: ""
# ANTREA_MULTICLUSTER_ENABLE: false
# ANTREA_MULTICLUSTER_NAMESPACE: ""

Spécification de la région

Lorsque vous déployez un cluster sur AWS, définissez AWS_REGION sur la région dans laquelle vous souhaitez déployer le cluster. Vous pouvez définir AWS_REGION dans le fichier de configuration de cluster, une variable d'environnement local ou un profil d'informations d'identification, comme décrit dans la section Configurer les informations d'identification du compte AWS.

Distribution des nœuds worker dans les zones de disponibilité

Lorsque vous créez un cluster prod dans plusieurs zones de disponibilité sur AWS, Tanzu Kubernetes Grid distribue uniformément ses nœuds de plan de contrôle et worker entre les zones de disponibilité (AZ) que vous avez spécifiées dans la configuration de votre cluster. Cela inclut les clusters de charge de travail qui sont configurés avec l'un des éléments suivants :

Nombre par défaut de nœuds de plan de contrôle
Paramètre CONTROL_PLANE_MACHINE_COUNT supérieur au nombre de nœuds de plan de contrôle par défaut
Nombre de nœuds worker par défaut
Paramètre WORKER_MACHINE_COUNT supérieur au nombre de nœuds worker par défaut

Par exemple, si vous spécifiez WORKER_MACHINE_COUNT: 5, Tanzu Kubernetes Grid déploie deux nœuds worker dans la première zone de disponibilité, deux nœuds worker dans la deuxième zone de disponibilité et un nœud worker dans la troisième zone de disponibilité. Vous pouvez éventuellement personnaliser ce mécanisme de placement par zone de disponibilité par défaut pour les nœuds worker en suivant les instructions de la section Configuration des paramètres de placement par zone de disponibilité pour les nœuds worker ci-dessous. Vous ne pouvez pas personnaliser le mécanisme de placement par zone de disponibilité par défaut pour les nœuds de plan de contrôle.

Configuration des paramètres de placement par zone de disponibilité pour les nœuds worker

Lors de la création d'un cluster prod dans plusieurs zones de disponibilité sur AWS, vous pouvez éventuellement spécifier le nombre de nœuds worker que la commande tanzu cluster create crée dans chacune des trois zones de disponibilité.

Pour ce faire :

Incluez les variables suivantes dans votre fichier de configuration du cluster :
- WORKER_MACHINE_COUNT_0 : Définit le nombre de nœuds worker dans la première zone de disponibilité, AWS_NODE_AZ.
- WORKER_MACHINE_COUNT_1 : Définit le nombre de nœuds worker dans la deuxième zone de disponibilité, AWS_NODE_AZ_1.
- WORKER_MACHINE_COUNT_2 : Définit le nombre de nœuds worker dans la troisième zone de disponibilité, AWS_NODE_AZ_2.
Définissez ces variables en plus d'autres paramètres obligatoires et facultatifs, comme décrit dans la section Modèle de cluster de charge de travail ci-dessus.

Créez le cluster. Par exemple :

tanzu cluster create my-prod-cluster -f my-prod-cluster-config.yaml

Déploiement d'un cluster prod à partir d'un cluster de gestion de développement

Lorsque vous créez un cluster de charge de travail prod à partir d'un cluster de gestion dev qui s'exécute sur AWS, vous devez définir un sous-ensemble de variables supplémentaires dans le fichier de configuration du cluster avant d'exécuter la commande tanzu cluster create. Cela permet à Tanzu Kubernetes Grid de créer le cluster et de répartir ses nœuds de plan de contrôle et worker entre les zones de disponibilité.

Pour créer un cluster de charge de travail prod à partir d'un cluster de gestion dev sur AWS, procédez comme suit :

Définissez les variables suivantes dans le fichier de configuration du cluster :
- Définissez PLAN sur prod.
- Variables AWS_NODE_AZ : AWS_NODE_AZ a été défini lorsque vous avez déployé votre cluster de gestion dev. Pour le cluster de charge de travail prod, ajoutez AWS_NODE_AZ_1 et AWS_NODE_AZ_2.
- Variables AWS_PUBLIC_SUBNET_ID (VPC existant) : AWS_PUBLIC_NODE_CIDR ou AWS_PUBLIC_SUBNET_ID a été défini lorsque vous avez déployé votre cluster de gestion dev. Pour le cluster de charge de travail prod, ajoutez l'une des options suivantes :
  - AWS_PUBLIC_NODE_CIDR_1 et AWS_PUBLIC_NODE_CIDR_2
  - AWS_PUBLIC_SUBNET_ID_1 et AWS_PUBLIC_SUBNET_ID_2
- Variables AWS_PRIVATE_SUBNET_ID (VPC existant) : AWS_PRIVATE_NODE_CIDR ou AWS_PRIVATE_SUBNET_ID a été défini lorsque vous avez déployé votre cluster de gestion dev. Pour le cluster de charge de travail prod, ajoutez l'une des options suivantes :
  - AWS_PRIVATE_NODE_CIDR_1 et AWS_PRIVATE_NODE_CIDR_2
  - AWS_PRIVATE_SUBNET_ID_1 et AWS_PRIVATE_SUBNET_ID_2
(Facultatif) Personnalisez le mécanisme de placement par zone de disponibilité par défaut pour les nœuds worker que vous prévoyez de déployer en suivant les instructions de la section Configuration des paramètres de placement par zone de disponibilité pour les nœuds worker. Par défaut, Tanzu Kubernetes Grid distribue uniformément les nœuds worker prod entre les zones de disponibilité.
Déployez le cluster en exécutant la commande tanzu cluster create. Par exemple :
```
tanzu cluster create my-cluster -f my-cluster-config.yaml
```

Créer un fichier de spécification d'objet

Vous pouvez utiliser la CLI Tanzu pour convertir un fichier de configuration de cluster en fichier de spécification d'objet de style Kubernetes pour un cluster de charge de travail basé sur une classe sans déployer le cluster :

Pour générer un fichier de spécification d'objet pour chaque cluster basé sur une classe que vous créez avec tanzu cluster create, assurez-vous que la fonctionnalité auto-apply-generated-clusterclass-based-configuration est définie sur false dans la configuration de la CLI Tanzu. Cette fonctionnalité est définie sur false par défaut. Lorsque auto-apply-generated-clusterclass-based-configuration est défini sur false et que vous exécutez tanzu cluster create avec l'indicateur --file, la commande convertit votre fichier de configuration de cluster en fichier de spécification d'objet et se ferme sans créer le cluster. Après avoir examiné la configuration, réexécutez tanzu cluster create avec le fichier de spécification d'objet généré par la CLI Tanzu. Si vous avez mis à jour la configuration par défaut, pour la rétablir à false, exécutez :
```
tanzu config set features.cluster.auto-apply-generated-clusterclass-based-configuration false
```
Pour générer un fichier de spécification d'objet pour un cluster unique, transmettez l'option --dry-run à tanzu cluster create et enregistrez la sortie dans un fichier. Utilisez les mêmes options et le même --file de configuration que vous utiliseriez pour créer le cluster. Par exemple :
```
tanzu cluster create my-cluster --file my-cluster-config.yaml --dry-run > my-cluster-spec.yaml
```
Vous pouvez utiliser cette spécification d'objet pour déployer un cluster, comme décrit dans la section Créer un cluster basé sur une classe à partir d'une spécification d'objet.

Tâches suivantes

Passez à la section Créer des clusters de charge de travail.