Créer un cluster

Cette page explique comment créer un cluster et un pool de nœuds dans GKE sur Azure sur Kubernetes version 1.29.3-gke.600.

Avant de commencer

Pour mettre en œuvre les étapes décrites sur cette page, procédez comme suit :

  1. Suivez la procédure décrite dans Configurer les prérequis.

  2. Déterminez si vous souhaitez exécuter le plan de contrôle dans plusieurs zones ou dans une seule zone.

  3. Sélectionnez les plages CIDR (classless inter-domain routing) à fournir à votre cluster.

Emplacement zonal du plan de contrôle

Par défaut, GKE sur Azure place les instances dupliquées de plan de contrôle distinctes dans le même sous-réseau sur trois zones de la région sélectionnée. Vous pouvez choisir ces zones et sous-réseaux.

Si vous souhaitez utiliser l'emplacement par défaut des instances de plan de contrôle dupliquées, passez à la section Sélectionner des plages CIDR pour votre cluster.

Passerelle Azure NAT et plans de contrôle de cluster

Chaque instance dupliquée du plan de contrôle nécessite également une connectivité au service de gestion hébergé par Google pour fonctionner à leur état normal.

Si vous utilisez la passerelle Azure NAT pour fournir une connectivité sortante, vous devez examiner les conséquences d'une défaillance de zone sur le plan de contrôle du cluster. Un point de terminaison de passerelle NAT est isolé vers une seule zone ou est régional/non zonal, ce qui représente un point de défaillance unique.

Si vous souhaitez placer les instances dupliquées du plan de contrôle dans une même zone, utilisez un seul sous-réseau et une seule zone. Si vous utilisez la passerelle NAT pour la connectivité sortante, assurez-vous que le point de terminaison est placé dans la même zone.

Si vous souhaitez placer des instances dupliquées dans deux ou trois zones, vous pouvez transmettre une liste de sous-réseaux et de zones lorsque vous créez un cluster. Lorsque vous transmettez deux sous-réseaux et zones, GKE sur Azure place deux instances dupliquées dans la première zone fournie. Quand vous passez dans trois sous-réseaux et zones, GKE sur Azure place des instances répliquées dans chaque sous-réseau. Pour en savoir plus, consultez la section Placer des instances dupliquées dans un sous-réseau spécifique.

Pour plus d'informations sur la configuration des sous-réseaux et des zones Azure pour la haute disponibilité, consultez la section Isolation de zones avec des piles zonales dans la documentation Azure.

Placer les instances dupliquées dans un sous-réseau spécifique

Cette rubrique est facultative.

Pour contrôler dans quelles zones les instances dupliquées du plan de contrôle sont placées, utilisez l'option --replica-placements et transmettez une liste d'ID de sous-réseaux et de zones lorsque vous créez votre cluster. Vous pouvez utiliser jusqu'à trois sous-réseaux et zones dans lesquels placer les instances dupliquées du plan de contrôle.

Pour formater la liste des sous-réseaux, procédez comme suit :

  1. Récupérez vos ID de sous-réseau Azure à l'aide de l'outil de ligne de commande az :

    az network vnet subnet show \
  --resource-group=VNET_RESOURCE_GROUP_NAME --vnet-name=VNET_NAME \
  --name SUBNET_NAME --query "id" -otsv

    Remplacez les éléments suivants :

    • CLUSTER_RESOURCE_GROUP_NAME : nom d'un groupe de ressources existant dans lequel vous souhaitez exécuter votre cluster
    • VNET_RESOURCE_GROUP_NAME : nom du groupe de ressources contenant le réseau VNet
    • VNET_NAME : nom de votre réseau VNet
    • SUBNET_NAME : nom de votre sous-réseau

    La sortie correspond à l'ID du sous-réseau. Les ID de sous-réseau Azure se présentent comme suit :

    /subscriptions/SUBSCRIPTION_ID/resourceGroups/RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/VNET_NAME/subnets/SUBNET_NAME

    Répétez cette commande pour chaque sous-réseau dans lequel vous souhaitez créer une instance dupliquée du plan de contrôle. Copiez les ID de sous-réseau dans un éditeur de texte pour l'étape suivante.

  2. Créez une liste d'ID de sous-réseau et de zones de disponibilité Azure séparés par des virgules, en délimitant la partie correspondant aux sous-réseaux et la partie correspondant aux zones par deux-points. Par exemple, pour créer des instances dupliquées du plan de contrôle dans subnet1 dans la zone 1, subnet2 dans la zone 2 et subnet3 dans la zone 3, utilisez la chaîne suivante :

    /subscriptions/SUBSCRIPTION_ID/resourceGroups/RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/VNET_NAME/subnets/subnet1:1,/subscriptions/SUBSCRIPTION_ID/resourceGroups/RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/VNET_NAME/subnets/subnet2:2,/subscriptions/SUBSCRIPTION_ID/resourceGroups/RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/VNET_NAME/subnets/subnet3:3

    Copiez cette chaîne et utilisez-la comme valeur pour l'option --replica-placements lorsque vous créez un cluster.

Sélectionner des plages CIDR pour votre cluster

Lorsque vous créez un cluster dans GKE sur Azure, 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 vous recommandons d'utiliser 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 problème.

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

Détails sur la sélection de plages

GKE sur Azure utilise un réseau superposé pour les pods et les services. Il n'est donc pas nécessaire que les plages d'adresses IP de ces réseaux soient routables au sein du VNet. 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 VNet, à 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 VNet.

Par exemple, voici une configuration valide car les réseaux de pods, de services et de nœuds ne se chevauchent pas (le VNet 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 VNet : 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 VNet, car il n'y a pas de chevauchement avec les instances dupliquées du plan de contrôle.

  • Réseau VNet : 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 VNet :

  • Réseau VNet : 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 les adresses aux objets Pod à partir 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 à communiquer aux services d'urgence

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'authentifier sur Azure

GKE sur Azure propose deux méthodes d'authentification à Azure : la fédération d'identité de charge de travail et la création d'un certificat client. L'authentification par fédération d'identité de charge de travail est la méthode recommandée, car elle est plus simple et plus sécurisée.

Fédération d'identité de charge de travail

La fédération des identifiants de charge de travail permet à GKE sur Azure de s'authentifier auprès d'Azure à l'aide d'un compte de service Google, afin de gérer les ressources dans l'application Azure AD. Contrairement à AzureClient, vous n'avez pas besoin de gérer les certificats ni de les importer manuellement dans Azure AD.

Pour configurer des identifiants d'identité fédérée sur votre application Azure AD, exécutez les commandes suivantes. Notez que vous pouvez ajouter jusqu'à vingt identifiants à chaque application Azure AD.

  1. Enregistrez votre ID d'application Azure dans des variables d'environnement :

    APPLICATION_ID=$(az ad app list --all \
  --query "[?displayName=='APPLICATION_NAME'].appId" --output tsv)
PROJECT_ID="$(gcloud config get-value project)"
PROJECT_NUMBER=$(gcloud projects describe "$PROJECT_ID" \
--format "value(projectNumber)")

  2. Créez un fichier JSON nommé credential.json.

    {
  "name": "CREDENTIAL_NAME",
  "issuer": "https://accounts.google.com",
  "subject": "service-PROJECT_NUMBER@gcp-sa-gkemulticloud.iam.gserviceaccount.com",
  "audiences": ["api://AzureADTokenExchange"],
  "description": "Allow GKE on Azure to authenticate to the Azure AD application using a Google service account."
}
    • CREDENTIAL_NAME : nom de l'identifiant.
    • PROJECT_NUMBER : numéro du projet Google Cloud qui héberge le cluster.

  3. Créez des identifiants d'identité fédérée sur l'application Azure AD :

    az ad app federated-credential create --id "${APPLICATION_ID}" --parameters credential.json

Pour en savoir plus, consultez la documentation Azure Fédération d'identité de charge de travail Azure AD avec Google Cloud.

Vous pouvez également provisionner les identifiants d'identité fédérée Azure à l'aide de Terraform. Pour en savoir plus, consultez azuread_application_federated_identity_credential.

Après avoir configuré les identifiants, créez ou sélectionnez une paire de clés SSH pour votre cluster.

Créer une paire de clés SSH

Lorsque vous créez un cluster, vous devez fournir une paire de clés SSH. Si vous disposez déjà d'une paire de clés, ignorez cette étape.

  1. Pour créer une paire de clés, utilisez l'outil de ligne de commande ssh-keygen :

    ssh-keygen -m PEM -t rsa -b 4096 -f KEY_PATH

    Remplacez KEY_PATH par le chemin d'accès à la nouvelle clé privée.

  2. Stockez la clé dans une variable d'environnement :

    SSH_PUBLIC_KEY=$(cat KEY_PATH.pub)

    Par exemple, pour créer une paire de clés à l'emplacement ~/.ssh/anthos-multicloud-key.pub et stocker la clé publique dans une variable d'environnement, exécutez les commandes suivantes :

    ssh-keygen -m PEM -t rsa -b 4096 -f ~/.ssh/anthos-multicloud-key
SSH_PUBLIC_KEY=$(cat ~/.ssh/anthos-multicloud-key.pub)

Une fois la clé publique enregistrée dans une variable d'environnement, vous êtes prêt à créer un cluster.

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 auprès d'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 Azure utilise le nom du cluster comme nom d'appartenance au parc, vous devez vous assurer que les noms de vos clusters sont uniques dans 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 un cluster

Pour créer un cluster, exécutez les commandes suivantes :

  1. Enregistrez vos ID de groupe de ressources Azure, de VNet et de sous-réseau dans des variables d'environnement :

    SUBSCRIPTION_ID=$(az account show --query "id" --output tsv)
TENANT_ID=$(az account list \
  --query "[?id=='${SUBSCRIPTION_ID}'].{tenantId:tenantId}" --output tsv)
CLUSTER_RG_ID=$(az group show --resource-group=CLUSTER_RESOURCE_GROUP_NAME \
  --query "id" -otsv)
VNET_ID=$(az network vnet show --resource-group=VNET_RESOURCE_GROUP_NAME \
  --name=VNET_NAME --query "id" -otsv)
SUBNET_ID=$(az network vnet subnet show \
  --resource-group=VNET_RESOURCE_GROUP_NAME --vnet-name=VNET_NAME \
  --name default --query "id" -otsv)

    Remplacez les éléments suivants :

    • CLUSTER_RESOURCE_GROUP_NAME : nom d'un groupe de ressources existant dans lequel vous souhaitez exécuter votre cluster
    • VNET_RESOURCE_GROUP_NAME : nom du groupe de ressources contenant le réseau VNet
    • VNET_NAME : nom de votre réseau VNet

  2. Créez un cluster avec Google Cloud CLI :

    Fédération d'identité de charge de travail

    gcloud container azure clusters create CLUSTER_NAME \
    --location GOOGLE_CLOUD_LOCATION \
    --fleet-project FLEET_PROJECT \
    --azure-tenant-id "${TENANT_ID}" \
    --azure-application-id "${APPLICATION_ID}" \
    --azure-region AZURE_REGION \
    --pod-address-cidr-blocks POD_CIDR \
    --service-address-cidr-blocks SERVICE_CIDR \
    --vm-size VM_SIZE \
    --cluster-version 1.29.3-gke.600 \
    --ssh-public-key "$SSH_PUBLIC_KEY" \
    --resource-group-id "$CLUSTER_RG_ID" \
    --vnet-id "$VNET_ID" \
    --subnet-id "$SUBNET_ID" # Optional, see following note \
    --tags "control-plane=CLUSTER_NAME" \
    --admin-users ADMIN_USERS_LIST

    Client Azure

    gcloud container azure clusters create CLUSTER_NAME \
    --location GOOGLE_CLOUD_LOCATION \
    --fleet-project FLEET_PROJECT \
    --client CLIENT_NAME \
    --azure-region AZURE_REGION \
    --pod-address-cidr-blocks POD_CIDR \
    --service-address-cidr-blocks SERVICE_CIDR \
    --vm-size VM_SIZE \
    --cluster-version 1.29.3-gke.600 \
    --ssh-public-key "$SSH_PUBLIC_KEY" \
    --resource-group-id "$CLUSTER_RG_ID" \
    --vnet-id "$VNET_ID" \
    --subnet-id "$SUBNET_ID" # Optional, see following note \
    --tags "control-plane=CLUSTER_NAME" \
    --admin-users ADMIN_USERS_LIST

    Remplacez les éléments suivants :

    • CLUSTER_NAME : nom du cluster
    • GOOGLE_CLOUD_LOCATION : zone Google Cloud qui gère votre cluster
    • FLEET_PROJECT par le 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.
    • AZURE_REGION : région Azure compatible associée à votre région Google Cloud
    • POD_CIDR : plage d'adresses des pods de votre cluster (par exemple, 10.0.1.0/18)
    • SERVICE_CIDR : plage d'adresses des services de votre cluster
    • VM_SIZE : taille de VM Azure compatible
    • 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.
    • CLIENT_NAME : nom de votre AzureClient.

  3. Vérifiez l'état de votre cluster :

    gcloud container azure clusters describe CLUSTER_NAME  --location GOOGLE_CLOUD_LOCATION

    Remplacez les éléments suivants :

    • CLUSTER_NAME
    • GOOGLE_CLOUD_LOCATION

    La sortie inclut des informations sur l'état et la configuration de votre cluster.

Autoriser Cloud Logging/Cloud Monitoring

Pour que GKE sur Azure 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 si vous n'avez pas créé au moins un cluster 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.

Créer un pool de nœuds

Avant de créer un pool de nœuds, vous avez besoin des éléments suivants :

  • Autorisations requises pour utiliser l'outil de ligne de commande az afin de récupérer un ID de sous-réseau Azure
  • Accès à la clé publique SSH du cluster

Pour créer un pool de nœuds, exécutez les commandes suivantes :

  1. Enregistrez votre ID de sous-réseau Azure VNet et votre clé publique SSH dans des variables d'environnement :

    SUBNET_ID=$(az network vnet subnet show \
  --resource-group=VNET_RESOURCE_GROUP_NAME --vnet-name=VNET_NAME \
  --name default --query "id" -otsv)
SSH_PUBLIC_KEY=$(cat KEY_PATH.pub)

    Remplacez les éléments suivants :

    • VNET_RESOURCE_GROUP_NAME : nom du groupe de ressources contenant le réseau VNet
    • VNET_NAME : nom de votre réseau VNet
    • KEY_PATH : chemin d'accès à votre paire de clés

  2. Créez un pool de nœuds à l'aide de Google Cloud CLI :

    gcloud container azure node-pools create NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --location GOOGLE_CLOUD_LOCATION \
    --node-version 1.29.3-gke.600 \
    --vm-size VM_SIZE \
    --max-pods-per-node 110 \
    --min-nodes MIN_NODES \
    --max-nodes MAX_NODES \
    --ssh-public-key "${SSH_PUBLIC_KEY}" \
    --subnet-id "${SUBNET_ID}"

    Remplacez les éléments suivants :

    • NODE_POOL_NAME : nom unique du pool de nœuds, par exemple node-pool-1
    • CLUSTER_NAME : nom de votre cluster GKE sur Azure.
    • GOOGLE_CLOUD_LOCATION : zone Google Cloud qui gère votre cluster
    • VM_SIZE : taille de VM Azure compatible
    • MIN_NODES : nombre minimal de nœuds dans le pool de nœuds. Pour plus d'informations, consultez la section Autoscaler de cluster.
    • MAX_NODES : nombre maximal de nœuds dans le pool de nœuds

  3. Vérifiez l'état de votre pool de nœuds :

    gcloud container azure node-pools describe NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --location GOOGLE_CLOUD_LOCATION

    Remplacez les éléments suivants :

    • NODE_POOL_NAME : nom unique du pool de nœuds, par exemple node-pool-1
    • CLUSTER_NAME : nom de votre cluster GKE sur Azure.
    • GOOGLE_CLOUD_LOCATION : zone Google Cloud qui gère votre cluster

    Le résultat inclut l'état de votre pool de nœuds, y compris s'il s'agit de PROVISIONING ou de RUNNING.

Étape suivante