Créer un cluster d'administrateur à l'aide des 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 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'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, vous devez demander à un propriétaire du projet de vous attribuer les rôles suivants:

Si vous souhaitez accéder aux pages GKE Enterprise et GKE de 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 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 Google Distributed Cloud pour la première fois, la console est peut-être plus facile à utiliser que la gcloud CLI.

Une fois que vous vous êtes familiarisé avec les informations à fournir pour créer des clusters, la gcloud CLI peut s'avérer 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'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 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.

La page Conditions préalables affiche les conditions requises pour votre poste de travail administrateur et vos machines de nœud de cluster. Le planificateur d'adresses IP de la section Configuration réseau requise vous aide à planifier les adresses IP nécessaires à l'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 en termes de matériel, 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 en termes de matériel, de système d'exploitation et de connectivité pour les 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 du nœud et adresses IP virtuelles, vous pouvez fournir une adresse IP de nœud de départ et une adresse IP virtuelle. La console affiche alors la table des adresses IP dont vous avez besoin. Ces adresses IP ne sont pas appliquées à la configuration du cluster d'administrateur. Ils sont conçus pour vous aider à planifier les adresses IP dont vous avez besoin pour votre installation. Vous pouvez télécharger la table 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, 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 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 Install bootstrap environment (Installer l'environnement d'amorçage) dans la barre de navigation de gauche.

gcloud CLI

Prérequis concernant 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 prérequis en termes de matériel, de mise en réseau et de système d'exploitation que pour la création du cluster avec 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 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 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 utilisez la gcloud CLI pour créer le cluster d'administrateur, 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 in Docker (kind) 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, 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. Dans le champ Nom, saisissez le nom du cluster d'administrateur. Notez que le nom du cluster d'amorçage est obtenu en ajoutant bootstrap- au nom du cluster d'administrateur.

  2. Sélectionnez la version 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 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:

    • Les métadonnées du cluster dont l'API GKE On-Prem a besoin pour gérer son cycle de vie
    • 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. 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.

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 Google Distributed Cloud disponibles 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 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.

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 les appels par centres d'intérêt.

  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 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 laisser bmctl créer les comptes de service requis, soit créer les comptes de service et les fichiers de clés vous-même, puis les transmettre à la commande bmctl register bootstrap.

bmctl crée des associations de compte

Exécutez 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à remplis.

  • 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 Google Distributed Cloud utilise ce compte de service pour télécharger des images de conteneur à 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 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é figurant sur la page 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 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 la création du cluster.

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 Connect Agent (anthos-baremetal-connect).

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

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

Une fois que bmctl a créé le cluster d'amorçage, un résultat semblable aux lignes suivantes 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.

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

    Vous devez établir la connexion au cluster d'amorçage 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écutez 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 (ou "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 Kubernetes.

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

  6. Cliquez sur Verify and Create (Valider et créer).

    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

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 répertorié, 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 dans 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. Une fois le cluster créé, vous ne pourrez plus modifier son nom.

  • FLEET_HOST_PROJECT_ID: projet dans lequel le cluster d'administrateur sera automatiquement enregistré après la création du cluster. 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 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:

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

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

  • VERSION: version de Google Distributed Cloud La 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 comprises entre 32 et 250, et entre 64 et 250 pour les clusters standards. La valeur par défaut si --max-pods-per-node n'est pas inclus dans la commande est 110. Une fois le cluster créé, cette valeur ne peut plus être mise à jour.

    Le nombre maximal de pods par nœud (ou "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.

  • CONTROL_PLANE_VIP: adresse IP virtuelle (VIP) 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 qu'il soit possible de 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 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 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 le 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 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 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.

    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 pour les 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 pour les réseaux 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 courantes. Pour en savoir plus, consultez la page Configurer le stockage local.

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

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

  • --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 options et de leur description, consultez la documentation de référence de la 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 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 sur gcloud container bare-metal operations.

Corriger les erreurs liées aux 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 est inaccessible. Sur le poste de travail administrateur, un message 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, 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 plus d'informations, consultez gcloud container bare-metal admin-clusters update.

Les détails du processus de création du cluster sont disponibles sur votre poste de travail administrateur. Si les vérifications préliminaires réussissent, un message semblable au suivant 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 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 limiter l'accès à ce kubeconfig, car il contient des identifiants d'authentification pour le 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 :

    • Accorde à votre compte utilisateur le rôle clusterrole/view Kubernetes sur le cluster.
    • Il configure le cluster de sorte 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. 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