Créer un cluster d'utilisateur à l'aide de clients API Anthos On-Prem

Cette page explique comment créer un cluster d'utilisateur à l'aide de la console Google Cloud, de Google Cloud CLI (gcloud CLI) ou de Terraform.

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 de Google Cloud. Terraform, la console et la gcloud CLI sont les clients de l'API. Ils utilisent l'API 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 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 créer un cluster d'utilisateur en créant un fichier de configuration de cluster d'utilisateur et en utilisant bmctl, comme décrit dans la section Créer un cluster d'utilisateur.

Si vous souhaitez utiliser Terraform, 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 un cluster d'utilisateur qui sera géré par l'API Anthos On-Prem.

Avant de commencer

Cette section décrit les exigences pour créer un cluster d'utilisateur à l'aide de clients API Anthos On-Prem.

Accorder des autorisations IAM

Si vous n'êtes pas propriétaire du projet, vous devez disposer du rôle roles/gkeonprem.admin.

Si vous souhaitez accéder aux pages GKE Enterprise et Google Kubernetes Engine dans la console, vous devez également disposer des rôles suivants:

Une fois le cluster créé, si vous n'êtes pas propriétaire du projet et que vous souhaitez utiliser la passerelle Connect pour vous connecter au cluster d'utilisateur via la ligne de commande, les rôles suivants sont requis :

  • roles/gkehub.gatewayAdmin : ce rôle vous permet d'accéder à l'API de passerelle Connect. Si vous n'avez besoin que d'un accès en lecture seule au cluster, l'autorisation roles/gkehub.gatewayReader est suffisante.

  • roles/gkehub.viewer: ce rôle vous permet de récupérer les identifiants du cluster.

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.

API Google requises

Assurez-vous que toutes les API Google requises sont bien activées dans le projet hôte.

Si vous utilisez la gcloud CLI pour créer le cluster, vous devez activer l'API Anthos On-Prem. Si vous utilisez la console pour créer le cluster, l'API Anthos On-Prem est automatiquement activée.

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

Conditions préalables pour le cluster d'administrateur

Vous devez disposer d'un cluster d'administrateur fonctionnel avant de pouvoir créer un cluster d'utilisateur. Le cluster d'administrateur doit:

  • avoir accès au serveur d'API Kubernetes sur le cluster d'utilisateur après sa création ;

  • disposer d'une connectivité réseau à tous les nœuds du cluster d'utilisateur après sa création ;

  • Doit être enregistré auprès d'un parc. L'ID de projet configuré dans le champ gkeConnect.projectID de ce cluster d'administrateur, appelé projet hôte du parc, doit être le même projet que celui dans lequel vous allez créer le cluster d'utilisateur.

Prérequis pour la machine du nœud de cluster

Passez en revue les conditions préalables pour les machines de nœud de cluster pour vous assurer que les machines qui exécuteront le cluster d'utilisateur répondent aux conditions préalables.

Accès à la ligne de commande

Une fois le cluster créé, si vous souhaitez utiliser la passerelle Connect pour exécuter kubectl sur le cluster d'utilisateur 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.

Créer un cluster d'utilisateur

Vous pouvez utiliser Terraform, la console Google Cloud ou la Google Cloud CLI (gcloud CLI) pour créer un cluster géré par l'API Anthos On-Prem. Si vous installez GKE sur une solution Bare Metal pour la première fois, la console est peut-être l'outil le plus simple à utiliser.

Une fois que vous maîtrisez les informations à fournir pour créer des clusters, vous pouvez utiliser Terraform ou la gcloud CLI, en particulier si vous prévoyez de créer plusieurs clusters. Terraform est un outil standard d'infrastructure en tant que code. Si votre organisation utilise déjà Terraform, vous souhaiterez probablement l'utiliser pour créer des clusters et gérer leur cycle de vie.

Avec la gcloud CLI, vous pouvez enregistrer la commande avec ses arguments dans un fichier texte et apporter les modifications nécessaires pour créer des clusters supplémentaires. 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 un pool de nœuds, et spécifier l'option --impersonate-service-account pour automatiser la création.

Console

La plupart des paramètres de la console correspondent aux champs du fichier de configuration du cluster.

  1. Dans la console Google Cloud, accédez à la page des clusters GKE Enterprise.

    Accéder à la page des 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. Il doit s'agir du même projet que celui dans lequel le cluster d'administrateur est enregistré. Une fois le cluster d'utilisateur créé, il est automatiquement enregistré dans le parc du projet sélectionné.

  3. Cliquez sur Create Cluster (Créer le cluster).

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

  5. À côté de Bare Metal, cliquez sur Configure.

  6. Passez en revue les prérequis et l'exemple d'architecture. Lorsque vous êtes prêt, cliquez sur Suivant pour commencer à configurer le cluster.

Les sections suivantes vous guident dans la configuration du cluster d'utilisateur.

Paramètres de base du cluster

Saisissez les informations de base sur le cluster.

  1. Saisissez un nom pour le cluster d'utilisateur.

  2. Sous Cluster d'administrateur, sélectionnez le cluster d'administrateur dans la liste.

  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 d'utilisateur 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 de manière unique le cluster dans Google Cloud.

  4. Sélectionnez la version de GKE sur Bare Metal pour votre cluster d'utilisateur. Les clusters d'utilisateur doivent être de la même version mineure que le cluster d'administrateur ou d'une version mineure inférieure à celle du cluster d'administrateur.

  5. En tant que créateur du cluster, vous disposez de droits d'administrateur sur celui-ci. Vous pouvez également saisir l'adresse e-mail d'un autre utilisateur qui gérera le cluster dans le champ Administrateur.

    Une fois le cluster créé, l'API Anthos On-Prem applique les stratégies de contrôle d'accès basé sur les rôles (RBAC) Kubernetes au cluster afin de vous accorder, à vous et aux autres administrateurs, le rôle Kubernetes.clusterrole/cluster-admin, qui fournit un accès complet à chaque ressource du cluster dans tous les espaces de noms.

  6. Dans la section Configuration des nœuds, spécifiez les éléments suivants:

    • Nombre maximal de pods par nœud: saisissez le nombre maximal de pods pouvant être exécutés sur un seul nœud. Les valeurs autorisées sont comprises entre 32 et 250 inclus. Kubernetes attribue un bloc CIDR (Classless Inter-Domain Routing) à chaque nœud, afin que chaque pod puisse avoir une adresse IP unique. La taille du bloc CIDR correspond au nombre maximal de pods par nœud. Pour en savoir plus sur la définition du nombre maximal de pods par nœud, consultez la section Mise en réseau de pods.

    • Environnement d'exécution de conteneurs: containerd est le seul environnement d'exécution de conteneurs disponible pour votre cluster.

  7. Cliquez sur Suivant pour accéder à la section Mise en réseau.

Mise en réseau

Dans cette section, vous spécifiez les adresses IP des nœuds, des pods et des services de votre cluster. Si vous utilisez l'équilibrage de charge groupé avec MetalLB, vous devez également le configurer.

  1. Dans la section de nœud Plan de contrôle, saisissez l'adresse IPv4 de chaque nœud de plan de contrôle. Les nœuds du plan de contrôle exécutent la charge de travail du système. En règle générale, il s'agit d'une machine unique 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é. Ce champ peut être modifié chaque fois que vous mettez à jour ou mettez à niveau un cluster.

    Cliquez sur + Ajouter une adresse IP si nécessaire pour saisir d'autres adresses IP.

  2. Dans la section Équilibreur de charge, sélectionnez l'équilibreur de charge dans la liste Mode à configurer pour votre cluster. Pour en savoir plus, consultez la page Présentation des équilibreurs de charge.

    Groupé avec MetalLB

    Configurer l'équilibrage de charge avec l'équilibreur de charge MetalLB groupé Avec cette option, GKE sur Bare Metal déploie des équilibreurs de charge de couche 4 qui s'exécutent sur un pool de nœuds de calcul dédié ou sur les mêmes nœuds que le plan de contrôle.

    1. Dans la section Pools de nœuds de l'équilibreur de charge, sélectionnez l'une des options suivantes:

      • Utiliser les nœuds du plan de contrôle: sélectionnez cette option pour exécuter les équilibreurs de charge sur les mêmes nœuds que le plan de contrôle.

      • Créer un pool de nœuds d'équilibreur de charge: choisissez cette option avancée si vous devez exécuter les équilibreurs de charge sur un pool de nœuds de calcul dédié. Tous les nœuds du pool de nœuds de l'équilibreur de charge doivent se trouver dans le même sous-réseau de couche 2 que les adresses IP virtuelles (VIP) de l'équilibreur de charge que vous configurez dans la section Pools d'adresses de l'équilibreur de charge.

        1. Dans le champ Adresse IP 1 du pool de nœuds de l'équilibreur de charge, saisissez une adresse IPv4 pour un nœud de votre pool de nœuds de l'équilibreur de charge.

        2. Cliquez sur + Ajouter une adresse IP si nécessaire pour saisir des adresses IP supplémentaires.

    2. Dans la section Pools d'adresses de l'équilibreur de charge, ajoutez un ou plusieurs pools d'adresses que le contrôleur MetalLB peut choisir et attribuer aux services de type LoadBalancer. L'adresse IP virtuelle d'entrée, que vous spécifiez dans la section Adresses IP virtuelles, doit se trouver dans l'un de ces pools.

      1. Saisissez un nom pour le pool d'adresses.

      2. Saisissez une plage d'adresses IP au format CIDR (par exemple : 192.0.2.0/26) ou au format 192.0.2.64-192.0.2.72. Pour spécifier une adresse IP unique dans un pool, utilisez /32 au format CIDR (par exemple : 192.0.2.1/32).

      3. Si l'adresse IP virtuelle d'entrée ne se trouve pas dans la plage d'adresses, sélectionnez + Ajouter une plage d'adresses IP et saisissez une autre plage d'adresses incluant l'adresse IP virtuelle d'entrée.

        Les adresses IP de chaque pool ne peuvent pas se chevaucher et doivent se trouver dans le même sous-réseau que les nœuds du cluster.

      4. Sous Attribution des adresses IP, sélectionnez l'une des options suivantes:

        • Automatic (Automatique) : sélectionnez cette option si vous souhaitez que le contrôleur MetalLB attribue automatiquement des adresses IP du pool d'adresses aux services de type LoadBalancer.
        • Manuel: sélectionnez cette option si vous avez l'intention d'utiliser des adresses du pool pour spécifier manuellement les adresses des services de type LoadBalancer.

      5. Cliquez sur Éviter les adresses IP présentant des bugs si vous souhaitez que le contrôleur MetalLB n'utilise pas les adresses du pool qui se terminent par .0 ou .255. Cela évite le problème des bugs avec les appareils grand public qui suppriment par erreur le trafic envoyé à ces adresses IP spéciales.

      6. Lorsque vous avez fini, cliquez sur Terminé.

      7. Si nécessaire, cliquez sur Ajouter un pool d'adresses.

    Équilibreur de charge manuel

    L'équilibrage de charge manuel vous permet de configurer vos propres solutions d'équilibrage de charge pour le trafic des plans de contrôle et des plans de données. Vous devez configurer l'adresse IP virtuelle du plan de contrôle sur l'équilibreur de charge externe avant de créer un cluster. L'équilibreur de charge externe du plan de contrôle peut également être utilisé pour le trafic du plan de données, ou vous pouvez configurer un équilibreur de charge distinct pour le plan de données. Pour en savoir plus, consultez la page Configurer l'équilibrage de charge manuel.

  3. Dans la section Adresses IP virtuelles, saisissez les informations suivantes :

    • Adresse IP virtuelle du plan de contrôle: adresse IP de destination à utiliser pour le trafic envoyé au serveur d'API Kubernetes du cluster d'utilisateur. L'adresse IP virtuelle du plan de contrôle doit se trouver dans le même sous-réseau que les nœuds de l'équilibreur de charge et ne doit se trouver dans aucune des plages d'adresses utilisées pour les pools d'adresses de l'équilibreur de charge.

    • Port: port de destination utilisé pour le trafic envoyé au serveur d'API Kubernetes. La valeur par défaut est 443.

    • Adresse IP virtuelle d'entrée : adresse IP à configurer sur l'équilibreur de charge pour le proxy d'entrée. Saisissez une adresse de l'un des pools d'adresses de l'équilibreur de charge.

  4. Dans la section CIDR des services et des pods, spécifiez les plages d'adresses IP du service Kubernetes et des pods au format CIDR. Elles ne doivent pas se chevaucher entre elles, ni avec aucune adresse externe au cluster que vous souhaitez atteindre depuis l'intérieur du cluster. Nous vous recommandons d'utiliser les plages d'adresses IP privées définies par la RFC 1918. La console fournit les plages d'adresses par défaut suivantes, mais vous pouvez les modifier:

    • CIDR des services: 10.96.0.0/20 Si vous n'acceptez pas la valeur par défaut, saisissez une plage CIDR comprise entre /24 et /12, où /12 fournit le plus d'adresses IP.

    • CIDR des pods: 192.168.0.0/16 Si vous n'acceptez pas la valeur par défaut, saisissez une plage CIDR comprise entre /18 et /8, où /8 correspond au plus grand nombre d'adresses IP.

  5. Dans la section des attributs avancés, vous pouvez éventuellement spécifier les éléments suivants:

    • URL du proxy: adresse HTTP de votre serveur proxy. Incluez le numéro de port, même s'il est identique au port par défaut du schéma, par exemple: http://my-proxy.example.local:80.

    • URL: liste d'adresses IP, de plages d'adresses IP, de noms d'hôte et de noms de domaine séparés par une virgule qui ne doivent pas passer par le serveur proxy. Lorsque GKE sur Bare Metal envoie une requête à l'une de ces adresses, ou à l'un de ces hôtes ou domaines, la requête est envoyée directement.

  6. Cliquez sur Suivant.

Stockage

GKE sur Bare Metal fournit des interfaces de stockage de blocs et de fichiers. Elles disposent d'options par défaut, mais vous pouvez personnaliser les configurations. Pour en savoir plus, consultez la section Configurer le stockage local.

  1. Vous pouvez éventuellement configurer les éléments suivants:

    • Installation de nœuds pour approvisionneurs de volumes locaux: spécifie la configuration des PV (objets PersistentVolumes) locaux secondés par des disques installés. Vous devez formater et installer ces disques avant ou après la création du cluster.

    • Partage de l'approvisionneur de volume local: spécifie la configuration des PersistentVolumes locaux secondés par des sous-répertoires dans un système de fichiers partagé. Ces sous-répertoires sont automatiquement créés lors de la création du cluster.

  2. Cliquez sur Suivant.

Fonctionnalités

Pour vous aider à surveiller, dépanner et exploiter votre cluster, les éléments suivants sont activés automatiquement et ne peuvent pas être désactivés:

Créer un pool de nœuds

Votre cluster doit comporter au moins un pool de nœuds de calcul. Un pool de nœuds représente le modèle des groupes de nœuds de calcul créés dans ce cluster.

Dans la console, vous configurez au moins un pool de nœuds (ou acceptez les valeurs par défaut), puis vous créez le cluster. Vous pouvez ajouter des pools de nœuds supplémentaires après la création du cluster. Avec la gcloud CLI, vous devez d'abord créer le cluster, puis y ajouter un ou plusieurs pools de nœuds.

  1. Cliquez sur pool par défaut dans la barre de navigation de gauche.

  2. Dans la section Paramètres par défaut du pool de nœuds, saisissez le nom du pool de nœuds ou acceptez le nom "default-pool".

  3. Dans la section Nœuds de calcul, saisissez les adresses IP des machines sur lesquelles le cluster doit être exécuté.

  4. Dans la section Métadonnées du pool de nœuds (facultatif), si vous souhaitez ajouter des libellés et des rejets Kubernetes, procédez comme suit:

    1. Cliquez sur + Ajouter des libellés Kubernetes. Saisissez la clé et la valeur du libellé. Répétez l'opération autant de fois que nécessaire.
    2. Cliquez sur + Ajouter un rejet. Saisissez la clé, la valeur et l'effet pour le rejet. Répétez l'opération autant de fois que nécessaire.

  5. Cliquez sur Vérifier et terminer pour créer le cluster d'utilisateur. La création du cluster d'utilisateur prend 15 minutes ou plus. La console affiche les 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 et réessayer de créer le cluster.

gcloud CLI

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

gcloud container bare-metal clusters create

Après avoir créé le cluster, vous devez créer au moins un pool de nœuds à l'aide de la commande suivante:

gcloud container bare-metal node-pools create

La plupart des options de création du cluster et du pool de nœuds correspondent aux champs du fichier de configuration du cluster d'utilisateur. Pour commencer, vous pouvez tester la commande complète dans la section Exemples. Pour en savoir plus sur les options, consultez les sections qui suivent les exemples ou consultez la documentation de référence de gcloud CLI.

Avant de commencer

La version de GKE sur bare metal que vous sélectionnez lors de la création d'un cluster d'utilisateur doit être compatible avec votre cluster d'administrateur. De plus, les dernières versions mineures ou correctives ne sont disponibles dans l'API Anthos On-Prem que 7 à 10 jours après la publication. Vous pouvez exécuter une commande gcloud pour obtenir la liste des versions compatibles que vous pouvez installer sur le cluster d'utilisateur.

  1. Veillez à mettre à jour les composants:

    gcloud components update

  2. Obtenez la liste des versions disponibles à installer sur le cluster d'utilisateur:

    gcloud container bare-metal clusters query-version-config \
  --admin-cluster-membership=ADMIN_CLUSTER_NAME \
  --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership-location=global \
  --location=REGION

    Remplacez les éléments suivants :

    • ADMIN_CLUSTER_NAME: nom du cluster d'administrateur.

    • FLEET_HOST_PROJECT_ID: ID du projet dans lequel le cluster d'administrateur est enregistré.

    • REGION: région Google Cloud que vous avez spécifiée lors de l'enregistrement du cluster dans l'API Anthos On-Prem.

Nous vous recommandons d'utiliser la version compatible la plus élevée pour obtenir les derniers correctifs et améliorations.

Examples

Cette section fournit un exemple de commande permettant de créer un cluster à l'aide de l'équilibreur de charge MetalLB et un exemple utilisant un équilibreur de charge manuel. Les informations que vous spécifiez varient en fonction du type d'équilibreur de charge que vous utiliserez. Pour en savoir plus, consultez la page Présentation des équilibreurs de charge.

Les exemples présentés ici créent le cluster sans pool de nœuds. Une fois le cluster en cours d'exécution, vous devez ajouter un pool de nœuds avant de déployer des charges de travail.

MetalLB

Veillez à faire défiler la page si nécessaire pour remplir l'espace réservé ADMIN_CLUSTER_NAME correspondant à l'indicateur --admin-cluster-membership.

gcloud container bare-metal clusters create USER_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership=projects/FLEET_HOST_PROJECT_ID/locations/global/memberships/ADMIN_CLUSTER_NAME \
  --location=REGION \
  --version=VERSION \
  --admin-users=YOUR_EMAIL_ADDRESS \
  --admin-users=ANOTHER_EMAIL_ADDRESS \
  --metal-lb-address-pools='pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \
  --control-plane-node-configs='node-ip=CP_IP_ADDRESS_1,labels=CP_KEY_1.1=CP_VALUE_1.1;CP_KEY_1.2=CP_VALUE_1.2;...' \
  --control-plane-vip=CONTROL_PLANE_VIP \
  --control-plane-load-balancer-port=CONTROL_PLANE_LB_PORT \
  --ingress-vip=INGRESS_VIP \
  --island-mode-service-address-cidr-blocks=SERVICE_CIDR_BLOCK \
  --island-mode-pod-address-cidr-blocks=POD_CIDR_BLOCK \
  --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

Remplacez les éléments suivants :

  • USER_CLUSTER_NAME: nom de votre choix pour votre cluster d'utilisateur. Une fois le cluster créé, son nom ne peut plus être modifié. Ce nom doit :
    • contenir au maximum 40 caractères ;
    • ne contenir que des caractères alphanumériques minuscules ou un trait d'union - ;
    • commencer par un caractère alphabétique ;
    • se terminer par un caractère alphanumérique.
  • FLEET_HOST_PROJECT_ID: ID du projet dans lequel vous souhaitez créer le cluster. Le projet spécifié est également utilisé comme projet hôte du parc. Il doit s'agir du même projet que celui dans lequel le cluster d'administrateur est enregistré. Une fois le cluster d'utilisateur créé, il est automatiquement enregistré dans le parc du projet sélectionné. Le projet hôte du parc ne peut plus être modifié une fois le cluster créé.
  • ADMIN_CLUSTER_NAME: nom du cluster d'administrateur qui gère le cluster d'utilisateur. Le nom du cluster d'administrateur est le dernier segment du nom complet du cluster qui identifie de manière unique le cluster dans Google Cloud : projects/FLEET_HOST_PROJECT_ID/locations/global/memberships/ADMIN_CLUSTER_NAME
  • 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éé, la région ne peut plus être modifiée. Ce paramètre spécifie la région dans laquelle sont stockés les éléments suivants :
    • Métadonnées du cluster d'utilisateur 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 de manière unique le cluster dans Google Cloud.

  • VERSION: version de GKE sur Bare Metal pour votre cluster d'utilisateur.
  • YOUR_EMAIL_ADDRESS et ANOTHER_EMAIL_ADDRESS : si vous n'incluez pas l'option --admin-users, en tant que créateur du cluster, vous disposez par défaut des droits d'administrateur de cluster. Toutefois, si vous incluez --admin-users pour désigner un autre utilisateur en tant qu'administrateur, vous ignorez la valeur par défaut et devez inclure votre adresse e-mail et celle de l'autre administrateur. Par exemple, pour ajouter deux administrateurs: 
        --admin-users=sara@example.com \
    --admin-users=amal@example.com

    Lorsque le cluster est créé, l'API Anthos On-Prem applique au cluster les stratégies de contrôle des accès basées sur les rôles (RBAC) de Kubernetes pour vous accorder, ainsi que les autres administrateurs, le rôle Kubernetes clusterrole/cluster-admin. Celui-ci fournit un accès complet à toutes les ressources du cluster dans tous les espaces de noms.

Pools d'adresses MetalLB

  • --metal-lb-address-pools: spécifiez la configuration des pools d'adresses que l'équilibreur de charge MetalLB doit utiliser. La valeur de l'indicateur est au format suivant:
'pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \

La valeur comporte des segments qui commencent par les mots clés pool, avoid-buggy-ip, manual-assign et addresses. Séparez chaque segment par une virgule.

  • pool: nom de votre choix pour le pool.

  • avoid-buggy-ips: si vous définissez ce paramètre sur True, le contrôleur MetalLB n'attribue pas d'adresses IP se terminant par .0 ou .255 aux services. Cela permet d'éviter que des appareils grand public présentant des bugs aient généré par erreur le trafic envoyé à ces adresses IP spéciales. Si aucune valeur n'est spécifiée, la valeur par défaut est False.

  • manual-assign: si vous ne souhaitez pas que le contrôleur MetalLB attribue automatiquement les adresses IP de ce pool aux services, définissez ce paramètre sur True. Un développeur peut ensuite créer un service de type LoadBalancer et spécifier manuellement l'une des adresses du pool. Si aucune valeur n'est spécifiée, manual-assign est défini sur False.

  • Dans la liste de addresses: chaque adresse doit être une plage au format CIDR ou avec trait d'union. Pour spécifier une seule adresse IP dans un pool (par exemple, pour l'adresse IP virtuelle d'entrée), utilisez /32 au format CIDR (par exemple, 192.0.2.1/32).

Notez les règles de syntaxe suivantes:

  • Entourez la valeur entière de guillemets simples.
  • Les espaces ne sont pas autorisés.
  • Séparez chaque plage d'adresses IP par un point-virgule.

Vous pouvez spécifier plusieurs instances de l'indicateur, comme illustré dans l'exemple suivant:

--metal-lb-address-pools='pool=pool1,avoid-buggy-ips=False,manual-assign=True,addresses=192.0.2.0/26;192.0.2.64-192.0.2.72'
--metal-lb-address-pools='pool=pool2,avoid-buggy-ips=True,manual-assign=True,addresses=10.251.133.0/24;10.251.134.80/32'

Nœuds MetalLB

  • Facultatif : --metal-lb-load-balancer-node-configs. Par défaut, l'équilibreur de charge s'exécute sur les mêmes nœuds que le plan de contrôle. Si vous devez exécuter l'équilibreur de charge sur un pool de nœuds de calcul dédié, spécifiez cette option pour chaque nœud. Tous les nœuds du pool de nœuds de l'équilibreur de charge doivent se trouver dans le même sous-réseau de couche 2 que les adresses IP virtuelles (VIP) de l'équilibreur de charge.

    La valeur de l'indicateur est au format suivant:

    'node-ip=LB_IP_ADDRESS_1,labels=LB_KEY_1.1=LB_VALUE_1.1;LB_KEY_1.2=LB_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 votre pool de nœuds de l'équilibreur de charge. 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 ne sont pas autorisés.
    • Séparez chaque paire clé=valeur du segment labels par un point-virgule.

    Si vous spécifiez --metal-lb-load-balancer-node-configs, vous pouvez inclure les indicateurs suivants (facultatif) :

    • --metal-lb-load-balancer-node-labels: utilisez cette option pour ajouter des libellés à tous les nœuds du pool de nœuds de l'équilibreur de charge. Séparez la liste des paires clé=valeur par une virgule.

      --metal-lb-load-balancer-node-labels=KEY_1=VALUE_1,KEY_2=VALUE_2

    • --metal-lb-load-balancer-node-taints: utilisez cette option pour ajouter des rejets à tous les nœuds du pool de nœuds de l'équilibreur de charge. Chaque rejet est une paire clé=valeur associée à un effet, qui doit être l'un des éléments suivants: PreferNoSchedule, NoSchedule ou NoExecute.

      --metal-lb-load-balancer-node-taints=KEY_1=VALUE_1:EFFECT_1,KEY_2=VALUE_2:EFFECT_2

    L'exemple suivant ajoute trois nœuds au pool de nœuds de l'équilibreur de charge. Tous les nœuds sont étiquetés avec lb-pool-key=lb-pool-value et ont le rejet dedicated=experimental:PreferNoSchedule.

    --metal-lb-load-balancer-node-configs='node-ip=192.0.2.1' \
--metal-lb-load-balancer-node-configs='node-ip=192.0.2.2,labels=key2.1=value2.1' \
--metal-lb-load-balancer-node-configs='node-ip=192.0.2.3,labels=key3.1=value3.1;key3.2=value3.2' \
--metal-lb-load-balancer-node-labels=lb-pool-key=lb-pool-value \
--metal-lb-load-balancer-node-taints=dedicated=experimental:PreferNoSchedule \

Nœuds du plan de contrôle

  • --control-plane-node-configs : 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 fois que vous mettez à jour ou mettez à niveau un 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;...' \

    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 ne sont pas autorisés.
    • Séparez chaque paire clé-valeur du segment labels par un point-virgule.

    Vous pouvez également inclure les indicateurs suivants:

  • --control-plane-node-labels: utilisez cette option pour ajouter des étiquettes à tous les nœuds du plan de contrôle. Séparez la liste des paires clé=valeur par une virgule. 
      --control-plane-node-labels=KEY_1=VALUE_1,KEY_2=VALUE_2
  • --control-plane-node-taints: utilisez cette option pour ajouter des rejets à tous les nœuds du plan de contrôle. Chaque rejet est une paire clé=valeur associée à un effet, qui doit être l'un des éléments suivants: PreferNoSchedule, NoSchedule ou NoExecute.

    L'exemple suivant ajoute trois nœuds aux nœuds du plan de contrôle. Tous les nœuds sont étiquetés cp-node-pool-key=cp-node-pool-value et ont le rejet dedicated=experimental:PreferNoSchedule.

      --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-planer-node-configs='node-ip=192.0.2.3,labels=key3.1=value3.1;key3.2=value3.2' \
  --control-plane-node-labels=cp-node-pool-key=cp-node-pool-value \
  --control-plane-node-taints=dedicated=experimental:PreferNoSchedule \

Adresses IP virtuelles

  • CONTROL_PLANE_VIP: adresse IP que vous avez choisi de configurer sur l'équilibreur de charge pour le serveur d'API Kubernetes du cluster d'utilisateur.

    Exemple : --control-plane-vip=203.0.113.3

  • CONTROL_PLANE_LB_PORT: port sur lequel l'équilibreur de charge diffuse le serveur d'API Kubernetes.

    Exemple : -control-plane-load-balancer-port=443

  • INGRESS_VIP: adresse IP que vous avez choisi de configurer sur l'équilibreur de charge pour le proxy d'entrée.

    Exemple : --ingress-vip=10.251.134.80

    L'adresse IP de l'adresse IP virtuelle d'entrée doit se trouver dans l'un des pools d'adresses MetalLB.

CIDR des services et des pods

  • SERVICE_CIDR_BLOCK: plage d'adresses IP, au format CIDR, à utiliser 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.

    Exemple : --island-mode-service-address-cidr-blocks=10.96.0.0/20

  • POD_CIDR_BLOCK: plage d'adresses IP, au format CIDR, à utiliser pour les pods de votre cluster. La plage CIDR doit être comprise entre /18 et /8, où /8 correspond au plus grand nombre d'adresses IP.

    Exemple : --island-mode-pod-address-cidr-blocks=192.168.0.0/16

Stockage

  1. --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.
  2. --lvp-share-storage-class: il s'agit de la StorageClass à utiliser pour créer des volumes persistants. La StorageClass est créée lors de la création du cluster.
  3. --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.
  4. --lvp-node-mounts-config-storage: classe de stockage avec laquelle les PV sont créés lors de la création du cluster.

Pour en savoir plus sur le stockage, consultez la page Configurer le stockage local.

Mode manuel

L'équilibrage de charge manuel vous permet de configurer vos propres solutions d'équilibrage de charge pour le trafic des plans de contrôle et des plans de données. Vous devez configurer l'adresse IP virtuelle du plan de contrôle sur l'équilibreur de charge externe avant de créer un cluster. L'équilibreur de charge externe du plan de contrôle peut également être utilisé pour le trafic du plan de données, ou vous pouvez configurer un équilibreur de charge distinct pour le plan de données. Pour en savoir plus, consultez la page Configurer l'équilibrage de charge manuel.

Veillez à faire défiler la page si nécessaire pour remplir l'espace réservé ADMIN_CLUSTER_NAME correspondant à l'indicateur --admin-cluster-membership.

gcloud container bare-metal clusters create USER_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership=projects/FLEET_HOST_PROJECT_ID/locations/global/memberships/ADMIN_CLUSTER_NAME \
  --location=REGION \
  --version=VERSION \
  --admin-users=YOUR_EMAIL_ADDRESS \
  --admin-users=ANOTHER_EMAIL_ADDRESS \
  --enable-manual-lb \
  --control-plane-node-configs='node-ip=CP_IP_ADDRESS_1,labels=CP_KEY_1.1=CP_VALUE_1.1;CP_KEY_1.2=CP_VALUE_1.2;...' \
  --control-plane-vip=CONTROL_PLANE_VIP \
  --control-plane-load-balancer-port=CONTROL_PLANE_LB_PORT \
  --ingress-vip=INGRESS_VIP \
  --island-mode-service-address-cidr-blocks=SERVICE_CIDR_BLOCK \
  --island-mode-pod-address-cidr-blocks=POD_CIDR_BLOCK \
  --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

Remplacez les éléments suivants :

  • USER_CLUSTER_NAME: nom de votre choix pour votre cluster d'utilisateur. Une fois le cluster créé, son nom ne peut plus être modifié. Ce nom doit :
    • contenir au maximum 40 caractères ;
    • ne contenir que des caractères alphanumériques minuscules ou un trait d'union - ;
    • commencer par un caractère alphabétique ;
    • se terminer par un caractère alphanumérique.
  • FLEET_HOST_PROJECT_ID: ID du projet dans lequel vous souhaitez créer le cluster. Le projet spécifié est également utilisé comme projet hôte du parc. Il doit s'agir du même projet que celui dans lequel le cluster d'administrateur est enregistré. Une fois le cluster d'utilisateur créé, il est automatiquement enregistré dans le parc du projet sélectionné. Le projet hôte du parc ne peut plus être modifié une fois le cluster créé.
  • ADMIN_CLUSTER_NAME: nom du cluster d'administrateur qui gère le cluster d'utilisateur. Le nom du cluster d'administrateur est le dernier segment du nom complet du cluster qui identifie de manière unique le cluster dans Google Cloud : projects/FLEET_HOST_PROJECT_ID/locations/global/memberships/ADMIN_CLUSTER_NAME
  • 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éé, la région ne peut plus être modifiée. Ce paramètre spécifie la région dans laquelle sont stockés les éléments suivants :
    • Métadonnées du cluster d'utilisateur 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 de manière unique le cluster dans Google Cloud.

  • VERSION: version de GKE sur Bare Metal pour votre cluster d'utilisateur.
  • YOUR_EMAIL_ADDRESS et ANOTHER_EMAIL_ADDRESS : si vous n'incluez pas l'option --admin-users, en tant que créateur du cluster, vous disposez par défaut des droits d'administrateur de cluster. Toutefois, si vous incluez --admin-users pour désigner un autre utilisateur en tant qu'administrateur, vous ignorez la valeur par défaut et devez inclure votre adresse e-mail et celle de l'autre administrateur. Par exemple, pour ajouter deux administrateurs: 
        --admin-users=sara@example.com \
    --admin-users=amal@example.com

    Lorsque le cluster est créé, l'API Anthos On-Prem applique au cluster les stratégies de contrôle des accès basées sur les rôles (RBAC) de Kubernetes pour vous accorder, ainsi que les autres administrateurs, le rôle Kubernetes clusterrole/cluster-admin. Celui-ci fournit un accès complet à toutes les ressources du cluster dans tous les espaces de noms.

Nœuds du plan de contrôle

  • --control-plane-node-configs : 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 fois que vous mettez à jour ou mettez à niveau un 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;...' \

    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 ne sont pas autorisés.
    • Séparez chaque paire clé-valeur du segment labels par un point-virgule.

    Vous pouvez également inclure les indicateurs suivants:

  • --control-plane-node-labels: utilisez cette option pour ajouter des étiquettes à tous les nœuds du plan de contrôle. Séparez la liste des paires clé=valeur par une virgule. 
      --control-plane-node-labels=KEY_1=VALUE_1,KEY_2=VALUE_2
  • --control-plane-node-taints: utilisez cette option pour ajouter des rejets à tous les nœuds du plan de contrôle. Chaque rejet est une paire clé=valeur associée à un effet, qui doit être l'un des éléments suivants: PreferNoSchedule, NoSchedule ou NoExecute.

    L'exemple suivant ajoute trois nœuds aux nœuds du plan de contrôle. Tous les nœuds sont étiquetés cp-node-pool-key=cp-node-pool-value et ont le rejet dedicated=experimental:PreferNoSchedule.

      --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-planer-node-configs='node-ip=192.0.2.3,labels=key3.1=value3.1;key3.2=value3.2' \
  --control-plane-node-labels=cp-node-pool-key=cp-node-pool-value \
  --control-plane-node-taints=dedicated=experimental:PreferNoSchedule \

Adresses IP virtuelles

  • CONTROL_PLANE_VIP: adresse IP que vous avez choisi de configurer sur l'équilibreur de charge pour le serveur d'API Kubernetes du cluster d'utilisateur.

    Exemple : --control-plane-vip=203.0.113.3

  • CONTROL_PLANE_LB_PORT: port sur lequel l'équilibreur de charge diffuse le serveur d'API Kubernetes.

    Exemple : -control-plane-load-balancer-port=443

  • INGRESS_VIP: adresse IP que vous avez choisi de configurer sur l'équilibreur de charge pour le proxy d'entrée.

    Exemple : --ingress-vip=10.251.134.80

    L'adresse IP de l'adresse IP virtuelle d'entrée doit se trouver dans l'un des pools d'adresses MetalLB.

CIDR des services et des pods

  • SERVICE_CIDR_BLOCK: plage d'adresses IP, au format CIDR, à utiliser 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.

    Exemple : --island-mode-service-address-cidr-blocks=10.96.0.0/20

  • POD_CIDR_BLOCK: plage d'adresses IP, au format CIDR, à utiliser pour les pods de votre cluster. La plage CIDR doit être comprise entre /18 et /8, où /8 correspond au plus grand nombre d'adresses IP.

    Exemple : --island-mode-pod-address-cidr-blocks=192.168.0.0/16

Stockage

  1. --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.
  2. --lvp-share-storage-class: il s'agit de la StorageClass à utiliser pour créer des volumes persistants. La StorageClass est créée lors de la création du cluster.
  3. --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.
  4. --lvp-node-mounts-config-storage: classe de stockage avec laquelle les PV sont créés lors de la création du cluster.

Pour en savoir plus sur le stockage, consultez la page Configurer le stockage local.

Avant d'exécuter la commande gcloud pour créer le cluster, vous pouvez inclure --validate-only pour valider la configuration que vous avez spécifiée dans les options de la commande gcloud. Lorsque vous êtes prêt à créer le cluster, supprimez cet indicateur et exécutez la commande.

La création du cluster d'utilisateur prend 15 minutes ou plus. Vous pouvez afficher le cluster dans la console Google Cloud, sur la page Clusters Anthos.

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

Créer un pool de nœuds

Une fois le cluster créé, vous devez créer au moins un pool de nœuds avant de déployer des charges de travail. Un pool de nœuds représente le modèle des groupes de nœuds de calcul créés dans ce cluster. Avec la gcloud CLI, vous devez d'abord créer le cluster, puis y ajouter un ou plusieurs pools de nœuds.

gcloud container bare-metal node-pools create NODE_POOL_NAME \
  --cluster=USER_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --location=REGION \
  --node-configs='node-ip=NP_IP_ADDRESS_1,labels=NP_KEY_1.1=NP_VALUE_1.1;NP_KEY_1.2=NP_VALUE_1.2;...'

Remplacez les éléments suivants :

  • NODE_POOL_NAME: nom de votre choix pour le pool de nœuds. Ce nom doit :

    • contenir au maximum 40 caractères ;
    • ne contenir que des caractères alphanumériques minuscules ou un trait d'union - ;
    • commencer par un caractère alphabétique ;
    • se terminer par un caractère alphanumérique.

  • USER_CLUSTER_NAME: nom du cluster d'utilisateur que vous venez de créer.

  • FLEET_HOST_PROJECT_ID: ID du projet dans lequel le cluster est enregistré.

  • REGION: région Google Cloud que vous avez spécifiée lors de la création du cluster.

  • --node-configs : adresse IPv4 d'une machine de nœud de calcul. Spécifiez cette option pour chaque nœud. La valeur de l'indicateur est au format suivant:

    'node-ip=NP_IP_ADDRESS_1,labels=NP_KEY_1.1=NP_VALUE_1.1;NP_KEY_1.2=NP_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 calcul. Vous ne pouvez spécifier qu'un seul élément node-ip par indicateur. Ajoutez à nouveau cette option pour chaque nœud du pool de nœuds.

    • 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 ne sont pas autorisés.
    • Séparez chaque paire clé=valeur du segment labels par un point-virgule.

    Vous pouvez également spécifier les éléments suivants :

    • --node-labels=KEY=VALUE,...: liste d'étiquettes Kubernetes séparées par une virgule (paires clé=valeur) appliquées à chaque nœud du pool.

    • --node-taints=KEY=VALUE:EFFECT,...Liste de rejets Kubernetes séparés par une virgule et appliqué à chaque nœud du pool. Les rejets sont des paires clé/valeur associées à un effet. Les rejets sont utilisés avec des tolérances pour la planification des pods. Spécifiez l'une des options suivantes pour EFFECT: NoSchedule, PreferNoSchedule, NoExecute.

L'exemple suivant crée un pool de nœuds nommé default-pool sur user-cluster- et ajoute deux nœuds au pool. Tous les deux nœuds sont étiquetés avec node-pool-key=node-pool-value et ont le rejet dedicated=experimental:PreferNoSchedule.

gcloud container bare-metal node-pools create default-pool \
  --cluster=user-cluster-1  \
  --project=example-project-12345 \
  --location=us-west1 \
  --node-configs='node-ip=10.200.0.10' \
  --node-configs='node-ip=10.200.0.11,labels=key2.1=value2.1' \
  --node-labels=node-pool-key=node-pool-value \
  --node-taints=dedicated=experimental:PreferNoSchedule

Pour en savoir plus, consultez la documentation de référence de gcloud CLI.

Terraform

Avant de commencer

La version de GKE sur bare metal que vous sélectionnez lors de la création d'un cluster d'utilisateur doit être compatible avec votre cluster d'administrateur. De plus, les dernières versions mineures ou correctives ne sont disponibles dans l'API Anthos On-Prem que 7 à 10 jours après la publication. Vous pouvez exécuter une commande gcloud pour obtenir la liste des versions compatibles que vous pouvez installer sur le cluster d'utilisateur.

  1. Veillez à mettre à jour les composants:

    gcloud components update

  2. Obtenez la liste des versions disponibles à installer sur le cluster d'utilisateur:

    gcloud container bare-metal clusters query-version-config \
  --admin-cluster-membership=ADMIN_CLUSTER_NAME \
  --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership-location=global \
  --location=REGION

    Remplacez les éléments suivants :

    • ADMIN_CLUSTER_NAME: nom du cluster d'administrateur.

    • FLEET_HOST_PROJECT_ID: ID du projet dans lequel le cluster d'administrateur est enregistré.

    • REGION: région Google Cloud que vous avez spécifiée lors de l'enregistrement du cluster dans l'API Anthos On-Prem.

Nous vous recommandons d'utiliser la version compatible la plus élevée pour obtenir les derniers correctifs et améliorations.

Exemple

Vous pouvez utiliser l'exemple de configuration de base suivant pour créer un cluster d'utilisateur avec un équilibreur de charge MetalLB groupé. Pour en savoir plus, consultez la documentation de référence sur google_gkeonprem_bare_metal_cluster.

  1. Clonez le dépôt anthos-samples et accédez au répertoire où se trouve l'exemple Terraform:

    git clone https://github.com/GoogleCloudPlatform/anthos-samples
cd anthos-samples/anthos-onprem-terraform/abm_user_cluster_metallb

    L'exemple fournit un exemple de fichier de variables à transmettre à main.tf.

  2. Créez une copie du fichier terraform.tfvars.sample:

    cp terraform.tfvars.sample terraform.tfvars
    anthos-onprem-terraform/abm_user_cluster_metallb/terraform.tfvars.sample 
    
project_id          = "PROJECT_ID"
region              = "ON_PREM_API_REGION"
admin_cluster_name  = "ADMIN_CLUSTER_NAME"
bare_metal_version  = "VERSION"
admin_user_emails   = ["YOUR_EMAIL_ADDRESS", "ADMIN_2_EMAIL_ADDRESS"]
cluster_name        = "abm-user-cluster-metallb"
control_plane_ips   = ["10.200.0.4"]
worker_node_ips     = ["10.200.0.5", "10.200.0.6"]
control_plane_vip   = "10.200.0.50"
ingress_vip         = "10.200.0.51"
lb_address_pools    = [
    { name = "lbpool_1", addresses = ["10.200.0.51-10.200.0.70"] }
]

  3. Modifiez les valeurs de paramètre dans terraform.tfvars, puis enregistrez le fichier.

    La liste suivante décrit les variables:

    • project_id: ID du projet dans lequel vous souhaitez créer le cluster. Le projet spécifié est également utilisé comme projet hôte du parc. Il doit s'agir du même projet que celui dans lequel le cluster d'administrateur est enregistré. Une fois le cluster d'utilisateur créé, il est automatiquement enregistré dans le parc du projet sélectionné. 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.

    • admin_cluster_name: nom du cluster d'administrateur qui gère le cluster d'utilisateur.

    • bare_metal_version: version de GKE sur bare metal pour votre cluster d'utilisateur. Spécifiez la même version que le cluster d'administrateur, ou une version mineure inférieure à celle du cluster d'administrateur.

    • cluster_name: nom de votre choix pour votre cluster d'utilisateur. Une fois le cluster créé, son nom ne peut plus être modifié. Ce nom doit :

      • contenir au maximum 40 caractères ;
      • ne contenir que des caractères alphanumériques minuscules ou un trait d'union - ;
      • commencer par un caractère alphabétique ;
      • se terminer par un caractère alphanumérique.

    • control_plane_ips: liste d'une ou de plusieurs adresses IPv4 pour les nœuds du plan de contrôle. Les nœuds du plan de contrôle exécutent la charge de travail du système. 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 un cluster.

    • worker_node_ips: liste d'une ou de plusieurs adresses IPv4 pour les machines de nœuds de calcul.

    • control_plane_vip: adresse IP virtuelle que vous avez choisi de configurer sur l'équilibreur de charge pour le serveur d'API Kubernetes du cluster d'utilisateur.

    • ingress_vip: adresse IP que vous avez choisi de configurer sur l'équilibreur de charge pour le proxy d'entrée.

    • lb_address_pools: liste de mappages qui définissent les pools d'adresses que l'équilibreur de charge MetalLB doit utiliser L'adresse IP virtuelle d'entrée doit se trouver dans l'un de ces pools.

    • admin_user_emails: liste des adresses e-mail des utilisateurs disposant de droits d'administrateur sur le cluster. Veillez à ajouter votre adresse e-mail si vous avez l'intention d'administrer le cluster.

    Une fois le cluster créé, l'API Anthos On-Prem applique les stratégies de contrôle des accès basé sur les rôles (RBAC) de Kubernetes pour accorder aux administrateurs le rôle clusterrole/cluster-admin Kubernetes. Celui-ci fournit un accès complet à toutes les ressources du cluster dans tous les espaces de noms. Cela permet également aux utilisateurs de se connecter à la console à l'aide de leur identité Google.

  4. Enregistrez les modifications dans terraform.tfvars.

  5. Initialisez et créez le plan Terraform :

    terraform init

    Terraform installe toutes les bibliothèques nécessaires, comme le fournisseur Google Cloud.

  6. Vérifiez la configuration et apportez des modifications si nécessaire:

    terraform plan

  7. Appliquez le plan Terraform pour créer le cluster d'utilisateur:

    terraform apply

    La création du cluster d'utilisateur prend 15 minutes ou plus. Vous pouvez afficher le cluster dans la console Google Cloud, sur la page Clusters Anthos.

Se connecter au cluster d'utilisateur

Lorsque vous créez un cluster d'utilisateur dans la console, celui-ci est configuré avec les stratégies de contrôle des accès basé sur les rôles (RBAC) de Kubernetes afin que vous puissiez vous y connecter à l'aide de votre identité Google Cloud. Lorsque vous créez un cluster d'utilisateur avec la gcloud CLI, ces stratégies RBAC vous sont attribuées par défaut si vous n'incluez pas l'option --admin-users. Si vous incluez --admin-users pour désigner un autre utilisateur en tant qu'administrateur, vous ignorez la valeur par défaut et devez inclure à la fois votre adresse e-mail et celle de l'autre administrateur. Pour en savoir plus sur les stratégies IAM et RBAC requises, consultez la page Configurer l'authentification de l'identité Google.

Tous les clusters possèdent un point de terminaison canonique. Le point de terminaison expose le serveur d'API Kubernetes utilisé par kubectl et d'autres services pour communiquer avec votre plan de contrôle de cluster via le port TCP 443. Ce point de terminaison n'est pas accessible depuis l'Internet public. Si vous avez accès au point de terminaison privé de votre cluster via votre VPC, vous pouvez vous y connecter directement et générer un fichier kubeconfig directement. Sinon, vous pouvez utiliser la passerelle de connexion.

Pour accéder au cluster d'utilisateur à partir de la ligne de commande, vous avez besoin d'un fichier kubeconfig. Il existe deux façons d'obtenir un fichier kubeconfig:

  • Utiliser la passerelle Connect pour accéder au cluster à partir d'un ordinateur sur lequel Google Cloud CLI est installé. Dans ce cas, kubectl utilise le kubeconfig de la passerelle Connect, qui transfère de manière sécurisée le trafic vers le point de terminaison privé en votre nom.

  • Pour un accès direct aux points de terminaison privés, créez un fichier kubeconfig sur votre poste de travail administrateur et gérez le cluster depuis celui-ci.

Assurez-vous d'attendre que Google Cloud Console indique que le cluster d'utilisateur est opérationnel.

Passerelle Connect

  1. initialize gcloud CLI pour l'utiliser avec le projet hôte du parc, ou exécutez les commandes suivantes pour vous connecter avec votre compte Google, définissez le projet hôte du parc en tant que projet par défaut et mettez à jour les composants :

    gcloud auth login
gcloud config set project PROJECT_ID
gcloud components update

  2. Récupérez les identifiants du cluster utilisés pour interagir avec la passerelle Connect. Dans la commande suivante, remplacez MEMBERSHIP_NAME par le nom de votre cluster. Dans GKE sur Bare Metal, le nom de l'appartenance est identique au nom du cluster.

    gcloud container fleet memberships get-credentials MEMBERSHIP_NAME

    Cette commande affiche un élément kubeconfig spécifique à une passerelle Connect qui vous permet de vous connecter au cluster via la passerelle.

Une fois que vous disposez des identifiants nécessaires, vous pouvez exécuter des commandes à l'aide de kubectl comme vous le feriez normalement pour n'importe quel cluster Kubernetes. Vous n'avez pas besoin de spécifier le nom du fichier kubeconfig, par exemple:

kubectl get namespaces

Poste de travail administrateur

Exécutez la commande bmctl get credentials pour récupérer un fichier kubeconfig pour le cluster d'utilisateur que vous venez de créer.

bmctl get credentials --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG_PATH

Remplacez les éléments suivants :

  • CLUSTER_NAME : nom du cluster d'utilisateur cible

  • ADMIN_KUBECONFIG_PATH : chemin d'accès au fichier kubeconfig du cluster d'administrateur

Un objet kubeconfig avec les identifiants du cluster d'utilisateur est écrit dans un fichier bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-TIMESTAMP-kubeconfig. La partie TIMESTAMP du nom du fichier indique la date et l'heure de création du fichier.

Comme ce fichier contient les identifiants d'authentification de votre cluster, vous devez le stocker dans un emplacement sécurisé avec accès limité.

Étapes suivantes