Créer un cluster d'utilisateur à l'aide de clients d'API GKE On-Prem

Cette page explique comment créer un cluster d'utilisateur à l'aide de la console Google Cloud, de Google Cloud CLI (gcloud CLI) ou de Terraform.

Qu'est-ce que l'API GKE On-Prem ?

L'API GKE On-Prem est une API hébergée par Google Cloud qui vous permet de gérer le cycle de vie de vos clusters sur site à l'aide de Terraform et des applications Google Cloud standards. L'API GKE On-Prem s'exécute sur l'infrastructure Google Cloud. Terraform, la console et gcloud CLI sont des clients de l'API. Ils l'utilisent pour créer des clusters dans votre centre de données.

Pour gérer le cycle de vie de vos clusters, l'API GKE On-Prem doit stocker les métadonnées sur l'état de votre cluster dans Google Cloud, en utilisant la région Google Cloud que vous spécifiez lors de la création du cluster. Ces métadonnées permettent à l'API de gérer le cycle de vie du cluster et n'incluent pas de données spécifiques à la charge de travail.

Lorsque vous créez un cluster à l'aide d'un client d'API GKE On-Prem, vous spécifiez un projet Google Cloud. Une fois le cluster créé, il est automatiquement enregistré dans le parc du projet spécifié. Ce projet est appelé projet hôte du parc. Le projet hôte de parc ne peut pas être modifié une fois le cluster créé.

Si vous préférez, vous pouvez créer un cluster d'utilisateur en créant un fichier de configuration de cluster d'utilisateur et en utilisant bmctl, comme décrit dans la section Créer un cluster d'utilisateur.

Si vous souhaitez utiliser Terraform, la console ou gcloud CLI pour gérer le cycle de vie des clusters créés à l'aide de bmctl, consultez la section Configurer un cluster d'utilisateurs pour qu'il soit géré par l'API GKE On-Prem.

Avant de commencer

Cette section décrit les exigences relatives à la création d'un cluster utilisateur à l'aide de clients API GKE On-Prem.

Accorder des autorisations IAM

Si vous n'êtes pas le propriétaire du projet, vous devez disposer du rôle roles/gkeonprem.admin.

Si vous souhaitez accéder aux pages GKE Enterprise et Google Kubernetes Engine dans la console, vous devez également disposer des rôles suivants :

Une fois le cluster créé, si vous n'êtes pas propriétaire du projet et que vous souhaitez utiliser la passerelle Connect pour vous connecter au cluster d'utilisateur via la ligne de commande, les rôles suivants sont requis :

  • roles/gkehub.gatewayAdmin : ce rôle vous permet d'accéder à l'API de passerelle Connect. Si vous n'avez besoin que d'un accès en lecture seule au cluster, le paramètre roles/gkehub.gatewayReader est suffisant.

  • roles/gkehub.viewer : ce rôle vous permet de récupérer les identifiants du cluster.

Pour en savoir plus sur l'attribution de rôles, consultez la page Gérer l'accès aux projets, aux dossiers et aux organisations.

API Google requises

Assurez-vous que toutes les API Google requises sont bien activées dans le projet hôte.

Si vous utilisez gcloud CLI pour créer le cluster, vous devez activer l'API GKE On-Prem. Si vous utilisez la console pour créer le cluster, elle active automatiquement l'API GKE On-Prem.

gcloud services enable --project FLEET_HOST_PROJECT_ID \
    gkeonprem.googleapis.com

Prérequis pour les clusters d'administrateur

Vous devez disposer d'un cluster d'administrateur fonctionnel avant de pouvoir créer un cluster d'utilisateur. Le cluster d'administrateur doit :

  • Avoir accès au serveur d'API Kubernetes sur le cluster d'utilisateur après sa création

  • disposer d'une connectivité réseau à tous les nœuds du cluster d'utilisateurs une fois celui-ci créé ;

  • être enregistré sur un parc. L'ID de projet configuré dans le champ gkeConnect.projectID de ce cluster d'administrateur, appelé projet hôte de parc, doit correspondre au projet dans lequel vous allez créer le cluster d'utilisateurs.

Prérequis pour les machines du nœud de cluster

Consultez les prérequis pour les machines du nœud de cluster pour vous assurer que les machines qui exécuteront le cluster d'utilisateurs répondent aux conditions préalables.

Accès à la ligne de commande

Une fois le cluster créé, si vous souhaitez utiliser la passerelle Connect pour exécuter kubectl sur le cluster d'utilisateur sur des ordinateurs autres que le poste de travail administrateur, installez les outils de ligne de commande suivants sur l'ordinateur que vous prévoyez d'utiliser.

  • Dernière version de gcloud CLI.
  • kubectl pour exécuter des commandes sur les clusters Kubernetes. Si vous devez installer kubectl, suivez ces instructions.

Créer un cluster d'utilisateur

Vous pouvez utiliser Terraform, la console Google Cloud ou Google Cloud CLI (gcloud CLI) pour créer un cluster géré par l'API GKE On-Prem. Si vous installez Google Distributed Cloud pour la première fois, la console est peut-être l'outil le plus simple à utiliser.

Une fois que vous vous serez familiarisé avec les informations à fournir pour créer des clusters, vous trouverez peut-être plus pratique d'utiliser Terraform ou gcloud CLI, en particulier si vous devez créer plusieurs clusters. Terraform est un outil IaC (Infrastructure as Code) standard dans l'industrie. Si votre organisation utilise déjà Terraform, vous pouvez l'utiliser pour créer des clusters et gérer leur cycle de vie.

Avec gcloud CLI, vous pouvez enregistrer la commande avec ses arguments dans un fichier texte et apporter les modifications nécessaires pour créer des clusters supplémentaires. Si vous utilisez un outil CI/CD, tel que Cloud Build, vous pouvez utiliser les commandes gcloud pour créer un cluster et un pool de nœuds, et spécifier l'indicateur --impersonate-service-account pour automatiser la création.

Console

La plupart des paramètres de la console correspondent aux champs du fichier de configuration du cluster.

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

    Accéder à la page Créer un cluster cloud distribué

  2. Sélectionnez le projet 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é.

  3. Cliquez sur Suivant pour commencer à configurer le cluster.

Les sections suivantes vous guident dans la configuration du cluster d'utilisateur.

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.

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

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

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

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

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

  4. Sélectionnez la version de Google Distributed Cloud pour votre cluster d'utilisateurs. Les clusters d'utilisateur doivent utiliser la même version mineure que le cluster d'administrateur ou une version mineure antérieure.

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

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

  6. Dans la section Configuration des nœuds, spécifiez les éléments suivants :

    • Nombre maximal de pods par nœud : saisissez le nombre maximal de pods pouvant être exécutés sur un même nœud. Les valeurs autorisées sont comprises entre 32 et 250, inclus. Kubernetes attribue un bloc CIDR (Classless Inter-Domain Routing) à chaque nœud afin que chaque pod puisse avoir une adresse IP unique. La taille du bloc CIDR correspond au nombre maximal de pods par nœud. Pour en savoir plus sur la définition du nombre maximal de pods par nœud, consultez la page Mise en réseau de pods.

    • Environnement d'exécution de conteneur : containerd est le seul environnement d'exécution de conteneur disponible pour votre cluster.

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

Mise en réseau

Dans cette section, vous spécifiez les adresses IP des nœuds, des pods et des services de votre cluster. Si vous utilisez l'équilibrage de charge groupé avec MetalLB, vous devez également le configurer.

  1. Dans la section Plan de contrôle, saisissez l'adresse IPv4 de chaque nœud du plan de contrôle. Les nœuds du plan de contrôle exécutent la charge de travail du système. En règle générale, il s'agit d'une machine unique si vous utilisez un déploiement minimal, ou de trois machines si vous utilisez un déploiement à haute disponibilité. Spécifiez un nombre de nœuds impair afin de disposer d'un quorum majoritaire pour la haute disponibilité. Ce champ peut être modifié à chaque mise à jour ou mise à niveau d'un cluster.

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

  2. Dans la section Équilibreur de charge, sélectionnez l'équilibreur de charge dans la liste Mode à configurer pour votre cluster. Pour en savoir plus, consultez la section Présentation des équilibreurs de charge.

    Groupé avec MetalLB

    Configurez l'équilibrage de charge avec l'équilibreur de charge MetalLB fourni. Avec cette option, Google Distributed Cloud déploie des équilibreurs de charge de couche 4 qui s'exécutent sur un pool dédié de nœuds de calcul ou sur les mêmes nœuds que le plan de contrôle.

    1. Dans la section Pools de nœuds de l'équilibreur de charge, sélectionnez l'une des options suivantes :

      • Utiliser des nœuds de plan de contrôle : sélectionnez cette option pour exécuter les équilibreurs de charge sur les mêmes nœuds que le plan de contrôle.

      • Créer un pool de nœuds d'équilibreur de charge : sélectionnez cette option avancée si vous devez exécuter les équilibreurs de charge sur un pool dédié de nœuds de calcul. Tous les nœuds du pool de nœuds d'équilibrage de charge doivent se trouver dans le même sous-réseau de couche 2 que les adresses IP virtuelles (VIP) de l'équilibreur de charge que vous configurez dans la section Pools d'adresses d'équilibrage de charge.

        1. Dans le champ IP 1 du pool de nœuds de l'équilibreur de charge, saisissez une adresse IPv4 pour un nœud de votre pool de nœuds de l'équilibreur de charge.

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

    2. Dans la section Pools d'adresses de l'équilibreur de charge, ajoutez un ou plusieurs pools d'adresses que le contrôleur MetalLB pourra choisir et attribuer aux services de type LoadBalancer. L'adresse IP virtuelle d'entrée, que vous spécifiez dans la section Adresses IP virtuelles, doit se trouver dans l'un de ces pools.

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

      2. Saisissez une plage d'adresses IP au format CIDR (par exemple, 192.0.2.0/26) ou au format 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 l'adresse IP virtuelle d'entrée ne se trouve pas dans la plage d'adresses, sélectionnez + Ajouter une plage d'adresses IP et saisissez une autre plage d'adresses qui inclut l'adresse IP virtuelle d'entrée.

        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é.

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

    Équilibreur de charge manuel

    Avec l'équilibrage de charge manuel, vous configurez vos propres solutions d'équilibrage de charge pour le trafic du plan de contrôle et du plan de données. Vous devez configurer l'adresse IP virtuelle de votre plan de contrôle sur l'équilibreur de charge externe avant de créer un cluster. L'équilibreur de charge du plan de contrôle externe peut également être utilisé pour le trafic du plan de données, ou vous pouvez configurer un équilibreur de charge distinct pour le plan de données. Pour en savoir plus, consultez la section Configurer l'équilibrage de charge manuel.

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

    • Adresse IP virtuelle du plan de contrôle : l'adresse IP de destination à utiliser pour le trafic envoyé au serveur d'API Kubernetes du cluster d'utilisateur. L'adresse IP virtuelle du plan de contrôle doit se trouver dans le même sous-réseau que les nœuds de l'équilibreur de charge et ne doit pas se trouver dans l'une des plages d'adresses utilisées pour les pools d'adresses de l'équilibreur de charge.

    • Port : port de destination utilisé pour le trafic envoyé au serveur d'API Kubernetes. La valeur par défaut est 443.

    • Adresse IP virtuelle d'entrée : adresse IP à configurer sur l'équilibreur de charge pour le proxy d'entrée. Saisissez une adresse IP de l'un des pools d'adresses de l'équilibreur de charge

  4. Dans la section Plages CIDR des services et des pods, spécifiez les plages d'adresses IP des services Kubernetes et des pods au format CIDR. Celles-ci ne doivent pas se chevaucher entre elles, ni avec aucune adresse externe au cluster que vous souhaitez atteindre depuis l'intérieur du cluster. Nous vous recommandons d'utiliser les plages d'adresses IP privées définies par la RFC 1918. La console fournit les plages d'adresses par défaut suivantes, mais vous pouvez les modifier :

    • CIDR du service : 10.96.0.0/20 Si vous n'acceptez pas la valeur par défaut, saisissez une plage CIDR comprise entre /24 et /12, où /12 fournit le plus d'adresses IP.

    • CIDR du pod : 192.168.0.0/16 Si vous n'acceptez pas la valeur par défaut, saisissez une plage CIDR comprise entre /18 et /8, où /8 correspond au plus grand nombre d'adresses IP.

  5. Dans la section Attributs avancés, spécifiez éventuellement les éléments suivants :

    • URL du proxy : adresse HTTP de votre serveur proxy. Incluez le numéro de port même s'il est identique au port par défaut du schéma. Par exemple : http://my-proxy.example.local:80

    • URL : Liste d'adresses IP, de plages d'adresses IP, de noms d'hôte et de noms de domaine séparés par une virgule qui ne doivent pas passer par le serveur proxy. Lorsque Google Distributed Cloud envoie une requête à l'un de ces hôtes, domaines ou adresses, la requête est envoyée directement.

  6. Cliquez sur Suivant.

Stockage

Google Distributed Cloud fournit des interfaces de stockage de blocs et de fichiers. Elles disposent d'options par défaut, mais vous pouvez personnaliser les configurations. Pour en savoir plus, consultez la section Configurer le stockage local.

  1. Vous pouvez éventuellement configurer les éléments suivants :

    • Installations de nœuds de l'approvisionneur de volume local : spécifie la configuration des PersistentVolumes (PV) locaux secondés par des disques installés. Vous devez formater et installer ces disques avant ou après la création du cluster.

    • Partage de l'approvisionneur de volume local : spécifie la configuration des PersistentVolumes locaux reposant sur des sous-répertoires d'un système de fichiers partagé. Ces sous-répertoires sont générés automatiquement lors de la création du cluster.

  2. Cliquez sur Suivant.

Fonctionnalités

Pour vous aider à surveiller, à résoudre les problèmes et à exploiter votre cluster, les éléments suivants sont activés automatiquement et ne peuvent pas être désactivés :

Créer un pool de nœuds

Votre cluster doit comporter au moins un pool de nœuds pour les nœuds de calcul. Un pool de nœuds représente le modèle des groupes de nœuds de calcul créés dans ce cluster.

Dans la console, vous configurez au moins un pool de nœuds (ou acceptez les valeurs par défaut), puis vous créez le cluster. Vous pouvez ajouter des pools de nœuds supplémentaires après la création du cluster. Avec gcloud CLI, vous créez d'abord le cluster, puis ajoutez un ou plusieurs pools de nœuds au cluster nouvellement créé.

  1. Cliquez sur Pool par défaut dans la barre de navigation de gauche.

  2. Dans la section Paramètres par défaut du pool de nœuds, saisissez le nom du pool de nœuds ou acceptez "default-pool" comme nom.

  3. Dans la section Nœuds de calcul, saisissez les adresses IP des machines sur lesquelles le cluster doit s'exécuter.

  4. 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.

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

    En cas de problème de configuration, la console affiche un message d'erreur suffisamment clair pour que vous puissiez résoudre le problème de configuration et réessayer de créer le cluster.

CLI gcloud

Utilisez la commande suivante pour créer un cluster d'utilisateurs :

gcloud container bare-metal 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 bare-metal node-pools create

La plupart des indicateurs de création du cluster et du pool de nœuds correspondent aux champs du fichier de configuration du cluster d'utilisateur. Pour vous aider à démarrer, vous pouvez tester la commande complète dans la section Exemples. Pour en savoir plus sur les options, consultez les sections qui suivent les exemples ou la documentation de référence de gcloud CLI.

Avant de commencer

La version de Google Distributed Cloud que vous sélectionnez lors de la création d'un cluster d'utilisateur doit être compatible avec votre cluster d'administrateur. De plus, les dernières versions mineures ou correctifs ne sont disponibles dans l'API GKE On-Prem que 7 à 10 jours après leur publication. Vous pouvez exécuter une commande gcloud pour obtenir la liste des versions compatibles que vous pouvez installer sur le cluster d'utilisateur.

  1. Veillez à mettre à jour les composants :

    gcloud components update

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

    gcloud container fleet memberships list \
  --project=FLEET_HOST_PROJECT_ID

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

    Le résultat ressemble à ce qui suit :

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

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

  3. Obtenez la liste des versions disponibles à installer sur le cluster d'utilisateur :

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

    Remplacez les éléments suivants :

    • ADMIN_CLUSTER_NAME : nom du cluster d'administrateur.

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

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

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

    La sortie de la commande ressemble à ceci :

    versions:
- version: 1.16.2
- version: 1.16.1
- version: 1.16.0
- version: 1.15.7
- version: 1.15.6
- version: 1.15.5

Nous vous suggérons d'utiliser la version la plus récente pour bénéficier des dernières corrections et améliorations.

Exemples

Cette section fournit un exemple de commande qui crée un cluster à l'aide de l'équilibreur de charge MetalLB et un exemple utilisant un équilibreur de charge manuel. Les informations que vous spécifiez varient en fonction du type d'équilibreur de charge que vous utiliserez. Pour en savoir plus, consultez la page Présentation des équilibreurs de charge.

Les exemples créent le cluster sans pool de nœuds. Une fois le cluster en cours d'exécution, vous devez ajouter un pool de nœuds avant de déployer des charges de travail.

MetalLB

Cet exemple montre comment créer un cluster d'utilisateur avec l'équilibreur de charge MetalLB fourni.

gcloud container bare-metal 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 \
  --metal-lb-address-pools='pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \
  --control-plane-node-configs='node-ip=CP_IP_ADDRESS_1,labels=CP_KEY_1.1=CP_VALUE_1.1;CP_KEY_1.2=CP_VALUE_1.2;...' \
  --control-plane-vip=CONTROL_PLANE_VIP \
  --control-plane-load-balancer-port=CONTROL_PLANE_LB_PORT \
  --ingress-vip=INGRESS_VIP \
  --island-mode-service-address-cidr-blocks=SERVICE_CIDR_BLOCK \
  --island-mode-pod-address-cidr-blocks=POD_CIDR_BLOCK \
  --lvp-share-path=/mnt/localpv-share \
  --lvp-share-storage-class=local-shared \
  --lvp-node-mounts-config-path=/mnt/localpv-disk \
  --lvp-node-mounts-config-storage-class=local-disks

Remplacez les éléments suivants :

  • USER_CLUSTER_NAME : Nom de votre choix pour le cluster d'utilisateur. Une fois le cluster créé, il n'est plus possible de modifier son nom. 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 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é. Le projet hôte de parc ne peut pas être modifié une fois le cluster créé.
  • ADMIN_CLUSTER_NAME : nom du cluster d'administrateur qui gère le cluster d'utilisateur. Dans l'indicateur --admin-cluster-membership, vous pouvez utiliser le nom de cluster entièrement spécifié, 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 avec --admin-cluster-membership-project et l'emplacement avec --admin-cluster-membership-location. L'emplacement du cluster d'administrateur est global ou une région Google Cloud. Si vous devez 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 Fleet (gkehub.googleapis.com) et le service Connect (gkeconnect.googleapis.com) s'exécutent. Spécifiez us-west1 ou une autre région compatible. La région ne peut pas être modifiée une fois le cluster créé. Ce paramètre spécifie la région dans laquelle les éléments suivants sont stockés :
    • Métadonnées du cluster d'utilisateur dont l'API GKE On-Prem a besoin pour gérer le cycle de vie du cluster
    • Données Cloud Logging et Cloud Monitoring des composants système
    • Journal d'audit d'administrateur créé par Cloud Audit Logs

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

  • VERSION : version de Google Distributed Cloud pour votre cluster d'utilisateur.
  • YOUR_EMAIL_ADDRESS et ANOTHER_EMAIL_ADDRESS : si vous n'incluez pas l'indicateur --admin-users, vous disposez par défaut des droits d'administrateur du cluster en tant que créateur du cluster. Toutefois, si vous incluez --admin-users pour désigner un autre utilisateur en tant qu'administrateur, vous remplacez 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

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

Pools d'adresses MetalLB

  • --metal-lb-address-pools : spécifiez la configuration des pools d'adresses à utiliser par l'équilibreur de charge MetalLB. La valeur de l'indicateur a le format suivant :
'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 commençant 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 de nœuds.

  • avoid-buggy-ips : Si vous définissez cette valeur sur True, le contrôleur MetalLB n'attribue pas les adresses IP se terminant par .0 ou .255 aux services. Cela évite le problème des bugs avec les appareils grand public qui suppriment 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 de addresses : chaque adresse doit être une plage au format CIDR ou une plage avec des traits d'union. Pour spécifier une seule adresse IP dans un pool (par exemple, pour l'adresse IP virtuelle d'entrée), utilisez /32 au format CIDR (par exemple, 192.0.2.1/32).

Notez les règles de syntaxe suivantes :

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

Vous pouvez spécifier plusieurs instances de l'indicateur, comme illustré dans l'exemple suivant :

--metal-lb-address-pools='pool=pool1,avoid-buggy-ips=False,manual-assign=True,addresses=192.0.2.0/26;192.0.2.64-192.0.2.72'
--metal-lb-address-pools='pool=pool2,avoid-buggy-ips=True,manual-assign=True,addresses=10.251.133.0/24;10.251.134.80/32'

Nœuds MetalLB

  • Facultatif : --metal-lb-load-balancer-node-configs : par défaut, l'équilibreur de charge s'exécute sur les mêmes nœuds que le plan de contrôle. Si vous devez exécuter l'équilibreur de charge sur un pool dédié de nœuds de calcul, spécifiez cet indicateur pour chaque nœud. Tous les nœuds du pool de nœuds d'équilibrage de charge doivent se trouver dans le même sous-réseau de couche 2 que les adresses IP virtuelles de l'équilibrage de charge.

    La valeur de l'indicateur a le format suivant :

    'node-ip=LB_IP_ADDRESS_1,labels=LB_KEY_1.1=LB_VALUE_1.1;LB_KEY_1.2=LB_VALUE_1.2;...' \

    La valeur comporte des segments commençant par les mots clés node-ip et labels. Séparez chaque segment par une virgule.

    • node-ip : adresse IP d'un nœud de votre pool de nœuds d'équilibreur de charge. Vous ne pouvez spécifier qu'un seul node-ip par indicateur. Si vous devez spécifier plusieurs nœuds, incluez à nouveau l'indicateur pour chaque nœud.

    • labels : une ou plusieurs paires clé=valeur associées au nœud.

    Notez les règles de syntaxe suivantes :

    • Placez la valeur entière entre guillemets simples.
    • Les espaces blancs ne sont pas autorisés.
    • Séparez chaque paire clé=valeur dans le segment labels par un point-virgule.

    Si vous spécifiez --metal-lb-load-balancer-node-configs, vous pouvez éventuellement inclure les indicateurs suivants :

    • --metal-lb-load-balancer-node-labels : utilisez cet indicateur pour ajouter des étiquettes à tous les nœuds du pool de nœuds de l'équilibreur de charge. Séparez la liste des paires clé=valeur par une virgule.

      --metal-lb-load-balancer-node-labels=KEY_1=VALUE_1,KEY_2=VALUE_2

    • --metal-lb-load-balancer-node-taints : utilisez cet indicateur pour ajouter des rejets à tous les nœuds du pool de nœuds de l'équilibreur de charge. Chaque rejet est une paire clé=valeur associée à un effet, qui doit être l'un des éléments suivants : PreferNoSchedule, NoSchedule ou NoExecute.

      --metal-lb-load-balancer-node-taints=KEY_1=VALUE_1:EFFECT_1,KEY_2=VALUE_2:EFFECT_2

    L'exemple suivant ajoute trois nœuds au pool de nœuds de l'équilibreur de charge. Tous les nœuds sont étiquetés avec lb-pool-key=lb-pool-value et ont le rejet dedicated=experimental:PreferNoSchedule.

    --metal-lb-load-balancer-node-configs='node-ip=192.0.2.1' \
--metal-lb-load-balancer-node-configs='node-ip=192.0.2.2,labels=key2.1=value2.1' \
--metal-lb-load-balancer-node-configs='node-ip=192.0.2.3,labels=key3.1=value3.1;key3.2=value3.2' \
--metal-lb-load-balancer-node-labels=lb-pool-key=lb-pool-value \
--metal-lb-load-balancer-node-taints=dedicated=experimental:PreferNoSchedule \

Nœuds du plan de contrôle

  • --control-plane-node-configs : adresse IPv4 d'un nœud de plan de contrôle. Les nœuds du plan de contrôle exécutent la charge de travail du système. Spécifiez cet indicateur pour chaque nœud du plan de contrôle. En règle générale, vous disposez d'une seule machine si vous utilisez un déploiement minimal, ou de trois machines si vous utilisez un déploiement à haute disponibilité. Spécifiez un nombre de nœuds impair afin de disposer d'un quorum majoritaire pour la haute disponibilité. Vous pouvez modifier ces adresses à chaque mise à jour ou mise à niveau d'un cluster.

    La valeur de l'indicateur a le format suivant :

      'node-ip=CP_IP_ADDRESS_1,labels=CP_KEY_1.1=CP_VALUE_1.1;CP_KEY_1.2=CP_VALUE_1.2;...' \

    La valeur comporte des segments commençant par les mots clés node-ip et labels. Séparez chaque segment par une virgule.

  • node-ip : adresse IP d'un nœud de plan de contrôle. Vous ne pouvez spécifier qu'un seul node-ip par indicateur. Si vous devez spécifier plusieurs nœuds, incluez à nouveau l'indicateur pour chaque nœud.
  • labels : une ou plusieurs paires clé=valeur associées au nœud.

    Notez les règles de syntaxe suivantes :

    • Placez la valeur entière entre guillemets simples.
    • Les espaces blancs ne sont pas autorisés.
    • Séparez chaque paire clé=valeur du segment labels par un point-virgule.

    Vous pouvez également inclure les options suivantes :

  • --control-plane-node-labels : utilisez cet indicateur pour ajouter des libellés à tous les nœuds du plan de contrôle. Séparez la liste des paires clé=valeur par une virgule. 
      --control-plane-node-labels=KEY_1=VALUE_1,KEY_2=VALUE_2
  • --control-plane-node-taints : utilisez cet indicateur pour ajouter des rejets à tous les nœuds du plan de contrôle. Chaque rejet est une paire clé=valeur associée à un effet, qui doit être l'un des éléments suivants : PreferNoSchedule, NoSchedule ou NoExecute.

    L'exemple suivant ajoute trois nœuds aux nœuds du plan de contrôle. Tous les nœuds sont étiquetés avec cp-node-pool-key=cp-node-pool-value et ont le rejet dedicated=experimental:PreferNoSchedule.

      --control-plane-node-configs='node-ip=192.0.2.1' \
  --control-plane-node-configs='node-ip=192.0.2.2,labels=key2.1=value2.1' \
  --control-planer-node-configs='node-ip=192.0.2.3,labels=key3.1=value3.1;key3.2=value3.2' \
  --control-plane-node-labels=cp-node-pool-key=cp-node-pool-value \
  --control-plane-node-taints=dedicated=experimental:PreferNoSchedule \

Adresses IP virtuelles

  • 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_LB_PORT : port sur lequel l'équilibreur de charge sert le serveur d'API Kubernetes.

    Exemple : -control-plane-load-balancer-port=443

  • 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.

CIDR des services et des pods

  • SERVICE_CIDR_BLOCK : Une plage d'adresses IP au format CIDR à utiliser pour les services de votre cluster. La plage CIDR doit être comprise entre /24 et /12, où /12 correspond au plus grand nombre d'adresses IP.

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

  • POD_CIDR_BLOCK : Une plage d'adresses IP au format CIDR à utiliser pour les pods de votre cluster La plage CIDR doit être comprise entre /18 et /8, où /8 correspond au plus grand nombre d'adresses IP.

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

Stockage

  1. --lvp-share-path : chemin d'accès à la machine hôte dans laquelle les sous-répertoires peuvent être créés. Un volume persistant (PersistentVolume ou PV) local est créé pour chaque sous-répertoire.
  2. --lvp-share-storage-class : StorageClass à utiliser pour créer des volumes persistants. La StorageClass est créée lors de la création du cluster.
  3. --lvp-node-mounts-config-path : chemin d'accès à la machine hôte dans laquelle les disques installés peuvent être détectés. Un volume persistant (PersistentVolume ou PV) local est créé pour chaque installation.
  4. --lvp-node-mounts-config-storage : classe de stockage avec laquelle les volumes persistants sont créés lors de la création du cluster.

Pour en savoir plus sur le stockage, consultez la section Configurer le stockage local.

Manuel

Avec l'équilibrage de charge manuel, vous configurez vos propres solutions d'équilibrage de charge pour le trafic du plan de contrôle et du plan de données. Vous devez configurer l'adresse IP virtuelle de votre plan de contrôle sur l'équilibreur de charge externe avant de créer un cluster. L'équilibreur de charge du plan de contrôle externe peut également être utilisé pour le trafic du plan de données, ou vous pouvez configurer un équilibreur de charge distinct pour le plan de données. Pour en savoir plus, consultez la section Configurer l'équilibrage de charge manuel.

Si nécessaire, faites défiler l'écran pour renseigner l'espace réservé ADMIN_CLUSTER_NAME pour l'indicateur --admin-cluster-membership.

gcloud container bare-metal 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 \
  --enable-manual-lb \
  --control-plane-node-configs='node-ip=CP_IP_ADDRESS_1,labels=CP_KEY_1.1=CP_VALUE_1.1;CP_KEY_1.2=CP_VALUE_1.2;...' \
  --control-plane-vip=CONTROL_PLANE_VIP \
  --control-plane-load-balancer-port=CONTROL_PLANE_LB_PORT \
  --ingress-vip=INGRESS_VIP \
  --island-mode-service-address-cidr-blocks=SERVICE_CIDR_BLOCK \
  --island-mode-pod-address-cidr-blocks=POD_CIDR_BLOCK \
  --lvp-share-path=/mnt/localpv-share \
  --lvp-share-storage-class=local-shared \
  --lvp-node-mounts-config-path=/mnt/localpv-disk \
  --lvp-node-mounts-config-storage-class=local-disks

Remplacez les éléments suivants :

  • USER_CLUSTER_NAME : Nom de votre choix pour le cluster d'utilisateur. Une fois le cluster créé, il n'est plus possible de modifier son nom. 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 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é. Le projet hôte de parc ne peut pas être modifié une fois le cluster créé.
  • ADMIN_CLUSTER_NAME : nom du cluster d'administrateur qui gère le cluster d'utilisateur. Dans l'indicateur --admin-cluster-membership, vous pouvez utiliser le nom de cluster entièrement spécifié, 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 avec --admin-cluster-membership-project et l'emplacement avec --admin-cluster-membership-location. L'emplacement du cluster d'administrateur est global ou une région Google Cloud. Si vous devez 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 Fleet (gkehub.googleapis.com) et le service Connect (gkeconnect.googleapis.com) s'exécutent. Spécifiez us-west1 ou une autre région compatible. La région ne peut pas être modifiée une fois le cluster créé. Ce paramètre spécifie la région dans laquelle les éléments suivants sont stockés :
    • Métadonnées du cluster d'utilisateur dont l'API GKE On-Prem a besoin pour gérer le cycle de vie du cluster
    • Données Cloud Logging et Cloud Monitoring des composants système
    • Journal d'audit d'administrateur créé par Cloud Audit Logs

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

  • VERSION : version de Google Distributed Cloud pour votre cluster d'utilisateur.
  • YOUR_EMAIL_ADDRESS et ANOTHER_EMAIL_ADDRESS : si vous n'incluez pas l'indicateur --admin-users, vous disposez par défaut des droits d'administrateur du cluster en tant que créateur du cluster. Toutefois, si vous incluez --admin-users pour désigner un autre utilisateur en tant qu'administrateur, vous remplacez 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

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

Nœuds du plan de contrôle

  • --control-plane-node-configs : adresse IPv4 d'un nœud de plan de contrôle. Les nœuds du plan de contrôle exécutent la charge de travail du système. Spécifiez cet indicateur pour chaque nœud du plan de contrôle. En règle générale, vous disposez d'une seule machine si vous utilisez un déploiement minimal, ou de trois machines si vous utilisez un déploiement à haute disponibilité. Spécifiez un nombre de nœuds impair afin de disposer d'un quorum majoritaire pour la haute disponibilité. Vous pouvez modifier ces adresses à chaque mise à jour ou mise à niveau d'un cluster.

    La valeur de l'indicateur a le format suivant :

      'node-ip=CP_IP_ADDRESS_1,labels=CP_KEY_1.1=CP_VALUE_1.1;CP_KEY_1.2=CP_VALUE_1.2;...' \

    La valeur comporte des segments commençant par les mots clés node-ip et labels. Séparez chaque segment par une virgule.

  • node-ip : adresse IP d'un nœud de plan de contrôle. Vous ne pouvez spécifier qu'un seul node-ip par indicateur. Si vous devez spécifier plusieurs nœuds, incluez à nouveau l'indicateur pour chaque nœud.
  • labels : une ou plusieurs paires clé=valeur associées au nœud.

    Notez les règles de syntaxe suivantes :

    • Placez la valeur entière entre guillemets simples.
    • Les espaces blancs ne sont pas autorisés.
    • Séparez chaque paire clé=valeur du segment labels par un point-virgule.

    Vous pouvez également inclure les options suivantes :

  • --control-plane-node-labels : utilisez cet indicateur pour ajouter des libellés à tous les nœuds du plan de contrôle. Séparez la liste des paires clé=valeur par une virgule. 
      --control-plane-node-labels=KEY_1=VALUE_1,KEY_2=VALUE_2
  • --control-plane-node-taints : utilisez cet indicateur pour ajouter des rejets à tous les nœuds du plan de contrôle. Chaque rejet est une paire clé=valeur associée à un effet, qui doit être l'un des éléments suivants : PreferNoSchedule, NoSchedule ou NoExecute.

    L'exemple suivant ajoute trois nœuds aux nœuds du plan de contrôle. Tous les nœuds sont étiquetés avec cp-node-pool-key=cp-node-pool-value et ont le rejet dedicated=experimental:PreferNoSchedule.

      --control-plane-node-configs='node-ip=192.0.2.1' \
  --control-plane-node-configs='node-ip=192.0.2.2,labels=key2.1=value2.1' \
  --control-planer-node-configs='node-ip=192.0.2.3,labels=key3.1=value3.1;key3.2=value3.2' \
  --control-plane-node-labels=cp-node-pool-key=cp-node-pool-value \
  --control-plane-node-taints=dedicated=experimental:PreferNoSchedule \

Adresses IP virtuelles

  • 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_LB_PORT : port sur lequel l'équilibreur de charge sert le serveur d'API Kubernetes.

    Exemple : -control-plane-load-balancer-port=443

  • 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.

CIDR des services et des pods

  • SERVICE_CIDR_BLOCK : Une plage d'adresses IP au format CIDR à utiliser pour les services de votre cluster. La plage CIDR doit être comprise entre /24 et /12, où /12 correspond au plus grand nombre d'adresses IP.

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

  • POD_CIDR_BLOCK : Une plage d'adresses IP au format CIDR à utiliser pour les pods de votre cluster La plage CIDR doit être comprise entre /18 et /8, où /8 correspond au plus grand nombre d'adresses IP.

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

Stockage

  1. --lvp-share-path : chemin d'accès à la machine hôte dans laquelle les sous-répertoires peuvent être créés. Un volume persistant (PersistentVolume ou PV) local est créé pour chaque sous-répertoire.
  2. --lvp-share-storage-class : StorageClass à utiliser pour créer des volumes persistants. La StorageClass est créée lors de la création du cluster.
  3. --lvp-node-mounts-config-path : chemin d'accès à la machine hôte dans laquelle les disques installés peuvent être détectés. Un volume persistant (PersistentVolume ou PV) local est créé pour chaque installation.
  4. --lvp-node-mounts-config-storage : classe de stockage avec laquelle les volumes persistants sont créés lors de la création du cluster.

Pour en savoir plus sur le stockage, consultez la section Configurer le stockage local.

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

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

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

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

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

Créer un pool de nœuds

Une fois le cluster créé, vous devez créer au moins un pool de nœuds avant de déployer des charges de travail. Un pool de nœuds représente le modèle des groupes de nœuds de calcul créés dans ce cluster. Avec gcloud CLI, vous créez d'abord le cluster, puis ajoutez un ou plusieurs pools de nœuds au cluster nouvellement créé.

gcloud container bare-metal node-pools create NODE_POOL_NAME \
  --cluster=USER_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --location=REGION \
  --node-configs='node-ip=NP_IP_ADDRESS_1,labels=NP_KEY_1.1=NP_VALUE_1.1;NP_KEY_1.2=NP_VALUE_1.2;...'

Remplacez les éléments suivants :

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

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

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

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

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

  • --node-configs : adresse IPv4 d'une machine de nœud de calcul. Spécifiez cette option pour chaque nœud. La valeur de l'indicateur a le format suivant :

    'node-ip=NP_IP_ADDRESS_1,labels=NP_KEY_1.1=NP_VALUE_1.1;NP_KEY_1.2=NP_VALUE_1.2;...' \

    La valeur comporte des segments commençant par les mots clés node-ip et labels. Séparez chaque segment par une virgule.

    • node-ip : adresse IP d'un nœud de calcul. Vous ne pouvez spécifier qu'un seul node-ip par indicateur. Ajoutez à nouveau cet indicateur pour chaque nœud du pool de nœuds.

    • labels : une ou plusieurs paires clé=valeur associées au nœud.

    Notez les règles de syntaxe suivantes :

    • Placez la valeur entière entre guillemets simples.
    • Les espaces blancs ne sont pas autorisés.
    • Séparez chaque paire clé=valeur dans le segment labels par un point-virgule.

    Vous pouvez également spécifier les éléments suivants :

    • --node-labels=KEY=VALUE,... : liste de libellés Kubernetes (paires clé-valeur) séparés par une virgule, appliqués à chaque nœud du pool.

    • --node-taints=KEY=VALUE:EFFECT,...Liste de rejets Kubernetes, séparés par une virgule, appliqués à chaque nœud du pool. Les rejets sont des paires clé-valeur associées à un effet. Les rejets sont utilisés avec des tolérances pour la planification des pods. Spécifiez l'un des éléments suivants pour EFFECT : NoSchedule, PreferNoSchedule ou NoExecute.

L'exemple suivant crée un pool de nœuds appelé default-pool sur user-cluster- et ajoute deux nœuds au pool de nœuds. Les deux nœuds sont tous deux étiquetés avec node-pool-key=node-pool-value et ont le rejet dedicated=experimental:PreferNoSchedule,

gcloud container bare-metal node-pools create default-pool \
  --cluster=user-cluster-1  \
  --project=example-project-12345 \
  --location=us-west1 \
  --node-configs='node-ip=10.200.0.10' \
  --node-configs='node-ip=10.200.0.11,labels=key2.1=value2.1' \
  --node-labels=node-pool-key=node-pool-value \
  --node-taints=dedicated=experimental:PreferNoSchedule

Pour en savoir plus, consultez la documentation de référence de gcloud CLI.

Terraform

Avant de commencer

La version de Google Distributed Cloud que vous sélectionnez lors de la création d'un cluster d'utilisateur doit être compatible avec votre cluster d'administrateur. De plus, les dernières versions mineures ou correctifs ne sont disponibles dans l'API GKE On-Prem que 7 à 10 jours après leur publication. Vous pouvez exécuter une commande gcloud pour obtenir la liste des versions compatibles que vous pouvez installer sur le cluster d'utilisateur.

  1. Veillez à mettre à jour les composants :

    gcloud components update

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

    gcloud container fleet memberships list \
  --project=FLEET_HOST_PROJECT_ID

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

    Le résultat ressemble à ce qui suit :

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

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

  3. Obtenez la liste des versions disponibles à installer sur le cluster d'utilisateur :

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

    Remplacez les éléments suivants :

    • ADMIN_CLUSTER_NAME : nom du cluster d'administrateur.

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

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

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

    La sortie de la commande ressemble à ceci :

    versions:
- version: 1.16.2
- version: 1.16.1
- version: 1.16.0
- version: 1.15.7
- version: 1.15.6
- version: 1.15.5

Nous vous suggérons d'utiliser la version la plus récente pour bénéficier des dernières corrections et améliorations.

Exemple

Vous pouvez utiliser l'exemple de configuration de base suivant pour créer un cluster utilisateur avec l'équilibreur de charge MetalLB groupé. Pour plus d'informations, consultez la documentation de référence de google_gkeonprem_bare_metal_cluster.

Définir des variables dans terraform.tfvars

L'exemple fournit un exemple de fichier de variables à transmettre à main.tf, qui montre comment configurer l'équilibreur de charge MetalLB fourni.

  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/abm_user_cluster_metallb

    L'exemple fournit un exemple de fichier de variables à transmettre à main.tf.

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

    cp terraform.tfvars.sample terraform.tfvars

  3. Modifiez les valeurs des paramètres dans terraform.tfvars et enregistrez le fichier.

    
project_id          = "PROJECT_ID"
region              = "ON_PREM_API_REGION"
admin_cluster_name  = "ADMIN_CLUSTER_NAME"
bare_metal_version  = "VERSION"
admin_user_emails   = ["YOUR_EMAIL_ADDRESS", "ADMIN_2_EMAIL_ADDRESS"]
cluster_name        = "abm-user-cluster-metallb"
control_plane_ips   = ["10.200.0.4"]
worker_node_ips     = ["10.200.0.5", "10.200.0.6"]
control_plane_vip   = "10.200.0.50"
ingress_vip         = "10.200.0.51"
lb_address_pools    = [
    { name = "lbpool_1", addresses = ["10.200.0.51-10.200.0.70"] }
]

    La liste suivante décrit les variables :

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

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

    • admin_cluster_name : nom du cluster d'administrateur qui gère le cluster d'utilisateur. L'exemple suppose que le cluster d'administration utilise global comme région. Si vous disposez d'un cluster d'administration 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}"

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

    • bare_metal_version : version de Google Distributed Cloud pour votre cluster d'utilisateur. Spécifiez la même version que le cluster d'administrateur ou une version qui n'est pas inférieure de plus d'une version mineure au cluster d'administrateur.

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

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

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

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

    • control_plane_ips : liste d'une ou plusieurs adresses IPv4 pour les nœuds du plan de contrôle. Les nœuds du plan de contrôle exécutent la charge de travail du système. En règle générale, vous disposez d'une seule machine si vous utilisez un déploiement minimal, ou de trois machines si vous utilisez un déploiement à haute disponibilité. Spécifiez un nombre de nœuds impair afin de disposer d'un quorum majoritaire pour la haute disponibilité. Vous pouvez modifier ces adresses chaque fois que vous mettez à jour ou mettez à niveau un cluster.

    • worker_node_ips : liste d'une ou plusieurs adresses IPv4 pour les machines de nœud de calcul.

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

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

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

  4. Enregistrez les modifications dans terraform.tfvars.

  5. Initialisez et créez le plan Terraform :

    terraform init

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

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

    terraform plan

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

    terraform apply

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

Se connecter au cluster d'utilisateur

Lorsque vous créez un cluster d'utilisateur dans la console, il est configuré avec les règles de contrôle des accès basé sur les rôles (RBAC) de Kubernetes. Vous pouvez ainsi vous connecter au cluster à l'aide de votre identité Google Cloud. Lorsque vous créez un cluster d'utilisateur avec gcloud CLI, ces règles RBAC vous sont accordées par défaut si vous n'incluez pas l'indicateur --admin-users. Si vous incluez --admin-users pour désigner un autre utilisateur en tant qu'administrateur, vous remplacez la valeur par défaut et vous devez inclure à la fois votre adresse e-mail et celle de l'autre administrateur. Pour en savoir plus sur les règles IAM et RBAC requises, consultez la section Configurer l'authentification des identités Google.

Tous les clusters possèdent un point de terminaison canonique. Le point de terminaison expose le serveur d'API Kubernetes utilisé par kubectl et d'autres services pour communiquer avec votre plan de contrôle de cluster via le port TCP 443. Ce point de terminaison n'est pas accessible depuis l'Internet public. Si vous avez accès au point de terminaison privé de votre cluster via votre VPC, vous pouvez vous connecter directement au point de terminaison privé et générer directement un fichier kubeconfig. Sinon, vous pouvez utiliser la passerelle Connect.

Pour accéder au cluster d'utilisateur à partir de la ligne de commande, vous avez besoin d'un fichier kubeconfig. Il existe deux façons d'obtenir un fichier kubeconfig :

  • Utiliser la passerelle Connect pour accéder au cluster à partir d'un ordinateur sur lequel Google Cloud CLI est installé. Dans ce cas, kubectl utilise le kubeconfig de la passerelle Connect, qui transfère ensuite de manière sécurisée le trafic vers le point de terminaison privé en votre nom.

  • Pour accéder directement aux points de terminaison privés, créez un fichier kubeconfig sur votre poste de travail administrateur, puis gérez le cluster depuis votre poste de travail administrateur.

Assurez-vous d'attendre que Google Cloud Console indique que le cluster d'utilisateur est opérationnel.

Passerelle Connect

  1. Initialisez gcloud CLI pour l'utiliser avec le projet hôte du parc, ou exécutez les commandes suivantes pour vous connecter avec votre compte Google, définissez le projet hôte du parc en tant que projet par défaut et mettez à jour les composants :

    gcloud auth login
gcloud config set project PROJECT_ID
gcloud components update

  2. Récupérez les identifiants du cluster utilisés pour interagir avec la passerelle Connect. Dans la commande suivante, remplacez MEMBERSHIP_NAME par le nom de votre cluster. Dans Google Distributed Cloud, le nom de l'appartenance est identique au nom du cluster.

    gcloud container fleet memberships get-credentials MEMBERSHIP_NAME

    Cette commande affiche un élément kubeconfig spécifique à une passerelle Connect qui vous permet de vous connecter au cluster via la passerelle.

Une fois que vous disposez des identifiants nécessaires, vous pouvez exécuter des commandes en utilisant kubectl comme vous le feriez normalement pour tout cluster Kubernetes. Il n'est pas nécessaire de spécifier le nom du fichier kubeconfig, par exemple :

kubectl get namespaces

Poste de travail administrateur

Utilisez la commande bmctl get credentials pour récupérer un fichier kubeconfig pour le cluster d'utilisateurs nouvellement créé.

bmctl get credentials --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG_PATH

Remplacez les éléments suivants :

  • CLUSTER_NAME : nom du cluster d'utilisateur cible

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

Un kubeconfig avec les identifiants du cluster d'utilisateur est écrit dans un fichier, bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-TIMESTAMP-kubeconfig. L'élément TIMESTAMP figurant dans le nom du fichier indique la date et l'heure de création du fichier.

Comme ce fichier contient les identifiants d'authentification de votre cluster, vous devez le stocker dans un emplacement sécurisé avec accès limité.

Étape suivante