Créer un cluster d'utilisateur

gkectl

Présentation de la procédure

Voici les principales étapes à suivre pour créer un cluster d'utilisateur à l'aide de gkectl:

1. Se connecter au poste de travail administrateur

   Le poste de travail administrateur est une VM disposant des outils nécessaires pour créer un cluster d'utilisateur.

2. Remplir vos fichiers de configuration

   Spécifiez les détails de votre nouveau cluster en remplissant un fichier de configuration du cluster d'utilisateur, un fichier de configuration des identifiants et éventuellement un fichier de bloc d'adresses IP.

3. (Facultatif) Importez des images d'OS dans vSphere et transférez des images de conteneurs vers le registre privé, le cas échéant.

   Exécutez gkectl prepare.

4. Créer un cluster d'utilisateur

   Exécutez gkectl create cluster pour créer un cluster comme spécifié dans votre fichier de configuration.

5. Vérifier que votre cluster d'utilisateur est en cours d'exécution

   Utilisez kubectl pour afficher les nœuds de votre cluster.

À la fin de cette procédure, vous disposerez d'un cluster d'utilisateur en cours d'exécution dans lequel vous pourrez déployer vos charges de travail.

Si vous utilisez VPC Service Controls, des erreurs peuvent s'afficher lorsque vous exécutez certaines commandes gkectl, telles que "Validation Category: GCP - [UNKNOWN] GCP service: [Stackdriver] could not get GCP services". Pour éviter ces erreurs, ajoutez le paramètre --skip-validation-gcp à vos commandes.

Remplir vos fichiers de configuration

Procédez comme suit sur votre poste de travail administrateur.

Lorsque gkeadm a créé votre poste de travail administrateur, il a généré un fichier de configuration nommé user-cluster.yaml. Ce fichier de configuration vous permet de créer votre cluster d'utilisateur.

Familiarisez-vous avec le fichier de configuration en analysant le fichier de configuration du cluster d'utilisateur. Nous vous recommandons de conserver ce document ouvert dans un nouvel onglet ou dans une autre fenêtre, car vous en aurez besoin pour réaliser les étapes suivantes.

name

Saisissez le nom de votre choix pour le cluster d'utilisateur dans le champ name.

gkeOnPremVersion

Ce champ est déjà renseigné. Il spécifie la version de Google Distributed Cloud. Par exemple, 1.30.100-gke.96.

enableControlplaneV2

Pour créer un cluster d'utilisateur avec Controlplane V2 activé, définissez enableControlplaneV2 sur true.

Lorsque Controlplane V2 est activé, le plan de contrôle du cluster d'utilisateur s'exécute sur les nœuds du cluster d'utilisateur lui-même. Nous vous recommandons d'activer Controlplane V2.

kubeception

Si vous définissez ce champ sur false, le cluster utilisera kubeception. Avec kubeception, le plan de contrôle du cluster d'utilisateur s'exécute sur les nœuds du cluster d'administrateur.

Pour un cluster kubeception :

• Définissez enableControlplaneV2 sur false.

• Ne remplissez pas la section controlPlaneIPBlock.

• Spécifiez les adresses IP des nœuds du plan de contrôle du cluster d'utilisateur dans le fichier de bloc d'adresses IP du cluster d'administrateur.

enableDataplaneV2

Définissez enableDataplaneV2 sur true.

vCenter

Les valeurs définies dans la section vCenter du fichier de configuration du cluster d'administrateur sont globales. Autrement dit, elles s'appliquent au cluster d'administrateur et aux clusters d'utilisateur.

Pour chaque cluster d'utilisateur que vous créez, vous avez la possibilité de remplacer certaines des valeurs vCenter globales.

Pour remplacer l'une des valeurs vCenter globales, renseignez les champs appropriés dans la section vCenter du fichier de configuration de votre cluster d'utilisateur.

Vous pouvez par exemple utiliser des clusters vSphere distincts pour votre cluster d'administrateur et vos clusters d'utilisateur, ainsi que des centres de données distincts pour votre cluster d'administrateur et vos clusters d'utilisateur.

Utiliser un centre de données et un cluster vSphere

L'option par défaut consiste à utiliser un centre de données et un cluster vSphere pour le cluster d'administrateur et le cluster d'utilisateur. Pour cette option, ne définissez aucune valeur vCenter dans le fichier de configuration du cluster d'utilisateur. Les valeurs vCenter seront héritées du cluster d'administrateur.

Utiliser des clusters vSphere distincts

Si vous souhaitez créer un cluster d'utilisateur dans son propre cluster vSphere, spécifiez une valeur pour vCenter.cluster dans le fichier de configuration du cluster d'utilisateur.

Si votre cluster d'administrateur et votre cluster d'utilisateur se trouvent dans des clusters vSphere distincts, ils peuvent se trouver dans le même centre de données ou dans des centres de données différents.

Utiliser des centres de données vSphere distincts

Le cluster d'utilisateur et le cluster d'administrateur peuvent se trouver dans différents centres de données. Dans ce cas, ils se trouvent également dans des clusters vSphere distincts.

Si vous spécifiez vCenter.datacenter dans le fichier de configuration du cluster d'utilisateur, vous devez également spécifier :

• vCenter.networkName
• vCenter.datastore ou vCenter.storagePolicyName
• vCenter.cluster ou vCenter.resourcePool

Utiliser des comptes vCenter distincts

Un cluster d'utilisateur peut utiliser un autre compte vCenter que celui du cluster d'administrateur, avec un champ vCenter.credentials différent. Le compte vCenter du cluster d'administrateur doit avoir accès au centre de données du cluster d'administrateur, tandis que le compte vCenter destiné au cluster d'utilisateur n'a besoin que d'accéder au centre de données du cluster d'utilisateur.

Utiliser des instances distinctes de vCenter Server

Dans certains cas, il est judicieux de créer un cluster d'utilisateur qui utilise sa propre instance de vCenter Server. Autrement dit, le cluster d'administrateur et un cluster d'utilisateur associé utilisent des instances différentes de vCenter Server.

Par exemple, dans un emplacement périphérique, vous pouvez avoir une machine physique exécutant vCenter Server et une ou plusieurs machines physiques exécutant ESXi. Vous pouvez ensuite utiliser votre instance locale de vCenter Server pour créer une hiérarchie d'objets vSphere, y compris des centres de données, des clusters, des pools de ressources, des datastores et des dossiers.

Remplissez la section vCenter du fichier de configuration de votre cluster d'utilisateur. En particulier, spécifiez pour vCenter.address une valeur différente de l'adresse du serveur vCenter spécifiée dans le fichier de configuration du cluster d'administrateur. Exemple :

vCenter:
  address: "vc-edge.example"
  datacenter: "vc-edge"
  cluster: "vc-edge-workloads"
  resourcePool: "vc-edge-pool
  datastore: "vc-edge-datastore
  caCertPath: "/usr/local/google/home/me/certs/edge-cacert.pem"
  credentials:
    fileRef:
      path: "credential.yaml"
      entry: "vCenter-edge"
  folder: "edge-vm-folder"

Renseignez également le champ network.vCenter.networkName.

network

Décidez comment vous souhaitez que vos nœuds de calcul obtiennent leurs adresses IP. Vous disposez des options suivantes :

• Depuis un serveur DHCP que vous avez configuré à l'avance. Définissez network.ipMode.type sur "dhcp".

• À partir d'une liste d'adresses IP statiques que vous fournissez. Définissez network.ipMode.type sur "static", puis créez un fichier de bloc d'adresses IP qui fournit les adresses IP statiques. Pour obtenir un exemple de fichier de bloc d'adresses IP, consultez la section Exemple de fichiers de configuration renseignés.

Si vous avez décidé d'utiliser des adresses IP statiques pour vos nœuds de calcul, renseignez le champ network.ipMode.ipBlockFilePath.

Les nœuds du plan de contrôle pour votre cluster d'utilisateur doivent obtenir leurs adresses IP à partir d'une liste d'adresses statiques que vous fournissez. C'est le cas même si vos nœuds de calcul obtiennent leurs adresses à partir d'un serveur DHCP. Pour spécifier des adresses IP statiques pour vos nœuds de plan de contrôle, renseignez la section network.controlPlaneIPBlock. Si vous souhaitez un cluster d'utilisateur à haute disponibilité, spécifiez trois adresses IP. Sinon, spécifiez une seule adresse IP.

Spécifiez les serveurs DNS et NTP en remplissant la section hostConfig. Ces serveurs DNS et NTP sont destinés aux nœuds du plan de contrôle. Si vous utilisez des adresses IP statiques pour vos nœuds de calcul, ces serveurs DNS et NTP sont également destinés aux nœuds de calcul.

Les champs network.podCIDR et network.serviceCIDR sont préremplis avec des valeurs que vous pouvez laisser inchangées, sauf si elles entrent en conflit avec des adresses déjà utilisées sur votre réseau. Kubernetes utilise ces plages pour attribuer des adresses IP aux pods et aux services de votre cluster.

Que vous utilisiez un serveur DHCP ou que vous spécifiiez une liste d'adresses IP statiques, vous devez disposer de suffisamment d'adresses IP disponibles pour votre cluster d'utilisateur. Pour connaître le nombre d'adresses IP dont vous avez besoin, consultez la section Planifier vos adresses IP.

loadBalancer

Définissez une adresse IP virtuelle pour le serveur d'API Kubernetes de votre cluster d'utilisateur. Définissez-en une autre pour le service d'entrée de votre cluster d'utilisateur. Indiquez vos adresses IP virtuelles comme valeurs pour loadBalancer.vips.controlPlaneVIP et loadBalancer.vips.ingressVIP.

Choisissez le type d'équilibrage de charge que vous souhaitez utiliser. Vous disposez des options suivantes :

• Équilibrage de charge groupé MetalLB. Définissez loadBalancer.kind sur "MetalLB". Renseignez également la section loadBalancer.metalLB.addressPools, puis définissez enableLoadBalancer sur true pour au moins l'un de vos pools de nœuds. Pour en savoir plus, consultez la page Équilibrage de charge groupé avec MetalLB.

• Équilibrage de charge manuel. Définissez loadBalancer.kind sur "ManualLB", puis remplissez la section manualLB. Pour en savoir plus, consultez la page sur l'équilibrage de charge manuel.

Pour en savoir plus sur les options d'équilibrage de charge, consultez la page Présentation de l'équilibrage de charge.

advancedNetworking

Si vous envisagez de créer une passerelle NAT de sortie, définissez advancedNetworking sur true.

multipleNetworkInterfaces

Décidez si vous souhaitez configurer plusieurs interfaces réseau pour les pods et définissez multipleNetworkInterfaces en conséquence.

storage

Si vous souhaitez désactiver le déploiement des composants CSI vSphere, définissez storage.vSphereCSIDisabled sur true.

masterNode

Dans la section masterNode, vous pouvez spécifier le nombre de nœuds de plan de contrôle souhaités pour votre cluster d'utilisateur : un ou trois. Vous pouvez également spécifier un datastore pour les nœuds du plan de contrôle et si vous souhaitez activer le redimensionnement automatique des nœuds.

Rappelez-vous que vous avez spécifié des adresses IP pour les nœuds du plan de contrôle dans la section network.controlPlaneIPBlock.

nodePools

Un pool de nœuds est un groupe de nœuds au sein d'un cluster qui possèdent tous la même configuration. Par exemple, les nœuds d'un pool peuvent exécuter Windows et les nœuds d'un autre pool peuvent exécuter Linux.

Vous devez spécifier au moins un pool de nœuds en remplissant la section nodePools.

Pour en savoir plus, consultez les pages Pools de nœuds et Créer et gérer des pools de nœuds.

antiAffinityGroups

Définissez antiAffinityGroups.enabled sur true ou false.

Ce champ indique si Google Distributed Cloud crée des règles d'anti-affinité DRS (Distributed Resource Scheduler) pour vos nœuds de calcul, avec pour effet de les répartir sur au moins trois hôtes physiques de votre centre de données.

stackdriver

Si vous souhaitez activer Cloud Logging et Cloud Monitoring pour votre cluster, renseignez la section stackdriver.

Cette section est obligatoire par défaut. Autrement dit, si vous ne remplissez pas cette section, vous devez inclure l'option --skip-validation-stackdriver lorsque vous exécutez gkectl create cluster.

Notez les exigences suivantes pour les nouveaux clusters :

• L'ID dans stackdriver.projectID doit être identique à celui dans gkeConnect.projectID et cloudAuditLogging.projectID.

• La région Google Cloud définie dans stackdriver.clusterLocation doit être identique à celle définie dans cloudAuditLogging.clusterLocation et gkeConnect.location (si le champ est inclus dans votre fichier de configuration). De plus, si gkeOnPremAPI.enabled est true, la même région doit être définie dans gkeOnPremAPI.location.

Si les ID et les régions des projets ne sont pas identiques, la création du cluster échoue.

gkeConnect

Votre cluster d'utilisateur doit être enregistré dans un parc Google Cloud.

Renseignez la section gkeConnect pour spécifier un projet hôte du parc et un compte de service associé. L'ID dans gkeConnect.projectID doit être identique à celui défini dans stackdriver.projectID et cloudAuditLogging.projectID. Si les ID de projet ne sont pas identiques, la création du cluster échoue.

Dans les versions 1.28 et ultérieures, vous pouvez éventuellement spécifier une région dans laquelle les services Fleet et Connect s'exécutent dans gkeConnect.location. Si vous n'incluez pas ce champ, le cluster utilise les instances globales de ces services.

Si vous incluez gkeConnect.location dans votre fichier de configuration, la région que vous spécifiez doit être identique à celle configurée dans cloudAuditLogging.clusterLocation, stackdriver.clusterLocation et gkeOnPremAPI.location. Si les régions ne sont pas identiques, la création du cluster échoue.

gkeOnPremAPI

Dans les versions 1.16 et ultérieures, si l'API GKE On-Prem est activée dans votre projet Google Cloud, tous les clusters du projet sont automatiquement enregistrés dans l'API GKE On-Prem dans la région configurée dans stackdriver.clusterLocation. La région gkeOnPremAPI.location doit être identique à celle spécifiée dans cloudAuditLogging.clusterLocation, gkeConnect.location (si le champ est inclus dans votre fichier de configuration) et stackdriver.clusterLocation.

• Si vous souhaitez enregistrer tous les clusters du projet dans l'API GKE On-Prem, veillez à suivre les étapes de la section Avant de commencer pour activer et utiliser l'API GKE On-Prem dans le projet.

• Si vous ne souhaitez pas enregistrer le cluster dans l'API GKE On-Prem, incluez cette section et définissez gkeOnPremAPI.enabled sur false. Si vous ne souhaitez enregistrer aucun cluster dans le projet, désactivez gkeonprem.googleapis.com (nom de service de l'API GKE On-Prem) dans le projet. Pour obtenir des instructions, consultez la section Désactiver des services.

usageMetering

Si vous souhaitez activer la mesure de l'utilisation de votre cluster, renseignez la section usageMetering.

cloudAuditLogging

Si vous souhaitez intégrer les journaux d'audit du serveur d'API Kubernetes de votre cluster avec Cloud Audit Logs, remplissez la section cloudAuditLogging.

Notez les exigences suivantes pour les nouveaux clusters :

• L'ID dans cloudAuditLogging.projectID doit être identique à celui dans gkeConnect.projectID et stackdriver.projectID.

• La région dans cloudAuditLogging.clusterLocation doit être identique à celle définie dans gkeConnect.location (si le champ est inclus dans votre fichier de configuration) et stackdriver.clusterLocation. De plus, si gkeOnPremAPI.enabled est défini sur true, la même région doit être définie dans gkeOnPremAPI.location.

Si les ID et les régions des projets ne sont pas identiques, la création du cluster échoue.

Exemple de fichiers de configuration préremplis

Voici un exemple de fichier de bloc d'adresses IP et de fichier de configuration de cluster d'utilisateur :

user-ipblock.yaml

blocks:
  - netmask: 255.255.255.0
    gateway: 172.16.21.1
    ips:
    - ip: 172.16.21.2
      hostname: worker-vm-1
    - ip: 172.16.21.3
      hostname: worker-vm-2
    - ip: 172.16.21.4
      hostname: worker-vm-3
    - ip: 172.16.21.5
      hostname: worker-vm-4

user-cluster.yaml

cat user-cluster.yaml
apiVersion: v1
kind: UserCluster
name: "my-user-cluster"
gkeOnPremVersion: 1.30.100-gke.96
enableControlplaneV2: true
enableDataplaneV2: true
network:
  hostConfig:
    dnsServers:
    - "203.0.113.2"
    - "198.51.100.2"
    ntpServers:
    - "216.239.35.4"
  ipMode:
    type: "static"
    ipBlockFilePath: "user-ipblock.yaml"
  serviceCIDR: 10.96.0.0/20
  podCIDR: 192.168.0.0/16
  controlPlaneIPBlock:
    netmask: "255.255.255.0"
    gateway: "172.16.21.1"
    ips:
    - ip: "172.16.21.6"
      hostname: "cp-vm-1"
    - ip: "172.16.21.7"
      hostname: "cp-vm-2"
    - ip: "172.16.21.8"
      hostname: "cp-vm-3"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.21.40"
    ingressVIP: "172.16.21.30"
  kind: MetalLB
  metalLB:
    addressPools:
    - name: "address-pool-1"
      addresses:
      - "172.16.21.30-172.16.21.39"
masterNode:
  cpus: 4
  memoryMB: 8192
  replicas: 3
nodePools:
- name: "worker-node-pool"
  cpus: 4
  memoryMB: 8192
  replicas: 3
  enableLoadBalancer: true
antiAffinityGroups:
  enabled: true
gkeConnect:
  projectID: "my-project-123"
  location: "us-central1"
  registerServiceAccountKeyPath: "connect-register-sa-2203040617.json"
stackdriver:
  projectID: "my-project-123"
  clusterLocation: "us-central1"
  enableVPC: false
  serviceAccountKeyPath: "log-mon-sa-2203040617.json"
autoRepair:
  enabled: true

Voici les points importants à comprendre dans l'exemple précédent :

• Les adresses IP statiques des nœuds de calcul sont spécifiées dans un fichier de bloc d'adresses IP. Le fichier de blocs d'adresses IP comporte quatre adresses, même s'il n'y a que trois nœuds de calcul. L'adresse IP supplémentaire est nécessaire lors de la mise à niveau, de la mise à jour et de la réparation automatique du cluster.

• Les serveurs DNS et NTP sont spécifiés dans la section hostConfig. Dans cet exemple, ces serveurs DNS et NTP sont destinés aux nœuds du plan de contrôle et aux nœuds de calcul. En effet, les nœuds de calcul ont des adresses IP statiques. Si les nœuds de calcul devaient obtenir leurs adresses IP à partir d'un serveur DHCP, ces serveurs DNS et NTP ne seraient destinés qu'aux nœuds du plan de contrôle.

• Les adresses IP statiques des trois nœuds de plan de contrôle sont spécifiées dans la section network.controlPlaneIPBlock du fichier de configuration du cluster d'utilisateur. Aucune adresse IP supplémentaire n'est nécessaire dans ce bloc.

• Controlplane V2 est activé.

• Le champ masterNode.replicas est défini sur 3. Le cluster dispose donc d'un plan de contrôle à haute disponibilité.

• L'adresse IP virtuelle du plan de contrôle et l'adresse IP virtuelle d'entrée se trouvent dans le même VLAN que les nœuds de calcul et les nœuds du plan de contrôle.

• Les adresses IP virtuelles réservées pour les services de type LoadBalancer sont spécifiées dans la section loadBalancer.metalLB.addressPools du fichier de configuration du cluster d'utilisateur. Ces adresses IP virtuelles se trouvent sur le même VLAN que les nœuds de calcul et les nœuds du plan de contrôle. L'ensemble des adresses IP virtuelles spécifiées dans cette section doit inclure l'adresse IP virtuelle d'entrée et ne doit pas inclure l'adresse IP virtuelle du plan de contrôle.

• Le fichier de configuration du cluster d'utilisateur n'inclut pas de section vCenter. Le cluster d'utilisateur utilise donc les mêmes ressources vSphere que le cluster d'administrateur.

Valider votre fichier de configuration

Une fois que vous avez rempli le fichier de configuration du cluster d'utilisateur, exécutez gkectl check-config pour vérifier que le fichier est valide :

gkectl check-config --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Remplacez les éléments suivants :

• ADMIN_CLUSTER_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur.

• USER_CLUSTER_CONFIG : chemin d'accès au fichier de configuration du cluster d'utilisateur

Si la commande renvoie des messages d'échec, corrigez les problèmes et validez à nouveau le fichier.

Si vous souhaitez ignorer les validations les plus longues, transmettez l'option --fast. Pour ignorer des validations individuelles, utilisez les options --skip-validation-xxx. Pour en savoir plus sur la commande check-config, consultez la page Exécuter des vérifications préliminaires.

3. (Facultatif) Importez des images d'OS dans vSphere et transférez des images de conteneurs vers un registre privé

Exécutez gkectl prepare si l'une des conditions suivantes est remplie :

• Votre cluster d'utilisateur se trouve dans un centre de données vSphere différent de celui de votre cluster d'administrateur.

• Votre cluster d'utilisateur dispose d'un vCenter Server différent de celui de votre cluster d'administrateur.

• Votre cluster d'utilisateur utilise un registre de conteneurs privé différent de celui utilisé par votre cluster d'administrateur.

gkectl prepare --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --bundle-path BUNDLE \
    --user-cluster-config USER_CLUSTER_CONFIG

Remplacez les éléments suivants :

• ADMIN_CLUSTER_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur

• BUNDLE : chemin d'accès au fichier de bundle. Ce fichier se trouve sur votre poste de travail administrateur, dans /var/lib/gke/bundles/. Exemple :

  /var/lib/gke/bundles/gke-onprem-vsphere-1.30.100-gke.96-full.tgz
  

• USER_CLUSTER_CONFIG : chemin d'accès au fichier de configuration du cluster d'utilisateur

4. Créer un cluster d'utilisateur

Créez un cluster d'utilisateur :

gkectl create cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG 

Si vous utilisez VPC Service Controls, des erreurs peuvent s'afficher lorsque vous exécutez certaines commandes gkectl, telles que "Validation Category: GCP - [UNKNOWN] GCP service: [Stackdriver] could not get GCP services". Pour éviter ces erreurs, ajoutez le paramètre --skip-validation-gcp à vos commandes.

Localiser le fichier kubeconfig du cluster d'utilisateur

La commande gkectl create cluster crée un fichier kubeconfig nommé USER_CLUSTER_NAME-kubeconfig dans le répertoire actuel. Vous aurez besoin de ce fichier kubeconfig ultérieurement pour interagir avec votre cluster d'utilisateur.

Le fichier kubeconfig contient le nom de votre cluster d'utilisateur. Pour afficher le nom du cluster, vous pouvez exécuter la commande suivante :

kubectl config get-clusters --kubeconfig USER_CLUSTER_KUBECONFIG

La sortie affiche le nom du cluster. Exemple :

NAME
my-user-cluster

Si vous le souhaitez, vous pouvez modifier le nom et l'emplacement de votre fichier kubeconfig.

5. Vérifier que votre cluster d'utilisateur est en cours d'exécution

Vérifiez que votre cluster d'utilisateur est en cours d'exécution :

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG

Remplacez USER_CLUSTER_KUBECONFIG par le chemin d'accès du fichier kubeconfig de votre cluster d'utilisateur.

Le résultat affiche les nœuds du cluster d'utilisateur. Exemple :

cp-vm-1       Ready    control-plane,master   18m
cp-vm-2       Ready    control-plane,master   18m
cp-vm-3       Ready    control-plane,master   18m
worker-vm-1   Ready                           6m7s
worker-vm-2   Ready                           6m6s
worker-vm-3   Ready                           6m14s

Console

Commencer

1. Dans la console Google Cloud, accédez à la page Créer un cluster Google Distributed Cloud.

   Accéder à la page Créer un cluster Google Distributed Cloud

2. Sélectionnez le projet Google Cloud dans lequel vous souhaitez créer le cluster. Le projet sélectionné est également utilisé comme projet hôte du parc. Il doit s'agir du même projet que celui dans lequel le cluster d'administrateur est enregistré. Une fois le cluster d'utilisateur créé, il est automatiquement enregistré dans le parc du projet sélectionné.

Paramètres de base du cluster

Saisissez les informations de base sur le cluster.

1. Saisissez un nom pour le cluster d'utilisateur.

2. Sous Cluster d'administrateur, sélectionnez le cluster d'administrateur dans la liste. Si vous n'avez pas spécifié de nom pour le cluster d'administrateur lors de sa création, le nom est généré au format gke-admin-[HASH]. Si vous ne connaissez pas le nom du cluster d'administrateur, exécutez la commande suivante sur votre poste de travail administrateur :

   KUBECONFIG=ADMIN_CLUSTER_KUBECONFIG
   kubectl get OnPremAdminCluster -n kube-system -o=jsonpath='{.items[0].metadata.name}'
   

   Si le cluster d'administrateur que vous souhaitez utiliser ne s'affiche pas, consultez la section de dépannage Le cluster d'administrateur ne s'affiche pas dans la liste déroulante Paramètres de base du cluster.

3. Dans le champ emplacement de l'API GCP, sélectionnez la région Google Cloud dans la liste. Ce paramètre spécifie la région dans laquelle les API et les services suivants s'exécutent :

   • API GKE On-Prem (gkeonprem.googleapis.com)
   • Service de parc (gkehub.googleapis.com)
   • Connecter le service (gkeconnect.googleapis.com)

   Ce paramètre contrôle également la région dans laquelle les éléments suivants sont stockés :

   • Métadonnées du cluster d'utilisateur dont l'API GKE On-Prem a besoin pour gérer le cycle de vie du cluster
   • Données Cloud Logging et Cloud Monitoring des composants système
   • Journal d'audit d'administrateur créé par Cloud Audit Logs

   Le nom, le projet et l'emplacement du cluster permettent de l'identifier de manière unique dans Google Cloud.

4. Sélectionnez la version de Google Distributed Cloud pour votre cluster d'utilisateur.

5. En tant que créateur du cluster, vous disposez des droits d'administrateur du cluster. Si vous le souhaitez, saisissez l'adresse e-mail d'un autre utilisateur qui administrera le cluster dans le champ Utilisateur administrateur du cluster de la section Autorisation.

   Une fois le cluster créé, l'API GKE On-Prem applique les stratégies de contrôle d'accès basé sur les rôles (RBAC) Kubernetes au cluster afin de vous accorder, à vous et aux autres administrateurs, le rôle Kubernetes clusterrole/cluster-admin, qui fournit un accès complet à chaque ressource du cluster dans tous les espaces de noms.

6. Cliquez sur Suivant pour accéder à la section Plan de contrôle.

Plan de contrôle

Tous les champs de la section Plan de contrôle sont définis avec des valeurs par défaut. Examinez les valeurs par défaut et modifiez-les si nécessaire.

1. Dans le champ Processeurs virtuels des nœuds de plan de contrôle, saisissez le nombre de processeurs virtuels (4 au minimum) pour chaque nœud de plan de contrôle de votre cluster d'utilisateur.

2. Dans le champ Mémoire des nœuds de plan de contrôle, saisissez la taille de la mémoire en Mio (minimum 8192 et doit être un multiple de 4) pour chaque plan de contrôle de votre cluster d'utilisateur.

3. Sous Nœuds du plan de contrôle, sélectionnez le nombre de nœuds du plan de contrôle pour votre cluster d'utilisateur. Par exemple, vous pouvez utiliser un seul nœud de plan de contrôle pour un environnement de développement et trois nœuds de plan de contrôle pour les environnements de production et la haute disponibilité.

4. Si vous le souhaitez, sélectionnez Redimensionnement automatique des nœuds. Le redimensionnement signifie que les ressources de vCPU et de mémoire attribuées à un nœud sont ajustées automatiquement. Lorsque cette option est activée, les nœuds du plan de contrôle du cluster d'utilisateur sont redimensionnés en fonction du nombre de nœuds de calcul du cluster d'utilisateur. Ainsi, à mesure que vous ajoutez des nœuds de calcul au cluster d'utilisateur, la taille des nœuds du plan de contrôle est augmentée.

5. Si vous le souhaitez, sélectionnez Activer le plan de contrôle v2. L'activation de Controlplane V2 signifie que le plan de contrôle d'un cluster d'utilisateur s'exécute sur un ou plusieurs nœuds du cluster d'utilisateur lui-même plutôt que dans le cluster d'administrateur (appelé kubeception).

   Lorsque vous sélectionnez Activer le plan de contrôle v2, la section IP des nœuds du plan de contrôle s'affiche. Saisissez l'adresse IP de la passerelle, le masque de sous-réseau et les adresses IP des nœuds du plan de contrôle.

   Lorsque Controlplane V2 est activé, les champs "vCPU" et "Mémoire" s'appliquent aux nœuds du plan de contrôle du cluster d'utilisateur. Le nombre de nœuds est déterminé par le nombre d'adresses IP que vous saisissez. Lorsque Controlplane V2 n'est pas activé, les champs "vCPU", "Mémoire" et "Nombre de nœuds du plan de contrôle" s'appliquent aux nœuds du cluster d'administrateur. Assurez-vous de réserver suffisamment d'adresses IP pour votre cluster d'administrateur.

6. Cliquez sur Continuer pour accéder à la section Mise en réseau.

Mise en réseau

Dans cette section, vous spécifiez les adresses IP des nœuds, des pods et des services de votre cluster. Un cluster d'utilisateur doit disposer d'une adresse IP pour chaque nœud et d'une adresse IP supplémentaire pour un nœud temporaire nécessaire lors des mises à niveau, des mises à jour et de la réparation automatique du cluster. Pour en savoir plus, consultez la section De combien d'adresses IP un cluster d'utilisateur a-t-il besoin ?.

1. Dans la section Adresses IP des nœuds, sélectionnez le mode d'adresse IP du cluster d'utilisateur. Sélectionnez l'une des options suivantes :

   • DHCP : sélectionnez DHCP si vous souhaitez que les nœuds de votre cluster obtiennent leur adresse IP à partir d'un serveur DHCP.

   • Statique : sélectionnez Statique si vous souhaitez fournir des adresses IP statiques pour vos nœuds de cluster ou si vous souhaitez configurer l'équilibrage de charge manuel.

2. Si vous avez sélectionné DHCP, passez à l'étape suivante pour spécifier les plages CIDR de service et de pod. Dans le champ Mode IP statique, indiquez les informations suivantes :

   1. Saisissez l'adresse IP de la passerelle du cluster d'utilisateur.

   2. Saisissez le masque de sous-réseau pour les nœuds de cluster d'utilisateur.

   3. Dans la section Adresses IP, saisissez les adresses IP et, éventuellement, les noms d'hôte des nœuds du cluster d'utilisateur. Vous pouvez saisir une adresse IP individuelle v4 (telle que 192.0.2.1) ou un bloc CIDR d'adresses IPv4 (par exemple, 192.0.2.0/24).

      • Si vous saisissez un bloc CIDR, ne saisissez pas de nom d'hôte.

      • Si vous saisissez une adresse IP individuelle, vous pouvez éventuellement saisir un nom d'hôte. Si vous ne saisissez pas de nom d'hôte, Google Distributed Cloud utilise le nom de la VM dans vSphere comme nom d'hôte.

   4. Cliquez sur + Ajouter une adresse IP si nécessaire pour saisir d'autres adresses IP.

3. Dans la section plages CIDR des services et des pods, la console fournit les plages d'adresses suivantes pour vos services et pods Kubernetes :

   • CIDR des services : 10.96.0.0/20
   • CIDR des pods : 192.168.0.0/16

   Si vous préférez saisir vos propres plages d'adresses, consultez la section Adresses IP pour les pods et les services pour connaître les bonnes pratiques.

4. Si vous avez sélectionné Mode d'adresse IP statique ou Activer le plan de contrôle v2, spécifiez les informations suivantes dans la section Configuration de l'hôte:

   1. Saisissez les adresses IP des serveurs DNS.
   2. Saisissez les adresses IP des serveurs NTP.
   3. Vous pouvez éventuellement saisir des domaines de recherche DNS.

5. Cliquez sur Suivant pour accéder à la section Équilibreur de charge.

Équilibreur de charge

Choisissez l'équilibreur de charge à configurer pour votre cluster. Pour en savoir plus, consultez la page Présentation de l'équilibreur de charge.

Sélectionnez le type d'équilibreur de charge dans la liste.

Fonctionnalités

Cette section présente les fonctionnalités et les opérations activées sur le cluster.

1. Les éléments suivants sont activés automatiquement et ne peuvent pas être désactivés :

   • Cloud Logging pour les services système

   • Cloud Monitoring pour les services système

   • Journal d'audit pour les activités d'administration

2. Les éléments suivants sont activés par défaut, mais vous pouvez les désactiver :

   • Activer le pilote CSI vSphere : également appelé plug-in de stockage de conteneurs vSphere. Le pilote CSI (Container Storage Interface) s'exécute dans un cluster Kubernetes déployé dans vSphere pour provisionner des volumes persistants sur l'espace de stockage vSphere. Pour en savoir plus, consultez la page Utiliser le pilote Container Storage Interface (CSI) de vSphere.

   • Activer les groupes d'anti-affinité : les règles d'anti-affinité VMware Distributed Resource Scheduler (DRS) sont automatiquement créées pour les nœuds de votre cluster d'utilisateur, avec pour effet de les répartir sur au moins trois hôtes physiques dans votre centre de données. Assurez-vous que votre environnement vSphere répond aux exigences.

3. Cliquez sur Suivant pour configurer un pool de nœuds.

Pools de nœuds

Votre cluster sera créé avec au moins un pool de nœuds. Un pool de nœuds est un modèle pour un groupe de nœuds de calcul créés dans ce cluster. Pour en savoir plus, consultez la page Créer et gérer des pools de nœuds.

1. Dans la section Valeurs par défaut du pool de nœuds, renseignez les éléments suivants :

   1. Saisissez le nom du pool de nœuds ou acceptez "default-pool" comme nom.
   2. Saisissez le nombre de vCPU pour chaque nœud du pool (au moins quatre par nœud de calcul de cluster d'utilisateur).
   3. Saisissez la taille de la mémoire en mébioctets (Mio) pour chaque nœud du pool (8192 Mio au minimum par nœud de nœud de calcul de cluster d'utilisateur, doit être un multiple de 4).
   4. Dans le champ Nœuds, saisissez le nombre de nœuds du pool (minimum 3). Si vous avez saisi des adresses IP statiques pour les adresses IP de nœud dans la section Mise en réseau, assurez-vous d'avoir saisi suffisamment d'adresses IP pour prendre en charge ces nœuds de cluster d'utilisateur.
   5. Sélectionnez le type d'image de l'OS : Ubuntu, Ubuntu Containerd ou COS.
   6. Saisissez la taille du disque de démarrage en gibioctets (Gio) (40 Gio au minimum).
   7. Si vous utilisez MetalLB comme équilibreur de charge, MetalLB doit être activé dans au moins un pool de nœuds. Laissez l'option Utiliser ce pool de nœuds pour l'équilibrage de charge MetalB sélectionnée, ou ajoutez un autre pool de nœuds à utiliser pour MetalLB.

2. Dans la section Métadonnées du pool de nœuds (facultatif), si vous souhaitez ajouter des libellés et des rejets Kubernetes, procédez comme suit :

   1. Cliquez sur + Ajouter des libellés Kubernetes. Saisissez la clé et la valeur du libellé. Répétez l'opération autant de fois que nécessaire.
   2. Cliquez sur + Ajouter un rejet. Saisissez la clé, la valeur et l'effet pour le rejet. Répétez l'opération autant de fois que nécessaire.

3. Cliquez sur Vérifier et terminer pour créer le cluster d'utilisateur. La création du cluster d'utilisateur prend au moins 15 minutes. La console affiche les messages d'état de vérification des paramètres et de création du cluster dans votre centre de données.

   Si une erreur se produit lors de la vérification des paramètres, la console affiche un message d'erreur qui doit être suffisamment clair pour résoudre le problème de configuration avant de retenter de créer le cluster.

   Pour en savoir plus sur les erreurs possibles et sur la façon de les corriger, consultez la page Résoudre les problèmes de création de cluster d'utilisateur dans la console Google Cloud.

gcloud CLI

La commande suivante permet de créer un cluster d'utilisateur :

gcloud container vmware clusters create

Après avoir créé le cluster, vous devez créer au moins un pool de nœuds à l'aide de la commande suivante :

gcloud container vmware node-pools create

La plupart des indicateurs de création du cluster et du pool de nœuds correspondent aux champs du fichier de configuration du cluster d'utilisateur. Pour vous aider à démarrer, vous pouvez tester une commande complète dans la section Exemples.

Recueillir des informations

Rassemblez les informations dont vous avez besoin pour créer le cluster.

1. Obtenez le nom et l'emplacement d'appartenance au parc de votre cluster d'administrateur :

   gcloud container fleet memberships list \
       --project=FLEET_HOST_PROJECT_ID
   

   Remplacez FLEET_HOST_PROJECT_ID par l'ID du projet auquel le cluster d'administrateur est enregistré.

   Le résultat ressemble à ce qui suit :

   NAME             EXTERNAL_ID                           LOCATION
   admin-cluster-1  bb7803b4-8438-4b22-859f-4559b4b29072  global
   admin-cluster-2  ee16ee2b-6ec0-49fc-9413-3c89cbc70854  global
   admin-cluster-3  fc2b7ef5-39ff-4b63-b919-04c5adc67be4  us-west1
   

   L'emplacement spécifie l'endroit où les services Fleet et Connect s'exécutent. Les clusters d'administrateur créés avant la version 1.28 sont gérés par les services Fleet et Connect mondiaux. Dans la version 1.28 et les versions ultérieures, vous pouvez spécifier global ou une région Google Cloud lorsque vous créez le cluster d'administrateur. Vous spécifiez la région dans l'indicateur --admin-cluster-membership-location pour les exemples de commandes qui suivent.

2. Obtenez la liste des versions disponibles :

   gcloud container vmware clusters query-version-config \
       --admin-cluster-membership=ADMIN_CLUSTER_NAME \
       --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
       --admin-cluster-membership-location=ADMIN_CLUSTER_REGION \
       --location=REGION
   

   Remplacez les éléments suivants :

   • ADMIN_CLUSTER_NAME : nom du cluster d'administrateur.

   • FLEET_HOST_PROJECT_ID : ID du projet auquel le cluster d'administrateur est enregistré.

   • ADMIN_CLUSTER_REGION : région d'appartenance au parc du cluster d'administrateur. Il peut s'agir d'une région Google Cloud ou d'une région mondiale. Utilisez l'emplacement du cluster d'administrateur à partir de la sortie de gcloud container fleet memberships list.

   • REGION : région Google Cloud que vous utiliserez pour créer le cluster utilisateur. Il s'agit de la région dans laquelle l'API GKE On-Prem s'exécute et stocke ses métadonnées.

     • Si le cluster d'administrateur est enregistré dans l'API GKE On-Prem, utilisez la même région que le cluster d'administrateur. Pour connaître la région du cluster d'administrateur, exécutez la commande suivante :

       gcloud container vmware admin-clusters list \
         --project=FLEET_HOST_PROJECT_ID \
         --location=-
       

     • Si le cluster d'administrateur n'est pas inscrit dans l'API GKE On-Prem, spécifiez us-west1 ou une autre région compatible. Si vous enregistrez ensuite le cluster d'administrateur dans l'API GKE On-Prem, utilisez la même région que celle du cluster d'utilisateur.

   La sortie de la commande gcloud container vmware clusters query-version-config ressemble à ceci :

   versions:
   - isInstalled: true
     version: 1.28.800-gke.109
   - version: 1.29.0-gke.1456
   - version: 1.29.100-gke.248
   - version: 1.29.200-gke.245
   - version: 1.29.300-gke.184
   

   La commande génère également une explication des versions que vous pouvez utiliser pour créer ou mettre à niveau un cluster d'utilisateur. Les versions que vous pouvez utiliser pour créer ou mettre à niveau un cluster d'utilisateur sont annotées avec isInstalled: true, ce qui signifie que le cluster d'administrateur dispose des composants spécifiques à la version dont il a besoin pour gérer les clusters d'utilisateur de cette version. Si vous souhaitez utiliser une version installée sur le cluster d'administrateur, passez à la section Exemples pour créer le cluster d'utilisateur.

Installer une version supérieure

Un cluster d'administrateur peut gérer des clusters d'utilisateur avec différentes versions. La sortie de la commande query-version-config liste les autres versions que vous pouvez utiliser lorsque vous créez le cluster. Si vous souhaitez créer un cluster d'utilisateur dont la version est supérieure à celle du cluster d'administrateur, vous devez télécharger et déployer les composants dont le cluster d'administrateur a besoin pour gérer les clusters d'utilisateurs de cette version, comme suit :

gcloud container vmware admin-clusters update ADMIN_CLUSTER_NAME \
    --project=FLEET_HOST_PROJECT_ID \
    --location=REGION \
    --required-platform-version=VERSION

Remplacez VERSION par l'une des versions répertoriées dans la sortie de la commande query-version-config.

La commande télécharge la version des composants que vous spécifiez dans --required-platform-version sur le cluster d'administrateur, puis déploie les composants. Vous pouvez maintenant créer un cluster d'utilisateur avec la version spécifiée.

Si vous exécutez à nouveau gcloud container vmware clusters query-version-config, la version que vous avez spécifiée est annotée avec isInstalled: true.

Exemples

Les exemples suivants montrent comment créer un cluster d'utilisateur avec différents équilibreurs de charge avec Controlplane V2 activé. Avec Controlplane V2, le plan de contrôle d'un cluster d'utilisateur s'exécute sur un ou plusieurs nœuds du cluster d'utilisateur lui-même. Nous vous recommandons d'activer Controlplane V2. Dans la version 1.30 et les suivantes, Controlplane V2 doit être activé pour les nouveaux clusters d'utilisateurs. Pour en savoir plus sur les options d'équilibrage de charge disponibles, consultez la page Présentation de l'équilibrage de charge.

La plupart des exemples utilisent les valeurs par défaut pour configurer les nœuds du plan de contrôle. Si vous souhaitez modifier l'une des valeurs par défaut, incluez les indicateurs décrits dans la section Indicateurs du plan de contrôle. Si nécessaire, vous pouvez également modifier certains paramètres vSphere.

Avant d'exécuter la commande gcloud pour créer le cluster, vous pouvez inclure --validate-only pour valider la configuration que vous avez spécifiée dans les indicateurs de la commande gcloud. Lorsque vous êtes prêt à créer le cluster, supprimez cette option et exécutez la commande.

Si vous recevez une erreur après l'exécution de la commande gcloud container vmware clusters create pendant environ une minute ou plus, vérifiez si le cluster a été partiellement créé en exécutant la commande suivante :

gcloud container vmware clusters list \
    --project=FLEET_HOST_PROJECT_ID \
    --location=-

Si le cluster ne figure pas dans la sortie, corrigez l'erreur et exécutez à nouveau gcloud container vmware clusters create.

Si le cluster est listé dans la sortie, supprimez-le à l'aide de la commande suivante :

gcloud container vmware clusters delete USER_CLUSTER_NAME \
    --project=FLEET_HOST_PROJECT_ID \
    --location=REGION \
    --force \
    --allow-missing

Corrigez ensuite l'erreur et exécutez à nouveau gcloud container vmware clusters create.

Une fois le cluster en cours d'exécution, vous devez ajouter un pool de nœuds avant de déployer des charges de travail, comme décrit dans la section Créer un pool de nœuds.

gcloud container vmware clusters create USER_CLUSTER_NAME \
    --project=FLEET_HOST_PROJECT_ID \
    --admin-cluster-membership=ADMIN_CLUSTER_NAME \
    --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
    --admin-cluster-membership-location=ADMIN_CLUSTER_REGION \
    --location=REGION \
    --version=VERSION \
    --admin-users=YOUR_EMAIL_ADDRESS \
    --admin-users=ANOTHER_EMAIL_ADDRESS \
    --service-address-cidr-blocks=10.96.0.0/20 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --metal-lb-config-address-pools='pool=NAME,avoid-buggy-ips=AVOID_BUGGY_IPS,manual-assign=MANUAL_ASSIGN,addresses=IP_ADDRESS_RANGE_1' \
    --metal-lb-config-address-pools='pool=ingress-vip-pool,avoid-buggy-ips=False,manual-assign=True,addresses=INGRESS_VIP/32' \
    --enable-control-plane-v2 \
    --dns-servers=DNS_SERVER_1 \
    --ntp-servers=NTP_SERVER_1 \
    --control-plane-ip-block 'gateway=CP_GATEWAY,netmask=CP_NETMASK,ips=CP_IP_ADDRESS_1 CP_HOST_1' \
    --control-plane-vip=CONTROL_PLANE_VIP \
    --ingress-vip=INGRESS_VIP \
    --enable-dhcp

gcloud container vmware clusters create USER_CLUSTER_NAME \
    --project=FLEET_HOST_PROJECT_ID \
    --admin-cluster-membership=ADMIN_CLUSTER_NAME \
    --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
    --admin-cluster-membership-location=ADMIN_CLUSTER_REGION \
    --location=REGION \
    --version=VERSION \
    --admin-users=YOUR_EMAIL_ADDRESS \
    --admin-users=ANOTHER_EMAIL_ADDRESS \
    --service-address-cidr-blocks=10.96.0.0/20 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --metal-lb-config-address-pools='pool=NAME,avoid-buggy-ips=AVOID_BUGGY_IPS,manual-assign=MANUAL_ASSIGN,addresses=IP_ADDRESS_RANGE_1' \
    --metal-lb-config-address-pools='pool=ingress-vip-pool,avoid-buggy-ips=False,manual-assign=True,addresses=INGRESS_VIP/32' \
    --enable-control-plane-v2 \
    --control-plane-ip-block 'gateway=CP_GATEWAY,netmask=CP_NETMASK,ips=CP_IP_ADDRESS_1 CP_HOST_1' \
    --control-plane-vip=CONTROL_PLANE_VIP \
    --ingress-vip=INGRESS_VIP \
    --static-ip-config-ip-blocks='gateway=GATEWAY,netmask=NETMASK,ips=IP_ADDRESS_1 HOST_1;IP_ADDRESS_2 HOST_2;IP_ADDRESS_3 HOST_3;IP_ADDRESS_4 HOST_4' \
    --dns-servers=DNS_SERVER_1 \
    --ntp-servers=NTP_SERVER_1

gcloud container vmware clusters create USER_CLUSTER_NAME \
    --project=FLEET_HOST_PROJECT_ID \
    --admin-cluster-membership=ADMIN_CLUSTER_NAME \
    --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
    --admin-cluster-membership-location=ADMIN_CLUSTER_REGION \
    --location=REGION \
    --version=VERSION \
    --admin-users=YOUR_EMAIL_ADDRESS \
    --admin-users=ANOTHER_EMAIL_ADDRESS \
    --service-address-cidr-blocks=10.96.0.0/20 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --enable-control-plane-v2 \
    --control-plane-ip-block 'gateway=CP_GATEWAY,netmask=CP_NETMASK,ips=CP_IP_ADDRESS_1 CP_HOST_1' \
    --control-plane-vip=CONTROL_PLANE_VIP \
    --ingress-vip=INGRESS_VIP \
    --ingress-http-node-port=INGRESS_HTTP_NODE_PORT \
    --ingress-https-node-port=INGRESS_HTTPS_NODE_PORT \
    --static-ip-config-ip-blocks='gateway=GATEWAY,netmask=NETMASK,ips=IP_ADDRESS_1 HOST_1;IP_ADDRESS_2 HOST_2;IP_ADDRESS_3 HOST_3;IP_ADDRESS_4 HOST_4' \
    --dns-servers=DNS_SERVER_1 \
    --ntp-servers=NTP_SERVER_1

Indicateurs du plan de contrôle

Si vous souhaitez utiliser des valeurs autres que les valeurs par défaut pour la configuration du plan de contrôle, incluez un ou plusieurs des indicateurs suivants :

• --cpus=vCPUS : nombre de processeurs virtuels (4 au minimum) pour chaque nœud de plan de contrôle de votre cluster d'utilisateur. Si aucune valeur n'est spécifiée, la valeur par défaut est de quatre vCPU.

• --memory=MEMORY : taille de la mémoire en mebioctets (MiB) pour chaque plan de contrôle de votre cluster d'utilisateur. La valeur minimale est 8 192 et doit être un multiple de 4. Si aucune valeur n'est spécifiée, la valeur par défaut est 8 192.

• --replicas=NODES : nombre de nœuds de plan de contrôle pour votre cluster d'utilisateur. Par exemple, vous pouvez utiliser un seul nœud de plan de contrôle pour un environnement de développement et trois nœuds de plan de contrôle pour les environnements de production et la haute disponibilité.

• --enable-auto-resize : si vous souhaitez activer le redimensionnement automatique des nœuds du plan de contrôle pour le cluster d'utilisateur, incluez --enable-auto-resize. Le redimensionnement signifie que les ressources de vCPU et de mémoire attribuées à un nœud sont ajustées automatiquement. Lorsque cette option est activée, les nœuds du plan de contrôle du cluster d'utilisateur sont redimensionnés en fonction du nombre de nœuds de calcul du cluster d'utilisateur. Ainsi, à mesure que vous ajoutez des nœuds de calcul au cluster d'utilisateur, la taille des nœuds du plan de contrôle est augmentée.

• --enable-control-plane-v2 : pour activer Controlplane V2, ce que nous vous recommandons, incluez cet indicateur. Lorsque Controlplane V2 est activé, le plan de contrôle du cluster d'utilisateur s'exécute sur un ou plusieurs nœuds du cluster d'utilisateur lui-même. Dans la version 1.30 et les suivantes, Controlplane V2 est requis.

  Lorsque vous activez Controlplane V2, vous devez également spécifier les indicateurs suivants :

  • --dns-servers=DNS_SERVER_1,... : liste des adresses IP des serveurs DNS des VM, séparées par une virgule.

  • --ntp-servers=NTP_SERVER_1,... : liste des adresses IP des serveurs de temps à utiliser par les VM, séparées par une virgule.

  • --control-plane-ip-block, qui a le format suivant :

      --control-plane-ip-block 'gateway=CP_GATEWAY,netmask=CP_NETMASK,ips=CP_IP_ADDRESS_1;CP_IP_ADDRESS_2 CP_HOST_2'

    La valeur comporte des segments commençant par les mots clés gateway, netmask et ips. Séparez les segments par une virgule.

    Veuillez noter les points suivants :

    • Placez la valeur entière entre guillemets simples.

    • Les espaces blancs ne sont pas autorisés, sauf entre une adresse IP et un nom d'hôte.

      Dans la liste des adresses IP :

    • Vous pouvez spécifier une adresse IP individuelle ou un bloc CIDR d'adresses IP.

    • Séparez chaque adresse IP ou bloc CIDR par un point-virgule.

    • Pour une adresse IP individuelle, vous pouvez éventuellement spécifier un nom d'hôte après l'adresse IP. Séparez l'adresse IP et le nom d'hôte par un espace.

    • Si vous spécifiez un bloc CIDR, ne spécifiez pas de valeur pour le nom d'hôte.

      Exemple :

      --control-plane-ip-block 'gateway=192.168.0.1,netmask=255.0.0.0,ips=192.168.1.1;192.168.1.2 hostname-2;192.168.2.2/28`
      

  • Facultatif : --dns-search-domains=DNS_SEARCH_DOMAIN_1,... : liste des domaines de recherche DNS que les hôtes doivent utiliser, séparés par une virgule. Ces domaines sont utilisés dans le cadre d'une liste de recherche de domaines.

    Exemple :

    --dns-search-domains example.com,examplepetstore.com

  Pour obtenir la liste complète des options et de leurs descriptions, consultez la documentation de référence de gcloud CLI.

  Indicateurs vSphere

  Si nécessaire, spécifiez les indicateurs facultatifs suivants :

• --disable-aag-config : si vous n'incluez pas cet indicateur, les règles d'anti-affinité DRS (Distributed Resource Scheduler) de VMware sont automatiquement créées pour les nœuds de votre cluster d'utilisateur, ce qui les répartit sur au moins trois hôtes physiques dans votre centre de données. Assurez-vous que votre environnement vSphere répond aux exigences. Si votre cluster ne répond pas aux exigences, incluez cette option.

• --disable-vsphere-csi : si vous n'incluez pas cet indicateur, les composants CSI (Container Storage Interface) vSphere sont déployés dans le cluster d'utilisateur. Le pilote CSI s'exécute dans un cluster Kubernetes natif déployé dans vSphere pour provisionner des volumes persistants sur l'espace de stockage vSphere. Pour en savoir plus, consultez la page Utiliser le pilote Container Storage Interface (CSI) de vSphere. Si vous ne souhaitez pas déployer les composants CSI, incluez cet indicateur.

  Pour obtenir la liste complète des options et de leurs descriptions, consultez la documentation de référence de gcloud CLI.

  Suivre la progression de la création du cluster

  La sortie de la commande de création de cluster ressemble à ceci :

  Waiting for operation [projects/example-project-12345/locations/us-west1/operations/operation-1679543737105-5f7893fd5bae9-942b3f97-75e59179] to complete.
  

  Dans l'exemple de sortie, la chaîne operation-1679543737105-5f7893fd5bae9-942b3f97-75e59179 est le OPERATION_ID de l'opération de longue durée. Vous pouvez connaître l'état de l'opération à l'aide de la commande suivante :

  gcloud container vmware operations describe OPERATION_ID \
    --project=FLEET_HOST_PROJECT_ID \
    --location=REGION
  

  Pour plus d'informations, consultez la section Opérations gcloud container vmware.

  La création du cluster d'utilisateur prend au moins 15 minutes. Vous pouvez afficher le cluster dans la console Google Cloud sur la page Clusters GKE.

  Créer un pool de nœuds

  Une fois le cluster créé, vous devez créer au moins un pool de nœuds avant de déployer des charges de travail.

  gcloud container vmware node-pools create NODE_POOL_NAME \
  --cluster=USER_CLUSTER_NAME  \
  --project=FLEET_HOST_PROJECT_ID \
  --location=REGION \
  --image-type=IMAGE_TYPE  \
  --boot-disk-size=BOOT_DISK_SIZE \
  --cpus=vCPUS \
  --memory=MEMORY \
  --replicas=NODES \
  --enable-load-balancer
  

  Remplacez les éléments suivants :

• NODE_POOL_NAME : Nom de votre choix pour le pool de nœuds. Ce nom doit :

  • contenir au maximum 40 caractères ;
  • ne contenir que des caractères alphanumériques minuscules ou un trait d'union - ;
  • commencer par un caractère alphabétique ;
  • se terminer par un caractère alphanumérique.

• USER_CLUSTER_NAME : nom du cluster d'utilisateur nouvellement créé.

• FLEET_HOST_PROJECT_ID : ID du projet auquel le cluster d'administrateur est enregistré.

• REGION : région Google Cloud que vous avez spécifiée lors de la création du cluster.

• IMAGE_TYPE : type d'image de système d'exploitation à exécuter sur les VM du pool de nœuds Définissez l'une des valeurs suivantes : ubuntu_containerd ou cos.

• BOOT_DISK_SIZE : taille du disque de démarrage en gigaoctets pour chaque nœud du pool. La taille minimale est de 40 GiB.

• vCPUs : nombre de vCPU de chaque nœud du pool de nœuds. La valeur minimale est 4.

• MEMORY : taille de la mémoire en mebioctets (MiB) pour chaque nœud du pool. La valeur minimale est de 8 192 Mio par nœud de calcul de cluster d'utilisateurs, et la valeur doit être un multiple de 4.

• NODES : Nombre de nœuds dans le pool de nœuds. La valeur minimale est 3.

• Si vous utilisez MetalLB comme équilibreur de charge, vous pouvez inclure --enable-load-balancer si vous souhaitez autoriser le locuteur MetalLB à s'exécuter sur les nœuds du pool. MetalLB doit être activé dans au moins un pool de nœuds. Si vous n'incluez pas cet indicateur, vous devez créer un autre pool de nœuds à utiliser pour MetalLB.

  Pour en savoir plus sur les options facultatives, consultez la section Ajouter un pool de nœuds et la documentation de référence de gcloud CLI.

Exemples de commandes gcloud

gcloud container vmware clusters create user-cluster-1 \
    --project=example-project-12345 \
    --location=us-west1 \
    --admin-cluster-membership=projects/example-project-12345/locations/us-west1/memberships/admin-cluster-1 \
    --version=1.30.0-gke.1930 \
    --admin-users=sara@example.com \
    --admin-users=amal@example.com \
    --enable-dhcp \
    --service-address-cidr-blocks=10.96.0.0/20 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --metal-lb-config-address-pools='pool=lb-pool-1,manual-assign=False,avoid-buggy-ips=True,addresses=192.0.2.0/26;pool=lb-ingress-vip-pool,manual-assign=True,addresses=198.51.100.1/32' \
    --enable-control-plane-v2 \
    --control-plane-vip=203.0.113.1 \
    --ingress-vip=198.51.100.1

gcloud container vmware clusters create user-cluster-3 \
    --project=example-project-12345 \
    --location=europe-west1 \
    --admin-cluster-membership=projects/example-project-12345/locations/global/memberships/admin-cluster-1 \
    --version=1.30.0-gke.1930 \
    --admin-users=sara@example.com \
    --admin-users=amal@example.com \
    --static-ip-config-ip-blocks='gateway=192.0.2.254,netmask=255.255.255.0,ips=192.0.2.10 user-vm-1;192.0.2.11 user-vm-2' \
    --static-ip-config-ip-blocks='gateway=192.0.2.254,netmask=255.255.255.0,ips=192.0.2.12 user-vm-3;192.0.2.13 extra-vm' \
    --dns-servers=203.0.113.1,203.0.113.2  \
    --dns-search-domains=example.com,altostrat.com \
    --ntp-servers=203.0.113.3,203.0.113.4 \
    --service-address-cidr-blocks=10.96.0.0/20 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --enable-control-plane-v2 \
    --control-plane-ip-block 'gateway=192.0.2.254,netmask=255.255.255.0,ips=198.51.100.1 cp-vm-1;198.51.100.2 cp-vm-2;198.51.100.3 cp-vm-3' \
    --replicas=3 \
    --metal-lb-config-address-pools='pool=lb-pool-1,manual-assign=False,avoid-buggy-ips=True,addresses=192.0.2.0/26;lb-ingress-vip-pool,manual-assign=True,addresses=198.51.100.1/32' \
    --control-plane-vip=172.16.20.61 \
    --ingress-vip=172.16.20.62

gcloud container vmware clusters create user-cluster-4 \
    --project=example-project-12345 \
    --location=asia-east1 \
    --admin-cluster-membership=projects/example-project-12345/locations/asia-east1/memberships/admin-cluster-1 \
    --version=1.30.0-gke.1930 \
    --admin-users=sara@example.com \
    --admin-users=amal@example.com \
    --static-ip-config-ip-blocks='gateway=192.0.2.254,netmask=255.255.255.0,ips=192.0.2.10 user-vm-1;192.0.2.11 user-vm-2';ips=192.0.2.12 user-vm-3;192.0.2.13 extra-vm'\
    --dns-servers=203.0.113.1,203.0.113.2  \
    --ntp-servers=203.0.113.3,203.0.113.4 \
    --service-address-cidr-blocks=10.96.0.0/20 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --enable-control-plane-v2 \
    --control-plane-ip-block 'gateway=192.0.2.254,netmask=255.255.255.0,ips=198.51.100.1 cp-vm-1;198.51.100.2 cp-vm-2;198.51.100.3 cp-vm-3' \
    --replicas=3 \
    --control-plane-vip=192.0.2.60 \
    --ingress-vip=192.0.2.50 \
    --ingress-http-node-port=30243 \
    --ingress-https-node-port=30879

Terraform

Avant de commencer

1. Obtenez le nom et l'emplacement d'appartenance au parc de votre cluster d'administrateur :

   gcloud container fleet memberships list \
       --project=FLEET_HOST_PROJECT_ID
   

   Remplacez FLEET_HOST_PROJECT_ID par l'ID du projet auquel le cluster d'administrateur est enregistré.

   Le résultat ressemble à ce qui suit :

   NAME             EXTERNAL_ID                           LOCATION
   admin-cluster-1  bb7803b4-8438-4b22-859f-4559b4b29072  global
   admin-cluster-2  ee16ee2b-6ec0-49fc-9413-3c89cbc70854  global
   admin-cluster-3  fc2b7ef5-39ff-4b63-b919-04c5adc67be4  us-west1
   

   L'emplacement spécifie l'endroit où les services Fleet et Connect s'exécutent. Les clusters d'administrateur créés avant la version 1.28 sont gérés par les services Fleet et Connect mondiaux. Dans la version 1.28 et les versions ultérieures, vous pouvez spécifier global ou une région Google Cloud lorsque vous créez le cluster.

2. Obtenez la liste des versions disponibles :

   gcloud container vmware clusters query-version-config \
       --admin-cluster-membership=ADMIN_CLUSTER_NAME \
       --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
       --admin-cluster-membership-location=ADMIN_CLUSTER_REGION \
       --location=REGION
   

   Remplacez les éléments suivants :

   • ADMIN_CLUSTER_NAME : nom du cluster d'administrateur.

   • FLEET_HOST_PROJECT_ID : ID du projet auquel le cluster d'administrateur est enregistré.

   • ADMIN_CLUSTER_REGION : région d'appartenance au parc du cluster d'administrateur. Il peut s'agir d'une région Google Cloud ou d'une région mondiale. Utilisez l'emplacement du cluster d'administrateur à partir de la sortie de gcloud container fleet memberships list.

   • REGION : région Google Cloud que vous utiliserez pour créer le cluster. Il s'agit de la région dans laquelle l'API GKE On-Prem et les services Fleet et Connect s'exécutent. Spécifiez us-west1 ou une autre région compatible.

   La sortie de la commande ressemble à ceci :

   versions:
   - isInstalled: true
     version: 1.14.3-gke.25
   - version: 1.14.4-gke.54
   - version: 1.15.0-gke.581
   

   Les versions que vous pouvez utiliser pour créer un cluster d'utilisateur sont annotées avec isInstalled=true, ce qui signifie que le cluster d'administrateur dispose des composants spécifiques à la version dont il a besoin pour gérer les clusters d'utilisateurs de cette version. Si vous souhaitez créer un cluster d'utilisateur avec une autre version disponible, consultez la section Installer une version ultérieure à celle du cluster d'administrateur.

Exemple

Vous pouvez utiliser l'exemple de configuration de base suivant pour créer un cluster d'utilisateur avec l'équilibreur de charge MetalLB fourni et un pool de nœuds.

Pour en savoir plus et obtenir d'autres exemples, consultez la documentation de référence de google_gkeonprem_vmware_cluster.

Définir des variables dans terraform.tfvars

L'exemple fournit un exemple de fichier de variables à transmettre à main.tf, qui montre comment configurer l'équilibreur de charge MetalLB fourni et permettre à vos nœuds de cluster d'obtenir leurs adresses IP à partir d'un serveur DHCP que vous fournissez.

1. Clonez le dépôt anthos-samples et accédez au répertoire dans lequel se trouve l'exemple Terraform :

   git clone https://github.com/GoogleCloudPlatform/anthos-samples
   cd anthos-samples/anthos-onprem-terraform/avmw_user_cluster_metallb
   

2. Faites une copie du fichier terraform.tfvars.sample :

   cp terraform.tfvars.sample terraform.tfvars
   

3. Modifiez les valeurs des paramètres dans terraform.tfvars.

   project_id                  = "FLEET_HOST_PROJECT_ID"
   region                      = "REGION"
   admin_cluster_name          = "ADMIN_CLUSTER_NAME"
   on_prem_version             = "VERSION"
   admin_user_emails           = ["YOUR_EMAIL_ADDRESS", "ADMIN_2_EMAIL_ADDRESS"]
   cluster_name                = "avmw-user-cluster-metallb"
   control_plane_node_cpus     = 4
   control_plane_node_memory   = 8192
   control_plane_node_replicas = 3
   control_plane_vip           = "CONTROL_PLANE_VIP"
   ingress_vip                 = "INGRESS_VIP"
   lb_address_pools            = [
       { name = "lbpool_1", addresses = ["10.200.0.51-10.200.0.70"] }
   ]
   

   La liste suivante décrit les variables :

   • project_id : ID du projet dans lequel vous souhaitez créer le cluster. Le projet spécifié est également utilisé comme projet hôte du parc. Il doit s'agir du même projet que celui dans lequel le cluster d'administrateur est enregistré. Une fois le cluster d'utilisateur créé, il est automatiquement enregistré dans le parc du projet sélectionné. Le projet hôte de parc ne peut pas être modifié une fois le cluster créé.

   • region : région Google Cloud dans laquelle l'API GKE On-Prem (gkeonprem.googleapis.com), le service Fleet (gkehub.googleapis.com) et le service Connect (gkeconnect.googleapis.com) s'exécutent. Spécifiez us-west1 ou une autre région compatible.

   • admin_cluster_name : nom du cluster d'administrateur qui gère le cluster d'utilisateur. L'exemple suppose que le cluster d'administrateur utilise "global" comme région. Si vous disposez d'un cluster d'administrateur régional :

     1. Ouvrez main.tf dans un éditeur de texte.
     2. Recherchez admin_cluster_membership, qui se présente comme suit :

     admin_cluster_membership = "projects/${var.project_id}/locations/global/memberships/${var.admin_cluster_name}"

     1. Remplacez global par la région utilisée par le cluster d'administrateur et enregistrez le fichier.

   • on_prem_version : version de Google Distributed Cloud pour votre cluster d'utilisateur. En règle générale, vous spécifiez la même version que le cluster d'administrateur. Pour spécifier une version ultérieure, installez une version ultérieure à celle du cluster d'administrateur. Si vous ne connaissez pas la version du cluster d'administrateur, exécutez gcloud container vmware clusters query-version-config, qui est la première étape de Installer une version ultérieure à celle du cluster d'administrateur.

   • admin_user_emails : liste des adresses e-mail des utilisateurs auxquels vous souhaitez accorder des droits d'administrateur sur le cluster. Veillez à ajouter votre adresse e-mail si vous souhaitez administrer le cluster.

     Une fois le cluster créé, l'API GKE On-Prem applique les stratégies de contrôle d'accès basé sur les rôles (RBAC) Kubernetes au cluster afin de vous accorder, à vous et aux autres administrateurs, le rôle Kubernetes clusterrole/cluster-admin, qui fournit un accès complet à chaque ressource du cluster dans tous les espaces de noms. Cela permet également aux utilisateurs de se connecter à la console à l'aide de leur identité Google.

   • cluster_name : Nom de votre choix pour le cluster d'utilisateur. Le nom ne peut pas être modifié une fois le cluster créé. Ce nom doit :

     • contenir au maximum 40 caractères ;
     • ne contenir que des caractères alphanumériques minuscules ou un trait d'union - ;
     • commencer par un caractère alphabétique ;
     • se terminer par un caractère alphanumérique.

   • control_plane_node_cpus : nombre de vCPU pour chaque nœud du plan de contrôle de votre cluster d'utilisateur. Le nombre minimal est de quatre vCPU.

   • control_plane_node_memory : taille de la mémoire en mebioctets (MiB) pour chaque plan de contrôle de votre cluster d'utilisateur. La valeur minimale est 8 192 et doit être un multiple de 4.

   • control_plane_node_replicas : nombre de nœuds de plan de contrôle pour votre cluster d'utilisateur. Par exemple, vous pouvez entrer un seul nœud de plan de contrôle pour un environnement de développement et trois nœuds de plan de contrôle pour les environnements de production et la haute disponibilité.

   • control_plane_vip : adresse IP virtuelle (VIP) que vous avez choisie de configurer sur l'équilibreur de charge pour le serveur d'API Kubernetes du cluster d'utilisateur.

   • ingress_vip : Adresse IP que vous avez choisie de configurer sur l'équilibreur de charge pour le proxy d'entrée.

   • lb_address_pools : liste des mappages qui définissent les pools d'adresses à utiliser par l'équilibreur de charge MetalLB. L'adresse IP virtuelle d'entrée doit appartenir à l'un de ces pools. Renseignez les champs suivants :

     • name : nom du pool.
     • addresses : plage d'adresses au format CIDR ou au format de plage avec trait d'union. Pour spécifier une seule adresse IP dans un pool (par exemple, pour l'adresse IP virtuelle d'entrée), utilisez /32 au format CIDR, par exemple : 192.0.2.1/32.

     Remplacez les exemples d'adresses IP par vos valeurs et ajoutez des pools d'adresses supplémentaires si nécessaire.

4. Enregistrez les modifications dans terraform.tfvars. Si vous ne souhaitez pas apporter de modifications facultatives à main.tf, passez à la section suivante, Créer le cluster et un pool de nœuds.

Facultatif : Configurez les paramètres de cluster dans main.tf

Cette section décrit certaines modifications de configuration facultatives que vous pouvez apporter dans main.tf. Avant d'apporter des modifications, créez une sauvegarde de main.tf :

cp main.tf main.tf.bak

Mode d'adressage IP des nœuds de calcul

Par défaut, main.tf configure le cluster pour qu'il utilise un serveur DHCP que vous fournissez afin d'attribuer des adresses IP aux nœuds de calcul du cluster. DHCP est configuré en incluant le mappage dhcp_config dans le bloc network_config. Si vous souhaitez fournir des adresses IP statiques pour vos nœuds de calcul, apportez les modifications suivantes à main.tf :

1. Remplacez le bloc network_config et incluez un bloc static_ip_config. Exemple :

     network_config {
       service_address_cidr_blocks = ["10.96.0.0/12"]
       pod_address_cidr_blocks = ["192.168.0.0/16"]
       host_config {
         dns_servers = ["10.254.41.1"]
         ntp_servers = ["216.239.35.8"]
       }
       static_ip_config {
         ip_blocks {
           netmask = "255.255.252.0"
           gateway = "10.251.31.254"
           ips {
             ip = "10.251.30.153"
             hostname = "vm-1"
           }
           ips {
             ip = "10.251.31.206"
             hostname = "vm-2"
           }
           ips {
             ip = "10.251.31.193"
             hostname = "vm-3"
           }
           ips {
             ip = "10.251.30.230"
             hostname = "vm-4"
           }
         }
       }
     }
   

2. Remplacez les valeurs suivantes par les vôtres :

   • service_address_cidr_blocks : Une plage d'adresses IP au format CIDR à utiliser pour les services de votre cluster. Elle doit être au moins égale à /24.

   • pod_address_cidr_blocks : Une plage d'adresses IP au format CIDR à utiliser pour les pods de votre cluster. Elle doit être au moins égale à /18.

   • dns_servers : liste des adresses IP des serveurs DNS pour les VM.

   • ntp_servers : liste des adresses IP des serveurs de temps à utiliser par les VM.

   • Dans le bloc static_ip_config, remplacez les valeurs de netmask et gateway par les adresses de votre réseau. Remplacez ip et hostname par les adresses IP et les noms d'hôte de vos nœuds de calcul.

Configurer Controlplane V2

Par défaut, main.tf configure le plan de contrôle du cluster d'utilisateur pour qu'il s'exécute sur un ou plusieurs nœuds du cluster d'administrateur (appelé modèle kubeception). Si vous préférez, vous pouvez activer Controlplane V2. Lorsque Controlplane V2 est activé, le plan de contrôle du cluster d'utilisateur s'exécute sur un ou plusieurs nœuds du cluster d'utilisateur lui-même. Pour configurer Controlplane V2, apportez les modifications suivantes à main.tf :

1. Ajoutez la ligne suivante après la ligne contenant admin_cluster_membership :

     enable_control_plane_v2 = "true"
   

2. Ajoutez un mappage control_plane_v2_config au bloc network_config, par exemple :

     control_plane_v2_config {
       control_plane_ip_block {
         netmask = "255.255.252.0"
         gateway = "10.250.71.254"
         ips {
           ip = "10.250.68.54"
           hostname = "cpv2-vm1"
         }
         ips {
           ip = "10.250.68.128"
           hostname = "cpv2-vm2"
         }
         ips {
           ip = "10.250.71.50"
           hostname = "cpv2-vm3"
         }
       }
     }
   

3. Remplacez les valeurs de netmask et gateway par les adresses IP de votre réseau. Remplacez ip et hostname par les adresses IP de vos nœuds de plan de contrôle.

Créer le cluster et un pool de nœuds

1. Initialisez et créez le plan Terraform :

   terraform init
   

   Terraform installe les bibliothèques nécessaires, telles que le fournisseur Google Cloud.

2. Examinez la configuration et apportez les modifications nécessaires :

   terraform plan
   

3. Appliquez le plan Terraform pour créer le cluster d'utilisateur :

   terraform apply
   

   La création du cluster d'utilisateur prend environ 15 minutes, et la création du pool de nœuds 15 minutes supplémentaires. Vous pouvez afficher le cluster dans la console Google Cloud sur la page Clusters GKE.