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.
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.
RemarquePour 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.
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.
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: ""
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.
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 :
CONTROL_PLANE_MACHINE_COUNT
supérieur au nombre de nœuds de plan de contrôle par défautWORKER_MACHINE_COUNT
supérieur au nombre de nœuds worker par défautPar 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.
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
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 :
PLAN
sur prod
.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
.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
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
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.
Passez à la section Créer des clusters de charge de travail.