Créer un cluster

Cette page explique comment créer un cluster GKE sur AWS. Vous pouvez également créer un VPC et un cluster avec Terraform.

Avant de commencer

Avant de créer un cluster, vous devez remplir les conditions préalables. Vous devez notamment fournir les ressources suivantes :

  • Un VPC AWS sur lequel le cluster sera exécuté.
  • Jusqu'à trois sous-réseaux AWS pour les trois instances dupliquées du plan de contrôle. Chaque zone doit se trouver dans une zone de disponibilité AWS différente.
  • Rôle IAM AWS que GKE sur AWS assume lors de la gestion de votre cluster. Cela nécessite un ensemble spécifique d'autorisations IAM.
  • Clés CMK symétriques KMS pour le chiffrement au repos des données de cluster (etcd) et de la configuration.
  • Profil d'instance AWS IAM pour chaque instance dupliquée du plan de contrôle. Cela nécessite un ensemble spécifique d'autorisations IAM.
  • Une paire de clés SSH EC2 (facultatif) si vous avez besoin d'un accès SSH aux instances EC2 qui exécutent chaque instance dupliquée du plan de contrôle.

Vous êtes responsable de la création et de la gestion de ces ressources, qui peuvent être partagées entre tous vos clusters GKE. Toutes les autres ressources AWS sous-jacentes à l'échelle d'un cluster sont gérées par GKE sur AWS.

Sélectionner des plages CIDR pour votre cluster

Lorsque vous créez un cluster dans GKE sur AWS, vous devez fournir des plages d'adresses IPv4 à utiliser pour les pods et les services.

Ces plages d'adresses IP sont spécifiées à l'aide de la notation CIDR (Classless Inter-Domain Routing), par exemple, 100.64.0.0/16.

Nous recommandons les plages CIDR suivantes pour les services et les pods:

  • Services: 100.64.0.0/16
  • Pods: 100.96.0.0/11

Ces plages sont suffisamment grandes pour que vous puissiez développer votre cluster sans aucun problème.

Vous trouverez des informations supplémentaires dans les sections suivantes.

Informations sur la sélection de plages

GKE sur AWS utilise un réseau superposé pour les pods et les services. Par conséquent, les plages d'adresses IP de ces réseaux n'ont pas besoin d'être routables dans le VPC. La disponibilité de toutes les plages d'adresses IP que vous utilisez doivent être garanties. Pour plus d'informations, consultez la page Dataplane V2.

  • Les plages d'adresses IP des pods et des services peuvent chevaucher le réseau VPC, à condition qu'elles n'incluent pas les plages d'adresses IP du sous-réseau de plan de contrôle ou de pool de nœuds.

  • La plage d'adresses IP des pods et des services doit être comprise dans l'une des plages d'adresses IP privées suivantes :

    • 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 — Adresses IP privées (RFC 1918)
    • 100.64.0.0/10 — Espace d'adressage partagé (RFC 6598)
    • 192.0.0.0/24 — Attributions de protocole IETF (RFC 6890)
    • 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24 — Documentation (RFC 5737)
    • 192.88.99.0/24 — Relais IPv6 vers IPv4 (obsolète) (RFC 7526)
    • 198.18.0.0/15 — Série de tests comparatifs (RFC 2544)

Nous vous recommandons d'utiliser les plages d'adresses IP dans 100.64.0.0/10 (RFC 6598). Cette plage est rétablie pour la NAT de niveau opérateur, qui n'est probablement pas utilisée dans votre VPC.

Par exemple, voici une configuration valide car les réseaux de pods, de services et de nœuds ne se chevauchent pas (le VPC utilise des adresses IP privées RFC 1918, tandis que les réseaux de pods et de services sont superposés sur des adresses IP privées RFC 6598).

  • Réseau VPC : 10.0.0.0/16, 172.16.1.0/24, 172.16.2.0/24
  • Réseau du pod : 100.65.0.0/16
  • Réseau du service : 100.66.0.0/16

Ce qui suit est aussi une configuration valide, même si les réseaux de pod et de service se chevauchent avec le réseau VPC, car il n'y a pas de chevauchement avec les instances dupliquées du plan de contrôle.

  • Réseau VPC : 10.0.0.0/16
  • Réseau du pod : 10.0.1.0/24
  • Réseau du service : 10.0.2.0/24
  • Sous-réseaux des instances dupliquées du plan de contrôle : 10.0.3.0/24, 10.0.4.0/24, 10.0.5.0/24

La configuration suivante n'est pas valide, car la plage d'adresses IP du pod chevauche le réseau du plan de contrôle. Ce chevauchement peut empêcher les charges de travail de communiquer avec l'instance dupliquée du plan de contrôle dans le réseau VPC :

  • Réseau VPC : 10.0.0.0/16
  • Réseau du pod : 10.0.1.0/24
  • Réseau du service : 10.1.0.0/24
  • Sous-réseaux des instances dupliquées du plan de contrôle : 10.0.1.0/24, 10.0.2.0/24, 10.0.3.0/24

Détails sur la plage d'adresses des pods

Kubernetes alloue des adresses aux objets pod de la plage d'adresses des pods. La plage de pods d'un cluster est divisée en plages plus petites pour chaque nœud. Lorsqu'un pod est planifié sur un nœud particulier, Kubernetes attribue une adresse IP de pod provenant de la plage du nœud.

Pour calculer la taille de la plage d'adresses des pods, vous devez estimer le nombre de nœuds que vous souhaitez avoir dans votre cluster et le nombre de pods que vous souhaitez exécuter sur chaque nœud.

Le tableau suivant fournit des recommandations de taille pour les plages CIDR des pods en fonction du nombre de nœuds et de pods que vous souhaitez exécuter.

Tableau des plages d'adresses de pod

Plage d'adresses de pod Nombre maximal d'adresses IP de pod Nombre maximal de nœuds Nombre maximal de pods
/24
Plage d'adresses de pod la plus petite possible		 256 adresses 1 nœud 110 pods
/23 512 adresses 2 nœuds 220 pods
/22 1 024 adresses 4 nœuds 440 pods
/21 2 048 adresses 8 nœuds 880 pods
/20 4 096 adresses 16 nœuds 1 760 pods
/19 8 192 adresses 32 nœuds 3 520 pods
/18 16 384 adresses 64 nœuds 7 040 pods
/17 32 768 adresses 128 nœuds 14 080 pods
/16 65 536 adresses 256 nœuds 28 160 pods
/15 131 072 adresses 512 nœuds 56 320 pods
/14 262 144 adresses 1 024 nœuds 112 640 pods

Détails sur la plage d'adresses du service

Kubernetes attribue les adresses IP virtuelles des objets Service, par exemple des équilibreurs de charge à partir de cette plage d'adresses.

Pour calculer la taille de la plage d'adresses des services, vous devez effectuer une estimation du nombre de services souhaités dans le cluster.

Le tableau suivant fournit des recommandations de taille pour les plages CIDR de services en fonction du nombre de services que vous souhaitez exécuter.

Tableau des plages d'adresses de services

Plage d'adresses du service Nombre maximal de services
/27
Plage d'adresses de services la plus réduite possible		 32 services
/26 64 services
/25 128 services
/24 256 services
/23 512 services
/22 1 024 services
/21 2 048 services
/20 4 096 services
/19 8 192 services
/18 16 384 services
/17 32 768 services
/16
Plage d'adresses de services la plus étendue possible		 65 536 services

Sélectionner votre projet hôte du parc

Les parcs sont un concept Google Cloud qui permet d'organiser les clusters en groupes plus importants. Les parcs vous permettent de gérer plusieurs clusters sur plusieurs clouds et de leur appliquer des stratégies cohérentes. L'API GKE Multi-Cloud enregistre automatiquement vos clusters dans un parc lors de leur création.

Lorsque vous créez un cluster, vous spécifiez un projet hôte de parc dans lequel le cluster sera géré. Étant donné que GKE sur AWS utilise le nom du cluster comme nom d'appartenance au parc, vous devez vous assurer que les noms de vos clusters sont uniques au sein de votre parc.

Enregistrement multiprojets

Si vous souhaitez utiliser un projet hôte de parc autre que le projet Google Cloud dans lequel se trouve le cluster, vous devez appliquer une liaison de stratégie IAM supplémentaire au compte de service de l'agent de service multicloud. Cela permet au compte de service de gérer les parcs avec le projet hôte.

  1. Pour ajouter l'agent de service à votre projet, exécutez la commande suivante :

    gcloud beta services identity create --service=gkemulticloud.googleapis.com \
  --project=CLUSTER_PROJECT_NUMBER

    Remplacez CLUSTER_PROJECT_NUMBER par votre numéro de projet Google Cloud.

  2. Attribuez cette liaison à l'aide de la commande suivante :

    gcloud projects add-iam-policy-binding FLEET_PROJECT_ID \
  --member="serviceAccount:service-CLUSTER_PROJECT_NUMBER@gcp-sa-gkemulticloud.iam.gserviceaccount.com" \
  --role="roles/gkemulticloud.serviceAgent"

    Remplacez les éléments suivants :

    • FLEET_PROJECT_ID : projet Google Cloud de votre projet hôte de parc
    • CLUSTER_PROJECT_NUMBER : numéro de votre projet Google Cloud

Le nom du compte de l'agent de service multicloud a le format suivant : service-CLUSTER_PROJECT_NUMBER@gcp-sa-gkemulticloud.iam.gserviceaccount.com.

Vous pouvez trouver vos comptes de service sur la page Compte de service de Google Cloud Console. Pour savoir comment trouver votre numéro de projet, consultez la page Identifier des projets.

Créer votre cluster

Exécutez la commande suivante pour créer votre cluster sous GKE sur AWS. Pour plus d'informations sur cette commande, y compris ses paramètres facultatifs, consultez la page de référence gcloud container aws.

gcloud container aws clusters create CLUSTER_NAME \
  --aws-region AWS_REGION \
  --location GOOGLE_CLOUD_LOCATION \
  --cluster-version CLUSTER_VERSION \
  --fleet-project FLEET_PROJECT \
  --vpc-id VPC_ID \
  --subnet-ids CONTROL_PLANE_SUBNET_1,CONTROL_PLANE_SUBNET_2,CONTROL_PLANE_SUBNET_3 \
  --pod-address-cidr-blocks POD_ADDRESS_CIDR_BLOCKS \
  --service-address-cidr-blocks SERVICE_ADDRESS_CIDR_BLOCKS \
  --role-arn API_ROLE_ARN \
  --database-encryption-kms-key-arn DB_KMS_KEY_ARN \
  --admin-users ADMIN_USERS_LIST \
  --config-encryption-kms-key-arn CONFIG_KMS_KEY_ARN \
  --iam-instance-profile CONTROL_PLANE_PROFILE \
  --tags "Name=CLUSTER_NAME-cp"

Remplacez les éléments suivants :

  • CLUSTER_NAME : nom de cluster choisi.
  • AWS_REGION : région AWS dans laquelle créer le cluster.
  • GOOGLE_CLOUD_LOCATION : nom de l'emplacement Google Cloud à partir duquel ce cluster sera géré, comme défini dans les régions de gestion de Google Cloud.
  • CLUSTER_VERSION : version de Kubernetes à installer sur votre cluster.
  • FLEET_PROJECT : projet hôte du parc dans lequel le cluster sera enregistré. Si vous souhaitez gérer ce cluster depuis un autre projet Google Cloud, consultez la page Enregistrement multiprojets.
  • VPC_ID : ID du VPC AWS pour ce cluster.
  • CONTROL_PLANE_SUBNET_1, CONTROL_PLANE_SUBNET_2 et CONTROL_PLANE_SUBNET_3 : ID de sous-réseau des trois instances de plan de contrôle du cluster.
  • POD_ADDRESS_CIDR_BLOCKS : plage d'adresses CIDR pour les pods de votre cluster.
  • SERVICE_ADDRESS_CIDR_BLOCKS : plage d'adresses CIDR pour les services de votre cluster.
  • API_ROLE_ARN: nom ARN du rôle API GKE Multi-Cloud
  • CONTROL_PLANE_PROFILE: profil de l'instance IAM associée au cluster. Pour en savoir plus sur la mise à jour d'un profil d'instance IAM, consultez la section Mettre à jour le profil d'instance IAM AWS.
  • DB_KMS_KEY_ARN : nom ARN (Amazon Resource Name) de la clé KMS AWS servant à chiffrer les secrets du cluster.
  • CONFIG_KMS_KEY_ARN : nom ARN (Amazon Resource Name) de la clé KMS AWS servant à chiffrer les données utilisateur.
  • ADMIN_USERS_LIST (facultatif) : liste des adresses e-mail des utilisateurs auxquels accorder des droits d'administrateur, séparées par une virgule, par exemple "kai@example.com,hao@example.com,kalani@example.com". Défini par défaut sur l'utilisateur qui crée le cluster.

S'il est présent, le paramètre --tags applique le tag AWS donné à toutes les ressources AWS sous-jacentes gérées par GKE sur AWS. Cet exemple ajoute un tag aux nœuds de votre plan de contrôle avec le nom du cluster auquel ils appartiennent.

Vous ne pourrez pas vous connecter en SSH à ces nœuds de plan de contrôle à moins de spécifier une paire de clés SSH avec l'option --ssh-ec2-key-pair.

Pour afficher toutes les versions de Kubernetes compatibles avec un emplacement Google Cloud donné, exécutez la commande suivante.

gcloud container aws get-server-config --location GCP_LOCATION

Autoriser Cloud Logging/Cloud Monitoring

Pour que GKE sur AWS puisse créer et importer des journaux système et des métriques dans Google Cloud, il doit être autorisé.

Pour autoriser l'identité de charge de travail Kubernetes gke-system/gke-telemetry-agent à écrire des journaux dans Google Cloud Logging et des métriques dans Google Cloud Monitoring, exécutez la commande suivante :

gcloud projects add-iam-policy-binding GOOGLE_PROJECT_ID \
  --member="serviceAccount:GOOGLE_PROJECT_ID.svc.id.goog[gke-system/gke-telemetry-agent]" \
  --role=roles/gkemulticloud.telemetryWriter

Remplacez GOOGLE_PROJECT_ID par l'ID de projet Google Cloud du cluster.

Cette liaison IAM permet à tous les clusters du projet du projet Google Cloud d'importer des journaux et des métriques. Vous ne devez l'exécuter qu'après avoir créé votre premier cluster pour le projet.

L'ajout de cette liaison IAM échouera, sauf si au moins un cluster a été créé dans votre projet Google Cloud. En effet, le pool d'identités de charge de travail auquel il fait référence (GOOGLE_PROJECT_ID.svc.id.goog) n'est pas provisionné avant la création du cluster.

Étapes suivantes