Configurer une infrastructure minimale

Il s'agit de la première partie d'un guide qui vous explique comment effectuer une petite installation de démonstration de faisabilité de Google Distributed Cloud (logiciel uniquement) pour VMware avec un cluster d'utilisateur unique. Cette page est destinée aux administrateurs, aux architectes et aux opérateurs qui configurent, surveillent et gèrent l'infrastructure technique. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le contenu Google Cloud, consultez la section Rôles utilisateur et tâches courantes de l'utilisateur dans GKE Enterprise.

Ce document explique comment configurer des environnements vSphere et Google Cloud minimaux pour cette installation, et comment planifier vos adresses IP. L'article de suivi Créer des clusters de base vous explique comment créer un poste de travail administrateur, un cluster administrateur et un cluster utilisateur.

L'infrastructure que vous configurez à l'aide de ce guide peut ne pas convenir à vos besoins de production et cas d'utilisation réels. Pour en savoir plus sur les installations de production, consultez la présentation de l'installation et les guides.

Avant de commencer

Présentation de la procédure

Voici les principales étapes de cette configuration :

  1. Configurez votre environnement. Assurez-vous de pouvoir répondre aux exigences en termes de ressources. Nous fournissons un exemple de configuration d'un hôte ESXi et d'un datastore vSphere qui répondent aux exigences de cette installation.
  2. Configurez des objets vSphere. Les composants Google Distributed Cloud s'exécutent dans une hiérarchie d'objets vSphere.
  3. Planifiez vos adresses IP. Google Distributed Cloud vous oblige à fournir des adresses IP pour tous les nœuds, en plus des adresses IP virtuelles (VIP) pour l'accès des administrateurs et des utilisateurs à votre déploiement. Pour cette configuration, vous utiliserez des adresses IP statiques pour vos nœuds de cluster. Nous vous fournissons des exemples, mais nous vous recommandons de consulter votre administrateur réseau pour vous aider à choisir les adresses adaptées à votre propre réseau.
  4. Configurer les règles de pare-feu et de proxy
  5. Configurez les ressources Google Cloud, y compris un projet Google Cloud que vous utiliserez pour configurer et gérer Google Distributed Cloud, ainsi qu'un compte de service disposant des autorisations nécessaires pour accéder au logiciel des composants Google Distributed Cloud et le télécharger.

1. Configurer votre environnement

Pour cette installation minimale, vous pouvez utiliser un seul hôte physique exécutant ESXi.

  1. Assurez-vous que votre hôte dispose des ressources minimales suivantes en termes de processeur, de RAM et de stockage :

    • 8 processeurs physiques à 2,7 GHz avec l'hyperthreading activé
    • 80 gibioctets (Gio) de RAM
    • 470 Gio d'espace de stockage

  2. Assurez-vous que vous avez installé ESXi version 7.0u2 ou ultérieure.

  3. Assurez-vous d'utiliser vCenter Server version 7.0u2 ou ultérieure.

Exemple d'hôte et de datastore

Voici un exemple d'hôte ESXi et de datastore vSphere répondant aux exigences :

  • Configuration de l'hôte ESXi :

    • Fabricant : Dell Inc.
    • Processeurs physiques : 8 processeurs à 2,7 GHz
    • Type de processeur : Intel(R) Xeon(R) Platinum 8168 à 2,7 GHz
    • Sockets pour processeur : 2
    • Version d'ESXi : 7.0u2 ou version ultérieure
    • vCenter Server version 7.0u2 ou ultérieure
    • Hyper-Threading : activé

  • Configuration du datastore :

    • Type : VMFS 6.82
    • Type de disque : SSD
    • Fournisseur : DELL
    • Type de disque : logique
    • Niveau RAID : RAID1

2. Configurer des objets vSphere

Configurez les objets suivants dans votre environnement vSphere :

Notez les noms de votre centre de données vSphere, de votre cluster, de votre datastore et de votre réseau, car vous en aurez besoin pour configurer votre poste de travail d'administrateur dans Créer des clusters de base.

Si vous avez configuré un datastore vSAN, utilisez govc pour créer un dossier dans votre répertoire datastore à utiliser pour le disque de machine virtuelle (VMDK) de Google Distributed Cloud :

govc datastore.mkdir -namespace=true data-disks

3. Planifier vos adresses IP

Comme vous l'avez vu dans la présentation de Google Distributed Cloud, une installation Google Distributed Cloud nécessite un certain nombre d'adresses IP, y compris :

  • Adresses IP pour tous les nœuds
  • Adresses IP virtuelles (VIP) pour accéder aux composants du plan de contrôle tels que les serveurs d'API Kubernetes et aux applications exécutées sur vos clusters d'utilisateurs
  • Plages CIDR pour la communication entre les pods et les services

Par conséquent, la planification de vos adresses IP est une étape importante de la configuration de Google Distributed Cloud. Vous devez notamment vous assurer de ne pas créer de conflits d'adressage. Vous devrez peut-être demander à votre administrateur réseau de vous aider à trouver les valeurs appropriées à configurer, même pour cette installation simple. Dans la suite de cette section, nous fournissons des exemples de valeurs qui fonctionnent pour cette installation dans un réseau hypothétique. Vos valeurs seront différentes.

  • Les clusters de cette installation minimale utilisent l'équilibreur de charge MetalLB. Cet équilibreur de charge s'exécute sur les nœuds du cluster. Aucune VM supplémentaire n'est donc nécessaire pour l'équilibrage de charge.

  • Google Distributed Cloud vous permet de choisir entre fournir des adresses IP statiques pour vos nœuds de cluster ou utiliser un serveur DHCP. Dans cette installation simple, vous utiliserez des adresses IP statiques.

Exemple de VLAN

Pour cette petite installation, nous vous recommandons de placer votre poste de travail administrateur, vos nœuds de cluster d'administrateur et vos nœuds de cluster d'utilisateur sur le même VLAN de votre réseau vSphere. Par exemple, supposons que toutes les adresses IP de la plage 172.16.20.0/24 soient acheminées vers un VLAN particulier. Supposons également que votre administrateur réseau vous indique que vous pouvez utiliser 172.16.20.49 - 172.16.20.69 pour les VM et les adresses IP virtuelles.

Le schéma suivant illustre un VLAN doté d'un poste de travail d'administrateur, d'un cluster d'administrateur et d'un cluster d'utilisateur. Notez que les adresses IP virtuelles ne sont associées à aucun nœud particulier d'un cluster. En effet, l'équilibreur de charge MetalLB peut choisir le nœud qui annonce l'adresse IP virtuelle pour un service individuel. Par exemple, dans le cluster d'utilisateur, un nœud de calcul peut annoncer 172.16.20.64, et un autre nœud de calcul peut annoncer 172.16.20.65.

Adresses IP pour un cluster d'administrateur et un cluster d'utilisateur. 
Adresses IP pour un cluster d'administrateur et un cluster d'utilisateur (cliquez pour agrandir)

Exemple d'adresse IP : poste de travail administrateur

Pour le poste de travail administrateur, cet exemple utilise la première adresse de la plage fournie par votre administrateur réseau : 172.16.20.49.

Exemples d'adresses IP : nœuds de cluster

Le tableau suivant montre comment les adresses IP peuvent être utilisées pour les nœuds de cluster. Notez que le tableau affiche les adresses de deux nœuds supplémentaires : admin-vm-6 et user-vm-5. Les nœuds supplémentaires sont nécessaires lors des mises à niveau, des mises à jour et de la réparation automatique du cluster. Pour en savoir plus, consultez la page Gérer les adresses IP des nœuds.

Nom d'hôte de la VM Description Adresse IP
admin-vm-1 Nœud du plan de contrôle pour le cluster d'administrateur 172.16.20.50
admin-vm-2 Nœud du plan de contrôle pour le cluster d'administrateur 172.16.20.51
admin-vm-3 Nœud du plan de contrôle pour le cluster d'administrateur 172.16.20.52
user-vm-1 Nœud du plan de contrôle pour le cluster d'utilisateur. 172.16.20.53
user-vm-2 Nœud de calcul du cluster d'utilisateur 172.16.20.54
user-vm-3 Nœud de calcul du cluster d'utilisateur 172.16.20.55
user-vm-4 Nœud de calcul du cluster d'utilisateur 172.16.20.56
user-vm-5 172.16.20.57

Exemples d'adresses IP : adresses IP virtuelles pour le cluster d'administrateur

Le tableau suivant montre comment spécifier une adresse IP virtuelle de contrôle pour votre cluster d'administration.

VIP Description Adresse IP
Adresse IP virtuelle pour le serveur d'API Kubernetes du cluster d'administrateur Configuré sur l'équilibreur de charge pour le cluster d'administrateur. 172.16.20.58

Exemples d'adresses IP : adresses IP virtuelles pour le cluster d'utilisateur

Le tableau suivant montre comment spécifier des adresses IP virtuelles pour votre cluster d'utilisateur.

Notez que l'adresse IP virtuelle du serveur d'API Kubernetes du cluster utilisateur et l'adresse IP virtuelle d'entrée se trouvent dans le même VLAN que les nœuds de calcul et les nœuds du plan de contrôle.

VIP Description Adresse IP
Adresse IP virtuelle pour le serveur d'API Kubernetes du cluster d'utilisateur Configuré sur l'équilibreur de charge pour le cluster d'administrateur. 172.16.20.59
Adresse IP virtuelle d'entrée Configuré sur l'équilibreur de charge pour le cluster d'utilisateur. 172.16.20.60
Adresses IP virtuelles de service Dix adresses pour les services de type LoadBalancer.
Configuré si nécessaire sur l'équilibreur de charge pour le cluster d'utilisateur.
Notez que cette plage inclut l'adresse IP virtuelle d'entrée. Il s'agit d'une exigence pour l'équilibreur de charge MetalLB.		 172.16.20.60 - 172.16.20.69

Adresses IP pour les pods et les services

En plus des adresses IP des nœuds de votre cluster et de celles permettant d'accéder à votre déploiement, vous devez également spécifier les plages d'adresses pouvant être utilisées dans chaque cluster pour le trafic interne.

Pour ce faire, vous devez spécifier une plage CIDR à utiliser pour les adresses IP des pods et une autre à utiliser pour les adresses ClusterIP des services Kubernetes. Ces paramètres sont spécifiés dans la configuration du cluster, comme vous le verrez dans la prochaine partie de ce guide.

Lors de la planification de votre adresse IP, déterminez les plages CIDR que vous souhaitez utiliser pour les pods et les services. Sauf indication contraire de votre part, utilisez les plages par défaut suivantes :

ObjectifPlage CIDR par défaut
Pods du cluster d'administrateur192.168.0.0/16
Pods du cluster d'utilisateur192.168.0.0/16
Services du cluster d'administrateur10.96.232.0/24
Services du cluster d'utilisateur10.96.0.0/20

Les valeurs par défaut illustrent ces points :

  • La plage CIDR du pod peut être identique pour plusieurs clusters.

  • La plage CIDR de service d'un cluster ne doit pas chevaucher la plage CIDR de service d'un autre cluster.

  • Généralement, vous avez besoin de plus de pods que de services. Par conséquent, pour un cluster donné, vous souhaiterez probablement une plage CIDR de pods plus grande que la plage CIDR de service. Par exemple, la plage de pods par défaut pour un cluster d'utilisateur comporte 2^(32-16) = 2^16 adresses, mais la plage de services par défaut pour un cluster d'utilisateur ne comporte que 2^(32-20) = 2^12 adresses.

Éviter le chevauchement

Dans certains cas, vous pouvez utiliser des plages CIDR autres que celles par défaut pour éviter le chevauchement des adresses IP accessibles sur votre réseau. Les plages de services et de pods ne doivent chevaucher aucune adresse en dehors du cluster que vous souhaitez atteindre depuis l'intérieur du cluster.

Par exemple, supposons que votre plage de services soit 10.96.232.0/24 et que votre plage de pods soit 192.168.0.0/16. Tout trafic envoyé depuis un pod vers une adresse dans l'une de ces plages est traité comme étant dans un cluster et n'atteint aucune destination en dehors du cluster.

En particulier, les plages de services et de pods ne doivent pas chevaucher les éléments suivants :

  • Adresses IP des nœuds d'un cluster

  • Adresses IP utilisées par les machines des équilibreurs de charge

  • Adresses IP virtuelles utilisées par les nœuds de plan de contrôle et les équilibreurs de charge

  • Adresse IP des serveurs vCenter, DNS et NTP

Nous vous recommandons d'utiliser les plages d'adresses IP internes définies par la RFC 1918 pour vos plages de pods et de services.

Voici l'une des raisons pour lesquelles il est recommandé d'utiliser les adresses RFC 1918 Supposons que votre plage de services et de pods contienne des adresses IP externes. Tout trafic envoyé depuis un pod vers l'une de ces adresses externes sera traité comme du trafic interne au cluster et n'atteindra pas la destination externe.

Serveur DNS et passerelle par défaut

Avant de créer vos clusters d'utilisateur et d'administrateur, vous devez aussi connaître les adresses IP des éléments suivants :

  • Un serveur DNS pouvant être utilisé par votre poste de travail administrateur et vos nœuds de cluster

  • Un serveur NTP pouvant être utilisé par vos nœuds de cluster

  • L'adresse IP de la passerelle par défaut pour le sous-réseau contenant votre poste de travail d'administrateur et vos nœuds de cluster Par exemple, supposons que votre poste de travail d'administrateur, vos nœuds de cluster d'administrateur et vos nœuds de cluster d'utilisateur se trouvent tous dans le sous-réseau 172.16.20.0/24. L'adresse de la passerelle par défaut pour le sous-réseau peut être 172.16.20.1.

4. Configurer le pare-feu et le proxy

Configurez votre pare-feu et votre proxy pour autoriser le trafic Google Distributed Cloud nécessaire, conformément aux règles de proxy et de pare-feu. Pour effectuer cette tâche, vous aurez besoin des adresses IP des nœuds de cluster que vous avez identifiées dans la section précédente. Notez que, comme les adresses IP des clusters utilisateur et administrateur ne sont pas attribuées à des nœuds spécifiques, vous devez vous assurer que toutes les règles de pare-feu pertinentes s'appliquent à toutes les adresses IP de chaque cluster.

5. Configurer des ressources Google Cloud

Les projets Google Cloud constituent la base de la création, de l'activation et de l'utilisation de tous les services Google Cloud, y compris ceux utilisés pour installer et gérer Google Distributed Cloud. Si vous ne savez pas comment utiliser les projets Google Cloud, consultez Créer et gérer des projets.

  1. Choisissez un projet Google Cloud existant ou créez-en un.

  2. Notez l'ID du projet Google Cloud, car vous en aurez besoin ultérieurement.

Configurer Google Cloud CLI

Google Cloud CLI est un outil de ligne de commande que vous pouvez utiliser pour travailler avec votre projet. Suivez les instructions de la section Installer le SDK Google Cloud pour vous assurer que vous disposez de la version la plus récente.

Autorisations requises

Si vous êtes le propriétaire du projet (par exemple, si vous l'avez créé vous-même), vous disposez déjà de toutes les autorisations nécessaires pour effectuer le reste de cette installation simple. Si vous n'êtes pas le propriétaire du projet, vous ou l'administrateur de votre projet devez vous assurer que votre compte Google dispose des autorisations nécessaires.

Les rôles IAM suivants vous permettent de créer un compte de service, de lui attribuer des rôles IAM, d'activer des API et de vous assurer que l'outil gkeadm peut créer et gérer des comptes de service pour vous dans la deuxième partie de cette configuration :

  • resourcemanager.projectIamAdmin
  • serviceusage.serviceUsageAdmin
  • iam.serviceAccountCreator
  • iam.serviceAccountKeyAdmin

Pour en savoir plus sur les autorisations requises pour attribuer vous-même des rôles IAM, consultez la section Accorder, modifier et révoquer l'accès à des ressources. Si vous ne disposez pas de ces autorisations, un autre membre de votre organisation doit vous attribuer les rôles.

Pour accorder les rôles, procédez comme suit :

Linux et macOS

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="user:ACCOUNT" \
    --role="roles/resourcemanager.projectIamAdmin"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="user:ACCOUNT" \
    --role="roles/serviceusage.serviceUsageAdmin"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="user:ACCOUNT" \
    --role="roles/iam.serviceAccountCreator"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="user:ACCOUNT" \
    --role="roles/iam.serviceAccountKeyAdmin"

Windows

gcloud projects add-iam-policy-binding PROJECT_ID ^
    --member="user:ACCOUNT" ^
    --role="roles/resourcemanager.projectIamAdmin"

gcloud projects add-iam-policy-binding PROJECT_ID ^
    --member="user:ACCOUNT" ^
    --role="roles/serviceusage.serviceUsageAdmin"

gcloud projects add-iam-policy-binding PROJECT_ID ^
    --member="user:ACCOUNT" ^
    --role="roles/iam.serviceAccountCreator"

gcloud projects add-iam-policy-binding PROJECT_ID ^
    --member="user:ACCOUNT" ^
    --role="roles/iam.serviceAccountKeyAdmin"

Remplacez les éléments suivants :

  • PROJECT_ID : ID de votre projet Google Cloud
  • ACCOUNT : adresse e-mail d'identification de votre compte Google

Configurer des comptes de service

Votre projet Google Cloud doit disposer de quatre comptes de service pour que Google Distributed Cloud puisse l'utiliser. Dans cet exercice, deux de ces comptes de service sont générés automatiquement. Toutefois, vous devez créer les deux autres comptes de service manuellement :

  • Compte de service de connexion-enregistrement (généré automatiquement)
  • Compte de service de journalisation-surveillance (généré automatiquement)
  • Compte de service de journalisation d'audit (créé manuellement)
  • Compte de service d'accès aux composants (créé manuellement)

Compte de service de journalisation d'audit

  1. Dans votre projet Google Cloud, créez un compte de service que Google Distributed Cloud peut utiliser pour envoyer les journaux d'audit Kubernetes de votre cluster vers Cloud Audit Logs. Il s'agit de votre compte de service de journalisation d'audit.

    gcloud iam service-accounts create audit-logging-sa \
    --display-name "Audit Logging Service Account" \
    --project PROJECT_ID

    Remplacez PROJECT_ID par l'ID de votre projet Google Cloud.

  2. Obtenez l'adresse e-mail du compte de service de journalisation d'audit nouvellement créé :

    gcloud iam service-accounts list \
    --project PROJECT_ID

  3. Créez une clé JSON pour votre compte de service de journalisation d'audit :

    gcloud iam service-accounts keys create audit-logging-key.json \
    --iam-account SERVICE_ACCOUNT_EMAIL_AUDIT_LOGGING

    Remplacez SERVICE_ACCOUNT_EMAIL_AUDIT_LOGGING par l'adresse e-mail de votre compte de service de journalisation d'audit.

    Vous n'avez pas besoin d'accorder de rôles à votre compte de service de journalisation d'audit.

Compte de service d'accès au composant

  1. Dans votre projet Google Cloud, créez un compte de service que Google Distributed Cloud peut utiliser pour télécharger le code du composant de cluster en votre nom à partir de Container Registry. Il s'agit de votre compte de service d'accès aux composants.

    gcloud iam service-accounts create component-access-sa \
    --display-name "Component Access Service Account" \
    --project PROJECT_ID

    Remplacez PROJECT_ID par l'ID de votre projet Google Cloud.

  2. Obtenez l'adresse e-mail du compte de service d'accès aux composants nouvellement créé :

    gcloud iam service-accounts list \
    --project PROJECT_ID

  3. Pour créer une clé JSON pour votre compte de service d'accès aux composants, procédez comme suit :

    gcloud iam service-accounts keys create component-access-key.json \
   --iam-account SERVICE_ACCOUNT_EMAIL_COMPONENT_ACCESS

    Remplacez SERVICE_ACCOUNT_EMAIL_COMPONENT_ACCESS par l'adresse e-mail de votre compte de service d'accès aux composants.

  4. Ajoutez les rôles IAM suivants à votre compte de service d'accès aux composants :

    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:SERVICE_ACCOUNT_EMAIL_COMPONENT_ACCESS" \
    --role "roles/serviceusage.serviceUsageViewer"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:SERVICE_ACCOUNT_EMAIL_COMPONENT_ACCESS" \
    --role "roles/iam.roleViewer"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:SERVICE_ACCOUNT_EMAIL_COMPONENT_ACCESS" \
    --role "roles/iam.serviceAccountViewer"

Activer les API Google

  1. Activez les API Google suivantes dans votre projet Google Cloud. Vous pouvez ainsi utiliser tous les services Google Cloud requis par Google Distributed Cloud dans votre projet.

    gcloud services enable --project PROJECT_ID \
    anthos.googleapis.com \
    anthosgke.googleapis.com \
    anthosaudit.googleapis.com \
    cloudresourcemanager.googleapis.com \
    connectgateway.googleapis.com \
    container.googleapis.com \
    gkeconnect.googleapis.com \
    gkehub.googleapis.com \
    gkeonprem.googleapis.com \
    kubernetesmetadata.googleapis.com \
    serviceusage.googleapis.com \
    stackdriver.googleapis.com \
    opsconfigmonitoring.googleapis.com \
    monitoring.googleapis.com \
    logging.googleapis.com \
    iam.googleapis.com \
    storage.googleapis.com

  2. Si c'est la première fois que vous activez l'API GKE On-Prem (gkeonprem.googleapis.com) dans votre projet, vous devez initialiser l'API. Pour ce faire, appelez une commande de la gcloud CLI qui affiche les versions disponibles que vous pouvez utiliser pour créer un cluster d'utilisateurs :

    gcloud container vmware clusters query-version-config \
    --project=PROJECT_ID \
    --location="us-central1"

    Étape suivante

Créer des clusters de base