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.

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.

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

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.

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