Créer un cluster d'utilisateur à l'aide de clients 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 dans l'infrastructure de Google Cloud. Terraform, la console et la gcloud CLI sont des clients de l'API. Ils utilisent celle-ci 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 des métadonnées sur l'état de votre cluster dans Google Cloud, à l'aide de 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 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 du parc ne peut plus ê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 la gcloud CLI pour gérer le cycle de vie des clusters créés à l'aide de bmctl, consultez Configurer un cluster d'utilisateur à gérer par l'API GKE On-Prem.

Avant de commencer

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

Accorder des autorisations IAM

Si vous n'êtes pas 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 Connect Gateway. Si vous n'avez besoin que d'un accès en lecture seule au cluster, l'autorisation roles/gkehub.gatewayReader est suffisante.

  • 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 la 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, celle-ci active automatiquement l'API GKE On-Prem.

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

Conditions préalables pour le cluster 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:

  • Vous devez 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'utilisateur après sa création ;

  • Elle doit être enregistrée dans un parc. L'ID de projet configuré dans le champ gkeConnect.projectID de ce cluster d'administrateur (appelé projet hôte du parc) doit correspondre au projet dans lequel vous allez créer le cluster d'utilisateur.

Prérequis pour la machine du nœud de cluster

Consultez les conditions préalables pour les machines de nœud de cluster pour vous assurer que les machines qui exécuteront le cluster d'utilisateur 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 instructions.

Créer un cluster d'utilisateur

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

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

Avec la 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 de CI/CD, tel que Cloud Build, vous pouvez exécuter les commandes gcloud pour créer un cluster et un pool de nœuds, et spécifier l'option --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 GKE sur une solution Bare Metal.

    Accéder à la page Créer un cluster GKE sur une solution Bare Metal

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

  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 dans laquelle les API et 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 Bare Metal pour votre cluster d'utilisateur. Les clusters d'utilisateur doivent avoir la même version mineure que le cluster d'administrateur ou une version mineure inférieure à celle du cluster d'administrateur.

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

    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. 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 seul 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 section 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 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. Si vous utilisez l'équilibrage de charge groupé avec MetalLB, vous devez également le configurer.

  1. Dans la section de nœud 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 impair de nœuds afin de disposer d'un quorum majoritaire pour la haute disponibilité. Ce champ peut être modifié chaque fois que vous mettez à jour ou mettez à niveau 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 à configurer pour votre cluster dans la liste Mode. Pour en savoir plus, consultez la page Présentation des équilibreurs de charge.

    Groupé avec MetalLB

    Configurez l'équilibrage de charge avec l'équilibreur de charge MetalLB groupé. Avec cette option, GKE sur Bare Metal déploie des équilibreurs de charge de couche 4 qui s'exécutent sur un pool de nœuds de calcul dédié 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 les nœuds du 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: choisissez cette option avancée si vous devez exécuter les équilibreurs de charge sur un pool de nœuds de calcul dédié. Tous les nœuds du pool de nœuds de l'équilibreur de charge doivent appartenir au même sous-réseau de couche 2 que les adresses IP virtuelles (VIP) de l'équilibreur de charge que vous configurez à la section Pools d'adresses de l'équilibreur de charge.

        1. Dans le champ Adresse 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 des adresses IP supplémentaires.

    2. Dans la section Pools d'adresses de l'équilibreur de charge, ajoutez un ou plusieurs pools d'adresses que le contrôleur MetalLB peut choisir et attribuer à des 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, puis saisissez une autre plage d'adresses incluant 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:

        • Automatic (Automatique) : sélectionnez cette option si vous souhaitez que le contrôleur MetalLB attribue automatiquement les adresses IP du pool d'adresses aux services de type LoadBalancer.
        • Manuel: sélectionnez cette option si vous avez l'intention d'utiliser des adresses du pool pour spécifier manuellement les adresses des 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 des plans de contrôle et des plans 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 externe du plan de contrôle peut également être utilisé pour le trafic du plan de données. Vous pouvez également configurer un équilibreur de charge distinct pour le plan de données. Pour en savoir plus, consultez la page 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: 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 se trouver dans aucune 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 de l'un des pools d'adresses de l'équilibreur de charge.

  4. Dans la section CIDR des services et des pods, spécifiez les plages d'adresses IP du service Kubernetes et des pods au format CIDR. Elles ne doivent pas se chevaucher entre elles, ni avec aucune adresse extérieure 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 des services: 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 grand nombre d'adresses IP.

    • Pod CIDR: 192.168.0.0/16 Si vous n'acceptez pas la valeur par défaut, indiquez 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, vous pouvez éventuellement spécifier les éléments suivants:

    • Proxy URL (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 GKE sur Bare Metal envoie une requête à l'une de ces adresses, à l'un de ces hôtes ou à l'un de ces domaines, la requête est envoyée directement.

  6. Cliquez sur Suivant.

Stockage

GKE sur Bare Metal 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:

    • Installation de nœuds d'approvisionneurs de volumes locaux: spécifie la configuration des PersistentVolumes (PV) locaux soutenus 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 de l'PersistentVolumes local sauvegardé par les sous-répertoires d'un système de fichiers partagé. Ces sous-répertoires sont automatiquement créés lors de la création du cluster.

  2. Cliquez sur Suivant.

Fonctionnalités

Pour vous aider à surveiller, dépanner 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 devez configurer au moins un pool de nœuds (ou accepter les valeurs par défaut), puis créer le cluster. Vous pouvez ajouter des pools de nœuds supplémentaires après la création du cluster. Avec la gcloud CLI, vous devez d'abord créer le cluster, puis y ajouter un ou plusieurs pools de nœuds.

  1. Cliquez sur default pool (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 le nom "default-pool".

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

  4. Dans la section Métadonnées du pool de nœuds (facultatif), si vous souhaitez ajouter des étiquettes 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 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.

    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.

gcloud CLI

Exécutez la commande suivante pour créer un cluster d'utilisateur:

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 permettant de créer le cluster et le pool de nœuds correspondent aux champs du fichier de configuration du cluster d'utilisateur. Pour commencer, vous pouvez tester la commande complète dans la section Exemples. Pour plus d'informations sur les indicateurs, consultez les sections qui suivent les exemples ou reportez-vous à la documentation de référence de gcloud CLI.

Avant de commencer

La version de GKE sur Bare Metal que vous sélectionnez lors de la création d'un cluster d'utilisateur doit être une version compatible avec votre cluster d'administrateur. De plus, les dernières versions mineures ou correctives ne sont disponibles dans l'API GKE On-Prem que 7 à 10 jours après la 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 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.

  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 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:
- 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 compatible la plus récente pour obtenir les dernières corrections et améliorations.

Examples

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 présentés ici 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 groupé.

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 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 Bare Metal 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.

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 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-ips: 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 les bugs dans les appareils grand public, qui abandonnent 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 cette valeur 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 avec trait d'union. Pour spécifier une seule adresse IP dans un pool (par exemple, pour l'adresse IP virtuelle d'entrée), utilisez /32 au format CIDR (par exemple, 192.0.2.1/32).

Notez les règles de syntaxe suivantes:

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

Vous pouvez spécifier plusieurs instances de l'option, 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 de nœuds de calcul dédié, spécifiez cette option pour chaque nœud. Tous les nœuds du pool de nœuds de l'équilibreur de charge doivent se trouver dans le même sous-réseau de couche 2 que les adresses IP virtuelles de l'équilibreur 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 qui commencent par les mots clés node-ip et labels. Séparez chaque segment par une virgule.

    • node-ip: adresse IP d'un nœud dans le pool de nœuds de votre é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:

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

    Si vous spécifiez --metal-lb-load-balancer-node-configs, vous pouvez également inclure les options suivantes:

    • --metal-lb-load-balancer-node-labels: utilisez cette option pour ajouter des libellés à 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 cette option 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 correspondre à 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 comportent l'étiquette lb-pool-key=lb-pool-value et 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 cette option pour chaque nœud de 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 optez pour un déploiement à haute disponibilité. Spécifiez un nombre impair de nœuds 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 qui commencent 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 élément node-ip par option. Si vous devez spécifier plusieurs nœuds, incluez à nouveau l'option pour chaque nœud.
  • labels: une ou plusieurs paires clé=valeur associées au nœud.

    Notez les règles de syntaxe suivantes:

    • Entourez la valeur entière de 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 indicateurs suivants:

  • --control-plane-node-labels: utilisez cette option 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 cette option 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 comportent l'étiquette cp-node-pool-key=cp-node-pool-value et 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 diffuse 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: 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: 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 lequel les sous-répertoires peuvent être créés. Un PersistentVolume (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 de la machine hôte où les disques installés peuvent être détectés. Un PersistentVolume (PV) local est créé pour chaque installation.
  4. --lvp-node-mounts-config-storage: classe de stockage avec laquelle les PV sont créés lors de la création du cluster.

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

Mode manuel

Avec l'équilibrage de charge manuel, vous configurez vos propres solutions d'équilibrage de charge pour le trafic des plans de contrôle et des plans 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 externe du plan de contrôle peut également être utilisé pour le trafic du plan de données. Vous pouvez également configurer un équilibreur de charge distinct pour le plan de données. Pour en savoir plus, consultez la page Configurer l'équilibrage de charge manuel.

Veillez à faire défiler la page si nécessaire pour remplir l'espace réservé ADMIN_CLUSTER_NAME pour l'option --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 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 Bare Metal 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.

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 cette option pour chaque nœud de 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 optez pour un déploiement à haute disponibilité. Spécifiez un nombre impair de nœuds 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 qui commencent 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 élément node-ip par option. Si vous devez spécifier plusieurs nœuds, incluez à nouveau l'option pour chaque nœud.
  • labels: une ou plusieurs paires clé=valeur associées au nœud.

    Notez les règles de syntaxe suivantes:

    • Entourez la valeur entière de 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 indicateurs suivants:

  • --control-plane-node-labels: utilisez cette option 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 cette option 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 comportent l'étiquette cp-node-pool-key=cp-node-pool-value et 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 diffuse 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: 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: 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 lequel les sous-répertoires peuvent être créés. Un PersistentVolume (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 de la machine hôte où les disques installés peuvent être détectés. Un PersistentVolume (PV) local est créé pour chaque installation.
  4. --lvp-node-mounts-config-storage: classe de stockage avec laquelle les PV sont créés lors de la création du cluster.

Pour en savoir plus sur le stockage, consultez la page 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 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 bare-metal operations describe OPERATION_ID \
  --project=FLEET_HOST_PROJECT_ID \
  --location=REGION

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

Pour obtenir la liste complète des indicateurs 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 les 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 la gcloud CLI, vous devez d'abord créer le cluster, puis y ajouter un ou plusieurs pools de nœuds.

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 dans lequel 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 qui commencent 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 cette option 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:

    • Entourez la valeur entière de 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 spécifier les éléments suivants :

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

    • --node-taints=KEY=VALUE:EFFECT,...Liste de rejets Kubernetes séparés par une virgule et 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'une des options suivantes 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. Tous les deux nœuds possèdent l'étiquette node-pool-key=node-pool-value et 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 GKE sur Bare Metal que vous sélectionnez lors de la création d'un cluster d'utilisateur doit être une version compatible avec votre cluster d'administrateur. De plus, les dernières versions mineures ou correctives ne sont disponibles dans l'API GKE On-Prem que 7 à 10 jours après la 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 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.

  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 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:
- 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 compatible la plus récente pour obtenir les dernières corrections et améliorations.

Exemple

Vous pouvez utiliser l'exemple de configuration de base suivant pour créer un cluster d'utilisateur avec un équilibreur de charge MetalLB groupé. Pour en savoir plus, 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 groupé.

  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. 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, puis 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 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. L'exemple suppose que le cluster d'administrateur utilise global comme région. Si vous disposez d'un cluster d'administrateur régional:

      1. Ouvrez main.tf dans un éditeur de texte.

      2. Recherchez admin_cluster_membership, qui se présente comme suit:

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

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

    • bare_metal_version: version de GKE sur Bare Metal pour votre cluster d'utilisateur. Spécifiez la même version que le cluster d'administrateur ou une version dont la version mineure au maximum est infé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) pour accorder aux administrateurs le rôle clusterrole/cluster-admin Kubernetes, 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_ips: liste d'une ou de 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 impair de nœuds 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 de plusieurs adresses IPv4 pour les machines de nœuds de calcul.

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

  4. Enregistrez les modifications dans terraform.tfvars.

  5. Initialisez et créez le plan Terraform :

    terraform init

    Terraform installe toutes les bibliothèques nécessaires, comme le fournisseur Google Cloud.

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

    terraform plan

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

    terraform apply

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

Se connecter au cluster d'utilisateur

Lorsque vous créez un cluster d'utilisateur dans la console, celui-ci est configuré avec les stratégies de contrôle des accès basé sur les rôles (RBAC) de Kubernetes, ce qui vous permet de vous connecter au cluster à l'aide de votre identité Google Cloud. Lorsque vous créez un cluster d'utilisateur avec la gcloud CLI, ces stratégies RBAC vous sont attribuées par défaut si vous n'incluez pas l'option --admin-users. Si vous incluez --admin-users pour désigner un autre utilisateur comme administrateur, vous remplacez la valeur par défaut et devez inclure à la fois votre adresse e-mail et celle de l'autre administrateur. Pour en savoir plus sur les stratégies IAM et RBAC requises, consultez la page Configurer l'authentification de l'identité 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. Vous pouvez obtenir un fichier kubeconfig de deux façons:

  • 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 en toute sécurité le trafic vers le point de terminaison privé en votre nom.

  • Pour un accès direct aux points de terminaison privés, créez un fichier kubeconfig sur votre poste de travail administrateur et gérez le cluster depuis ce poste.

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

Passerelle Connect

  1. initialize 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 GKE sur Bare Metal, 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 à l'aide de kubectl comme vous le feriez normalement pour n'importe quel cluster Kubernetes. Vous n'avez pas besoin de spécifier le nom du fichier kubeconfig, par exemple:

kubectl get namespaces

Poste de travail administrateur

Exécutez la commande bmctl get credentials pour récupérer un fichier kubeconfig pour le cluster d'utilisateur que vous venez de créer.

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 contenant les identifiants du cluster d'utilisateur est écrit dans un fichier bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-TIMESTAMP-kubeconfig. La partie TIMESTAMP du 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é.

Étapes suivantes