Créer un cluster d'utilisateur

Dans GKE sur VMware, vos charges de travail s'exécutent sur un ou plusieurs clusters d'utilisateur. Ce document explique comment créer un cluster d'utilisateur.

Plusieurs outils permettent de créer un cluster d'utilisateur:

  • gkectl
  • console Google Cloud
  • Google Cloud CLI
  • Terraform

Trois de ces outils (console, gcloud CLI et Terraform) sont les clients de l'API GKE On-Prem.

Pour obtenir des conseils sur l'outil que vous pourriez utiliser, consultez la section Choisir un outil pour gérer le cycle de vie des clusters.

Avant de commencer

  • Si vous ne l'avez pas déjà fait, configurez vos ressources Google Cloud comme décrit dans ces documents:

    Lorsque vous configurez votre projet hôte de parc, tenez compte de votre choix d'outil, car si vous avez choisi l'un des clients de l'API GKE On-Prem, vous devez activer des API supplémentaires.

  • Avant de créer un cluster d'utilisateur, vous devez disposer d'un cluster d'administrateur pour le gérer. Si vous ne l'avez pas déjà fait, créez un poste de travail administrateur et un cluster d'administrateur.

    Si vous avez choisi d'utiliser l'un des clients API GKE On-Prem, vous devez activer les journaux d'audit et Cloud Logging pour le cluster d'administrateur.

  • Déterminez la version du cluster d'utilisateur que vous souhaitez installer. Lorsque vous créez un cluster d'utilisateur, vous installez généralement la version correspondant à celle du cluster d'administrateur. Toutefois, vous pouvez installer une version de correctif ultérieure ou une version mineure ultérieure. Pour en savoir plus, consultez la section Installer une version ultérieure à celle du cluster d'administrateur.

  • Demandez-vous si vous souhaitez que votre cluster d'utilisateur active le plan de contrôle V2. Lorsque le plan de contrôle 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. Nous vous recommandons vivement d'activer le plan de contrôle V2. L'alternative consiste à créer un cluster d'utilisateur utilisant kubeception. Dans le cas de kubeception, le plan de contrôle du cluster d'utilisateur s'exécute sur un ou plusieurs nœuds du cluster d'administrateur.

  • Consultez le document de planification des adresses IP et assurez-vous d'avoir suffisamment d'adresses IP disponibles.

  • Consultez la présentation de l'équilibrage de charge et réexaminez votre décision concernant le type d'équilibreur de charge que vous souhaitez utiliser. Vous pouvez utiliser l'équilibreur de charge MetalLB groupé ou configurer manuellement un équilibreur de charge de votre choix. Pour l'équilibrage de charge manuel, vous devez configurer l'équilibreur de charge avant de créer le cluster d'utilisateur.

  • Réfléchissez au nombre de pools de nœuds dont vous avez besoin et au système d'exploitation que vous souhaitez exécuter dans chacun de vos pools.

  • Déterminez si vous souhaitez utiliser des clusters vSphere distincts pour votre cluster d'administrateur et vos clusters d'utilisateur, et si vous souhaitez utiliser des centres de données distincts. Déterminez également si vous souhaitez utiliser des instances distinctes de vCenter Server.

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 machine 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 se produire 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 GKE sur VMware. Par exemple, 1.28.300-gke.123.

enableControlplaneV2

Pour créer un cluster d'utilisateur sur lequel le plan de contrôle V2 est activé, définissez enableControlplaneV2 sur true.

Lorsque le plan de contrôle 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 vivement d'activer le plan de contrôle V2.

kubeception

Si vous définissez ce champ sur false, le cluster utilise kubecetption. 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 de plan de contrôle du cluster d'utilisateur dans le fichier de blocs 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 en particulier 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 des centres de données différents. 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 a besoin d'accéder au centre de données du cluster d'administrateur, tandis que le compte vCenter du cluster d'utilisateur n'a besoin d'accéder qu'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 toute la section vCenter de votre fichier de configuration de 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éterminez 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 remplis.

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

Les nœuds du plan de contrôle de 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 les nœuds du plan de contrôle, remplissez la section network.controlPlaneIPBlock. Si vous souhaitez un cluster d'utilisateur haute disponibilité, spécifiez trois adresses IP. Sinon, spécifiez une 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 :

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 du plan de contrôle que vous souhaitez utiliser 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 indiquer si vous souhaitez activer le redimensionnement automatique pour ces 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 GKE sur VMware crée des règles d'anti-affinité Distributed Resource Scheduler (DRS) pour vos nœuds de calcul, ce qui entraîne leur propagation sur au moins trois hôtes physiques dans 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 de stackdriver.projectID doit être identique à celui de 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 correspond à true, la même région doit être définie dans gkeOnPremAPI.location.

Si les ID de projet et les régions 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.

À partir de la version 1.28, vous pouvez éventuellement spécifier la 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

À partir de la version 1.16, si l'API GKE On-Prem est activée dans votre projet Google Cloud, tous les clusters du projet sont enregistrés automatiquement 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, suivez la procédure décrite dans 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 du service pour 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 de cloudAuditLogging.projectID doit être identique à celui de 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 de projet et les régions 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.28.300-gke.123
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 possèdent des adresses IP statiques. Si les nœuds de calcul obtiennent leurs adresses IP à partir d'un serveur DHCP, ces serveurs DNS et NTP ne concernent que les 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.

  • Le plan de contrôle 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 d'adresses IP virtuelles spécifié dans cette section doit inclure l'adresse IP virtuelle d'entrée, mais pas 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 votre cluster d'administrateur.

  • Votre cluster d'utilisateur possède un serveur vCenter différent de votre cluster d'administrateur.

  • Votre cluster d'utilisateur utilise un registre de conteneurs privé différent du registre privé 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 de votre 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.28.300-gke.123-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 se produire 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

Le résultat 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

Premiers pas

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

    Accéder à la page "Créer un cluster GKE sur VMware"

  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 sont stockés les éléments suivants:

    • 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

    Ensemble, le nom, le projet et l'emplacement du cluster identifient de manière unique le cluster dans Google Cloud.

  4. Sélectionnez la version de GKE sur VMware pour votre cluster d'utilisateur.

  5. En tant que créateur du cluster, vous disposez de droits d'administrateur sur celui-ci. Vous pouvez également saisir l'adresse e-mail d'un autre utilisateur qui gérera le cluster dans le champ Utilisateur d'administrateur de cluster de la section Autorisation.

    Une fois le cluster créé, l'API GKE On-Prem applique au cluster les stratégies de contrôle des accès basé sur les rôles (RBAC) Kubernetes pour vous accorder, ainsi qu'aux autres administrateurs, le rôle Kubernetes clusterrole/cluster-admin, qui fournit un accès complet à toutes les ressources 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 les valeurs par défaut. Vérifiez les valeurs par défaut et modifiez-les si nécessaire.

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

  2. Dans le champ Mémoire du nœud du plan de contrôle, saisissez la taille de la mémoire en Mio (la valeur doit être au minimum 8 192 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 sélectionner un 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 à haute disponibilité.

  4. Vous pouvez également sélectionner Redimensionnement automatique des nœuds. Le redimensionnement signifie que les ressources de processeur virtuel 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 pour le cluster d'utilisateur sont redimensionnés en fonction du nombre de nœuds de calcul dans le 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 augmente.

  5. Vous pouvez également sélectionner Activer le plan de contrôle v2. Lorsque vous activez le plan de contrôle 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 plutôt que dans le cluster d'administrateur (appelé kubeception).

    Lorsque vous sélectionnez Activer le plan de contrôle v2, la section Adresses 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 le plan de contrôle V2 est activé, les champs de processeur virtuel et de 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 le plan de contrôle V2 n'est pas activé, les champs "Processeur virtuel", "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 Suivant 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, GKE sur VMware utilise le nom de la VM de 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.

Groupé avec MetalLB

Configurez l'équilibrage de charge groupé avec MetalLB. Vous ne pouvez utiliser MetalLB pour le cluster d'utilisateur que si votre cluster d'administrateur utilise SeeSaw ou MetalLB. Cette option nécessite une configuration minimale. MetalLB s'exécute directement sur les nœuds de votre cluster et ne nécessite pas de VM supplémentaires. Pour en savoir plus sur les avantages de MetalLB et les comparer aux autres options d'équilibrage de charge, consultez la page Équilibrage de charge groupé avec MetalLB.

  1. Dans la section Pools d'adresses, configurez au moins un pool d'adresses comme suit :

    1. Saisissez un nom pour le pool d'adresses.

    2. Saisissez une plage d'adresses IP contenant l'adresse IP virtuelle d'entrée au format CIDR (par exemple, 192.0.2.0/26) ou sous forme de plage (par exemple, 192.0.2.64-192.0.2.72). Pour spécifier une seule adresse IP dans un pool, utilisez /32 au format CIDR (par exemple, 192.0.2.1/32).

    3. Si les adresses IP de vos services de type LoadBalancer ne se trouvent pas dans la même plage d'adresses IP que l'adresse IP virtuelle d'entrée, cliquez sur + Ajouter une plage d'adresses IP et saisissez une autre plage d'adresses.

      Les adresses IP de chaque pool ne peuvent pas se chevaucher et doivent se trouver dans le même sous-réseau que les nœuds du cluster.

    4. Sous Attribution d'adresses IP, sélectionnez l'une des options suivantes :

      • Automatique : choisissez cette option si vous souhaitez que le contrôleur MetalLB attribue automatiquement des adresses IP du pool d'adresses aux services de type LoadBalancer.

      • Manuelle : choisissez cette option si vous comptez utiliser les adresses du pool pour spécifier manuellement des adresses pour les services de type LoadBalancer.

    5. Cliquez sur Éviter les adresses IP présentant des bugs si vous souhaitez que le contrôleur MetalLB n'utilise pas les adresses du pool qui se terminent par .0 ou .255. Cela évite le problème des bugs avec les appareils grand public qui suppriment par erreur le trafic envoyé à ces adresses IP spéciales.

    6. Lorsque vous avez fini, cliquez sur Terminé.

  2. Si nécessaire, cliquez sur Ajouter un pool d'adresses.

  3. Dans la section Adresses IP virtuelles, saisissez les informations suivantes :

    • Adresse IP virtuelle de plan de contrôle : l'adresse IP de destination à utiliser pour le trafic envoyé au serveur d'API Kubernetes du cluster d'utilisateur. Le serveur d'API Kubernetes du cluster d'utilisateur s'exécute sur un nœud du cluster d'administrateur. Cette adresse IP doit appartenir au même domaine L2 que les nœuds du cluster d'administrateur. N'ajoutez pas cette adresse dans la section Pools d'adresses.

    • Adresse IP virtuelle d'entrée : adresse IP à configurer sur l'équilibreur de charge pour le proxy d'entrée. Vous devez l'ajouter à un pool d'adresses dans la section Pools d'adresses.

  4. Cliquez sur Continuer.

F5 BIG-IP

Vous ne pouvez utiliser F5 BIG-IP pour le cluster d'utilisateur que si votre cluster d'administrateur utilise F5 BIG-IP. Assurez-vous d'installer et de configurer F5 BIG-IP ADC avant de l'intégrer à GKE sur VMware.

Le nom d'utilisateur et le mot de passe F5 sont hérités du cluster d'administrateur.

  1. Dans la section Adresses IP virtuelles, saisissez les informations suivantes :

    • Adresse IP virtuelle de plan de contrôle : l'adresse IP de destination à utiliser pour le trafic envoyé au serveur d'API Kubernetes.

    • Adresse IP virtuelle d'entrée : adresse IP à configurer sur l'équilibreur de charge pour le proxy d'entrée.

  2. Dans le champ Adresse, saisissez l'adresse de votre équilibreur de charge F5 BIG-IP.

  3. Dans le champ Partition, saisissez le nom d'une partition BIG-IP que vous avez créée pour votre cluster d'utilisateur.

  4. Dans le champ Nom du pool sNAT, saisissez le nom de votre pool SNAT, le cas échéant.

  5. Cliquez sur Continuer.

Mode manuel

Vous ne pouvez utiliser un équilibreur de charge manuel pour le cluster d'utilisateur que si votre cluster d'administrateur utilise un équilibreur de charge manuel. Dans GKE sur VMware, le serveur d'API Kubernetes et le proxy d'entrée sont tous deux exposés par un service Kubernetes de type LoadBalancer. Choisissez vos propres valeurs nodePort dans la plage 30 000 - 32 767 pour ces services. Pour le proxy d'entrée, choisissez une valeur nodePort pour le trafic HTTP et le trafic HTTPS. Pour en savoir plus, consultez la page Activer le mode d'équilibrage de charge manuel.

  1. Dans la section Adresses IP virtuelles, saisissez les informations suivantes :

    • Adresse IP virtuelle de plan de contrôle : l'adresse IP de destination à utiliser pour le trafic envoyé au serveur d'API Kubernetes.

    • Adresse IP virtuelle d'entrée : adresse IP à configurer sur l'équilibreur de charge pour le proxy d'entrée.

  2. Dans le champ Port du nœud de plan de contrôle, saisissez une valeur nodePort pour le serveur d'API Kubernetes.

  3. Dans le champ Port du nœud HTTP d'entrée, saisissez une valeur nodePort pour le trafic HTTP vers le proxy d'entrée.

  4. Dans le champ Port du nœud HTTPS d'entrée, saisissez une valeur nodePort pour le trafic HTTPS vers le proxy d'entrée.

  5. Dans le champ Port de nœud de serveur Konnectivity, saisissez une valeur nodePort pour le serveur Konnectivity.

  6. Cliquez sur Continuer.

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 :

  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 le 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 vCPUs pour chaque nœud du pool (au moins quatre par nœud de calcul de cluster d'utilisateur).
    3. Saisissez la taille de memory en mébioctets (Mio) pour chaque nœud du pool (la valeur doit être au minimum 8 192 Mio par nœud de calcul du cluster d'utilisateur et doit être un multiple de 4).
    4. Dans le champ Nœuds, saisissez le nombre de nœuds du pool (trois nœuds minimum). Si vous avez saisi des adresses IP statiques pour les adresses IP de nœuds dans la section Mise en réseau, assurez-vous d'avoir saisi suffisamment d'adresses IP pour accueillir ces nœuds de cluster d'utilisateur.
    5. Sélectionnez le type d'image d'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 MetalLB 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 15 minutes ou plus. La console affiche des messages d'état pendant qu'elle vérifie les paramètres et crée le cluster dans votre centre de données.

    Si une erreur survient lors de la vérification des paramètres, la console affiche un message d'erreur qui devrait être suffisamment clair pour que vous puissiez résoudre le problème de configuration et réessayer de créer le cluster.

    Pour en savoir plus sur les erreurs possibles et sur la manière de les corriger, consultez la page Résoudre les problèmes liés à la création de clusters d'utilisateur dans la console Google Cloud.

gcloud CLI

Exécutez la commande suivante pour 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 permettant de créer le cluster et le 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.

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 dans lequel 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'emplacement d'exécution des services Fleet et Connect. Les clusters d'administrateur créés avant la version 1.28 sont gérés par le parc mondial et les services Connect. À partir de la version 1.28, vous pouvez spécifier global ou une région Google Cloud lorsque vous créez le cluster d'administrateur. Vous devez spécifier la région dans l'option --admin-cluster-membership-location dans les exemples de commandes suivants.

  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 dans lequel 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 globale ou Google Cloud. 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 lors de la création du cluster. Il s'agit de la région dans laquelle l'API GKE On-Prem et les services Fleet and 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'utilisateur 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.

Examples

Les exemples suivants montrent comment créer un cluster d'utilisateur avec différents équilibreurs de charge. Pour en savoir plus sur les options d'équilibrage de charge disponibles, consultez la page Présentation de l'équilibreur de charge.

Les 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 options décrites dans la section Indicateurs de plan de contrôle. Si nécessaire, vous pouvez également modifier certains paramètres vSphere.

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

MetalLB et DHCP

Cet exemple montre comment créer un cluster d'utilisateur avec l'équilibreur de charge MetalLB groupé et comment utiliser votre serveur DHCP pour obtenir les adresses IP de vos nœuds de cluster.

Vous ne pouvez utiliser MetalLB pour le cluster d'utilisateur que si votre cluster d'administrateur utilise SeeSaw ou MetalLB. Cette option d'équilibrage de charge nécessite une configuration minimale. MetalLB s'exécute directement sur les nœuds de votre cluster et ne nécessite pas de VM supplémentaires. Pour en savoir plus sur les avantages de MetalLB et les comparer aux autres options d'équilibrage de charge, consultez la page Équilibrage de charge groupé avec MetalLB.

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=SERVICE_CIDR_BLOCK \
    --pod-address-cidr-blocks=POD_CIDR_BLOCK \
    --metal-lb-config-address-pools='pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \
    --control-plane-vip=CONTROL_PLANE_VIP \
    --ingress-vip=INGRESS_VIP \
    --enable-dhcp

Remplacez les éléments suivants :

  • USER_CLUSTER_NAME: nom de votre choix pour votre cluster d'utilisateur. Le nom ne peut plus ê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.
  • FLEET_HOST_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 projet 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 du parc ne peut plus être modifié une fois le cluster créé.
  • ADMIN_CLUSTER_NAME: nom du cluster d'administrateur qui gère le cluster d'utilisateur. Dans l'option --admin-cluster-membership, vous pouvez utiliser le nom de cluster complet, au format suivant: 
        projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME

    Vous pouvez également définir --admin-cluster-membership sur le nom du cluster d'administrateur, comme dans l'exemple de commande. Lorsque vous n'utilisez que le nom du cluster d'administrateur, définissez l'ID de projet du cluster d'administrateur sur --admin-cluster-membership-project et l'emplacement sur --admin-cluster-membership-location. L'emplacement du cluster d'administrateur est global ou une région Google Cloud. Pour trouver la région, exécutez gcloud container fleet memberships list.

  • REGION: région Google Cloud dans laquelle l'API GKE On-Prem (gkeonprem.googleapis.com), le service de parc (gkehub.googleapis.com) et le service Connect (gkeconnect.googleapis.com) sont exécutés. Spécifiez us-west1 ou une autre région disponible. Une fois le cluster créé, la région ne peut plus être modifiée. Ce paramètre spécifie la région dans laquelle sont stockés les éléments suivants :
    • 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

    Ensemble, le nom, le projet et l'emplacement du cluster identifient de manière unique le cluster dans Google Cloud.

  • VERSION: version de GKE sur VMware pour votre cluster d'utilisateur.
  • YOUR_EMAIL_ADDRESS et ANOTHER_EMAIL_ADDRESS : si vous n'incluez pas l'option --admin-users, en tant que créateur du cluster, vous disposez par défaut des droits d'administrateur de cluster. Toutefois, si vous incluez --admin-users pour désigner un autre utilisateur comme administrateur, vous ignorez la valeur par défaut et devez inclure à la fois votre adresse e-mail et celle de l'autre administrateur. Par exemple, pour ajouter deux administrateurs: 
        --admin-users=sara@example.com \
    --admin-users=amal@example.com

    Lorsque le cluster est créé, l'API GKE On-Prem applique au cluster les stratégies de contrôle des accès basé sur les rôles (RBAC) de Kubernetes pour vous accorder, ainsi qu'aux autres administrateurs, le rôle Kubernetes clusterrole/cluster-admin, qui fournit un accès complet à toutes les ressources du cluster dans tous les espaces de noms.

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

    Exemple : --service-address-cidr-blocks=10.96.0.0/20

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

    Exemple : --pod-address-cidr-blocks=192.168.0.0/16

  • --metal-lb-config-address-pools: incluez cette option pour spécifier la configuration des pools d'adresses que l'équilibreur de charge MetalLB doit utiliser. La valeur de cette option a le format suivant :
    --metal-lb-config-address-pool 'pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \

    La valeur comporte des segments qui commencent par les mots clés pool, avoid-buggy-ip, manual-assign et addresses. Séparez chaque segment par une virgule.

    • pool: nom de votre choix pour le pool.
    • avoid-buggy-ips1: si vous définissez ce paramètre sur True, le contrôleur MetalLB n'attribue pas d'adresses IP se terminant par .0 ou .255 aux services. Cela permet d'éviter que les appareils grand public qui présentent des bugs ne supprennent par erreur le trafic envoyé à ces adresses IP spéciales. Si aucune valeur n'est spécifiée, la valeur par défaut est False.
    • manual-assign: si vous ne souhaitez pas que le contrôleur MetalLB attribue automatiquement les adresses IP de ce pool aux services, définissez ce paramètre sur True. Un développeur peut ensuite créer un service de type LoadBalancer et spécifier manuellement l'une des adresses du pool. Si aucune valeur n'est spécifiée, manual-assign est défini sur False.
    • Dans la liste addresses: chaque adresse doit être une plage en notation CIDR ou au format de plage avec trait d'union. Pour spécifier une adresse IP unique 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.

    Veuillez noter les points suivants :

    • Entourez la valeur entière de guillemets simples.
    • Les espaces blancs ne sont pas autorisés.
    • Séparez chaque plage d'adresses IP par un point-virgule.

    Exemple :

    --metal-lb-config-address-pool 'pool=pool1,avoid-buggy-ips=True,manual-assign=True,addresses=10.251.134.80/32;192.168.1.0/26;192.168.1.2-192.168.1.3'
  • CONTROL_PLANE_VIP: adresse IP que vous avez choisi de configurer sur l'équilibreur de charge pour le serveur d'API Kubernetes du cluster d'utilisateur.

    Exemple : --control-plane-vip=203.0.113.3

  • INGRESS_VIP: adresse IP que vous avez choisi de configurer sur l'équilibreur de charge pour le proxy d'entrée.

    Exemple : --ingress-vip=10.251.134.80

    L'adresse IP de l'adresse IP virtuelle d'entrée doit se trouver dans l'un des pools d'adresses MetalLB.

  • --enable-dhcp: incluez --enable-dhcp si vous souhaitez que les nœuds de votre cluster obtiennent leur adresse IP à partir d'un serveur DHCP que vous fournissez. N'incluez pas cette option si vous souhaitez fournir des adresses IP statiques pour vos nœuds de cluster ou si vous souhaitez configurer l'équilibrage de charge manuel.

MetalLB et adresses IP statiques

Cet exemple montre comment créer un cluster d'utilisateur avec l'équilibreur de charge MetalLB groupé et comment attribuer des adresses IP statiques à vos nœuds de cluster.

Vous ne pouvez utiliser MetalLB pour le cluster d'utilisateur que si votre cluster d'administrateur utilise SeeSaw ou MetalLB. Cette option d'équilibrage de charge nécessite une configuration minimale. MetalLB s'exécute directement sur les nœuds de votre cluster et ne nécessite pas de VM supplémentaires. Pour en savoir plus sur les avantages de MetalLB et les comparer aux autres options d'équilibrage de charge, consultez la page Équilibrage de charge groupé avec MetalLB.

Veillez à faire défiler la page si nécessaire pour remplir l'espace réservé ADMIN_CLUSTER_NAME pour l'option --admin-cluster-membership. Cet exemple utilise le nom complet du cluster d'administrateur. Vous n'avez donc pas besoin d'inclure --admin-cluster-membership-location et --admin-cluster-membership-project.

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=SERVICE_CIDR_BLOCK \
    --pod-address-cidr-blocks=POD_CIDR_BLOCK \
    --metal-lb-config-address-pools='pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \
    --control-plane-vip=CONTROL_PLANE_VIP \
    --ingress-vip=INGRESS_VIP \
    --static-ip-config-ip-blocks='gateway=GATEWAY,netmask=NETMASK,ips=IP_ADDRESS_1;IP_ADDRESS_2 HOST_2;...' \
    --dns-servers=DNS_SERVER,... \
    --dns-search-domains=DNS_SEARCH_DOMAIN,... \
    --ntp-servers=NTP_SERVER,...

Remplacez les éléments suivants :

  • USER_CLUSTER_NAME: nom de votre choix pour votre cluster d'utilisateur. Le nom ne peut plus ê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.
  • FLEET_HOST_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 projet 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 du parc ne peut plus être modifié une fois le cluster créé.
  • ADMIN_CLUSTER_NAME: nom du cluster d'administrateur qui gère le cluster d'utilisateur. Dans l'option --admin-cluster-membership, vous pouvez utiliser le nom de cluster complet, au format suivant: 
        projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME

    Vous pouvez également définir --admin-cluster-membership sur le nom du cluster d'administrateur, comme dans l'exemple de commande. Lorsque vous n'utilisez que le nom du cluster d'administrateur, définissez l'ID de projet du cluster d'administrateur sur --admin-cluster-membership-project et l'emplacement sur --admin-cluster-membership-location. L'emplacement du cluster d'administrateur est global ou une région Google Cloud. Pour trouver la région, exécutez gcloud container fleet memberships list.

  • REGION: région Google Cloud dans laquelle l'API GKE On-Prem (gkeonprem.googleapis.com), le service de parc (gkehub.googleapis.com) et le service Connect (gkeconnect.googleapis.com) sont exécutés. Spécifiez us-west1 ou une autre région disponible. Une fois le cluster créé, la région ne peut plus être modifiée. Ce paramètre spécifie la région dans laquelle sont stockés les éléments suivants :
    • 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

    Ensemble, le nom, le projet et l'emplacement du cluster identifient de manière unique le cluster dans Google Cloud.

  • VERSION: version de GKE sur VMware pour votre cluster d'utilisateur.
  • YOUR_EMAIL_ADDRESS et ANOTHER_EMAIL_ADDRESS : si vous n'incluez pas l'option --admin-users, en tant que créateur du cluster, vous disposez par défaut des droits d'administrateur de cluster. Toutefois, si vous incluez --admin-users pour désigner un autre utilisateur comme administrateur, vous ignorez la valeur par défaut et devez inclure à la fois votre adresse e-mail et celle de l'autre administrateur. Par exemple, pour ajouter deux administrateurs: 
        --admin-users=sara@example.com \
    --admin-users=amal@example.com

    Lorsque le cluster est créé, l'API GKE On-Prem applique au cluster les stratégies de contrôle des accès basé sur les rôles (RBAC) de Kubernetes pour vous accorder, ainsi qu'aux autres administrateurs, le rôle Kubernetes clusterrole/cluster-admin, qui fournit un accès complet à toutes les ressources du cluster dans tous les espaces de noms.

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

    Exemple : --service-address-cidr-blocks=10.96.0.0/20

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

    Exemple : --pod-address-cidr-blocks=192.168.0.0/16

  • --metal-lb-config-address-pools: incluez cette option pour spécifier la configuration des pools d'adresses que l'équilibreur de charge MetalLB doit utiliser. La valeur de cette option a le format suivant :
    --metal-lb-config-address-pool 'pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \

    La valeur comporte des segments qui commencent par les mots clés pool, avoid-buggy-ip, manual-assign et addresses. Séparez chaque segment par une virgule.

    • pool: nom de votre choix pour le pool.
    • avoid-buggy-ips1: si vous définissez ce paramètre sur True, le contrôleur MetalLB n'attribue pas d'adresses IP se terminant par .0 ou .255 aux services. Cela permet d'éviter que les appareils grand public qui présentent des bugs ne supprennent par erreur le trafic envoyé à ces adresses IP spéciales. Si aucune valeur n'est spécifiée, la valeur par défaut est False.
    • manual-assign: si vous ne souhaitez pas que le contrôleur MetalLB attribue automatiquement les adresses IP de ce pool aux services, définissez ce paramètre sur True. Un développeur peut ensuite créer un service de type LoadBalancer et spécifier manuellement l'une des adresses du pool. Si aucune valeur n'est spécifiée, manual-assign est défini sur False.
    • Dans la liste addresses: chaque adresse doit être une plage en notation CIDR ou au format de plage avec trait d'union. Pour spécifier une adresse IP unique 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.

    Veuillez noter les points suivants :

    • Entourez la valeur entière de guillemets simples.
    • Les espaces blancs ne sont pas autorisés.
    • Séparez chaque plage d'adresses IP par un point-virgule.

    Exemple :

    --metal-lb-config-address-pool 'pool=pool1,avoid-buggy-ips=True,manual-assign=True,addresses=10.251.134.80/32;192.168.1.0/26;192.168.1.2-192.168.1.3'
  • CONTROL_PLANE_VIP: adresse IP que vous avez choisi de configurer sur l'équilibreur de charge pour le serveur d'API Kubernetes du cluster d'utilisateur.

    Exemple : --control-plane-vip=203.0.113.3

  • INGRESS_VIP: adresse IP que vous avez choisi de configurer sur l'équilibreur de charge pour le proxy d'entrée.

    Exemple : --ingress-vip=10.251.134.80

    L'adresse IP de l'adresse IP virtuelle d'entrée doit se trouver dans l'un des pools d'adresses MetalLB.

  • --static-ip-config-ip-blocks: spécifiez la passerelle par défaut, le masque de sous-réseau et la liste des adresses IP statiques des nœuds de calcul du cluster d'utilisateur. La valeur de cette option a le format suivant :
    --static-ip-config-ip-blocks 'gateway=GATEWAY,netmask=NETMASK,ips=IP_ADDRESS_1;IP_ADDRESS_2 HOST_2;...'

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

    Veuillez noter les points suivants :

    • Entourez la valeur entière de guillemets simples.
    • Les espaces 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. Lorsque vous ne spécifiez pas de nom d'hôte, GKE sur VMware utilise le nom de la VM de vSphere comme nom d'hôte.
    • Si vous spécifiez un bloc CIDR, ne spécifiez pas de valeur pour le nom d'hôte.

    Exemple :

    --static-ip-config-ip-blocks 'gateway=172.16.23.254,netmask=255.255.252.0,ips=172.16.20.10;172.16.20.11 host2;172.16.20.12/30'
  • DNS_SERVER: liste des adresses IP des serveurs DNS pour les VM, séparées par une virgule.
  • DNS_SEARCH_DOMAIN: liste des domaines de recherche DNS séparés par une virgule pour les hôtes à utiliser. Ces domaines sont utilisés dans le cadre d'une liste de recherche de domaines.

    Exemple :

    --dns-search-domains example.com,examplepetstore.com
  • NTP_SERVER: liste des adresses IP des serveurs de temps à utiliser, séparées par une virgule.

F5 BIG-IP et DHCP

Cet exemple montre comment créer un cluster d'utilisateur avec votre équilibreur de charge F5 BIG-IP et comment utiliser votre serveur DHCP pour obtenir les adresses IP de vos nœuds de cluster.

Vous ne pouvez utiliser F5 pour le cluster d'utilisateur que si votre cluster d'administrateur utilise F5. Assurez-vous d'installer et de configurer F5 BIG-IP ADC avant de l'intégrer à GKE sur VMware.

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=SERVICE_CIDR_BLOCK \
    --pod-address-cidr-blocks=POD_CIDR_BLOCK \
    --f5-config-address=F5_CONFIG_ADDRESS \
    --f5-config-partition=F5_CONFIG_PARTITION \
    --f5-config-snat-pool=F5_CONFIG_SNAT_POOL \
    --control-plane-vipCONTROL_PLANE_VIP \
    --ingress-vip=INGRESS_VIP \
    --enable-dhcp
  • USER_CLUSTER_NAME: nom de votre choix pour votre cluster d'utilisateur. Le nom ne peut plus ê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.
  • FLEET_HOST_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 projet 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 du parc ne peut plus être modifié une fois le cluster créé.
  • ADMIN_CLUSTER_NAME: nom du cluster d'administrateur qui gère le cluster d'utilisateur. Dans l'option --admin-cluster-membership, vous pouvez utiliser le nom de cluster complet, au format suivant: 
        projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME

    Vous pouvez également définir --admin-cluster-membership sur le nom du cluster d'administrateur, comme dans l'exemple de commande. Lorsque vous n'utilisez que le nom du cluster d'administrateur, définissez l'ID de projet du cluster d'administrateur sur --admin-cluster-membership-project et l'emplacement sur --admin-cluster-membership-location. L'emplacement du cluster d'administrateur est global ou une région Google Cloud. Pour trouver la région, exécutez gcloud container fleet memberships list.

  • REGION: région Google Cloud dans laquelle l'API GKE On-Prem (gkeonprem.googleapis.com), le service de parc (gkehub.googleapis.com) et le service Connect (gkeconnect.googleapis.com) sont exécutés. Spécifiez us-west1 ou une autre région disponible. Une fois le cluster créé, la région ne peut plus être modifiée. Ce paramètre spécifie la région dans laquelle sont stockés les éléments suivants :
    • 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

    Ensemble, le nom, le projet et l'emplacement du cluster identifient de manière unique le cluster dans Google Cloud.

  • VERSION: version de GKE sur VMware pour votre cluster d'utilisateur.
  • YOUR_EMAIL_ADDRESS et ANOTHER_EMAIL_ADDRESS : si vous n'incluez pas l'option --admin-users, en tant que créateur du cluster, vous disposez par défaut des droits d'administrateur de cluster. Toutefois, si vous incluez --admin-users pour désigner un autre utilisateur comme administrateur, vous ignorez la valeur par défaut et devez inclure à la fois votre adresse e-mail et celle de l'autre administrateur. Par exemple, pour ajouter deux administrateurs: 
        --admin-users=sara@example.com \
    --admin-users=amal@example.com

    Lorsque le cluster est créé, l'API GKE On-Prem applique au cluster les stratégies de contrôle des accès basé sur les rôles (RBAC) de Kubernetes pour vous accorder, ainsi qu'aux autres administrateurs, le rôle Kubernetes clusterrole/cluster-admin, qui fournit un accès complet à toutes les ressources du cluster dans tous les espaces de noms.

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

    Exemple : --service-address-cidr-blocks=10.96.0.0/20

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

    Exemple : --pod-address-cidr-blocks=192.168.0.0/16

  • F5_CONFIG_ADDRESS: adresse de votre équilibreur de charge F5 BIG-IP.

  • F5_CONFIG_PARTITION:nom d'une partition BIG-IP que vous avez créée pour votre cluster d'utilisateur.

  • F5_CONFIG_SNAT_POOL: nom de votre pool SNAT, le cas échéant.

  • CONTROL_PLANE_VIP: adresse IP que vous avez choisi de configurer sur l'équilibreur de charge pour le serveur d'API Kubernetes du cluster d'utilisateur.

    Exemple : --control-plane-vip=203.0.113.3

  • INGRESS_VIP: adresse IP que vous avez choisi de configurer sur l'équilibreur de charge pour le proxy d'entrée.

    Exemple : --ingress-vip=10.251.134.80

    L'adresse IP de l'adresse IP virtuelle d'entrée doit se trouver dans l'un des pools d'adresses MetalLB.

  • --enable-dhcp: incluez --enable-dhcp si vous souhaitez que les nœuds de votre cluster obtiennent leur adresse IP à partir d'un serveur DHCP que vous fournissez. N'incluez pas cette option si vous souhaitez fournir des adresses IP statiques pour vos nœuds de cluster ou si vous souhaitez configurer l'équilibrage de charge manuel.

Équilibrage de charge manuel et adresses IP statiques

Cet exemple montre comment créer un cluster d'utilisateur avec un équilibreur de charge manuel et attribuer des adresses IP statiques à vos nœuds de cluster.

Vous ne pouvez utiliser un équilibreur de charge manuel pour le cluster d'utilisateur que si votre cluster d'administrateur utilise un équilibreur de charge manuel. Dans GKE sur VMware, le serveur d'API Kubernetes, le proxy d'entrée et le service complémentaire d'agrégation des journaux sont tous deux exposés par un service Kubernetes de type LoadBalancer. Choisissez vos propres valeurs nodePort dans la plage 30 000 - 32 767 pour ces services. Pour le proxy d'entrée, choisissez une valeur nodePort pour le trafic HTTP et le trafic HTTPS. Pour en savoir plus, consultez la page Activer le mode d'équilibrage de charge manuel.

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=SERVICE_CIDR_BLOCK \
    --pod-address-cidr-blocks=POD_CIDR_BLOCK \
    --control-plane-vip=CONTROL_PLANE_VIP \
    --control-plane-node-port=CONTROL_PLANE_NODE_PORT \
    --ingress-vip=INGRESS_VIP \
    --ingress-http-node-port=INGRESS_HTTP_NODE_PORT \
    --ingress-https-node-port=INGRESS_HTTPS_NODE_PORT \
    --konnectivity-server-node-port=KONNECTIVITY_SERVER_NODE_PORT

Remplacez les éléments suivants :

  • USER_CLUSTER_NAME: nom de votre choix pour votre cluster d'utilisateur. Le nom ne peut plus ê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.
  • FLEET_HOST_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 projet 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 du parc ne peut plus être modifié une fois le cluster créé.
  • ADMIN_CLUSTER_NAME: nom du cluster d'administrateur qui gère le cluster d'utilisateur. Dans l'option --admin-cluster-membership, vous pouvez utiliser le nom de cluster complet, au format suivant: 
        projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME

    Vous pouvez également définir --admin-cluster-membership sur le nom du cluster d'administrateur, comme dans l'exemple de commande. Lorsque vous n'utilisez que le nom du cluster d'administrateur, définissez l'ID de projet du cluster d'administrateur sur --admin-cluster-membership-project et l'emplacement sur --admin-cluster-membership-location. L'emplacement du cluster d'administrateur est global ou une région Google Cloud. Pour trouver la région, exécutez gcloud container fleet memberships list.

  • REGION: région Google Cloud dans laquelle l'API GKE On-Prem (gkeonprem.googleapis.com), le service de parc (gkehub.googleapis.com) et le service Connect (gkeconnect.googleapis.com) sont exécutés. Spécifiez us-west1 ou une autre région disponible. Une fois le cluster créé, la région ne peut plus être modifiée. Ce paramètre spécifie la région dans laquelle sont stockés les éléments suivants :
    • 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

    Ensemble, le nom, le projet et l'emplacement du cluster identifient de manière unique le cluster dans Google Cloud.

  • VERSION: version de GKE sur VMware pour votre cluster d'utilisateur.
  • YOUR_EMAIL_ADDRESS et ANOTHER_EMAIL_ADDRESS : si vous n'incluez pas l'option --admin-users, en tant que créateur du cluster, vous disposez par défaut des droits d'administrateur de cluster. Toutefois, si vous incluez --admin-users pour désigner un autre utilisateur comme administrateur, vous ignorez la valeur par défaut et devez inclure à la fois votre adresse e-mail et celle de l'autre administrateur. Par exemple, pour ajouter deux administrateurs: 
        --admin-users=sara@example.com \
    --admin-users=amal@example.com

    Lorsque le cluster est créé, l'API GKE On-Prem applique au cluster les stratégies de contrôle des accès basé sur les rôles (RBAC) de Kubernetes pour vous accorder, ainsi qu'aux autres administrateurs, le rôle Kubernetes clusterrole/cluster-admin, qui fournit un accès complet à toutes les ressources du cluster dans tous les espaces de noms.

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

    Exemple : --service-address-cidr-blocks=10.96.0.0/20

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

    Exemple : --pod-address-cidr-blocks=192.168.0.0/16

  • CONTROL_PLANE_VIP: adresse IP que vous avez choisi de configurer sur l'équilibreur de charge pour le serveur d'API Kubernetes du cluster d'utilisateur.

    Exemple : --control-plane-vip=203.0.113.3

  • CONTROL_PLANE_NODE_PORT: valeur nodePort pour le serveur d'API Kubernetes.

  • INGRESS_VIP: adresse IP que vous avez choisi de configurer sur l'équilibreur de charge pour le proxy d'entrée.

    Exemple : --ingress-vip=203.0.113.4

  • INGRESS_HTTP_NODE_PORT: valeur nodePort pour le trafic HTTP vers le proxy d'entrée

  • INGRESS_HTTPS_NODE_PORT: valeur nodePort pour le trafic HTTPS vers le proxy d'entrée.

  • KONNECTIVITY_SERVER_NODE_PORT: valeur nodePort pour le serveur Konnectivity.

  • --static-ip-config-ip-blocks: spécifiez la passerelle par défaut, le masque de sous-réseau et la liste des adresses IP statiques des nœuds de calcul du cluster d'utilisateur. La valeur de cette option a le format suivant :
    --static-ip-config-ip-blocks 'gateway=GATEWAY,netmask=NETMASK,ips=IP_ADDRESS_1;IP_ADDRESS_2 HOST_2;...'

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

    Veuillez noter les points suivants :

    • Entourez la valeur entière de guillemets simples.
    • Les espaces 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. Lorsque vous ne spécifiez pas de nom d'hôte, GKE sur VMware utilise le nom de la VM de vSphere comme nom d'hôte.
    • Si vous spécifiez un bloc CIDR, ne spécifiez pas de valeur pour le nom d'hôte.

    Exemple :

    --static-ip-config-ip-blocks 'gateway=172.16.23.254,netmask=255.255.252.0,ips=172.16.20.10;172.16.20.11 host2;172.16.20.12/30'
  • DNS_SERVER: liste des adresses IP des serveurs DNS pour les VM, séparées par une virgule.
  • DNS_SEARCH_DOMAIN: liste des domaines de recherche DNS séparés par une virgule pour les hôtes à utiliser. Ces domaines sont utilisés dans le cadre d'une liste de recherche de domaines.

    Exemple :

    --dns-search-domains example.com,examplepetstore.com
  • NTP_SERVER: liste des adresses IP des serveurs de temps à utiliser, séparées par une virgule.

Indicateurs de plan de contrôle

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

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

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

  • --replicas=NODES: nombre de nœuds du plan de contrôle pour votre cluster d'utilisateur. Par exemple, vous pouvez sélectionner un 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 à 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 processeur virtuel 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 pour le cluster d'utilisateur sont redimensionnés en fonction du nombre de nœuds de calcul dans le 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 augmente.

  • --enable-control-plane-v2: si vous souhaitez activer le plan de contrôle V2, incluez --enable-control-plane-v2. Lorsque le plan de contrôle V2 est activé, 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. Par défaut, le plan de contrôle d'un cluster d'utilisateur s'exécute sur un ou plusieurs nœuds du cluster d'administrateur (appelé modèle kubeception). Lorsque le plan de contrôle V2 est activé, les valeurs de --cpus et --memory 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 dans --control-plane-ip-block. Lorsque le plan de contrôle V2 n'est pas activé, les valeurs de --cpus, --memory et --replicas s'appliquent aux nœuds du plan de contrôle dans le cluster d'administrateur. Assurez-vous de réserver suffisamment d'adresses IP pour votre cluster d'administrateur.

    Si vous activez le plan de contrôle V2, vous devez également spécifier les indicateurs suivants:

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

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

    • --control-plane-ip-block, au 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 qui commencent par les mots clés gateway, netmask et ips. Séparez les segments par une virgule.

      Veuillez noter les points suivants :

      • Entourez la valeur entière de 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 séparés par une virgule pour les hôtes à utiliser. 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 indicateurs et leur description, consultez la documentation de référence de gcloud CLI.

    Indicateurs vSphere

    Spécifiez les options facultatives suivantes si nécessaire:

  • --disable-aag-config: si vous n'incluez pas cet indicateur, les règles d'anti-affinité VMware Distributed Resource Scheduler (DRS) sont automatiquement créées pour les nœuds de votre cluster d'utilisateur, ce qui entraîne leur propagation 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 le 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, ajoutez cet indicateur.

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

    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 options de la commande gcloud. Lorsque vous êtes prêt à créer le cluster, supprimez cet indicateur et exécutez la commande.

    La sortie de la commande ressemble à ceci :

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

    Dans l'exemple de résultat, la chaîne operation-1679543737105-5f7893fd5bae9-942b3f97-75e59179 correspond au OPERATION_ID de l'opération de longue durée. Vous pouvez vérifier 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 page gcloud container vmware operation.

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

    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 les 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 dans lequel le cluster 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 ce paramètre sur l'une des valeurs suivantes: ubuntu_containerd ou cos.

  • BOOT_DISK_SIZE: taille du disque de démarrage en gibioctets (Gio) pour chaque nœud du pool. La valeur minimale est de 40 Gio.

  • vCPUs: nombre de processeurs virtuels pour chaque nœud du pool de nœuds. Le minimum est de 4.

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

  • NODES : Nombre de nœuds dans le pool de nœuds. Le nombre minimal est de 3.

  • Si vous utilisez MetalLB comme équilibreur de charge, vous pouvez éventuellement inclure --enable-load-balancer si vous souhaitez autoriser le haut-parleur 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 page Ajouter un pool de nœuds et la documentation de référence de gcloud CLI.

Exemples de commandes gcloud

MetalLB et DHCP

gcloud container vmware clusters create user-cluster-1 \
    --project=example-project-12345 \
    --location=us-west1 \
    --admin-cluster-membership=projects/example-project-12345/locations/global/memberships/admin-cluster-1 \
    --version=1.28.200-gke.111 \
    --admin-users=sara@example.com \
    --admin-users=amal@example.com \
    --enable-dhcp \
    --service-address-cidr-blocks=10.96.232.0/24 \
    --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=10.251.133.0/24;10.251.134.80/32;10.251.134.81/32' \
    --metal-lb-config-address-pools='pool=lb-pool-2,manual-assign=True,addresses=172.16.20.62/32' \
    --control-plane-vip=172.16.20.61 \
    --ingress-vip=172.16.20.62

Pour obtenir une description de l'option --metal-lb-config-address-pools, consultez la section Équilibreur de charge.

MetalLB et adresses IP statiques

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.28.200-gke.111 \
    --admin-users=sara@example.com \
    --admin-users=amal@example.com \
    --static-ip-config-ip-blocks='gateway=172.16.23.254,netmask=255.255.252.0,ips=172.16.20.10 user-vm-1;172.16.20.11 user-vm-2' \
    --static-ip-config-ip-blocks='gateway=172.16.23.255,netmask=255.255.252.0,ips=172.16.20.12 user-vm-3;172.16.20.13 extra-vm' \
    --dns-servers=203.0.113.1,198.51.100.1 \
    --dns-search-domains=example.com,altostrat.com \
    --ntp-servers=216.239.35.4,216.239.35.5 \
    --service-address-cidr-blocks=10.96.232.0/24 \
    --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=10.251.133.0/24;10.251.134.80/32;10.251.134.81/32' \
    --metal-lb-config-address-pools='pool=lb-pool-2,manual-assign=True,addresses=172.16.20.62/32' \
    --control-plane-vip=172.16.20.61 \
    --ingress-vip=172.16.20.62

F5 BIG-IP et DHCP

gcloud container vmware clusters create user-cluster-2 \
    --project=example-project-12345 \
    --location=us-west1 \
    --admin-cluster-membership=projects/example-project-12345/locations/global/memberships/admin-cluster-1 \
    --version=1.28.200-gke.111 \
    --admin-users=sara@example.com \
    --admin-users=amal@example.com \
    --enable-dhcp \
    --service-address-cidr-blocks=10.96.232.0/24 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --f5-config-address=203.0.113.2 \
    --f5-config-partition=my-f5-admin-partition \
    --control-plane-vip=172.16.20.61 \
    --ingress-vip=172.16.20.62

Pour obtenir une description des options F5, consultez la section Équilibreur de charge.

Équilibrage de charge manuel et adresses IP statiques

gcloud container vmware clusters create user-cluster-4 \
    --project=example-project-12345 \
    --location=asia-east1 \
    --admin-cluster-membership=projects/example-project-12345/locations/global/memberships/admin-cluster-1 \
    --version=1.28.200-gke.111 \
    --admin-users=sara@example.com \
    --admin-users=amal@example.com \
    --static-ip-config-ip-blocks='gateway=172.16.23.254,netmask=255.255.252.0,ips=172.16.20.10 user-vm-1;172.16.20.11 user-vm-2' \
    --static-ip-config-ip-blocks='gateway=172.16.23.255,netmask=255.255.252.0,ips=172.16.20.12 user-vm-3;172.16.20.13 extra-vm' \
    --dns-servers=203.0.113.1,198.51.100.1  \
    --ntp-servers=216.239.35.4,216.239.35.5 \
    --service-address-cidr-blocks=10.96.232.0/24 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --control-plane-vip=172.16.20.61 \
    --control-plane-node-port=30968 \
    --ingress-vip=172.16.20.62 \
    --ingress-http-node-port=32527 \
    --ingress-https-node-port=30139 \
    --konnectivity-server-node-port=30969

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 dans lequel 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'emplacement d'exécution des services Fleet et Connect. Les clusters d'administrateur créés avant la version 1.28 sont gérés par le parc mondial et les services Connect. À partir de la version 1.28, 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 dans lequel 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 globale ou Google Cloud. 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 lors de la création du cluster. Il s'agit de la région dans laquelle l'API GKE On-Prem et les services Fleet and 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'utilisateur 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 groupé et un pool de nœuds.

Pour obtenir plus d'informations et d'autres exemples, consultez la documentation de référence sur 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 groupé 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. Créez une copie du fichier terraform.tfvars.sample:

    cp terraform.tfvars.sample terraform.tfvars

  3. Modifiez les valeurs de 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 projet 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 du parc ne peut plus être modifié une fois le cluster créé.

    • region: région Google Cloud dans laquelle l'API GKE On-Prem (gkeonprem.googleapis.com), le service de parc (gkehub.googleapis.com) et le service Connect (gkeconnect.googleapis.com) sont exécutés. 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. Dans cet exemple, nous partons du principe 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, puis enregistrez le fichier.

    • on_prem_version: version de GKE sur VMware 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 la section Installer une version ultérieure à celle du cluster d'administrateur.

    • admin_user_emails: liste des adresses e-mail des utilisateurs disposant de droits d'administrateur sur le cluster. Veillez à ajouter votre adresse e-mail si vous avez l'intention d'administrer le cluster.

      Lorsque le cluster est créé, l'API GKE On-Prem applique au cluster les stratégies de contrôle des accès basé sur les rôles (RBAC) de Kubernetes pour attribuer aux administrateurs le rôle Kubernetes clusterrole/cluster-admin, qui fournit un accès complet à toutes les ressources 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 votre cluster d'utilisateur. Une fois le cluster créé, son nom ne peut plus être modifié. 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 processeurs virtuels pour chaque nœud de plan de contrôle de votre cluster d'utilisateur. Le minimum est de 4 vCPU.

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

    • control_plane_node_replicas: nombre de nœuds du plan de contrôle pour votre cluster d'utilisateur. Par exemple, vous pouvez indiquer un 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 à haute disponibilité.

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

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

    • lb_address_pools: liste des mappages définissant les pools d'adresses qui seront utilisés par l'équilibreur de charge MetalLB. L'adresse IP virtuelle d'entrée doit se trouver dans 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 dans la notation 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: Configurer les paramètres du cluster dans main.tf

Cette section décrit certaines modifications de configuration facultatives que vous pouvez effectuer dans main.tf. Avant d'apporter des modifications, effectuez 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. Le 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 éléments suivants par vos valeurs:

    • service_address_cidr_blocks: 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: 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 que les VM doivent utiliser.

    • 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 le plan de contrôle V2

Par défaut, main.tf configure le plan de contrôle pour que le cluster d'utilisateur 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 le plan de contrôle V2. Lorsque le plan de contrôle V2 est activé, 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. Pour configurer le plan de contrôle 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 des nœuds de votre 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 toutes les bibliothèques nécessaires, comme le fournisseur Google Cloud.

  2. Examinez la configuration et apportez des modifications si nécessaire:

    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 ou plus, et la création du pool de nœuds prend environ 15 minutes. Vous pouvez afficher le cluster dans la console Google Cloud sur la page Clusters Anthos.

Installer une version ultérieure à celle du cluster d'administrateur

Un cluster d'administrateur peut gérer des clusters d'utilisateur sous différentes versions. Si vous souhaitez créer un cluster d'utilisateur dont la version est ulté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'utilisateur de cette version, comme suit:

  1. 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 \
    --location=REGION

    Remplacez les éléments suivants :

    • ADMIN_CLUSTER_NAME: nom du cluster d'administrateur.

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

    • REGION: région Google Cloud dans laquelle l'API GKE On-Prem s'exécute. Il s'agit de la région que vous spécifierez lors de la création du cluster d'utilisateur. Spécifiez us-west1 ou une autre région disponible.

    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 installées sur le cluster d'administrateur sont annotées avec isInstalled=true.

  2. Si vous ne l'avez pas déjà fait, enregistrez le cluster d'administrateur dans l'API GKE On-Prem. Une fois le cluster enregistré dans l'API GKE On-Prem, vous n'avez pas besoin de répéter cette étape.

  3. Téléchargez la nouvelle version des composants et déployez-les dans le cluster d'administrateur:

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

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

Dépannage

Consultez la section Dépanner la création et la mise à niveau du cluster.

Étapes suivantes