Configuration du cluster de gestion pour AWS

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 Amazon Web Services (AWS) 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 AWS. La possibilité de créer des clusters de gestion TKG autonomes 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 gestion 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.

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 AWS. Vous pouvez copier ce modèle et l'utiliser pour déployer des clusters de gestion sur AWS.

Pour plus d'informations sur la mise à jour des paramètres communs à toutes les plates-formes cibles, reportez-vous à la section Créer un fichier de configuration de cluster de gestion.
Pour plus d'informations sur toutes les variables de fichier de configuration, reportez-vous à la Référence de variable de fichier de configuration de la CLI Tanzu.
Pour obtenir des exemples de configuration des paramètres vSphere, reportez-vous aux sections sous le modèle.

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: aws
# 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
#! 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
# OS_NAME: ""
# OS_VERSION: ""
# OS_ARCH: ""

#! ---------------------------------------------------------------------
#! AWS configuration
#! ---------------------------------------------------------------------

AWS_REGION:
AWS_NODE_AZ: ""
AWS_ACCESS_KEY_ID:
AWS_SECRET_ACCESS_KEY:
AWS_SSH_KEY_NAME:
BASTION_HOST_ENABLED: true
# 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_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_BASTION: sg-12345
# AWS_SECURITY_GROUP_CONTROLPLANE: sg-12346
# AWS_SECURITY_GROUP_APISERVER_LB: sg-12347
# AWS_SECURITY_GROUP_NODE: sg-12348
# AWS_SECURITY_GROUP_LB: sg-12349
# DISABLE_TMC_CLOUD_PERMISSIONS: false # Deactivates IAM permissions required for TMC enablement

#! ---------------------------------------------------------------------
#! 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 AWS

Pour fournir des informations sur votre compte AWS, la région et la zone de disponibilité dans lesquelles vous souhaitez déployer le cluster, procédez comme suit :

(Recommandé) Configurez un profil d'informations d'identification AWS avec la CLI AWS et définissez une variable d'environnement AWS_PROFILE pour le nom de profil sur votre machine de démarrage.
Incluez les informations d'identification du compte et d'autres informations dans le fichier de configuration du cluster. Par exemple :
```
AWS_REGION: eu-west-1
AWS_NODE_AZ: "eu-west-1a"
# Only use AWS_PROFILE OR combination of AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, but not both.
AWS_PROFILE: tkg
# AWS_ACCESS_KEY_ID:  <encoded:QUtJQVQ[...]SU82TTM=>
# AWS_SECRET_ACCESS_KEY: <encoded:eGN4RHJmLzZ[...]SR08yY2ticQ==>
AWS_SSH_KEY_NAME: default
BASTION_HOST_ENABLED: true
```
- Utilisez uniquement AWS_PROFILE ou une combinaison de AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY, mais pas les deux.
- Les valeurs pour AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY doivent être codées en base64.

Utiliser un équilibrage de charge interne pour le serveur d'API

Par défaut, Tanzu Kubernetes Grid sur AWS crée un équilibrage de charge public pour le serveur d'API Kubernetes du cluster de gestion.

Pour les environnements avec accès restreint à Internet, isolés ou derrière un proxy, vous pouvez éviter de créer un équilibrage de charge public en définissant AWS_LOAD_BALANCER_SCHEME_INTERNAL sur true dans le fichier de configuration du cluster :

AWS_LOAD_BALANCER_SCHEME_INTERNAL: true

Ce paramètre personnalise l'équilibrage de charge du cluster de gestion pour utiliser un schéma interne, ce qui signifie que son serveur d'API Kubernetes ne sera pas accessible et acheminé sur Internet.

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 Tanzu Kubernetes 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 CONTROL_PLANE_MACHINE_TYPE et 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.

CONTROL_PLANE_MACHINE_TYPE: "t3.large"
NODE_MACHINE_TYPE: "m5.large"

Vous pouvez remplacer ces paramètres à l'aide des options SIZE, CONTROLPLANE_SIZE et WORKER_SIZE. Pour créer un cluster Tanzu Kubernetes 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. Pour plus d'informations sur les configurations des différentes tailles d'instances de nœud pour Amazon EC2, reportez-vous à la section Types d'instance Amazon EC2.

SIZE: "t3.large"

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: "t3.large"
WORKER_SIZE: "m5.xlarge"

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

SIZE: "t3.large"
WORKER_SIZE: "m5.xlarge"

Configurer le VPC

Supprimez les commentaires et mettez à jour les lignes suivantes pour spécifier le VPC et l'autre infrastructure AWS qui hébergera et sera utilisée par le cluster de gestion autonome

AWS_REGION:
AWS_NODE_AZ:
AWS_PRIVATE_SUBNET_ID:
AWS_PUBLIC_SUBNET_ID:
AWS_SSH_KEY_NAME:
AWS_VPC_ID:
BASTION_HOST_ENABLED:
CONTROL_PLANE_MACHINE_TYPE:
NODE_MACHINE_TYPE:
SERVICE_CIDR:
CLUSTER_CIDR:

Si vous déployez un cluster de gestion de production, supprimez également les marques de commentaire et renseignez les éléments suivants pour les deux nœuds de plan de contrôle supplémentaires :

AWS_NODE_AZ_1:
AWS_NODE_AZ_2:
AWS_PRIVATE_SUBNET_ID_1:
AWS_PRIVATE_SUBNET_ID_2:
AWS_PUBLIC_SUBNET_ID_1:
AWS_PUBLIC_SUBNET_ID_2:

Par exemple, la configuration d'un cluster de gestion de production sur un VPC existant peut ressembler à ceci :

AWS_REGION: us-west-2
AWS_NODE_AZ: us-west-2a
AWS_NODE_AZ_1: us-west-2b
AWS_NODE_AZ_2: us-west-2c
AWS_PRIVATE_SUBNET_ID: subnet-ID
AWS_PRIVATE_SUBNET_ID_1: subnet-ID
AWS_PRIVATE_SUBNET_ID_2: subnet-ID
AWS_PUBLIC_SUBNET_ID: subnet-ID
AWS_PUBLIC_SUBNET_ID_1: subnet-ID
AWS_PUBLIC_SUBNET_ID_2: subnet-ID
AWS_SSH_KEY_NAME: tkg
AWS_VPC_ID: vpc-ID
BASTION_HOST_ENABLED: "true"
CONTROL_PLANE_MACHINE_TYPE: m5.large
NODE_MACHINE_TYPE: m5.large
SERVICE_CIDR: 100.64.0.0/13
CLUSTER_CIDR: 100.96.0.0/11

Par défaut, Tanzu Kubernetes Grid crée des groupes de sécurité pour connecter le plan de contrôle, les nœuds worker et les équilibrages de charge. Si vous avez besoin de règles personnalisées, vous pouvez préprovisionner les groupes de sécurité, ajouter les ensembles de règles et configurer des clusters pour utiliser les groupes de sécurité personnalisés comme décrit ci-dessous.

Configurer des groupes de sécurité personnalisés

Par défaut, Tanzu Kubernetes Grid crée cinq groupes de sécurité dans un VPC.

Pour empêcher Tanzu Kubernetes Grid de créer des groupes de sécurité et utiliser plutôt des groupes de sécurité existants préprovisionnés avec des ensembles de règles personnalisés, procédez comme suit :

Créez des groupes de sécurité avec des ensembles de règles personnalisés, correspondant aussi étroitement que possible aux ensembles de règles par défaut.
Spécifiez les groupes de sécurité personnalisés dans le fichier de configuration du cluster, en définissant les variables AWS_SECURITY_GROUP_* sur les noms des groupes de sécurité. Par exemple :
```
AWS_SECURITY_GROUP_BASTION: sg-12345
```

Les cinq groupes de sécurité, leurs règles par défaut et leurs variables de configuration de cluster correspondantes sont répertoriés ci-dessous :

Groupe : CLUSTER-NAME-bastion

Définissez avec la variable de configuration de cluster AWS_SECURITY_GROUP_BASTION.

Règles :

Description	Protocole	Depuis le port	Vers le port	Autoriser l'entrée depuis	Obligatoire
SSH	TCP	22	22	0.0.0.0/0	Non

Groupe : CLUSTER-NAME-node

Définissez avec la variable de configuration de cluster AWS_SECURITY_GROUP_NODE.

Règles :

Description	Protocole	Depuis le port	Vers le port	Autoriser l'entrée depuis	Obligatoire
SSH	TCP	22	22	Groupe de sécurité <cluster-name>-bastion	Non
Services de port de nœud	TCP	30000	32767	0.0.0.0/0	Non (voir la remarque ci-dessous)
API Kubelet	TCP	10250	10250	Groupes de sécurité <cluster-name>-controlplane et <cluster-name>-node	Oui
CNI Antrea	TCP	10349-10351	10349-10351	Groupe de sécurité <cluster-name>-node	Oui
GENEVE	UDP	6081	6081	Groupe de sécurité <cluster-name>-node	Oui

Remarque
0.0.0.0/0 est entrant uniquement depuis le VPC, les VPC homologues et tous les réseaux connectés via VPN ou DirectConnect. 0.0.0.0/0 ne doit pas être interprété comme étant accessible depuis Internet. Il est possible de modifier la plage de ports et la règle d'entrée pour les services de port de nœud tant qu'il s'agit d'administrateurs et qu'elles ne sont pas utilisées pour le fonctionnement du cluster.

Groupe : CLUSTER-NAME-controlplane

Définissez avec la variable de configuration de cluster AWS_SECURITY_GROUP_CONTROLPLANE.

Règles :

Description	Protocole	Depuis le port	Vers le port	Autoriser l'entrée depuis	Obligatoire
SSH	TCP	22	22	Groupe de sécurité <cluster-name>-bastion	Non
API Kubernetes	TCP	6443*	6443*	Groupes de sécurité <cluster-name>-apiserver-lb, <cluster-name>-apiserver-controlplane et <cluster-name>-apiserver-node	Oui
etcd	TCP	2379	2379	Groupe de sécurité <cluster-name>-controlplane	Oui
Homologue etcd	TCP	2380	2380	Groupe de sécurité <cluster-name>-controlplane	Oui
gestionnaire de modules complémentaires	TCP	9865	9865	Groupe de sécurité <nom du cluster>-plan de contrôle	Oui
contrôleur kapp	TCP	10100	10100	Groupe de sécurité <nom du cluster>-plan de contrôle	Oui

* Si vous définissez CLUSTER_API_SERVER_PORT, remplacez 6443 par le numéro de port que vous avez défini dans la variable.

Groupe : CLUSTER-NAME-apiserver-lb

Définissez avec la variable de configuration de cluster AWS_SECURITY_GROUP_APISERVER_LB.

Règles :

Description	Protocole	Depuis le port	Vers le port	Autoriser l'entrée depuis	Obligatoire
API Kubernetes	TCP	6443*	6443*	0.0.0.0/0	Non (voir la remarque ci-dessous)

* Si vous définissez CLUSTER_API_SERVER_PORT, remplacez 6443 par le numéro de port que vous avez défini dans la variable.

Remarque
la règle 0.0.0.0/0 par défaut est accessible depuis Internet lorsqu'elle n'est pas spécifiée pour provisionner l'équilibrage de charge en interne. Si l'équilibrage de charge est interne, il doit être accessible depuis le cluster de gestion (pour les clusters de charge de travail) ou la machine de démarrage (pour le cluster de gestion). Cette règle peut être verrouillée, mais si c'est le cas, la règle suivante DOIT être ajoutée :

Description	Protocole	Depuis le port	Vers le port	Autoriser l'entrée depuis	Obligatoire
API Kubernetes dans le cluster	TCP	6443*	6443*	Groupes de sécurité <cluster-name>-controlplane et <cluster-name>-node	Oui

* Si vous définissez CLUSTER_API_SERVER_PORT, remplacez 6443 par le numéro de port que vous avez défini dans la variable.

Groupe : CLUSTER-NAME-lb

Définissez avec la variable de configuration de cluster AWS_SECURITY_GROUP_LB.

Ce groupe de sécurité est utilisé pour les équilibrages de charge de travail. Aucune règle n’est ajoutée à ce groupe de sécurité et les administrateurs AWS doivent personnaliser l’ensemble de règles si nécessaire pour la charge de travail de l’application.

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.