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

Version 1.13 

• Dernière version
• 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 aussi créer un cluster d'utilisateur en créant un fichier de configuration de cluster d'utilisateur et en utilisant gkectl, comme décrit dans la section Créer un cluster d'utilisateur à l'aide de gkectl.

Si vous souhaitez utiliser Terraform, la console ou gcloud CLI pour gérer le cycle de vie des clusters créés à l'aide de gkectl, 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 des rôles, consultez Gérer l'accès aux projets, aux dossiers et aux organisations.

Enregistrer le cluster d'administrateur

Pour créer des clusters d'utilisateur à l'aide de clients API Anthos On-Prem, vous devez disposer d'un cluster d'administrateur et celui-ci doit être enregistré dans un parc.

• Si vous n'avez pas encore créé de cluster d'administrateur, remplissez la section gkeConnect de votre fichier de configuration de cluster d'administrateur.

• Si vous disposez d'un cluster d'administrateur mais que vous ne l'avez pas enregistré, consultez la section Enregistrer un cluster d'administrateur.

Activer les journaux d'audit pour les activités d'administration du cluster d'administrateur

La journalisation des activités d'administration dans les journaux d'audit Cloud doit être activée sur le cluster d'administrateur.

• Si vous n'avez pas encore créé de cluster d'administrateur, remplissez la section cloudAuditLogging du fichier de configuration de votre cluster d'administrateur.

• Pour mettre à jour un cluster d'administrateur existant, consultez la section Activer ou désactiver la journalisation dans Cloud Audit Logging pour le cluster d'administrateur.

Activer la journalisation et la surveillance au niveau du système pour le cluster d'administrateur

Cloud Logging et Cloud Monitoring doivent être activés sur le cluster d'administrateur.

• Si vous n'avez pas encore créé de cluster d'administrateur, remplissez la section stackdriver du fichier de configuration de votre cluster d'administrateur.

• Pour mettre à jour un cluster d'administrateur existant, consultez la section Activer ou désactiver la journalisation et la surveillance du cluster d'administrateur.

API Google requises

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

En outre, vous devez activer l'API Anthos On-Prem:

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

Accès à la ligne de commande

Une fois le cluster créé, si vous souhaitez utiliser la passerelle Connect pour vous connecter au cluster utilisateur via la ligne de commande, procédez comme suit :

Assurez-vous que les outils de ligne de commande suivants sont installés :

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

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

Versions disponibles pour les nouvelles installations

Lorsque vous créez un cluster d'utilisateur, vous installez généralement la version des clusters Anthos sur VMware correspondant au cluster d'administrateur. Toutefois, vous pouvez installer une version de correctif ultérieure ou une version mineure ultérieure. Par exemple, vous pouvez installer la dernière version de correctif lorsque vous créez un cluster d'utilisateur afin d'identifier les corrections de bugs. Comptez environ 7 à 10 jours après la publication d'une version de Clusters Anthos sur VMware pour que la version soit disponible dans l'API Anthos On-Prem.

Si vous souhaitez créer un cluster d'utilisateur qui est une version ultérieure à celui du cluster d'administrateur, commencez par télécharger un groupe spécifique aux composants dont le cluster d'administrateur a besoin pour gérer les clusters d'utilisateur au niveau de cette version, puis déployez les composants. Pour en savoir plus, consultez Installer une version ultérieure à la version du cluster d'administrateur.

Choisir un outil pour créer le cluster

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 vous installez des clusters Anthos sur VMware pour la première fois, la console est sans doute la solution la plus simple.

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.

Créer un cluster d'utilisateur

Console

La plupart des champs de Google Cloud Console correspondent aux champs du fichier de configuration du cluster d'utilisateur.

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 VMware vSphere, cliquez sur Configurer.

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. Si vous n'avez pas spécifié de nom pour le cluster d'administrateur lors de sa création, le nom est généré au format gke-admin-[HASH]. Si vous ne connaissez pas le nom du cluster d'administrateur, exécutez la commande suivante sur votre poste de travail administrateur :

   KUBECONFIG=ADMIN_CLUSTER_KUBECONFIG
   kubectl get OnPremAdminCluster -n kube-system -o=jsonpath='{.items[0].metadata.name}'
   

   Si le cluster d'administrateur que vous souhaitez utiliser ne s'affiche pas, consultez la section de dépannage Le cluster d'administrateur ne s'affiche pas dans la liste déroulante Paramètres de base du cluster.

3. Dans le champ emplacement de l'API GCP, 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 identifient de manière unique Google Cloud.

4. Sélectionnez la version d'Anthos clusters on VMware pour votre cluster d'utilisateur.

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 de cluster de la section Autorisation.

   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. Cliquez sur Suivant pour accéder à la section Plan de contrôle.

Plan de contrôle

Tous les champs de la section Plan de contrôle sont définis avec des valeurs par défaut. Vérifiez les valeurs par défaut et modifiez-les si nécessaire.

1. Dans le champ vCPU de nœud de plan de contrôle, saisissez le nombre de processeurs virtuels (au minimum 4) pour chaque nœud de plan de contrôle pour votre cluster d'utilisateur.
2. Dans le champ Mémoire du nœud du plan de contrôle, saisissez la taille de la mémoire en Mio (8 192 au minimum et doit être un multiple de 4) pour chaque plan de contrôle du cluster d'utilisateur.
3. Sous Nœuds du plan de contrôle, sélectionnez le nombre de nœuds de plan de contrôle pour votre cluster d'utilisateur. Par exemple, vous pouvez sélectionner un nœud de plan de contrôle pour un environnement de développement et trois nœuds de plan de contrôle pour les environnements de production et de haute disponibilité.

4. Si vous le souhaitez, sélectionnez Redimensionnement automatique des nœuds. Le redimensionnement signifie que les ressources de processeur virtuel et de mémoire attribuées à un nœud sont ajustées automatiquement. Lorsque cette option est activée, les nœuds du plan de contrôle du cluster d'utilisateur sont redimensionnés en fonction du nombre de nœuds de calcul dans le cluster d'utilisateur. Ainsi, à mesure que vous ajoutez des nœuds de calcul au cluster d'utilisateur, la taille des nœuds du plan de contrôle augmente.

5. 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. Un cluster d'utilisateur doit disposer d'une adresse IP pour chaque nœud et d'une adresse IP supplémentaire pour un nœud temporaire nécessaire à la mise à niveau, à la mise à jour et à la réparation automatique du cluster. Pour en savoir plus, consultez la section De combien d'adresses IP un cluster d'utilisateur a-t-il besoin ?.

1. Dans la section Adresses IP des nœuds, sélectionnez le mode d'adresse IP du cluster d'utilisateur. Sélectionnez l'une des options suivantes :

   • DHCP : sélectionnez DHCP si vous souhaitez que les nœuds de votre cluster obtiennent leur adresse IP à partir d'un serveur DHCP.

   • Statique : sélectionnez Statique si vous souhaitez fournir des adresses IP statiques pour vos nœuds de cluster ou si vous souhaitez configurer l'équilibrage de charge manuel.

2. Si vous avez sélectionné DHCP, passez à l'étape suivante pour spécifier les plages CIDR de service et de pod. Dans le champ Mode IP statique, indiquez les informations suivantes :

   1. Saisissez l'adresse IP de la passerelle du cluster d'utilisateur.

   2. Saisissez le masque de sous-réseau pour les nœuds de cluster d'utilisateur.

   3. Dans la section Adresses IP, saisissez les adresses IP et, éventuellement, les noms d'hôte des nœuds du cluster d'utilisateur. Vous pouvez saisir une adresse IP individuelle v4 (telle que 192.0.2.1) ou un bloc CIDR d'adresses IPv4 (par exemple, 192.0.2.0/24).

      • Si vous saisissez un bloc CIDR, ne saisissez pas de nom d'hôte.
      • Si vous saisissez une adresse IP individuelle, vous pouvez éventuellement saisir un nom d'hôte. Si vous ne saisissez pas de nom d'hôte, les clusters Anthos sur VMware utilisent le nom de la VM dans vSphere comme nom d'hôte.

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

3. Dans la section plages CIDR des services et des pods, la console fournit les plages d'adresses suivantes pour vos services et pods Kubernetes :

   • CIDR des services : 10.96.0.0/20
   • CIDR des pods : 192.168.0.0/16

   Si vous préférez saisir vos propres plages d'adresses, consultez la section Adresses IP pour les pods et les services pour connaître les bonnes pratiques.

4. Si vous avez sélectionné le mode IP statique, spécifiez les informations suivantes dans la section Configuration de l'hôte:

   1. Saisissez les adresses IP des serveurs DNS.
   2. Saisissez les adresses IP des serveurs NTP.
   3. Vous pouvez éventuellement saisir des domaines de recherche DNS.

5. Cliquez sur Suivant pour accéder à la section Équilibreur de charge.

Équilibreur de charge

Choisissez l'équilibreur de charge à configurer pour votre cluster. Pour en savoir plus, consultez la page Présentation de l'équilibreur de charge.

Sélectionnez le type d'équilibreur de charge dans la liste.

Groupé avec MetalLB

Configurez l'équilibrage de charge groupé avec MetalLB. Vous ne pouvez utiliser MetalLB pour le cluster d'utilisateur que si votre cluster d'administrateur utilise SeeSaw ou MetalLB. Cette option nécessite une configuration minimale. MetalLB s'exécute directement sur vos nœuds de cluster et ne nécessite pas de VM supplémentaire. Pour en savoir plus sur les avantages de MetalLB et sur ses différences par rapport aux autres options d'équilibrage de charge, consultez la page Équilibrage de charge groupé avec MetalLB.

1. Dans la section Pools d'adresses, configurez au moins un pool d'adresses comme suit :

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

   2. Saisissez une plage d'adresses IP contenant l'adresse IP virtuelle d'entrée au format CIDR (par exemple, 192.0.2.0/26) ou sous forme de plage (par exemple, 192.0.2.64-192.0.2.72). Pour spécifier une seule adresse IP dans un pool, utilisez /32 au format CIDR (par exemple, 192.0.2.1/32).

   3. Si les adresses IP de vos services de type LoadBalancer ne se trouvent pas dans la même plage d'adresses IP que l'adresse IP virtuelle d'entrée, cliquez sur + Ajouter une plage d'adresses IP et saisissez une autre plage d'adresses.

      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 d'adresses IP, sélectionnez l'une des options suivantes :

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

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

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

   • Adresse IP virtuelle de plan de contrôle : l'adresse IP de destination à utiliser pour le trafic envoyé au serveur d'API Kubernetes du cluster d'utilisateur. Le serveur d'API Kubernetes du cluster d'utilisateur s'exécute sur un nœud du cluster d'administrateur. Cette adresse IP doit appartenir au même domaine L2 que les nœuds du cluster d'administrateur. N'ajoutez pas cette adresse dans la section Pools d'adresses.

   • Adresse IP virtuelle d'entrée : adresse IP à configurer sur l'équilibreur de charge pour le proxy d'entrée. Vous devez l'ajouter à un pool d'adresses dans la section Pools d'adresses.

4. Cliquez sur Continuer.

Équilibreur de charge F5 BIG-IP

Vous ne pouvez utiliser F5 pour le cluster d'utilisateur que si votre cluster d'administrateur utilise F5. Veillez à installer et à configurer F5 BIG-IP ADC avant de l'intégrer à des clusters Anthos sur VMware. Consultez le guide d'installation de l'ADC F5 BIG-IP pour en savoir plus. Le nom d'utilisateur et le mot de passe F5 sont hérités du cluster d'administrateur.

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

   • Adresse IP virtuelle de plan de contrôle : l'adresse IP de destination à utiliser pour le trafic envoyé au serveur d'API Kubernetes.

   • Adresse IP virtuelle d'entrée : adresse IP à configurer sur l'équilibreur de charge pour le proxy d'entrée.

2. Dans le champ Adresse, saisissez l'adresse de votre équilibreur de charge F5 BIG-IP.

3. Dans le champ Partition, saisissez le nom d'une partition BIG-IP que vous avez créée pour votre cluster d'utilisateur.

4. Dans le champ Nom du pool sNAT, saisissez le nom de votre pool SNAT, le cas échéant.

5. Cliquez sur Continuer.

Équilibreur de charge manuel

Configurez l'équilibrage de charge manuel. Vous ne pouvez utiliser un équilibreur de charge manuel pour le cluster d'utilisateur que si votre cluster d'administrateur utilise un équilibreur de charge manuel. Dans Clusters Anthos sur VMware, le serveur d'API Kubernetes, le proxy d'entrée et le service complémentaire d'agrégation des journaux sont chacun exposés par un service Kubernetes de type LoadBalancer. Choisissez vos propres valeurs nodePort dans la plage 30000-32767 pour ces services. Pour le proxy d'entrée, choisissez une valeur nodePort pour le trafic HTTP et le trafic HTTPS. Pour en savoir plus, consultez la page Activer le mode d'équilibrage de charge manuel.

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

   • Adresse IP virtuelle de plan de contrôle : l'adresse IP de destination à utiliser pour le trafic envoyé au serveur d'API Kubernetes.

   • Adresse IP virtuelle d'entrée : adresse IP à configurer sur l'équilibreur de charge pour le proxy d'entrée.

2. Dans le champ Port du nœud de plan de contrôle, saisissez une valeur nodePort pour le serveur d'API Kubernetes. Le serveur d'API Kubernetes d'un cluster d'utilisateur s'exécute sur le cluster d'administrateur.

3. Dans le champ Port du nœud HTTP d'entrée, saisissez une valeur nodePort pour le trafic HTTP vers le proxy d'entrée.

4. Dans le champ Port du nœud HTTPS d'entrée, saisissez une valeur nodePort pour le trafic HTTPS vers le proxy d'entrée.

5. Dans le champ Port de nœud de serveur Konnectivity, saisissez une valeur nodePort pour le serveur Konnectivity.

6. Cliquez sur Continuer.

Caractéristiques

Cette section présente les fonctionnalités et les opérations activées sur le 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

1. Les éléments suivants sont activés par défaut, mais vous pouvez les désactiver :

   • Activer le pilote CSI vSphere : également appelé plug-in de stockage de conteneurs vSphere. Le pilote CSI (Container Storage Interface) s'exécute dans un cluster Kubernetes natif déployé dans vSphere pour provisionner des volumes persistants sur l'espace de stockage vSphere. Pour en savoir plus, consultez la page Utiliser le pilote Container Storage Interface (CSI) de vSphere.
   • Activer les groupes d'anti-affinité : les règles d'anti-affinité VMware Distributed Resource Scheduler (DRS) sont automatiquement créées pour les nœuds de votre cluster d'utilisateur, avec pour effet de les répartir sur au moins trois hôtes physiques dans votre centre de données. Assurez-vous que votre environnement vSphere répond aux exigences.
   Remarque :Si vous avez suivi la procédure Configurer une infrastructure minimale, vous ne disposez que d'un seul hôte ESXi. Veillez donc à décocher l'option Activer les groupes d'anti-affinité.

2. Cliquez sur Suivant pour configurer un pool de nœuds.

Pools de nœuds

Votre cluster sera créé avec au moins un pool de nœuds. Un pool de nœuds représente le modèle des groupes de nœuds créés dans ce cluster. Pour en savoir plus, consultez la page Créer et gérer des pools de nœuds.

1. Dans la section Valeurs par défaut du pool de nœuds, renseignez les éléments suivants :

   1. Saisissez le nom du pool de nœuds ou acceptez "default-pool" comme nom.
   2. Saisissez le nombre de processeurs virtuels pour chaque nœud du pool (au moins quatre par nœud de calcul de cluster d'utilisateur).
   3. Saisissez la taille de la mémoire en mébioctets (Mio) pour chaque nœud du pool (8192 Mio au minimum par nœud de nœud de calcul de cluster d'utilisateur, doit être un multiple de 4).
   4. Dans le champ Nœuds, saisissez le nombre de nœuds du pool (minimum 3). Si vous avez saisi des adresses IP statiques pour les adresses IP de nœud dans la section Mise en réseau, assurez-vous d'avoir saisi suffisamment d'adresses IP pour prendre en charge ces nœuds de cluster d'utilisateur.
   5. Sélectionnez le type d'image de l'OS : Ubuntu, Ubuntu Containerd ou COS.
   6. Saisissez la taille du disque de démarrage en gibioctets (Gio) (40 Gio au minimum).
   7. Si vous utilisez MetalLB comme équilibreur de charge, MetalLB doit être activé dans au moins un pool de nœuds. Laissez l'option Utiliser ce pool de nœuds pour l'équilibrage de charge MetalB sélectionnée, ou ajoutez un autre pool de nœuds à utiliser pour MetalLB.

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

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

   Si une erreur se produit lors de la vérification des paramètres, la console affiche un message d'erreur qui doit être suffisamment clair pour résoudre le problème de configuration avant de retenter de créer le cluster.

   Pour en savoir plus sur les erreurs possibles et sur la façon de les corriger, consultez la page Résoudre les problèmes de création de cluster d'utilisateur dans la console Google Cloud.

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 vmware 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 vmware 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 une commande complète dans la section Exemples.

Avant de commencer

1. Connectez-vous à votre compte Google.

   gcloud auth login
   

2. Veillez à mettre à jour les composants:

   gcloud components update
   

3. Obtenez la liste des versions disponibles:

   gcloud beta container vmware clusters query-version-config \
     --admin-cluster-membership=ADMIN_CLUSTER_NAME \
     --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
     --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.

   La sortie de la commande ressemble à ceci :

   versions:
   - isInstalled: true
     version: 1.14.3-gke.25
   - version: 1.14.4-gke.54
   - version: 1.15.0-gke.581
   

Les versions que vous pouvez utiliser pour créer un cluster d'utilisateur sont annotées avec isInstalled=true, ce qui signifie que le cluster d'administrateur dispose des composants spécifiques à la version dont il a besoin pour gérer les clusters d'utilisateur de cette version. Si vous souhaitez créer un cluster d'utilisateur avec une autre version disponible, consultez la section Installer une version ultérieure à la version du cluster d'administrateur.

Examples

Les exemples suivants montrent comment créer un cluster d'utilisateur avec différents équilibreurs de charge. Pour en savoir plus sur les options d'équilibrage de charge disponibles, consultez la page Présentation de l'équilibreur de charge.

Les exemples utilisent les valeurs par défaut pour configurer les nœuds du plan de contrôle. Si vous souhaitez modifier l'une des valeurs par défaut, incluez les options décrites dans la section Options du plan de contrôle. Si nécessaire, vous pouvez également modifier certains paramètres vSphere.

Une fois le cluster en cours d'exécution, ajoutez un pool de nœuds avant de déployer des charges de travail, comme décrit dans la section Créer un pool de nœuds.

MetalLB et DHCP

Cet exemple montre comment créer un cluster d'utilisateur avec l'équilibreur de charge MetalLB groupé et comment utiliser votre serveur DHCP pour obtenir les adresses IP de vos nœuds de cluster.

Vous ne pouvez utiliser MetalLB pour le cluster d'utilisateur que si votre cluster d'administrateur utilise SeeSaw ou MetalLB. Cette option d'équilibrage de charge nécessite une configuration minimale. MetalLB s'exécute directement sur vos nœuds de cluster et ne nécessite pas de VM supplémentaire. Pour en savoir plus sur les avantages de l'utilisation de MetallLB et pour la comparer aux autres options d'équilibrage de charge, consultez la page Équilibrage de charge groupé avec MetalLB.

Si nécessaire, veillez à renseigner l'espace réservé ADMIN_CLUSTER_NAME pour l'indicateur --admin-cluster-membership. Cet exemple utilise le nom complet du cluster d'administrateur. Vous n'avez donc pas besoin d'inclure --admin-cluster-membership-location et --admin-cluster-membership-project.

gcloud beta container vmware 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 \
  --service-address-cidr-blocks=SERVICE_CIDR_BLOCK \
  --pod-address-cidr-blocks=POD_CIDR_BLOCK \
  --metal-lb-config-address-pools='pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \
  --control-plane-vip=CONTROL_PLANE_VIP \
  --ingress-vip=INGRESS_VIP \
  --enable-dhcp

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

• SERVICE_CIDR_BLOCK: plage d'adresses IP au format CIDR à utiliser pour les services de votre cluster. Elle doit être au moins égale à /24.

  Exemple : --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. Elle doit être au moins égale à /18.

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

• --metal-lb-config-address-pools: inclut cette option pour spécifier la configuration des pools d'adresses que l'équilibreur de charge MetalLB doit utiliser. La valeur de cet indicateur est au format suivant :

  --metal-lb-config-address-pool '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-ips1: 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 évite que les appareils grand public génèrent des bugs en éliminant 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 au format de plage 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 un bloc /32 au format CIDR, par exemple : 192.0.2.1/32.

  Veuillez noter les points suivants :

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

  Exemple :

  --metal-lb-config-address-pool 'pool=pool1,avoid-buggy-ips=True,manual-assign=True,addresses=10.251.134.80/32;192.168.1.0/26;192.168.1.2-192.168.1.3'

• 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

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

• --enable-dhcp: incluez --enable-dhcp si vous souhaitez que les nœuds de votre cluster obtiennent leur adresse IP à partir d'un serveur DHCP que vous fournissez. N'incluez pas cette option si vous souhaitez fournir des adresses IP statiques pour vos nœuds de cluster ou si vous souhaitez configurer l'équilibrage de charge manuel.

MetalLB et IP statiques

Cet exemple montre comment créer un cluster d'utilisateur avec l'équilibreur de charge MetalLB groupé et attribuer des adresses IP statiques aux nœuds de votre cluster.

Vous ne pouvez utiliser MetalLB pour le cluster d'utilisateur que si votre cluster d'administrateur utilise SeeSaw ou MetalLB. Cette option d'équilibrage de charge nécessite une configuration minimale. MetalLB s'exécute directement sur vos nœuds de cluster et ne nécessite pas de VM supplémentaire. Pour en savoir plus sur les avantages de l'utilisation de MetallLB et pour la comparer aux autres options d'équilibrage de charge, consultez la page Équilibrage de charge groupé avec MetalLB.

Si nécessaire, veillez à renseigner l'espace réservé ADMIN_CLUSTER_NAME pour l'indicateur --admin-cluster-membership. Cet exemple utilise le nom complet du cluster d'administrateur. Vous n'avez donc pas besoin d'inclure --admin-cluster-membership-location et --admin-cluster-membership-project.

gcloud beta container vmware 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 \
  --service-address-cidr-blocks=SERVICE_CIDR_BLOCK \
  --pod-address-cidr-blocks=POD_CIDR_BLOCK \
  --metal-lb-config-address-pools='pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \
  --control-plane-vip=CONTROL_PLANE_VIP \
  --ingress-vip=INGRESS_VIP \
  --static-ip-config-ip-blocks='gateway=GATEWAY,netmask=NETMASK,ips=IP_ADDRESS_1;IP_ADDRESS_2 HOST_2;...' \
  --dns-servers=DNS_SERVER,... \
  --dns-search-domains=DNS_SEARCH_DOMAIN,... \
  --ntp-servers=NTP_SERVER,...

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

• SERVICE_CIDR_BLOCK: plage d'adresses IP au format CIDR à utiliser pour les services de votre cluster. Elle doit être au moins égale à /24.

  Exemple : --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. Elle doit être au moins égale à /18.

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

• --metal-lb-config-address-pools: inclut cette option pour spécifier la configuration des pools d'adresses que l'équilibreur de charge MetalLB doit utiliser. La valeur de cet indicateur est au format suivant :

  --metal-lb-config-address-pool '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-ips1: 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 évite que les appareils grand public génèrent des bugs en éliminant 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 au format de plage 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 un bloc /32 au format CIDR, par exemple : 192.0.2.1/32.

  Veuillez noter les points suivants :

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

  Exemple :

  --metal-lb-config-address-pool 'pool=pool1,avoid-buggy-ips=True,manual-assign=True,addresses=10.251.134.80/32;192.168.1.0/26;192.168.1.2-192.168.1.3'

• 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

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

• --static-ip-config-ip-blocks: spécifiez la passerelle par défaut, le masque de sous-réseau et la liste des adresses IP statiques des nœuds de calcul du cluster d'utilisateur. La valeur de cet indicateur est au format suivant :

  --static-ip-config-ip-blocks 'gateway=GATEWAY,netmask=NETMASK,ips=IP_ADDRESS_1;IP_ADDRESS_2 HOST_2;...'

  Cette valeur comporte des segments qui commencent par les mots clés gateway, netmask et ips. Séparez les segments par une virgule.

  Veuillez noter les points suivants :

  • Entourez toute la valeur de guillemets simples.
  • Les espaces blancs ne sont pas autorisés, sauf entre une adresse IP et un nom d'hôte.

  Dans la liste des adresses IP:

  • Vous pouvez spécifier une adresse IP individuelle ou un bloc d'adresses IP CIDR.
  • Séparez chaque adresse IP ou bloc CIDR par un point-virgule.
  • Pour une adresse IP individuelle, vous pouvez éventuellement spécifier un nom d'hôte après l'adresse IP. Séparez l'adresse IP et le nom d'hôte par un espace. Lorsque vous ne spécifiez pas de nom d'hôte, Clusters Anthos sur VMware utilise le nom de la VM vSphere comme nom d'hôte.
  • Si vous spécifiez un bloc CIDR, n'indiquez pas de valeur pour le nom d'hôte.

  Exemple :

  --static-ip-config-ip-blocks 'gateway=172.16.23.254,netmask=255.255.252.0,ips=172.16.20.10;172.16.20.11 host2;172.16.20.12/30'

• DNS_SERVER: liste des adresses IP des serveurs DNS pour les VM, séparées par une virgule.
• DNS_SEARCH_DOMAIN: liste des domaines de recherche DNS que les hôtes doivent utiliser, séparés par une virgule. Ces domaines sont utilisés dans le cadre d'une liste de recherche de domaines.

  Exemple :

  --dns-search-domains example.com,examplepetstore.com

• NTP_SERVER: liste des adresses IP des serveurs de temps que les VM doivent utiliser, séparées par une virgule.

F5 BIG-IP et DHCP

Cet exemple montre comment créer un cluster d'utilisateur avec votre équilibreur de charge F5 BIG-IP et comment utiliser votre serveur DHCP pour obtenir les adresses IP de vos nœuds de cluster.

Vous ne pouvez utiliser F5 pour le cluster d'utilisateur que si votre cluster d'administrateur utilise F5. Veillez à installer et à configurer F5 BIG-IP ADC avant de l'intégrer à des clusters Anthos sur VMware. Consultez le guide d'installation de l'ADC F5 BIG-IP pour en savoir plus. Le nom d'utilisateur et le mot de passe F5 sont hérités du cluster d'administrateur.

Si nécessaire, veillez à renseigner l'espace réservé ADMIN_CLUSTER_NAME pour l'indicateur --admin-cluster-membership. Cet exemple utilise le nom complet du cluster d'administrateur. Vous n'avez donc pas besoin d'inclure --admin-cluster-membership-location et --admin-cluster-membership-project.

gcloud beta container vmware 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 \
  --service-address-cidr-blocks=SERVICE_CIDR_BLOCK \
  --pod-address-cidr-blocks=POD_CIDR_BLOCK \
  --f5-config-address=F5_CONFIG_ADDRESS \
  --f5-config-partition=F5_CONFIG_PARTITION \
  --f5-config-snat-pool=F5_CONFIG_SNAT_POOL \
  --control-plane-vipCONTROL_PLANE_VIP \
  --ingress-vip=INGRESS_VIP \
  --enable-dhcp

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

• SERVICE_CIDR_BLOCK: plage d'adresses IP au format CIDR à utiliser pour les services de votre cluster. Elle doit être au moins égale à /24.

  Exemple : --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. Elle doit être au moins égale à /18.

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

• F5_CONFIG_ADDRESS: adresse de votre équilibreur de charge F5 BIG-IP.

• F5_CONFIG_PARTITION:nom d'une partition BIG-IP que vous avez créée pour votre cluster d'utilisateur.

• F5_CONFIG_SNAT_POOL: nom de votre pool SNAT, le cas échéant.

• 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

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

• --enable-dhcp: incluez --enable-dhcp si vous souhaitez que les nœuds de votre cluster obtiennent leur adresse IP à partir d'un serveur DHCP que vous fournissez. N'incluez pas cette option si vous souhaitez fournir des adresses IP statiques pour vos nœuds de cluster ou si vous souhaitez configurer l'équilibrage de charge manuel.

Équilibrage de charge manuel et adresse IP statique

Cet exemple montre comment créer un cluster d'utilisateur avec un équilibreur de charge manuel et comment attribuer des adresses IP statiques à vos nœuds de cluster.

Vous ne pouvez utiliser un équilibreur de charge manuel pour le cluster d'utilisateur que si votre cluster d'administrateur utilise un équilibreur de charge manuel. Dans Clusters Anthos sur VMware, le serveur d'API Kubernetes, le proxy d'entrée et le service complémentaire d'agrégation des journaux sont chacun exposés par un service Kubernetes de type LoadBalancer. Choisissez vos propres valeurs nodePort dans la plage 30000-32767 pour ces services. Pour le proxy d'entrée, choisissez une valeur nodePort pour le trafic HTTP et le trafic HTTPS. Pour en savoir plus, consultez la page Activer le mode d'équilibrage de charge manuel.

Si nécessaire, veillez à renseigner l'espace réservé ADMIN_CLUSTER_NAME pour l'indicateur --admin-cluster-membership. Cet exemple utilise le nom complet du cluster d'administrateur. Vous n'avez donc pas besoin d'inclure --admin-cluster-membership-location et --admin-cluster-membership-project.

gcloud beta container vmware 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 \
  --service-address-cidr-blocks=SERVICE_CIDR_BLOCK \
  --pod-address-cidr-blocks=POD_CIDR_BLOCK \
  --control-plane-vip=CONTROL_PLANE_VIP \
  --control-plane-node-port=CONTROL_PLANE_NODE_PORT \
  --ingress-vip=INGRESS_VIP \
  --ingress-http-node-port=INGRESS_HTTP_NODE_PORT \
  --ingress-https-node-port=INGRESS_HTTPS_NODE_PORT \
  --konnectivity-server-node-port=KONNECTIVITY_SERVER_NODE_PORT

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

• SERVICE_CIDR_BLOCK: plage d'adresses IP au format CIDR à utiliser pour les services de votre cluster. Elle doit être au moins égale à /24.

  Exemple : --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. Elle doit être au moins égale à /18.

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

• 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_NODE_PORT: valeur de nodePort pour le serveur d'API Kubernetes.

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

  Exemple : --ingress-vip=203.0.113.4

• INGRESS_HTTP_NODE_PORT: valeur nodePort pour le trafic HTTP vers le proxy d'entrée.

• INGRESS_HTTPS_NODE_PORT: une valeur nodePort pour le trafic HTTPS vers le proxy d'entrée.

• KONNECTIVITY_SERVER_NODE_PORT: valeur de nodePort pour le serveur Konnectivity.

• --static-ip-config-ip-blocks: spécifiez la passerelle par défaut, le masque de sous-réseau et la liste des adresses IP statiques des nœuds de calcul du cluster d'utilisateur. La valeur de cet indicateur est au format suivant :

  --static-ip-config-ip-blocks 'gateway=GATEWAY,netmask=NETMASK,ips=IP_ADDRESS_1;IP_ADDRESS_2 HOST_2;...'

  Cette valeur comporte des segments qui commencent par les mots clés gateway, netmask et ips. Séparez les segments par une virgule.

  Veuillez noter les points suivants :

  • Entourez toute la valeur de guillemets simples.
  • Les espaces blancs ne sont pas autorisés, sauf entre une adresse IP et un nom d'hôte.

  Dans la liste des adresses IP:

  • Vous pouvez spécifier une adresse IP individuelle ou un bloc d'adresses IP CIDR.
  • Séparez chaque adresse IP ou bloc CIDR par un point-virgule.
  • Pour une adresse IP individuelle, vous pouvez éventuellement spécifier un nom d'hôte après l'adresse IP. Séparez l'adresse IP et le nom d'hôte par un espace. Lorsque vous ne spécifiez pas de nom d'hôte, Clusters Anthos sur VMware utilise le nom de la VM vSphere comme nom d'hôte.
  • Si vous spécifiez un bloc CIDR, n'indiquez pas de valeur pour le nom d'hôte.

  Exemple :

  --static-ip-config-ip-blocks 'gateway=172.16.23.254,netmask=255.255.252.0,ips=172.16.20.10;172.16.20.11 host2;172.16.20.12/30'

• DNS_SERVER: liste des adresses IP des serveurs DNS pour les VM, séparées par une virgule.
• DNS_SEARCH_DOMAIN: liste des domaines de recherche DNS que les hôtes doivent utiliser, séparés par une virgule. Ces domaines sont utilisés dans le cadre d'une liste de recherche de domaines.

  Exemple :

  --dns-search-domains example.com,examplepetstore.com

• NTP_SERVER: liste des adresses IP des serveurs de temps que les VM doivent utiliser, séparées par une virgule.

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

Indicateurs du plan de contrôle

Si vous souhaitez utiliser des valeurs autres que celles par défaut pour la configuration du plan de contrôle, incluez une ou plusieurs des options suivantes:

• --cpus=vCPUS: nombre de processeurs virtuels (au minimum 4) pour chaque nœud de plan de contrôle pour votre cluster d'utilisateur. Si aucune valeur n'est spécifiée, la valeur par défaut est de 4 vCPU.

• --memory=MEMORY: taille de la mémoire en mébioctets (Mio) pour chaque plan de contrôle de votre cluster d'utilisateur. La valeur minimale est 8192 et doit être un multiple de 4. Si aucune valeur n'est spécifiée, la valeur par défaut est 8192.

• --replicas=NODES: nombre de nœuds de plan de contrôle pour votre cluster d'utilisateur. Par exemple, vous pouvez sélectionner un nœud de plan de contrôle pour un environnement de développement et trois nœuds de plan de contrôle pour les environnements de production et de haute disponibilité.

• --enable-auto-resize: si vous souhaitez activer le redimensionnement automatique des nœuds du plan de contrôle pour le cluster d'utilisateur, incluez --enable-auto-resize. Le redimensionnement signifie que les ressources de vCPU et de mémoire attribuées à un nœud sont ajustées automatiquement. Lorsque cette option est activée, les nœuds du plan de contrôle du cluster d'utilisateur sont redimensionnés en fonction du nombre de nœuds de calcul dans le cluster d'utilisateur. Ainsi, à mesure que vous ajoutez des nœuds de calcul au cluster d'utilisateur, la taille des nœuds du plan de contrôle augmente.

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

Indicateurs vSphere

Si nécessaire, spécifiez les options facultatives suivantes:

• --disable-aag-config: si vous n'incluez pas cet indicateur, les règles anti-affinité VMware DRS (Distributed Resource Scheduler) sont automatiquement créées pour les nœuds de votre cluster d'utilisateur. Par conséquent, elles sont réparties sur au moins trois hôtes physiques dans votre centre de données. Assurez-vous que votre environnement vSphere répond aux exigences. Si votre cluster ne répond pas aux exigences, incluez cette option.

  Remarque :Si vous avez suivi la procédure Configurer une infrastructure minimale, vous ne disposez que d'un seul hôte ESXi. Veillez donc à inclure cette option.

• --disable-vsphere-csi: si vous n'incluez pas cet indicateur, les composants vSphere Container Interface (CSI) sont déployés dans le cluster d'utilisateur. Le pilote CSI s'exécute dans un cluster Kubernetes natif déployé dans vSphere pour provisionner des volumes persistants sur l'espace de stockage vSphere. Pour en savoir plus, consultez la page Utiliser le pilote Container Storage Interface (CSI) de vSphere. Si vous ne souhaitez pas déployer les composants de CSI, incluez cet indicateur.

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

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.

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.

gcloud beta container vmware node-pools create NODE_POOL_NAME \
--cluster=USER_CLUSTER_NAME  \
--project=FLEET_HOST_PROJECT_ID \
--location=REGION \
--image-type=IMAGE_TYPE  \
--boot-disk-size=BOOT_DISK_SIZE \
--cpus=vCPUS \
--memory=MEMORY \
--replicas=NODES \
--enable-load-balancer

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: emplacement Google Cloud que vous avez spécifié lors de la création du cluster.

• IMAGE_TYPE: type d'image de système d'exploitation à exécuter sur les VM du pool de nœuds. Définissez l'une des options suivantes: ubuntu_containerd ou cos.

• BOOT_DISK_SIZE: taille du disque de démarrage en gibioctets (Gio) pour chaque nœud du pool. La valeur minimale est de 40 Gio.

• vCPUs: nombre de processeurs virtuels pour chaque nœud du pool de nœuds. La valeur minimale est de 4.

• MEMORY: taille de la mémoire en mébioctets (Mio) pour chaque nœud du pool. La valeur minimale est de 8 192 Mio par nœud de calcul de cluster d'utilisateur et la valeur doit être un multiple de 4.

• NODES: nombre de nœuds du pool de nœuds. La valeur minimale est 3.

• Si vous utilisez MetalLB comme équilibreur de charge, incluez éventuellement --enable-load-balancer si vous souhaitez autoriser le haut-parleur MetalLB à s'exécuter sur les nœuds du pool. MetalLB doit être activé dans au moins un pool de nœuds. Si vous n'incluez pas cet indicateur, vous devez créer un autre pool de nœuds à utiliser pour MetalLB.

Pour en savoir plus sur les indicateurs facultatifs, consultez Ajouter un pool de nœuds et 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 l'équilibreur de charge MetalLB groupé et un pool de nœuds.

Pour en savoir plus et obtenir d'autres exemples, consultez la documentation de référence sur google_gkeonprem_vmware_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/avmw_user_cluster_metallb
   

Définir des variables dans terraform.tfvars

L'exemple fournit un exemple de fichier de variables à transmettre à main.tf, qui montre comment configurer l'équilibreur de charge MetalLB groupé et permettre aux nœuds de votre cluster d'obtenir leurs adresses IP à partir d'un serveur DHCP que vous fournissez.

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

   cp terraform.tfvars.sample terraform.tfvars
   

2. Modifiez les valeurs des paramètres dans terraform.tfvars.

   anthos-onprem-terraform/avmw_user_cluster_metallb/terraform.tfvars.sample

   Afficher sur GitHub

   project_id                  = "FLEET_HOST_PROJECT_ID"
   region                      = "REGION"
   admin_cluster_name          = "ADMIN_CLUSTER_NAME"
   on_prem_version             = "VERSION"
   admin_user_emails           = ["YOUR_EMAIL_ADDRESS", "ADMIN_2_EMAIL_ADDRESS"]
   cluster_name                = "avmw-user-cluster-metallb"
   control_plane_node_cpus     = 4
   control_plane_node_memory   = 8192
   control_plane_node_replicas = 3
   control_plane_vip           = "CONTROL_PLANE_VIP"
   ingress_vip                 = "INGRESS_VIP"
   lb_address_pools            = [
       { name = "lbpool_1", addresses = ["10.200.0.51-10.200.0.70"] }
   ]
   

   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.

   • on_prem_version: version d'Anthos Clusters sur VMware pour votre cluster d'utilisateur. En règle générale, vous spécifiez la même version que le cluster d'administrateur. Pour spécifier une version ultérieure, installez une version ultérieure à la version du cluster d'administrateur. Si vous ne connaissez pas la version du cluster d'administrateur, exécutez gcloud beta container vmware clusters query-version-config. Il s'agit de la première étape de la section Installer une version ultérieure à celle du cluster d'administrateur.

   • 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 (RBAC) de Kubernetes au cluster afin d'accorder 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.

   • 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_node_cpus: nombre de processeurs virtuels pour chaque nœud de plan de contrôle pour votre cluster d'utilisateur. Le minimum est de 4 vCPU.

   • control_plane_node_memory: taille de la mémoire en mébioctets (Mio) pour chaque plan de contrôle de votre cluster d'utilisateur. La valeur minimale est 8192 et doit être un multiple de 4.

   • control_plane_node_replicas: nombre de nœuds de plan de contrôle pour votre cluster d'utilisateur. Par exemple, vous pouvez saisir un nœud de plan de contrôle pour un environnement de développement et trois nœuds pour un plan de contrôle pour les environnements de production et de haute disponibilité.

   • 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. Renseignez les champs suivants :

     • name: nom du pool.
     • addresses: plage d'adresses au format CIDR ou au format de plage avec trait d'union. Pour spécifier une seule adresse IP dans un pool (pour l'adresse IP virtuelle d'entrée, par exemple), utilisez /32 en notation CIDR, par exemple: 192.0.2.1/32.

     Remplacez les exemples d'adresses IP par vos valeurs et ajoutez des pools d'adresses supplémentaires si nécessaire.

3. Enregistrez les modifications dans terraform.tfvars. Si vous ne souhaitez apporter aucune modification facultative à main.tf, passez à la section suivante : Créer le cluster et un pool de nœuds.

Facultatif: Configurer les paramètres du cluster dans main.tf

Cette section décrit certaines modifications de configuration facultatives que vous pouvez effectuer dans main.tf. Avant d'apporter des modifications, effectuez une sauvegarde de main.tf:

cp main.tf main.tf.bak

Mode d'adressage IP du nœud de calcul

Par défaut, main.tf configure le cluster pour utiliser un serveur DHCP que vous fournissez pour attribuer les adresses IP aux nœuds de calcul du cluster. DHCP est configuré en incluant la carte dhcp_config dans le bloc network_config. Si vous souhaitez fournir des adresses IP statiques pour vos nœuds de calcul, apportez les modifications suivantes à main.tf:

1. Remplacez le bloc network_config et incluez un bloc static_ip_config. Exemple :

   network_config {
     service_address_cidr_blocks = ["10.96.0.0/12"]
     pod_address_cidr_blocks = ["192.168.0.0/16"]
     host_config {
       dns_servers = ["10.254.41.1"]
       ntp_servers = ["216.239.35.8"]
     }
     static_ip_config {
       ip_blocks {
         netmask = "255.255.252.0"
         gateway = "10.251.31.254"
         ips {
           ip = "10.251.30.153"
           hostname = "vm-1"
         }
         ips {
           ip = "10.251.31.206"
           hostname = "vm-2"
         }
         ips {
           ip = "10.251.31.193"
           hostname = "vm-3"
         }
         ips {
           ip = "10.251.30.230"
           hostname = "vm-4"
         }
       }
     }
   }
   

2. Remplacez les valeurs suivantes par vos valeurs:

   • service_address_cidr_blocks: plage d'adresses IP au format CIDR à utiliser pour les services de votre cluster. Elle doit être au moins égale à /24.

   • pod_address_cidr_blocks: plage d'adresses IP au format CIDR à utiliser pour les pods de votre cluster. Elle doit être au moins égale à /18.

   • dns_servers: liste des adresses IP des serveurs DNS pour les VM.

   • ntp_servers: liste des adresses IP des serveurs de temps que les VM doivent utiliser.

   • Dans le bloc static_ip_config, remplacez les valeurs de netmask et gateway par les adresses de votre réseau. Remplacez ip et hostname par les adresses IP et les noms d'hôte de vos nœuds de calcul.

Créer le cluster et un pool de nœuds

1. Initialisez et créez le plan Terraform :

   terraform init
   

   Terraform installe toutes les bibliothèques requises, par exemple le fournisseur Google Cloud.

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

   terraform plan
   

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

   terraform apply
   

   La création du cluster d'utilisateur prend environ 15 minutes, voire 15 minutes supplémentaires. 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 à l'aide d'un client API Anthos On-Prem, vous avez la possibilité de vous ajouter, vous et d'autres utilisateurs, en tant qu'annonceurs de cluster en spécifiant les adresses e-mail des comptes Google Cloud:

• Dans la console, votre adresse e-mail est automatiquement ajoutée sur la page Paramètres de base du cluster dans la section Autorisation. Vous avez la possibilité d'ajouter d'autres administrateurs du cluster.

• Avec gcloud CLI, incluez l'indicateur --admin-users défini sur votre adresse e-mail. L'indicateur n'a pas de liste. Ajoutez l'option --admin-users pour chaque administrateur du cluster.

• Avec l'exemple Terraform, vous pouvez vous spécifier vous-même et d'autres administrateurs dans la variable admin_user_emails du fichier terraform.tvars.sample.

Le cluster est configuré avec les stratégies de contrôle des accès basées sur les rôles (RBAC) de Kubernetes qui attribuent le rôle cluster-admin aux administrateurs et leur permettent de se connecter au cluster depuis la console à l'aide de leur identité Google Cloud. Pour en savoir plus, consultez 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. Sinon, vous pouvez utiliser la passerelle Connect. Dans ce cas, kubectl utilise Connect, qui transfère ensuite de manière sécurisée le trafic vers le point de terminaison privé en votre nom.

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é. La passerelle Connect vous permet de gérer facilement et en toute sécurité vos clusters. Pour en savoir plus, consultez la page Se connecter à des clusters enregistrés avec la passerelle Connect.

• Pour accéder directement aux points de terminaison privés, créer un fichier kubeconfig sur votre poste de travail administrateur, puis gérer le cluster depuis votre poste de travail administrateur.

Assurez-vous d'attendre que la 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 Clusters Anthos sur VMware, 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 en utilisant kubectl comme vous le feriez normalement pour tout cluster Kubernetes. Il n'est pas nécessaire de spécifier le nom du fichier kubeconfig, par exemple :

   kubectl get namespaces
   

Poste de travail administrateur

Pour créer le fichier kubeconfig du cluster d'utilisateur sur votre poste de travail administrateur, exécutez la commande suivante pour enregistrer localement un nouveau fichier kubeconfig pour le cluster d'utilisateur. Remplacez les éléments suivants :

• CLUSTER_NAME : nom du cluster d'utilisateur nouvellement créé.
• ADMIN_CLUSTER_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur.
• USER_CLUSTER_KUBECONFIG : nom du fichier kubeconfig du cluster d'utilisateur généré par la commande

kubectl get secret admin \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  -n CLUSTER_NAME \
  -o=jsonpath='{.data.admin\.conf}' | base64 -d > USER_CLUSTER_KUBECONFIG

Une fois le fichier enregistré, vous pouvez commencer à accéder au cluster d'utilisateur en utilisant kubectl sur le poste de travail administrateur, par exemple :

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get namespaces

Installer une version ultérieure à la version du cluster d'administrateur

Un cluster d'administrateur peut gérer des clusters d'utilisateur à différentes versions. Si vous souhaitez créer un cluster d'utilisateur qui est une version ultérieure au cluster d'administrateur, vous devez télécharger et déployer les composants dont le cluster d'administrateur a besoin pour gérer les clusters d'utilisateur de cette version. Pour ce faire, procédez comme suit:

1. Obtenez la liste des versions disponibles:

   gcloud beta container vmware clusters query-version-config \
       --admin-cluster-membership=ADMIN_CLUSTER_NAME \
       --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
       --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 dans laquelle l'API Anthos On-Prem s'exécute. Il s'agit de la région que vous indiquerez lorsque vous créerez le cluster d'utilisateur. Spécifiez us-west1 ou une autre région compatible.

   La sortie de la commande ressemble à ceci :

   versions:
   - isInstalled: true
     version: 1.14.3-gke.25
   - version: 1.14.4-gke.54
   - version: 1.15.0-gke.581
   

   Les versions installées sur le cluster d'administrateur sont annotées avec isInstalled=true.

2. Si vous ne l'avez pas déjà fait, enregistrez le cluster d'administrateur dans l'API Anthos On-Prem. Une fois le cluster enregistré dans l'API Anthos On-Prem, vous n'avez pas besoin de répéter cette étape.

3. Téléchargez la nouvelle version des composants et déployez-les dans le cluster d'administrateur:

   gcloud beta vmware admin-clusters update ADMIN_CLUSTER_NAME \
       --project=FLEET_HOST_PROJECT_ID \
       --location=REGION \
       --required-platform-version=VERSION
   

   Cette commande télécharge la version des composants que vous spécifiez dans --required-platform-version vers le cluster d'administrateur, puis déploie les composants. Vous pouvez maintenant créer un cluster d'utilisateur avec la version spécifiée.

Étapes suivantes

• Déployer une application
• Résoudre les problèmes de création d'un cluster d'utilisateur dans la console Cloud