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

Cette page explique comment créer un cluster d'administrateur à l'aide de la console Google Cloud ou de Google Cloud CLI (gcloud CLI). Ces deux clients Google Cloud standards utilisent l'API GKE On-Prem pour créer le cluster.

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 d'applications Google Cloud standards. L'API GKE On-Prem s'exécute sur l'infrastructure Google Cloud. Terraform, la console et gcloud CLI sont des clients de l'API. Ils l'utilisent pour créer des clusters dans votre centre de données.

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

Lorsque vous créez un cluster à l'aide d'un client 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 pas être modifié une fois le cluster créé.

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

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

Autorisations IAM

Si vous n'êtes pas propriétaire d'un projet Google Cloud, un propriétaire de projet doit vous accorder les rôles suivants :

Si vous souhaitez accéder aux pages GKE Enterprise et GKE dans la console, vous devez également disposer du rôle roles/container.viewer.

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.

Accès à la ligne de commande

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

  • Dernière version de gcloud CLI.

  • kubectl pour exécuter des commandes sur les clusters Kubernetes. Si vous devez installer kubectl, suivez ces instructions.

Choisir le client pour créer le cluster d'administrateur

Vous pouvez utiliser la console ou gcloud CLI pour créer un cluster d'administrateur géré par l'API GKE On-Prem. Si vous installez Google Distributed Cloud pour la première fois, vous trouverez peut-être la console plus facile à utiliser que gcloud CLI.

Une fois que vous maîtrisez les informations que vous devez fournir pour créer des clusters, vous trouverez peut-être gcloud CLI plus pratique, car vous pouvez enregistrer la commande avec ses arguments dans un fichier texte. Si vous utilisez un outil CI/CD, tel que Cloud Build, vous pouvez utiliser les commandes gcloud pour créer un cluster et spécifier l'indicateur --impersonate-service-account pour automatiser la création.

Prérequis

Console

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

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

  2. Sélectionnez le projet Cloud dans lequel vous souhaitez créer le cluster. Le projet sélectionné est également utilisé comme projet hôte du parc.

La page Prérequis affiche les exigences concernant votre station de travail administrateur et les machines de nœud de cluster. L'outil de planification des adresses IP de la section Exigences réseau vous aide à planifier les adresses IP requises pour une installation minimale d'un cluster d'administrateur et d'un cluster d'utilisateur.

Prérequis pour le poste de travail administrateur

Développez cette section pour afficher les exigences matérielles, de système d'exploitation et de connectivité pour votre poste de travail administrateur.

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

Développez cette section pour afficher les exigences concernant le matériel, le système d'exploitation et la connectivité des machines de nœud de cluster.

Configuration réseau requise

Cette section vous aide à planifier les adresses IP dont vous avez besoin pour un environnement minimal. Si vous le souhaitez, dans la section Adresse IP de nœud et adresses IP virtuelles, vous pouvez éventuellement fournir une adresse IP de nœud de démarrage et une adresse IP virtuelle. La console affiche alors une table des adresses IP virtuelles dont vous avez besoin. Ces adresses IP ne sont pas appliquées à la configuration du cluster d'administrateur. Elles sont destinées à vous aider à planifier les adresses IP dont vous avez besoin pour votre installation. Vous pouvez télécharger la table dans un fichier CSV, puis l'importer dans une feuille de calcul ou un outil de planification d'adresses IP afin de l'utiliser comme point de départ pour effectuer le suivi des adresses IP requises pour vos clusters.

Examiner les ressources Google Cloud

Assurez-vous que toutes les API Google requises sont bien activées dans le projet hôte. En outre, vous devez activer l'API GKE On-Prem :

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

Remplacez FLEET_HOST_PROJECT_ID par l'ID du projet hôte du parc.

Avant de créer le cluster, exécutez la commande bmctl register bootstrap sur votre poste de travail administrateur, comme décrit dans la section Préparer l'environnement d'amorçage. Cette commande peut créer les comptes de service requis avec les autorisations IAM minimales requises pour créer le cluster d'administration. Si vous préférez, vous pouvez configurer manuellement des comptes de service.

Lorsque vous êtes prêt à commencer, cliquez sur Installer l'environnement de démarrage dans la barre de navigation de gauche.

CLI gcloud

Prérequis pour le matériel, la mise en réseau et le système d'exploitation

La création d'un cluster d'administrateur à l'aide d'un client d'API GKE On-Prem nécessite les mêmes conditions préalables matérielles, réseau et système d'exploitation que la création du cluster à l'aide de bmctl. Pour en savoir plus, consultez la section Conditions préalables à l'installation.

API Google requises

Assurez-vous que toutes les API Google requises sont bien activées dans le projet hôte. En outre, vous devez activer l'API GKE On-Prem :

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

Remplacez FLEET_HOST_PROJECT_ID par l'ID du projet hôte du parc.

Comptes de service et autorisations requis

Avant de créer le cluster, exécutez la commande bmctl register bootstrap sur votre poste de travail administrateur, comme décrit dans la section Préparer l'environnement d'amorçage. Cette commande peut créer les comptes de service requis avec les autorisations IAM minimales requises pour créer le cluster d'administration. Si vous préférez, vous pouvez configurer manuellement les comptes de service.

Planifier des adresses IP

Avant de créer le cluster d'administrateur, vous devez planifier les adresses IP de vos clusters. Consultez la page Planifier vos adresses IP pour obtenir un exemple d'allocation d'adresses IP pour un cluster d'administrateur haute disponibilité et deux clusters d'utilisateur haute disponibilité. Même si vous allez utiliser gcloud CLI pour créer le cluster d'administrateur, vous pouvez suivre les étapes de console de cette section pour utiliser le planificateur d'adresses IP.

Préparer l'environnement d'amorçage

Avant de créer le cluster d'administrateur, vous devez exécuter la commande bmctl register bootstrap sur votre poste de travail administrateur. Cette commande déploie un cluster Kubernetes dans Docker (genre) sur le poste de travail administrateur. Ce cluster d'amorçage héberge les contrôleurs Kubernetes nécessaires à la création du cluster d'administrateur. Lorsque vous créez le cluster d'administrateur, les contrôleurs du cluster d'amorçage provisionnent des nœuds, exécutent des vérifications préliminaires et enregistrent le cluster d'administrateur dans le parc. Le cluster d'amorçage est automatiquement supprimé une fois le cluster créé.

Console

  1. Saisissez un nom pour le cluster d'administrateur. Notez que le nom du cluster d'amorçage est dérivé en ajoutant bootstrap- au nom du cluster d'administrateur.

  2. Sélectionnez la version de Google Distributed Cloud pour votre cluster d'administrateur.

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

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

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

  4. La console affiche les commandes à exécuter sur votre poste de travail administrateur. L'outil de ligne de commande bmctl doit correspondre à la version du cluster que vous créez. Si vous avez déjà téléchargé la version applicable de bmctl sur votre poste de travail administrateur, vous n'avez pas besoin de la télécharger à nouveau.

CLI gcloud

  1. Veillez à mettre à jour les composants :

    gcloud components update

  2. Exécutez la commande suivante pour vous connecter avec votre compte Google :

    gcloud auth login

  3. Répertoriez les versions disponibles de Google Distributed Cloud que vous pouvez installer. La version de bmctl que vous téléchargez pour créer l'environnement d'amorçage doit correspondre à la version que vous installerez sur le cluster d'administrateur.

    gcloud container bare-metal admin-clusters query-version-config \
  --location=REGION

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

Créer le cluster d'amorçage

Procédez comme suit sur votre poste de travail administrateur. Ces commandes sont affichées dans la console.

  1. Définissez vos identifiants utilisateur comme identifiants par défaut de l'application (ADC) :

    gcloud auth application-default login

    Suivez les instructions pour sélectionner votre compte Google pour ADC.

  2. Si nécessaire, téléchargez l'outil de ligne de commande bmctl dans le répertoire de travail actuel.

    gcloud storage cp gs://anthos-baremetal-release/bmctl/VERSION/linux-amd64/bmctl .
chmod a+x ./bmctl

    Remplacez VERSION par la version de Google Distributed Cloud que vous souhaitez installer. Si vous avez copié la commande à partir de la console, la version figure déjà dans la commande.

  3. Créez le cluster d'amorçage. Vous pouvez soit autoriser bmctl à créer les comptes de service requis, ou vous pouvez créer les comptes de service et de clés vous-même, puis transmettez-les à la commande bmctl register bootstrap.

bmctl crée des SA

Utilisez la commande suivante si vous souhaitez que bmctl crée les comptes de service requis avec les autorisations minimales requises pour créer le cluster d'administrateur. Cette commande suppose que bmctl se trouve dans le répertoire de travail actuel.

./bmctl register bootstrap \
  --ssh-key=YOUR_PRIVATE_KEY \
  --target-cluster-name=ADMIN_CLUSTER_NAME \
  --project-id=FLEET_HOST_PROJECT_ID

Remplacez les éléments suivants :

Si vous avez copié la commande affichée dans la console, les champs suivants sont déjà renseignés automatiquement.

  • ADMIN_CLUSTER_NAME : nom de votre cluster d'administrateur.

  • FLEET_HOST_PROJECT_ID : projet dans lequel le cluster d'administrateur sera automatiquement enregistré après sa création.

La commande bmctl register bootstrap crée les comptes de service suivants. Les clés de compte de service sont stockées dans le répertoire bmctl-workspace/.sa-keys.

Compte de service Objectif Rôles IAM
anthos-baremetal-gcr Le logiciel Google Distributed Cloud utilise ce compte de service pour télécharger des images de conteneurs à partir de Google Container Registry Aucun
anthos-baremetal-connect L'agent Connect utilise ce compte de service pour maintenir une connexion entre votre cluster et Google Cloud roles/gkehub.connect
anthos-baremetal-register L'agent Connect utilise ce compte de service pour enregistrer vos clusters dans le parc Google Cloud. roles/gkehub.admin
anthos-baremetal-cloud-ops L'agent Stackdriver utilise ce compte de service pour exporter les journaux et les métriques des clusters vers Cloud Logging et Cloud Monitoring. roles/logging.logWriter
roles/monitoring.metricWriter
roles/stackdriver.resourceMetadata.writer
roles/opsconfigmonitoring.resourceMetadata.writer
roles/monitoring.dashboardEditor

Spécifier des fichiers de clé SA

Si vous préférez, vous pouvez transmettre à bmctl les fichiers de clé de compte de service que vous avez créés. La commande suivante utilise les noms de fichiers de clé dans Configurer manuellement des comptes de service et part du principe que bmctl et les fichiers de clé se trouvent dans le répertoire de travail actuel.

./bmctl register bootstrap \
  --ssh-key=YOUR_PRIVATE_KEY \
  --target-cluster-name=ADMIN_CLUSTER_NAME \
  --project-id=FLEET_HOST_PROJECT_ID \
  --gcr-service-account-key=anthos-baremetal-gcr.json \
  --gke-agent-service-account-key=connect-agent.json \
  --gke-register-service-account-key=connect-register.json \
  --cloud-operation-service-account-key=anthos-baremetal-cloud-ops.json

Remplacez les éléments suivants :

  • YOUR_PRIVATE_KEY : chemin d'accès au fichier de clé SSH privée. Vous avez créé la clé SSH lors de la configuration de l'accès SSH racine aux nœuds.

  • ADMIN_CLUSTER_NAME: nom de votre cluster d'administrateur.

  • FLEET_HOST_PROJECT_ID : projet dans lequel le cluster d'administrateur sera automatiquement enregistré après sa création.

Les options suivantes spécifient le chemin d'accès aux fichiers de clé :

  • -gcr-service-account-key : chemin d'accès au fichier de clé du compte de service qui extrait les images de conteneur (anthos-baremetal-gcr).

  • --gke-agent-service-account-key : chemin d'accès au fichier de clé du compte de service de l'agent Connect (anthos-baremetal-connect).

  • --gke-register-service-account-key : chemin d'accès au fichier de clé du compte de service de l'agent Connect qui enregistre le cluster dans le parc (anthos-baremetal-register).

  • --cloud-operation-service-account-key : chemin d'accès au fichier de clé du compte de service pour auditer les journaux et surveiller les projets (anthos-baremetal-cloud-ops).

Une fois que bmctl a créé le cluster d'amorçage, vous obtenez un résultat semblable à celui-ci :

[2023-03-22 17:35:24+0000] Waiting for the temporary cluster to be registered... OK
[2023-03-22 17:35:37+0000] Please go to https://console.cloud.google.com/home/dashboard?project=example-project-12345 to create the cluster
[2023-03-22 17:35:37+0000] Waiting for preflight checks and cluster to run..

Créez le cluster d'administrateur :

Console

  1. Sur la page Installer l'environnement d'amorçage, cliquez sur Vérifier la connexion.

    Si l'opération réussit, la console affiche Connexion établie.

    La connexion au cluster d'amorçage doit être établie avant de continuer. Si la connexion n'est pas établie, vérifiez les arguments que vous avez spécifiés pour la commande bmctl register bootstrap :

    • Assurez-vous que la valeur de --target-cluster-name correspond au nom du cluster d'administrateur affiché dans la section Principes de base de l'environnement d'amorçage.

    • Assurez-vous que la valeur de --project-id correspond à l'ID du projet que vous avez sélectionné dans la console.

    Si vous devez modifier le nom du cluster d'amorçage ou l'ID de projet, saisissez Ctrl-C pour quitter bmctl register bootstrap et exécutez à nouveau la commande.

  2. Cliquez sur Suivant pour commencer à configurer le cluster d'administrateur. La plupart des paramètres de la console correspondent aux champs du fichier de configuration du cluster.

  3. Sous Configuration des nœuds, saisissez une valeur comprise entre 64 et 250 dans le champ Nombre maximal de pods par nœud ou acceptez la valeur par défaut (110). Une fois le cluster créé, vous ne pouvez plus modifier cette valeur.

    Le nombre maximal de pods par nœud (appelé "densité de pods") est également limité par les ressources IP disponibles de votre cluster. Pour plus de détails, consultez la section Mise en réseau de pods.

  4. Cliquez sur Suivant.

  5. Sur la page Mise en réseau, définissez la manière dont vos nœuds et composants du cluster communiquent entre eux et avec le plan de contrôle de Kubernetes.

    Pour en savoir plus, maintenez le pointeur sur le  à côté de chaque champ.

  6. Cliquez sur Vérifier et créer.

    La console affiche les messages d'état de vérification des paramètres et de création du cluster dans votre centre de données.

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

CLI gcloud

Avant de créer le cluster d'administrateur, vérifiez que le cluster d'amorçage a été enregistré en tant que membre du parc :

gcloud container fleet memberships list \
  --project=FLEET_HOST_PROJECT_ID

Si le cluster d'amorçage n'est pas listé, vérifiez le nom du cluster d'amorçage et l'ID de projet que vous avez spécifiés à bmctl register bootstrap. Si vous devez modifier le nom du cluster d'amorçage ou l'ID de projet, saisissez Ctrl-C pour quitter bmctl register bootstrap et exécutez à nouveau la commande.

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

gcloud container bare-metal admin-clusters create

La plupart des options que vous spécifiez à la commande correspondent aux champs du fichier de configuration du cluster d'utilisateur.

Pour créer un cluster d'administrateur avec l'équilibreur de charge groupé :

gcloud container bare-metal admin-clusters create ADMIN_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --location=REGION \
  --version=VERSION \
  --max-pods-per-node=MAX_PODS_PER_NODE \
  --control-plane-vip=CONTROL_PLANE_VIP \
  --control-plane-load-balancer-port=CONTROL_PLANE_LOAD_BALANCER_PORT \
  --control-plane-node-configs 'CONTROL_PLANE_NODE_CONFIG' \
  --island-mode-service-address-cidr-blocks=SERVICE_ADDR_CIDR \
  --island-mode-pod-address-cidr-blocks=POD_ADDR_CIDR \
  --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

Si vous souhaitez utiliser l'équilibrage de charge manuel, ajoutez --enable-manual-lb à la commande.

Remplacez les éléments suivants :

  • ADMIN_CLUSTER_NAME: nom de votre cluster d'administrateur. Une fois le cluster créé, son nom ne peut plus être modifié.

  • FLEET_HOST_PROJECT_ID : projet dans lequel le cluster d'administrateur sera automatiquement enregistré après sa création. Le projet hôte du parc ne peut pas être modifié une fois le cluster créé.

  • REGION : région Google Cloud dans laquelle l'API GKE On-Prem s'exécute. 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 :

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

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

  • VERSION : version de Google Distributed Cloud. La version doit correspondre à la version bmctl que vous avez utilisée pour exécuter bmctl register bootstrap. Vous pouvez vérifier la version de bmctl en exécutant bmctl version sur le poste de travail administrateur.

  • MAX_PODS_PER_NODE  : pour les clusters d'administrateur, les valeurs autorisées sont 32-250 et 64-250 pour les clusters non haute disponibilité. Si --max-pods-per-node n'est pas inclus dans la commande, la valeur par défaut est 110. Une fois le cluster créé, cette valeur ne peut pas être mise à jour.

    Le nombre maximal de pods par nœud (appelé "densité de pods") est également limité par les ressources IP disponibles de votre cluster. Pour plus de détails, consultez la section Mise en réseau de pods.

  • CONTROL_PLANE_VIP : adresse IP virtuelle de l'équilibreur de charge pour le serveur d'API Kubernetes du cluster. Incluez l'adresse IP virtuelle du plan de contrôle dans le sous-réseau des nœuds de l'équilibreur de charge. N'incluez pas l'adresse IP virtuelle du plan de contrôle dans les pools d'adresses de l'équilibreur de charge.

  • CONTROL_PLANE_LOAD_BALANCER_PORT : port sur lequel l'équilibreur de charge diffuse le plan de contrôle. Bien que vous puissiez configurer une autre valeur, le port 443 est le port standard utilisé pour les connexions HTTPS.

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

    La valeur de l'indicateur a le format suivant :

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

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

    • node-ip : adresse IP d'un nœud de plan de contrôle. Vous ne pouvez spécifier qu'un seul é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 :

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

    Exemple :

    --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-plane-node-configs 'node-ip=192.0.2.3,labels=key3.1=value3.1;key3.2=value3.2' \

  • SERVICE_ADDR_CIDR : plage d'adresses IPv4, au format CIDR, 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. Nous vous recommandons d'utiliser une plage de l'espace d'adressage IP pour les Internet privés, définie dans la RFC 1918, par exemple 10.96.0.0/20.

  • POD_ADDR_CIDR : plage d'adresses IPv4 au format CIDR à utiliser pour les pods du cluster d'utilisateur. La plage CIDR doit être comprise entre /18 et /8, où /8 correspond au plus grand nombre d'adresses IP. Nous vous recommandons d'utiliser une plage de l'espace d'adressage IP pour les Internet privés, définie dans la RFC 1918, par exemple 192.168.0.0/16.

Vous devez spécifier les options de stockage suivantes. L'exemple de commande inclut des valeurs typiques. Pour en savoir plus, consultez la section Configurer le stockage local.

  • --lvp-share-path : chemin d'accès à la machine hôte dans laquelle les sous-répertoires peuvent être créés. Un volume persistant (PersistentVolume ou PV) local est créé pour chaque sous-répertoire.

  • --lvp-share-storage-class : StorageClass à utiliser pour créer des volumes persistants. La StorageClass est créée lors de la création du cluster.

  • --lvp-node-mounts-config-path : chemin d'accès de la machine hôte dans laquelle les disques installés peuvent être détectés. Un volume persistant (PersistentVolume ou PV) local est créé pour chaque installation.

  • --lvp-node-mounts-config-storage : classe de stockage avec laquelle les volumes persistants sont créés lors de la création du cluster.

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

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 est le OPERATION_ID de l'opération de longue durée. Vous pouvez connaître l'état de l'opération à l'aide de la commande suivante :

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

Pour plus d'informations, consultez la page opérations bare-metal de conteneur gcloud.

Corriger les erreurs détectées lors des requêtes préliminaires

Avant de créer le cluster, bmctl exécute une série de requêtes préliminaires pour valider la configuration. En cas de problème avec la configuration, la commande gcloud ... create se termine avec une erreur semblable à la suivante :

ERROR: (gcloud.container.bare-metal.admin-clusters.create) Invalid resource state for "projects/694677185633/locations/us-west1/bareMetalAdminClusters/abm-cluster-1": cluster preflight checks failed

Par exemple, supposons qu'une requête préliminaire a échoué, car le nœud du plan de contrôle n'a pas pu être atteint. Sur le poste de travail administrateur, un résultat semblable à celui-ci s'affiche :

[2023-03-27 20:34:38+0000] Waiting for preflight check job to finish... OK
[2023-03-27 20:35:58+0000] - Validation Category: machines and network
[2023-03-27 20:35:58+0000]    - [PASSED] pod-cidr
[2023-03-27 20:35:58+0000]    - [FAILED] node-network (log: bmctl-workspace/log/register-bootstrap-20230327-201548/node-network)
[2023-03-27 20:35:58+0000]        - Failed to connect to the host via ssh: ssh: connect to host 10.100.0.5 port 22: Connection timed out
[2023-03-27 20:35:58+0000] Flushing logs... OK
[2023-03-27 20:35:58+0000] Error polling the preflight check abm-cluster-mar-27 in the cluster-abm-cluster-mar-27: preflight check failed

  1. Sur le poste de travail administrateur, assurez-vous que le processus bmctl register bootstrap est toujours en cours d'exécution. Si ce n'est pas le cas, exécutez à nouveau la commande avec les mêmes arguments et ajoutez l'option --reuse-bootstrap-cluster=true.

  2. Exécutez gcloud ... update pour corriger l'adresse IP non valide :

    gcloud container bare-metal admin-clusters update ADMIN_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --location=REGION \
  --control-plane-node-configs 'node-ip=NEW_NODE_ID_ADDRESS'

    Pour en savoir plus, consultez la page mise à jour des clusters d'administrateur bare metal pour les conteneurs gcloud.

Les détails du processus de création du cluster sont générés sur votre poste de travail administrateur. Si les vérifications préliminaires réussissent, vous obtenez un résultat semblable au suivant :

[2023-03-22 23:12:47+0000] Waiting for cluster kubeconfig to become ready OK
[2023-03-22 23:15:47+0000] Writing kubeconfig file
[2023-03-22 23:15:47+0000] kubeconfig of cluster being created is present at bmctl-workspace/abm-cluster-1/abm-cluster-1-kubeconfig
[2023-03-22 23:15:47+0000] Please restrict access to this file as it contains authentication credentials of your cluster.
[2023-03-22 23:15:47+0000] Waiting for cluster to become ready OK
[2023-03-22 23:20:17+0000] Please run
[2023-03-22 23:20:17+0000] kubectl --kubeconfig bmctl-workspace/abm-cluster-1/abm-cluster-1-kubeconfig get nodes
[2023-03-22 23:20:17+0000] to get cluster nodes status.
[2023-03-22 23:20:17+0000] Waiting for node pools to become ready OK
[2023-03-22 23:20:37+0000] Waiting for metrics to become ready in GCP OK
[2023-03-22 23:25:38+0000] Waiting for cluster API provider to install in the created admin cluster OK
[2023-03-22 23:25:48+0000] Moving admin cluster resources to the created admin cluster
[2023-03-22 23:25:51+0000] Waiting for node update jobs to finish OK
[2023-03-22 23:27:41+0000] Flushing logs... OK
[2023-03-22 23:27:41+0000] Deleting membership... OK
[2023-03-22 23:27:42+0000] Deleting bootstrap cluster.

Se connecter au cluster d'administrateur

La commande bmctl register bootstrap crée un fichier kubeconfig pour le cluster d'administrateur sur votre poste de travail administrateur. Le répertoire où se trouve le fichier kubeconfig et le nom du fichier sont basés sur le nom du cluster d'administrateur, comme suit :

bmctl-workspace/ADMIN_CLUSTER_NAME/ADMIN_CLUSTER_NAME-kubeconfig

Vous devez restreindre l'accès à cet kubeconfig, car il contient les identifiants d'authentification du cluster.

Si vous souhaitez utiliser votre identité Google pour vous connecter au cluster, vous pouvez configurer la passerelle Connect comme suit :

  1. Sur votre poste de travail administrateur, définissez la variable d'environnement KUBECONFIG :

    export KUBECONFIG=$HOME/bmctl-workspace/ADMIN_CLUSTER_NAME/ADMIN_CLUSTER_NAME-kubeconfig

  2. Définissez le contexte actuel dans une variable d'environnement :

    export CONTEXT="$(kubectl config current-context)"

  3. Exécutez la commande gcloud suivante : Cette commande effectue les opérations suivantes :

    • Accorde à votre compte utilisateur le rôle clusterrole/view Kubernetes sur le cluster.
    • Configure le cluster afin que vous puissiez exécuter des commandes kubectl en lecture seule sur votre ordinateur local sans avoir à vous connecter en SSH au poste de travail administrateur.

    Remplacez GOOGLE_ACCOUNT_EMAIL par l'adresse e-mail associée à votre compte Google Cloud. Exemple : --users=alex@example.com.

    gcloud container fleet memberships generate-gateway-rbac  \
    --membership=ADMIN_CLUSTER_NAME \
    --role=clusterrole/view \
    --users=GOOGLE_ACCOUNT_EMAIL \
    --project=FLEET_HOST_PROJECT_ID \
    --kubeconfig=$KUBECONFIG \
    --context=$CONTEXT\
    --apply

    Le résultat de cette commande ressemble à ce qui suit, qui est tronqué pour des raisons de lisibilité :

    Validating input arguments.
Specified Cluster Role is: clusterrole/view
Generated RBAC policy is:
--------------------------------------------
...

Writing RBAC policy for user: GOOGLE_ACCOUNT_EMAIL to cluster.
Successfully applied the RBAC policy to cluster.

Une fois ces stratégies RBAC en place, vous pouvez vous connecter au cluster depuis la console à l'aide de votre identité Google. En outre, vous pouvez exécuter des commandes kubectl en lecture seule sur des ordinateurs autres que le poste de travail administrateur à l'aide d'un kubeconfig spécial qui achemine les requêtes via la passerelle Connect.

  1. Exécutez la commande suivante sur un ordinateur autre que le poste de travail administrateur pour obtenir l'entrée kubeconfig pouvant accéder au cluster via la passerelle Connect.

    gcloud container fleet memberships get-credentials ADMIN_CLUSTER_NAME \
    --project=FLEET_HOST_PROJECT_ID

    Le résultat ressemble à ce qui suit :

    Starting to build Gateway kubeconfig...
Current project_id: FLEET_HOST_PROJECT_ID
A new kubeconfig entry "connectgateway_FLEET_HOST_PROJECT_ID_global_ADMIN_CLUSTER_NAME" has been generated and set as the current context.

  2. Vous pouvez désormais exécuter des commandes kubectl via la passerelle Connect :

    kubectl get pods -A

Étape suivante