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

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

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

Si vous préférez, vous pouvez créer un cluster d'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 la gcloud CLI pour gérer le cycle de vie des clusters créés à l'aide de bmctl, consultez la section Configurer les clusters à gérer par l'API GKE On-Prem.

Autorisations IAM

Si vous n'êtes pas propriétaire d'un projet Google Cloud, celui-ci doit vous attribuer 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 de connexion pour exécuter des commandes kubectl sur le cluster 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.

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

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

Une fois que vous vous serez familiarisé avec les informations à fournir pour créer des clusters, la gcloud CLI vous permettra peut-être d'enregistrer la commande et ses arguments dans un fichier texte. Si vous utilisez un outil de CI/CD, tel que Cloud Build, vous pouvez exécuter les commandes gcloud pour créer un cluster et spécifier l'option --impersonate-service-account pour automatiser la création.

Prérequis

Console

  1. Dans la console, accédez à la page Créer un cluster GKE sur une solution Bare Metal.

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

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

La page Prérequis affiche les exigences relatives au poste de travail administrateur et aux machines de nœud de cluster. Le planificateur d'adresses IP de la section Exigences réseau vous aide à planifier les adresses IP nécessaires 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 la configuration matérielle, le système d'exploitation et la connectivité requise 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é pour les machines du nœud de cluster.

Configuration réseau requise

Cette section vous aide à planifier les adresses IP dont vous avez besoin pour un environnement minimal. Dans la section Adresse IP du nœud et adresses IP virtuelles, vous pouvez éventuellement fournir une adresse IP de nœud de départ et une adresse IP virtuelle (VIP). La console affiche alors une table d'adresses IP dont vous avez besoin. Ces adresses IP ne sont pas appliquées à la configuration du cluster d'administrateur. Elles sont conçues pour vous aider à planifier les adresses IP dont vous avez besoin pour votre installation. Vous pouvez télécharger le tableau au format CSV et 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 suivre les adresses IP nécessaires à vos clusters.

Consultez 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, vous devez exécuter 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 permet de créer les comptes de service requis avec les autorisations IAM minimales requises pour créer le cluster d'administrateur. Si vous préférez, vous pouvez configurer les comptes de service manuellement.

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

gcloud CLI

Configuration requise 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 API GKE On-Prem nécessite les mêmes conditions préalables en termes de matériel, de réseau et de système d'exploitation que la création du cluster à l'aide de bmctl. Pour en savoir plus, consultez la section Conditions préalables d'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, vous devez exécuter 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 permet de créer les comptes de service requis avec les autorisations IAM minimales requises pour créer le cluster d'administrateur. Si vous préférez, vous pouvez configurer les comptes de service manuellement.

Planifier les adresses IP

Avant de créer le cluster d'administrateur, vous devez planifier les adresses IP de vos clusters. Consultez la section Planifier vos adresses IP pour voir 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 créez le cluster d'administrateur à l'aide de la gcloud CLI, vous pouvez suivre les étapes de cette section concernant la console 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 les nœuds, effectuent des vérifications préliminaires et enregistrent le cluster d'administrateur dans le parc. Il 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 le préfixe bootstrap- au nom du cluster d'administrateur.

  2. Sélectionnez la version de GKE sur Bare Metal 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 l'API GKE On-Prem s'exécute et la région dans laquelle les éléments suivants sont stockés:

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

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

  4. La console affiche les commandes que vous devez 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.

gcloud CLI

  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 de GKE sur Bare Metal 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 allez installer 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 lors de la création du cluster. Il s'agit de la région dans laquelle l'API GKE On-Prem et les services Fleet and Connect s'exécutent. Spécifiez us-west1 ou une autre région compatible.

Créer le cluster d'amorçage

Procédez comme suit sur votre poste de travail administrateur. Ces commandes s'affichent 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 afin de 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.

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

    Remplacez VERSION par la version de GKE sur Bare Metal 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 laisser bmctl créer les comptes de service requis, soit créer les comptes de service et les fichiers de clé vous-même, puis les transmettre à la commande bmctl register bootstrap.

bmctl crée des associations de confiance.

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.

  • 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 la création du cluster.

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 GKE sur Bare Metal utilise ce compte de service pour télécharger des images de conteneurs à partir de Google Container Registry. Aucune
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 les 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é décrits dans la section Configurer les comptes de service manuellement et suppose 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 à votre clé SSH privée. Vous avez créé la clé SSH lorsque vous avez configuré un 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 la création du cluster.

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

  • -gcr-service-account-key: chemin d'accès au fichier de clé du compte de service qui extrait des 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 consigner les journaux d'audit et surveiller les projets (anthos-baremetal-cloud-ops).

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

[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éer le cluster d'administrateur

Console

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

    En cas de réussite, 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 dans 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 du projet, saisissez Ctrl-C pour quitter bmctl register bootstrap et réexécuter 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 mettre à jour 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 en savoir plus, 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 les nœuds et les composants du cluster communiquent entre eux et avec le plan de contrôle de Kubernetes.

    Pour obtenir des informations détaillées, pointez sur le à côté de chaque champ.

  6. Cliquez sur Valider et créer.

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

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

gcloud CLI

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 ne figure pas dans la liste, vérifiez son nom et l'ID de projet que vous avez spécifiés dans bmctl register bootstrap. Si vous devez modifier le nom du cluster d'amorçage ou l'ID du projet, saisissez Ctrl-C pour quitter bmctl register bootstrap et réexécuter la commande.

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

gcloud container bare-metal admin-clusters create

La plupart des indicateurs 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é, procédez comme suit:

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. Le nom ne peut plus être modifié une fois le cluster créé.

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

  • REGION: région Google Cloud dans laquelle l'API GKE On-Prem 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 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 GDCV pour Bare Metal. Cette version doit correspondre à la version de 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 standards. 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 plus être mise à jour.

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

  • CONTROL_PLANE_VIP: adresse IP virtuelle sur l'équilibreur de charge pour le serveur d'API Kubernetes du cluster. Incluez l'adresse IP virtuelle du plan de contrôle dans le même sous-réseau que les 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 du plan de contrôle. Les nœuds du plan de contrôle exécutent la charge de travail du système. Spécifiez cette option pour chaque nœud de plan de contrôle. En règle générale, vous disposez d'une seule machine si vous utilisez un déploiement minimal ou de trois machines si vous 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 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 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 node-ip par indicateur. Si vous devez spécifier plusieurs nœuds, incluez à nouveau l'indicateur pour chaque nœud.

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

    Notez les règles de syntaxe suivantes:

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

    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 dans l'espace d'adressage IP des réseaux 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 dans l'espace d'adressage IP des réseaux Internet privés, définie dans la RFC 1918, par exemple 192.168.0.0/16.

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

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

  • --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 où les disques installés peuvent être détectés. Un PersistentVolume (PV) local est créé pour chaque installation.

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

Pour obtenir la liste complète des indicateurs et 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 correspond au OPERATION_ID de l'opération de longue durée. Vous pouvez vérifier l'état de l'opération à l'aide de la commande suivante:

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

Pour en savoir plus, consultez la page gcloud container bare-metal operation.

Corriger les erreurs se produisant lors des vérifications préliminaires

Avant de créer le cluster, bmctl exécute une série de vérifications préliminaires pour vérifier la configuration. En cas de problème de configuration, la commande gcloud ... create se ferme avec une erreur semblable à celle-ci:

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 vérification 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, vous devriez voir un résultat semblable à celui-ci:

[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, réexécutez 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 sur gcloud container bare-metal admin-clusters update.

Les détails du processus de création du cluster sont affichés sur votre poste de travail administrateur. Si les vérifications préliminaires réussissent, un résultat semblable à celui-ci s'affiche:

[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 dans lequel se trouve kubeconfig et le nom de 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 à ce 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 de connexion 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 :

    • Attribue à votre compte utilisateur le rôle Kubernetes clusterrole/view sur le cluster.
    • Il 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é par souci 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 à partir de la console à l'aide de votre identité Google. De plus, 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 de connexion.

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

    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 maintenant exécuter des commandes kubectl via la passerelle de connexion:

    kubectl get pods -A

Étapes suivantes