Créer un cluster d'utilisateur à l'aide des 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 gcloud CLI sont des clients de l'API qui 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 des 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 les données spécifiques aux charges 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. Une fois le cluster créé, le projet hôte du parc ne peut plus être modifié.

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 la section Configurer un cluster d'utilisateur à gérer par l'API GKE On-Prem.

Avant de commencer

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

Accorder des autorisations IAM

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

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, 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 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, elle 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.

  • Vous devez disposer d'une connectivité réseau à tous les nœuds du cluster d'utilisateur après sa création.

  • Ils doivent être enregistrés 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 la section Prérequis pour les machines de nœud de cluster pour vous assurer que les machines qui exécutent le cluster d'utilisateur remplissent les 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 Bare Metal pour la première fois, la console est peut-être l'outil le plus facile à utiliser.

Une fois que vous connaîtrez mieux les informations à fournir pour créer des clusters, Terraform ou la gcloud CLI peut s'avérer plus pratique, en particulier si vous comptez créer plusieurs clusters. Terraform est un outil Infrastructure as Code standard dans l'industrie. Si votre organisation utilise déjà Terraform, vous souhaiterez probablement l'utiliser pour créer des clusters et gérer leur cycle de vie.

La gcloud CLI vous permet d'enregistrer la commande avec ses arguments dans un fichier texte et d'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'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 Bare Metal.

    Accéder à la page Créer un cluster GKE sur 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 les services suivants s'exécutent:

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

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

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

    Le nom, le projet et l'emplacement du cluster 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 le cluster. Vous pouvez également saisir l'adresse e-mail d'un autre utilisateur chargé d'administrer le cluster dans le champ Administrateur.

    Une fois le cluster créé, l'API GKE On-Prem applique les stratégies de contrôle des accès basé sur les rôles (RBAC) Kubernetes au cluster pour vous attribuer, à vous et 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 des pods.

    • Environnement d'exécution du 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 Nœud du 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 dans la liste Mode à configurer pour votre cluster. Pour en savoir plus, consultez la page Présentation des équilibreurs de charge.

    Groupé avec MetalLB

    Configurer 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 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 les nœuds du plan de contrôle: choisissez 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 dédié de nœuds de calcul. 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 (VIP) de l'équilibreur de charge que vous configurez dans 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 du pool de votre é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 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 adresse IP unique dans un pool, utilisez /32 dans le 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 comprenant 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: 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 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 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 des services Kubernetes et des pods au format CIDR. Elles ne doivent pas se chevaucher, 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 d'adresses IP.

    • CIDR de 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 fournit le plus 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 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.

Espace de 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:

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

    • Local volume provisioner share (Partage de l'approvisionneur de volume local) : spécifie la configuration du PersistentVolumes local sauvegardé par des sous-répertoires dans 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 est un modèle pour les groupes de nœuds de calcul créés dans ce cluster.

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

  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 le nom "default-pool".

  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 é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, puis réessayer de créer le cluster.

gcloud CLI

Utilisez 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 options permettant de créer le cluster et le pool de nœuds correspondent aux champs du fichier de configuration du cluster d'utilisateur. Pour vous aider à démarrer, vous pouvez tester l'intégralité de la commande 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 GKE sur Bare Metal 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 correctives 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 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 indique 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 les services mondiaux Fleet et 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. Spécifiez la région dans l'option --admin-cluster-membership-location des exemples de commandes ci-dessous.

  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 mondiale ou d'une région Google Cloud. Utilisez l'emplacement du cluster d'administrateur indiqué dans le résultat 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 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 recommandons d'utiliser la version compatible la plus élevée pour obtenir les dernières corrections et améliorations.

Examples

Cette section fournit un exemple de commande permettant de créer 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 allez utiliser. 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. Une fois le cluster créé, vous ne pourrez plus 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 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é. Une fois le cluster créé, le projet hôte du parc ne peut plus être modifié.
  • 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 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. 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 compatible. Une fois le cluster créé, la région ne peut plus être modifiée. Ce paramètre spécifie la région dans laquelle les éléments suivants sont stockés :
    • Les 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 en tant qu'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

    Une fois le cluster créé, l'API GKE On-Prem applique les stratégies de contrôle des accès basé sur les rôles (RBAC) Kubernetes au cluster pour vous attribuer, à vous et aux autres 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.

Pools d'adresses MetalLB

  • --metal-lb-address-pools: spécifiez la configuration des pools d'adresses que l'équilibreur de charge MetalLB doit utiliser. La valeur de l'indicateur est au 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'attribuera pas d'adresses IP se terminant par .0 ou .255 aux services. Cela permet d'éviter que des appareils grand public présentant des bugs ne 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 à plage traitée. Pour spécifier une adresse IP unique dans un pool (par exemple, pour l'adresse IP virtuelle d'entrée), utilisez /32 au format CIDR (par exemple, 192.0.2.1/32).

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 inclut 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 du pool de nœuds de votre équilibreur de charge. 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 chacun d'eux.

    • 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 éventuellement 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 l'équilibreur de charge. Chaque rejet est une paire clé/valeur associée à un effet, qui doit correspondre à l'une des valeurs suivantes: 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 cette option 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 fois que vous mettez à jour ou mettez à niveau 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 contient 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 chacun d'eux.
  • 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 options suivantes:

  • --control-plane-node-labels: utilisez cet indicateur pour ajouter des étiquettes à 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 portent le libellé 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 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

Espace de stockage

  1. --lvp-share-path: chemin d'accès de la machine hôte dans laquelle les sous-répertoires peuvent être créés. Un PersistentVolume local (PV) est créé pour chaque sous-répertoire.
  2. --lvp-share-storage-class: il s'agit de la 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: il s'agit du chemin d'accès à la machine hôte où les disques installés peuvent être découverts. Un PersistentVolume 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.

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

N'oubliez pas de 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. Une fois le cluster créé, vous ne pourrez plus 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 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é. Une fois le cluster créé, le projet hôte du parc ne peut plus être modifié.
  • 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 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. 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 compatible. Une fois le cluster créé, la région ne peut plus être modifiée. Ce paramètre spécifie la région dans laquelle les éléments suivants sont stockés :
    • Les 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 en tant qu'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

    Une fois le cluster créé, l'API GKE On-Prem applique les stratégies de contrôle des accès basé sur les rôles (RBAC) Kubernetes au cluster pour vous attribuer, à vous et aux autres 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.

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 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 fois que vous mettez à jour ou mettez à niveau 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 contient 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 chacun d'eux.
  • 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 options suivantes:

  • --control-plane-node-labels: utilisez cet indicateur pour ajouter des étiquettes à 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 portent le libellé 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 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

Espace de stockage

  1. --lvp-share-path: chemin d'accès de la machine hôte dans laquelle les sous-répertoires peuvent être créés. Un PersistentVolume local (PV) est créé pour chaque sous-répertoire.
  2. --lvp-share-storage-class: il s'agit de la 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: il s'agit du chemin d'accès à la machine hôte où les disques installés peuvent être découverts. Un PersistentVolume 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 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 résultat, la chaîne operation-1679543737105-5f7893fd5bae9-942b3f97-75e59179 correspond au 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 15 minutes ou plus. Pour afficher le cluster dans la console Google Cloud, accédez à la page Clusters GKE.

Pour obtenir la liste complète des options et de leur description, consultez la documentation de référence de la 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 est un modèle pour les groupes de nœuds de calcul créés dans ce cluster. Avec la gcloud CLI, vous créez d'abord le cluster, puis vous ajoutez un ou plusieurs pools de nœuds au cluster que vous venez de créer.

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 que vous venez de créer.

  • 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 inclut 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 élément node-ip par option. 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 des virgules appliquées à chaque nœud du pool.

    • --node-taints=KEY=VALUE:EFFECT,...Liste des 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 les 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 à ce pool. Tous les deux nœuds sont associés au libellé 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 GKE sur Bare Metal 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 correctives 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 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 indique 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 les services mondiaux Fleet et 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. Spécifiez la région dans l'option --admin-cluster-membership-location des exemples de commandes ci-dessous.

  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 mondiale ou d'une région Google Cloud. Utilisez l'emplacement du cluster d'administrateur indiqué dans le résultat 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 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 recommandons d'utiliser la version compatible la plus élevée 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 sur 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 des 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é. Une fois le cluster créé, le projet hôte du parc ne peut plus être modifié.

    • 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 n'est pas plus d'une inférieure à celle du cluster d'administrateur.

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

      Une fois le cluster créé, l'API GKE On-Prem applique les stratégies de contrôle des accès basé sur les rôles Kubernetes (RBAC) au cluster pour attribuer 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éé, le 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 de cartes qui définissent les pools d'adresses à utiliser 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. Pour afficher le cluster dans la console Google Cloud, accédez à 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) Kubernetes afin que vous puissiez 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 accordées par défaut si vous n'incluez pas l'option --admin-users. Si vous incluez --admin-users pour désigner un autre utilisateur en tant qu'administrateur, vous ignorez la valeur par défaut. Vous 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. 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 paramètre kubeconfig de la passerelle Connect, qui transfère en votre nom le trafic de manière sécurisée vers le point de terminaison privé.

  • 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 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. 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 d'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. 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'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. TIMESTAMP 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é.

Étapes suivantes