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

Pour gérer le cycle de vie de vos clusters, l'API Anthos On-Prem doit stocker les 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 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. Le projet hôte du parc ne peut plus être modifié une fois le cluster créé.

Si vous préférez, vous pouvez aussi 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 Créer un cluster d'administrateur.

Si vous souhaitez utiliser la console ou gcloud CLI pour gérer le cycle de vie des clusters créés à l'aide de bmctl, consultez Configurer les 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 de projet doit vous attribuer les rôles suivants:

Si vous souhaitez accéder aux pages Anthos 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 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 ces instructions.

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

Vous pouvez utiliser la console ou gcloud CLI pour créer un cluster d'administrateur géré par l'API Anthos On-Prem. Si c'est la première fois que vous installez des clusters Anthos sur bare metal, vous trouverez peut-être la console plus facile à utiliser que gcloud CLI.

Une fois que vous maîtrisez les informations que vous devez fournir pour créer des clusters, vous pouvez utiliser gcloud CLI plus facilement, 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 Google Cloud, accédez à la page Clusters d'Anthos.

    Accéder à la page "Clusters Anthos"

  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 Configurer. Assurez-vous que l'option Créer un cluster d'administrateur est sélectionnée.

La page Conditions préalables affiche les conditions requises pour votre poste de travail administrateur et vos machines de nœuds de cluster. Le planificateur d'adresses IP de la section Configuration réseau requise vous permet de 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 matérielles, de système d'exploitation et de connectivité de 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é requis 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. Dans la section Adresses IP de nœuds et adresses IP virtuelles, vous pouvez éventuellement fournir une adresse IP de nœud de démarrage et une adresse IP virtuelle (VIP). La console affiche un tableau des 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 la table au format CSV et l'importer dans une feuille de calcul ou un outil de planification d'adresses IP afin de commencer à suivre les adresses IP requises pour vos clusters.

Examinez 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 de parc.

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

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

gcloud CLI

Conditions préalables pour le matériel, la mise en réseau et le système d'exploitation

La création d'un cluster d'administrateur à l'aide d'un client d'API Anthos On-Prem nécessite les mêmes prérequis de matériel, de mise en réseau et de système d'exploitation que la création du cluster avec bmctl. Pour en savoir plus, consultez 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 de parc.

Comptes de service et autorisations requis

Avant de créer le cluster, exécutez la commande bmctl register bootstrap sur votre poste de travail administrateur, comme décrit dans la section Préparer l'environnement d'amorçage. Cette commande peut créer les comptes de service requis avec les autorisations IAM minimales requises pour créer le cluster d'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 obtenir un exemple d'allocation d'adresses IP pour un cluster d'administrateur haute disponibilité et deux clusters d'utilisateurs à haute disponibilité. Même si vous prévoyez de créer le cluster d'administrateur à l'aide de gcloud CLI, vous pouvez suivre les étapes de la console décrites dans cette section pour utiliser le planificateur d'adresses IP.

Préparer l'environnement d'amorçage

Avant de créer le cluster d'administrateur, vous devez exécuter la commande bmctl register bootstrap sur votre poste de travail administrateur. Cette commande déploie un cluster Kubernetes in Docker (kind) sur le poste de travail administrateur. Ce cluster bootstrap 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. Saisissez un nom pour le cluster d'administrateur. Notez que le nom du cluster d'amorçage est dérivé du préfixe bootstrap-.

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

    • Les 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, le projet et l'emplacement du cluster permettent d'identifier le cluster de manière unique 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 de disposer de la dernière version de gcloud CLI, y compris des 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 à votre compte Google:

    gcloud auth login

  5. Répertoriez les clusters Anthos sur bare metal disponibles que vous pouvez installer. La version 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 beta 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 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 le service 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 des clusters Anthos sur bare metal que vous souhaitez installer. Si vous avez copié la commande depuis la console, la version figure déjà dans la commande.

  3. Créez le cluster d'amorçage. Vous pouvez laisser bmctl créer les comptes de service requis, ou vous pouvez 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 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 est enregistré automatiquement une fois le cluster créé.

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-barémetal-gcr Anthos sur bare metal utilise ce compte de service pour télécharger des images de conteneurs depuis Google Container Registry. Aucune
anthos-barétope-connect Connect Agent utilise ce compte de service pour maintenir une connexion entre votre cluster et Google Cloud roles/gkehub.connect (rôles/gkehub.connect)
anthos-barélite-enregistrement Connect Agent utilise ce compte de service pour enregistrer vos clusters dans le parc Google Cloud. roles/gkehub.admin
anthos-barélites-opérations-cloud L'agent Stackdriver utilise ce compte de service pour exporter les journaux et les métriques des clusters vers Cloud Logging et Cloud Monitoring. roles/logging.logWriter
roles/monitoring.metricWriter
roles/stackdriver.resourceMetadata.writer
roles/opsconfigmonitoring.resourceMetadata.writer
roles/monitoring.dashboardEditor

Spécifier des fichiers de clé SA

Si vous préférez, vous pouvez transmettre à bmctl les fichiers de clé de compte de service que vous avez créés. La commande suivante utilise les noms de fichiers de clé dans Configurer 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 est enregistré automatiquement une fois le cluster créé.

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 conteneurs (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é du compte de service pour auditer les journaux et surveiller les projets (anthos-baremetal-cloud-ops).

Une fois que bmctl a créé le cluster d'amorçage, 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 Install bootstrap environment (Installer l'environnement d'amorçage), cliquez sur Check Connection (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 pour --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 du nœud, 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 Next (Suivant).

  5. Sur la page Mise en réseau, définissez la façon dont les nœuds et les composants du cluster communiquent entre eux et avec le plan de contrôle de Kubernetes.

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

  6. Cliquez sur Valider et créer.

    La console affiche des messages d'état lorsqu'elle valide 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 doit être suffisamment clair pour vous permettre de résoudre le problème de configuration, puis réessayez 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 le nom du cluster d'amorçage et l'ID de projet que vous avez spécifié à 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écutez la commande.

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

gcloud beta 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é:

gcloud beta 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 est enregistré automatiquement une fois le cluster créé. 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 Anthos On-Prem s'exécute. Spécifiez us-west1 ou une autre région compatible. Une fois le cluster créé, sa 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 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, le projet et l'emplacement du cluster permettent d'identifier le cluster de manière unique dans Google Cloud.

  • VERSION: version d'Anthos clusters on Bare Metal. La version doit correspondre à la version bmctl que vous avez utilisée pour exécuter bmctl register bootstrap. Vous pouvez vérifier la version bmctl en exécutant bmctl version sur le poste de travail administrateur.

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

    Le nombre maximal de pods par nœud (appelé "densité de pods") est également limité par les ressources IP disponibles de votre cluster. Pour 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 du plan de contrôle. En règle générale, vous disposez d'une seule machine si vous utilisez un déploiement minimal ou de trois machines si vous utilisez un déploiement à haute disponibilité. Spécifiez un nombre de nœuds impair afin de disposer d'un quorum majoritaire pour la haute disponibilité. Vous pouvez modifier ces adresses chaque fois que vous mettez à jour ou mettez à niveau le cluster.

    La valeur de l'indicateur est au 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;...' \

    Cette 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'option pour chaque nœud.

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

    Notez les règles de syntaxe suivantes:

    • Entourez toute la valeur de guillemets simples.
    • Les espaces blancs ne sont pas autorisés.
    • Séparez chaque paire clé-valeur dans le 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'adresses IP pour les Internet privés, définie dans la RFC 1918, par exemple 172.26.232.0/24.

  • 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'adresses IP pour les Internet privés, définie dans la RFC 1918, par exemple 192.168.0.0/16.

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

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

  • --lvp-share-storage-class: ressource 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écouverts. Un PersistentVolume local (PV) 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 gcloud CLI.

La sortie de la commande ressemble à ceci :

Waiting for operation [projects/example-project-12345/locations/us-west1/operations/operation-1679543737105-5f7893fd5bae9-942b3f97-75e59179] to complete.

Dans l'exemple de résultat, la chaîne operation-1679543737105-5f7893fd5bae9-942b3f97-75e59179 est le OPERATION_ID de l'opération de longue durée. Vous pouvez connaître l'état de l'opération à l'aide de la commande suivante:

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

Pour en savoir plus, consultez la page sur gcloud beta container bare-metal Operations.

Corriger les erreurs de requête préliminaire

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.alpha.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 échoue, car le nœud du plan de contrôle est inaccessible. Sur le poste de travail administrateur, vous devriez obtenir 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, exécutez à nouveau la commande avec les mêmes arguments et ajoutez l'indicateur --reuse-bootstrap-cluster=true.

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

    gcloud beta 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 gcloud beta 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, vous devriez voir ce qui suit:

[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 est basé 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 Connect comme suit:

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

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

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

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

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

    • Accorde à votre compte utilisateur le rôle clusterrole/view Kubernetes sur le cluster.
    • Configure le cluster 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 plus 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 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 maintenant exécuter des commandes kubectl via la passerelle Connect:

    kubectl get pods -A

Étapes suivantes