Configurer une infrastructure minimale

Ce guide est la première partie d'un guide qui présente une petite démonstration de faisabilité de l'installation de Google Distributed Cloud avec un cluster d'utilisateur unique.

Ce document explique comment configurer les environnements vSphere et Google Cloud minimaux pour cette installation et planifier vos adresses IP. Dans la suite de la section Créer des clusters de base, vous découvrirez comment créer un poste de travail administrateur, un cluster d'administrateur et un cluster d'utilisateur.

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

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 besoins en ressources. Nous fournissons un exemple de configuration pour un hôte ESXi et 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. Avec Google Distributed Cloud, vous devez fournir des adresses IP pour tous les nœuds, en plus des adresses IP virtuelles (VIP) pour l'accès administrateur et utilisateur à votre déploiement. Dans cette configuration, vous allez utiliser des adresses IP statiques pour vos nœuds de cluster. Nous fournissons des exemples, mais nous vous recommandons de consulter votre administrateur réseau pour vous aider à choisir les adresses appropriées pour votre propre réseau.
  4. Configurer vos règles de pare-feu et de proxy
  5. Configurez des 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 aux logiciels des composants Google Distributed Cloud et les 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 du processeur, de la RAM et de la capacité de stockage minimaux suivants:

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

  2. Assurez-vous qu'ESXi version 7.0u2 ou ultérieure est installé.

  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 ESXi: 7.0u2 ou ultérieure
    • Version de vCenter Server: 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, cluster, datastore et réseau vSphere, car vous en aurez besoin pour configurer votre poste de travail 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 sur le disque de machine virtuelle (VMDK) de GKE sur VMware :

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 les suivantes:

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

C'est pourquoi une partie importante de la configuration de Google Distributed Cloud consiste à planifier vos adresses IP et à s'assurer que vous ne créez pas de conflits d'adressage. Votre administrateur réseau devra peut-être vous aider à trouver les valeurs appropriées à configurer, même pour cette installation simple. Dans le reste de cette section, nous fournissons des exemples de valeurs qui fonctionnent pour cette installation dans un réseau fictif. Vos valeurs seront différentes.

  • Les clusters de cette installation minimale utilisent l'équilibreur de charge MetalLB groupé. 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 allez utiliser 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 autorise à utiliser les plages 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 qui vous a été 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 la table 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: adresse IP virtuelle pour le cluster d'administrateur

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

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 d'utilisateur et l'adresse IP virtuelle d'entrée se trouvent sur 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

Outre les adresses IP de vos nœuds de cluster et pour 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 au cluster.

Pour ce faire, spécifiez une plage CIDR à utiliser pour les adresses IP des pods, et une autre plage CIDR à utiliser pour les adresses ClusterIP des services Kubernetes. Celles-ci sont spécifiées lors de la configuration du cluster, comme vous le verrez dans la prochaine partie de ce guide.

Dans le cadre de la planification des adresses IP, déterminez les plages CIDR que vous souhaitez utiliser pour les pods et les services. Sauf indication contraire, 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 des pods plus grande que la plage CIDR des services. 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 devrez peut-être utiliser des plages CIDR autres que celles par défaut pour éviter tout chevauchement avec 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 figurant dans l'une de ces plages est traité comme au sein du 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'administrateur et d'utilisateur, vous devez également 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 les nœuds de votre 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, en respectant les 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. Étant donné que les adresses IP des clusters d'utilisateur et d'administrateur ne sont pas attribuées à des nœuds spécifiques, vous devez vous assurer que toutes les règles de pare-feu applicables s'appliquent à toutes les adresses IP de chaque cluster.

5. Configurer des ressources Google Cloud

Les projets Google Cloud constituent une base pour la création, l'activation et 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 travailler avec des projets Google Cloud, vous trouverez davantage d'informations dans la section Créer et gérer des projets.

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

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

Configurer Google Cloud CLI

La Google Cloud CLI est un outil de ligne de commande que vous pouvez utiliser pour travailler sur votre projet. Suivez les instructions de la section Installer Google Cloud SDK 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 avez créé le projet 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 du 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 à votre place 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 page Accorder, modifier et révoquer les accès à des ressources. Si vous ne disposez pas de ces autorisations, un autre membre de votre organisation doit les attribuer à votre place.

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 permettant d'identifier votre compte Google

Configurer des comptes de service

Votre projet Google Cloud doit disposer de quatre comptes de service que Google Distributed Cloud peut 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 Connect-register (généré automatiquement)
  • Compte de service Logging-monitoring (généré automatiquement)
  • Compte de service de journalisation d'audit (création manuelle)
  • Compte de service d'accès aux composants (création manuelle)

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 depuis votre cluster vers Cloud Audit Logging. 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 que vous venez de créer:

    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'attribuer 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 des composants 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 au composant que vous venez de créer:

    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 au composant.

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

    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. Cela vous permet d'utiliser tous les services Google Cloud nécessaires à 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 vous activez l'API GKE On-Prem (gkeonprem.googleapis.com) pour la première fois 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'utilisateur:

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

    Étapes suivantes

Créer des clusters de base