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

Version 1.13 

• Le plus récent
• Version 1.16
• Versions antérieures (non compatibles)

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 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 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 gcloud CLI pour gérer le cycle de vie des clusters créés à l'aide de bmctl, consultez Configurer un cluster d'utilisateur pour qu'il soit géré par l'API Anthos On-Prem.

Avant de commencer

Cette section décrit les conditions requises 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 Anthos et Google Kubernetes Engine dans la console, vous devez également disposer des rôles suivants:

• roles/container.viewer
• roles/gkehub.viewer

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 Connect Gateway. Si vous n'avez besoin que d'un accès en lecture seule au cluster, le roles/gkehub.gatewayReader suffit.

• 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 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, cela active automatiquement l'API Anthos On-Prem.

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

Conditions préalables au 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 ;

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

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

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

Consultez les conditions préalables à la machine du nœud de cluster pour vous assurer que les machines qui vont exécuter le cluster d'utilisateur remplissent les 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.

Remarque :Si vous utilisez Cloud Shell comme environnement shell pour interagir avec Google Cloud, ces outils sont installés pour vous.

• Dernière version de gcloud CLI.
• kubectl pour exécuter des commandes sur les clusters Kubernetes. Si vous devez installer kubectl, suivez ces instructions.

Créer un cluster d'utilisateur

Vous pouvez utiliser Terraform, la console Google Cloud ou Google Cloud CLI (gcloud CLI) pour créer un cluster géré par l'API Anthos On-Prem. Si c'est la première fois que vous installez des clusters Anthos sur bare metal, la console sera probablement l'outil le plus facile à utiliser.

Une fois que vous connaissez mieux les informations à fournir pour créer des clusters, Terraform ou gcloud CLI peuvent vous sembler plus pratiques, en particulier si vous créez plusieurs clusters. Terraform est un outil Infrastructure as Standard de type Infrastructure as Code. Si votre organisation utilise déjà Terraform, il peut être utile de vous en servir pour créer des clusters et gérer leur cycle de vie.

Gcloud CLI vous permet d'enregistrer la commande avec ses arguments dans un fichier texte et d'apporter les modifications nécessaires pour créer des clusters supplémentaires. Si vous utilisez un outil CI/CD, tel que Cloud Build, vous pouvez utiliser 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 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. 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 Configurer.

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

4. Sélectionnez la version des clusters Anthos 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 au cluster d'administrateur.

5. En tant que créateur du cluster, vous disposez des droits d'administrateur pour celui-ci. Saisissez éventuellement l'adresse e-mail d'un autre utilisateur qui administrera 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.

   Remarque : En plus des stratégies RBAC Kubernetes, vous devez attribuer des rôles IAM (Identity and Access Management) aux utilisateurs qui ne sont pas propriétaires de projet. Pour en savoir plus sur l'attribution des rôles IAM, consultez Attribuer les rôles requis.

6. Dans la section Configuration du nœud, 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 plus d'informations sur la définition du nombre maximal de pods par nœud, consultez la page 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 de nœuds impair 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 dans la liste Mode l'équilibreur de charge à configurer pour votre cluster. Pour en savoir plus, consultez la Présentation des équilibreurs de charge.

   Groupé avec MetalLB

   Configurer l'équilibrage de charge avec l'équilibreur de charge MetalLB groupé Avec cette option, les clusters Anthos sur bare metal déploient 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 des nœuds de plan de contrôle: choisissez 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 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 du pool de nœuds de l'équilibreur de charge 1, saisissez une adresse IPv4 pour un nœud du 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 de plage (par exemple, 192.0.2.64-192.0.2.72). Pour spécifier une seule adresse IP dans un pool, utilisez /32 dans la notation 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, puis 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:

         • Automatique: choisissez cette option si vous souhaitez que le contrôleur MetalLB attribue automatiquement les adresses IP du pool d'adresses aux services de type LoadBalancer.
         • Manuel: choisissez cette option si vous avez l'intention d'utiliser des adresses du pool afin de spécifier manuellement des adresses pour les 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

   Avec l'équilibrage de charge manuel, vous configurez vos propres solutions d'équilibrage de charge pour le trafic du plan de contrôle et du plan 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 du plan de contrôle externe peut également être utilisé pour le trafic du plan de données. Vous pouvez également configurer un équilibreur de charge distinct pour le plan de données. Pour en savoir plus, consultez la section 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 figurer 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 des services 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 de service: 10.96.0.0/20 si vous n'acceptez pas la plage CIDR par défaut, saisissez une plage CIDR comprise entre /24 et /12, où /12 correspond au plus grand nombre d'adresses IP.

   • CIDR de pod: 192.168.0.0/16 si vous n'acceptez pas la plage par défaut, saisissez une plage CIDR comprise entre /18 et /8, où /8 fournit le plus d'adresses IP.

5. Dans la section des attributs 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 des adresses IP, des plages d'adresses IP, des noms d'hôte et des noms de domaine séparés par une virgule qui ne doivent pas passer par le serveur proxy. Lorsque des clusters Anthos sur bare metal envoient une requête à l'une de ces adresses, à ces hôtes ou à ces domaines, la requête est envoyée directement.

6. Cliquez sur Suivant.

Stockage

Clusters Anthos 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:

   • Montages de nœuds pour approvisionneurs de volumes locaux: spécifie la configuration du PersistentVolumes local (PV) reposant sur 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 de l'élément PersistentVolumes local reposant sur des sous-répertoires dans un système de fichiers partagé. Ces sous-répertoires sont créés automatiquement lors de la création du cluster.

2. Cliquez sur Suivant.

Caractéristiques

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:

• Cloud Logging pour les services système
• Cloud Monitoring pour les services système
• Journal d'audit pour les activités d'administration

Créer un pool de nœuds

Votre cluster doit comporter au moins un pool de nœuds pour les 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 devez configurer au moins un pool de nœuds (ou accepter les valeurs par défaut), puis créer le cluster. Vous pouvez ajouter des pools de nœuds supplémentaires après avoir créé le cluster. Avec 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 s'exécuter.

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

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

Preview

Cette fonctionnalité est soumise aux "Conditions des offres de pré-DG" dans la section "Conditions d'utilisation générales" des Conditions spécifiques au service. Les fonctionnalités pré-DG sont disponibles "en l'état" et peuvent avoir une assistance limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

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

gcloud beta 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 beta container bare-metal node-pools create

La plupart des indicateurs de création du cluster et du pool de nœuds correspondent aux champs du fichier de configuration du cluster d'utilisateur. Pour vous aider à démarrer, 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

1. Connectez-vous à votre compte Google.

   gcloud auth login
   

2. Veillez à mettre à jour les composants:

   gcloud components update
   

Examples

Cette section fournit un exemple de commande qui crée un cluster à l'aide de l'équilibreur de charge MetalLB et d'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 Présentation des équilibreurs de charge.

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

Si nécessaire, veillez à renseigner l'espace réservé ADMIN_CLUSTER_NAME pour l'indicateur --admin-cluster-membership.

gcloud beta 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é. Le 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 projet 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 pas être modifié après la création du cluster.
• 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éé, 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 :
  • 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 le cluster de manière unique dans Google Cloud.

• VERSION: version d'Anthos Clusters 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, les droits d'administrateur de cluster vous sont attribués par défaut. Toutefois, si vous incluez --admin-users pour désigner un autre utilisateur en tant qu'administrateur, vous ignorez le paramètre par défaut et devez inclure votre adresse e-mail et celle de l'autre administrateur. Par exemple, pour ajouter deux administrateurs:

      --admin-users=[e-mail] \
      --admin-users=[e-mail]

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

  Remarque:En plus des stratégies Kubernetes RBAC, vous devez attribuer des rôles Identity and Access Management (IAM) aux utilisateurs qui ne sont pas propriétaires des projets. Pour en savoir plus sur l'attribution des rôles IAM, consultez Attribuer les rôles requis.

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;...' \

Cette 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 finissant par .0 ou .255 aux services. Cela permet d'éviter que des appareils grand public présentant des bugs suppriment 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 addresses, chaque adresse doit être une plage au format CIDR ou aux plages de traits d'union. Pour spécifier une seule adresse IP dans un pool (par exemple, pour l'adresse IP virtuelle d'entrée), utilisez un bloc /32 au format CIDR (par exemple, 192.0.2.1/32).

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 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 de l'équilibreur de charge.

  Important :Si vous créez votre cluster sans pool de nœuds d'équilibreur de charge dédié, vous ne pourrez pas l'ajouter ultérieurement. Pour les clusters configurés avec au moins un nœud d'équilibreur de charge, vous pouvez le mettre à jour pour ajouter d'autres nœuds au pool.

  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;...' \
  

  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 votre pool de nœuds d'équilibreur de charge. 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.

  Si vous spécifiez --metal-lb-load-balancer-node-configs, vous pouvez éventuellement inclure les options suivantes:

  • --metal-lb-load-balancer-node-labels: utilisez cet indicateur pour ajouter des libellés à tous les nœuds du pool de nœuds de l'équilibreur de charge. Séparez les 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 cet indicateur 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. Cette valeur doit être l'une des suivantes: 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 associés à l'étiquette 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 du plan de contrôle. En règle générale, vous avez une seule machine si vous utilisez un déploiement minimal, ou 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;...' \

  Cette valeur contient 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.

  Vous pouvez également inclure les options suivantes:

• --control-plane-node-labels: utilisez cet indicateur pour ajouter des libellés à tous les nœuds de 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 cet indicateur pour ajouter des rejets à tous les nœuds du plan de contrôle. Chaque rejet est une paire clé-valeur associée à un effet. Cette valeur doit être l'une des suivantes: PreferNoSchedule, NoSchedule ou NoExecute.

  L'exemple suivant ajoute trois nœuds aux nœuds du plan de contrôle. Tous les nœuds sont associés à l'étiquette 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 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.
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écouverts. Un PersistentVolume local (PV) 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 Configurer le stockage local.

Manuel

Avec l'équilibrage de charge manuel, vous configurez vos propres solutions d'équilibrage de charge pour le trafic du plan de contrôle et du plan 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 du plan de contrôle externe peut également être utilisé pour le trafic du plan de données. Vous pouvez également configurer un équilibreur de charge distinct pour le plan de données. Pour en savoir plus, consultez la section Configurer l'équilibrage de charge manuel.

Si nécessaire, veillez à renseigner l'espace réservé ADMIN_CLUSTER_NAME pour l'indicateur --admin-cluster-membership.

gcloud beta 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é. Le 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 projet 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 pas être modifié après la création du cluster.
• 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éé, 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 :
  • 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 le cluster de manière unique dans Google Cloud.

• VERSION: version d'Anthos Clusters 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, les droits d'administrateur de cluster vous sont attribués par défaut. Toutefois, si vous incluez --admin-users pour désigner un autre utilisateur en tant qu'administrateur, vous ignorez le paramètre par défaut et devez inclure votre adresse e-mail et celle de l'autre administrateur. Par exemple, pour ajouter deux administrateurs:

      --admin-users=[e-mail] \
      --admin-users=[e-mail]

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

  Remarque:En plus des stratégies Kubernetes RBAC, vous devez attribuer des rôles Identity and Access Management (IAM) aux utilisateurs qui ne sont pas propriétaires des projets. Pour en savoir plus sur l'attribution des rôles IAM, consultez Attribuer les rôles requis.

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 du plan de contrôle. En règle générale, vous avez une seule machine si vous utilisez un déploiement minimal, ou 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;...' \

  Cette valeur contient 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.

  Vous pouvez également inclure les options suivantes:

• --control-plane-node-labels: utilisez cet indicateur pour ajouter des libellés à tous les nœuds de 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 cet indicateur pour ajouter des rejets à tous les nœuds du plan de contrôle. Chaque rejet est une paire clé-valeur associée à un effet. Cette valeur doit être l'une des suivantes: PreferNoSchedule, NoSchedule ou NoExecute.

  L'exemple suivant ajoute trois nœuds aux nœuds du plan de contrôle. Tous les nœuds sont associés à l'étiquette 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 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.
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écouverts. Un PersistentVolume local (PV) 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 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 options et de 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 gcloud CLI, vous devez d'abord créer le cluster, puis y ajouter un ou plusieurs pools de nœuds.

gcloud beta 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 nouvellement créé.

• 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 cet indicateur 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;...' \
  

  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 calcul. Vous ne pouvez spécifier qu'un seul node-ip par indicateur. Ajoutez à nouveau cet indicateur 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 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.

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

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

  • --node-taints=KEY=VALUE:EFFECT,...Liste de rejets Kubernetes appliqués à chaque nœud du pool, séparés par une virgule. 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 valeurs suivantes pour EFFECT: NoSchedule, PreferNoSchedule, NoExecute.

L'exemple suivant crée un pool de nœuds appelé default-pool sur user-cluster- et ajoute deux nœuds au pool. Tous les deux nœuds portent l'étiquette node-pool-key=node-pool-value et ont le rejet dedicated=experimental:PreferNoSchedule,

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

Preview

Cette fonctionnalité est soumise aux "Conditions des offres de pré-DG" dans la section "Conditions d'utilisation générales" des Conditions spécifiques au service. Les fonctionnalités pré-DG sont disponibles "en l'état" et peuvent avoir une assistance limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

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 dans lequel 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

   Afficher sur GitHub

   
   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 des paramètres dans terraform.tfvars et 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 d'Anthos clusters on Bare Metal pour votre cluster d'utilisateur. Spécifiez la même version que le cluster d'administrateur, ou une version qui n'est pas plus d'une version mineure inférieure au 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 n'avez qu'une seule machine si vous utilisez un déploiement minimal, ou 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 (VIP) 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 des 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 auxquels des droits d'administrateur doivent être accordés 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ées sur les rôles Kubernetes (RBAC) au cluster pour attribuer aux utilisateurs administrateurs le rôle Kubernetes clusterrole/cluster-admin, qui fournit un accès complet à toutes les ressources du cluster dans tous les espaces de noms. Les utilisateurs peuvent également 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 requises, par exemple 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ées sur les rôles (RBAC) de Kubernetes pour que vous puissiez vous connecter au cluster à l'aide de votre identité Google Cloud. Lorsque vous créez un cluster d'utilisateur avec 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 comme administrateur, vous devez remplacer la valeur par défaut, et inclure 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 des identités 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 connecter directement au point de terminaison privé 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 en toute sécurité 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, puis gérez le cluster depuis votre poste de travail administrateur.

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

Passerelle Connect

1. Initialisez 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 les clusters Anthos 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 un 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 kubeconfig avec les identifiants du cluster d'utilisateur est écrit dans un fichier bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-TIMESTAMP-kubeconfig. Le TIMESTAMP dans le 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

• Sécuriser vos conteneurs à l'aide de SELinux
• Gérer des clusters à partir de la console Google Cloud