Créer un cluster d'administrateur à l'aide de clients API Anthos 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 Anthos On-Prem pour créer le cluster.

Qu'est-ce que l'API Anthos On-Prem ?

L'API Anthos 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 Anthos On-Prem s'exécute dans l'infrastructure Google Cloud. Terraform, la console et la 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 Anthos 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 les données spécifiques à la charge de travail.

Lorsque vous créez un cluster à l'aide d'un client API Anthos 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 Configurer des clusters à gérer par l'API Anthos On-Prem.

Autorisations IAM

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

Si vous souhaitez accéder aux pages GKE Enterprise et Google Kubernetes Engine 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 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 Anthos On-Prem. Si vous installez GKE sur une solution Bare Metal pour la première fois, la console peut vous sembler plus facile à utiliser que la gcloud CLI.

Une fois que vous connaîtrez mieux les informations que vous devez fournir pour créer des clusters, la gcloud CLI sera peut-être plus pratique, car elle vous permet 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 Google Cloud, accédez à la page des clusters GKE Enterprise.

    Accéder à la page "Clusters GKE Enterprise"

  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.

  3. Cliquez sur Créer un cluster.

  4. Dans la boîte de dialogue, cliquez sur Sur site.

  5. À côté de Bare Metal, cliquez sur Configure (Configurer). Assurez-vous que l'option Créer un cluster d'administrateur est sélectionnée.

La page Prérequis affiche les exigences pour votre poste de travail administrateur et vos 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 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 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 la configuration matérielle, le système d'exploitation et la connectivité requise 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. Vous pouvez éventuellement fournir une adresse IP de nœud de départ et une adresse IP virtuelle dans la section Adresse IP du nœud et adresses IP virtuelles. 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. Ils sont destinés à vous aider à planifier les adresses IP dont vous avez besoin pour votre installation. Vous pouvez télécharger le tableau au format CSV, puis l'importer dans une feuille de calcul ou un outil de planification des 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 Anthos 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 manuellement les comptes de service.

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

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 Anthos On-Prem nécessite les mêmes prérequis en matière de matériel, de mise en 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 à 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 Anthos 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 manuellement les comptes de service.

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 utilisez la gcloud CLI pour créer le cluster d'administrateur, vous pouvez suivre les étapes de cette section concernant la console afin d'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. 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 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 Anthos On-Prem s'exécute et la région dans laquelle les éléments suivants sont stockés:

    • Métadonnées du cluster dont l'API Anthos 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 du cluster, le projet et l'emplacement permettent d'identifier 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. Assurez-vous que vous disposez de la dernière version de gcloud CLI, y compris les composants bêta de gcloud CLI.

  2. Si vous ne disposez pas encore des composants bêta, exécutez la commande suivante pour les installer:

    gcloud components install beta

  3. Si nécessaire, mettez à jour les composants de gcloud CLI:

    gcloud components update

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

    gcloud auth login

  5. Listez 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 dans laquelle l'API Anthos On-Prem s'exécute. Spécifiez us-west1 ou une autre région disponible.

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 pour sélectionner votre compte Google pour l'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 et les transmettre à la commande bmctl register bootstrap.

bmctl crée des associations de sécurité.

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 \
  --name=bootstrap-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. Le nom du cluster d'amorçage doit être au format bootstrap-ADMIN_CLUSTER_NAME.

  • 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 Anthos sur bare metal 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 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 fichier 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 \
  --name=bootstrap-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. Le nom du cluster d'amorçage doit être au format bootstrap-ADMIN_CLUSTER_NAME.

  • 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 de l'agent Connect (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'accéder aux journaux d'audit et de 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.

    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 dans la commande bmctl register bootstrap:

    • Assurez-vous que la valeur de --name correspond au Nom d'amorçage dérivé 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 exécuter à 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 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 lorsqu'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 qui devrait être suffisamment clair pour que vous puissiez le résoudre, 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 ne figure pas dans la liste, vérifiez son nom et l'ID du projet que vous avez spécifié sur 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 pour 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 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 Anthos On-Prem s'exécute. Spécifiez us-west1 ou une autre région disponible. Une fois le cluster créé, la région ne peut plus être modifiée. Ce paramètre spécifie la région dans laquelle les éléments suivants sont stockés:

    • Métadonnées du cluster dont l'API Anthos 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 du cluster, le projet et l'emplacement permettent d'identifier de manière unique le cluster dans Google Cloud.

  • VERSION: version de GKE sur Bare Metal. Elle 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. 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 (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 (VIP) 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 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 de plan de contrôle. Les nœuds du plan de contrôle exécutent la charge de travail du système. Spécifiez cette option pour chaque nœud de plan de contrôle. En règle générale, vous disposez d'une seule machine si vous utilisez un déploiement minimal ou de trois machines si vous 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 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 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 typiques. 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 Operations.

Corriger les erreurs survenues 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 termine avec une erreur semblable à la suivante:

ERROR: (gcloud.beta.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 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, 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 gcloud container bare-metal admin-clusters update.

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, 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 le fichier 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 des identifiants d'authentification pour le 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 :

    • Attribue à votre compte utilisateur le rôle Kubernetes clusterrole/view sur le cluster.
    • Il configure le cluster pour 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 à partir de la console à l'aide de votre identité Google. De plus, vous pouvez exécuter des commandes kubectl en lecture seule sur les 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

Étapes suivantes