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.
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"
# 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_USERNAME: userPrincipalName
# LDAP_USER_SEARCH_ID_ATTRIBUTE: DN
# LDAP_USER_SEARCH_EMAIL_ATTRIBUTE: DN
# LDAP_USER_SEARCH_NAME_ATTRIBUTE:
# LDAP_GROUP_SEARCH_BASE_DN:
# LDAP_GROUP_SEARCH_FILTER:
# LDAP_GROUP_SEARCH_USER_ATTRIBUTE: DN
# LDAP_GROUP_SEARCH_GROUP_ATTRIBUTE:
# LDAP_GROUP_SEARCH_NAME_ATTRIBUTE: cn
# 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: ""
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
AWS_PROFILE
ou une combinaison de AWS_ACCESS_KEY_ID
et AWS_SECRET_ACCESS_KEY
, mais pas les deux.AWS_ACCESS_KEY_ID
et AWS_SECRET_ACCESS_KEY
doivent être codées en base64.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.
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"
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.
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 :
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 |
Remarque0.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.
Remarquela 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.
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.