Configurer une infrastructure minimale

Il s'agit de la première partie d'un guide qui vous guide tout au long d'une petite démonstration de faisabilité de l'installation de GKE sur VMware avec un cluster d'utilisateur unique.

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

L'infrastructure que vous configurez à l'aide de ce guide n'est peut-être pas adaptée à vos besoins de production et cas d'utilisation réels. Pour en savoir plus sur les installations en 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 besoins en ressources. Nous fournissons un exemple de configuration pour un hôte ESXi et un datastore vSphere conformes aux exigences de cette installation.
  2. Configurez des objets vSphere. Les composants GKE sur VMware s'exécutent dans une hiérarchie d'objets vSphere.
  3. Planifiez vos adresses IP. GKE sur VMware nécessite que vous fournissiez des adresses IP pour tous les nœuds, en plus des adresses IP virtuelles (VIP) pour autoriser l'accès administrateur et utilisateur à votre déploiement. Pour cette configuration, vous allez utiliser 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 afin qu'il vous aide à choisir les adresses appropriées pour votre propre réseau.
  4. Configurer vos 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 GKE sur VMware, et un compte de service disposant des autorisations nécessaires pour accéder et télécharger le logiciel des composants GKE sur VMware.

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 capacités minimales de processeur, de mémoire RAM et de stockage suivantes:

    • 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
    • ESXi version 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 dans votre répertoire datastore un dossier qui sera utilisé pour 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 GKE sur VMware, l'installation d'aGKE sur VMware nécessite un certain nombre d'adresses IP, y compris les suivantes:

  • Adresses IP pour tous les nœuds
  • Adresses IP virtuelles 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 GKE sur VMware consiste à planifier vos adresses IP, y compris à vous assurer que vous ne créez pas de conflits d'adressage. Même dans le cas de cette installation très simple, votre administrateur réseau pourra vous aider à trouver les valeurs à configurer. 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.

  • GKE sur VMware 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 demande d'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 s'affichent pas pour un nœud particulier dans 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. Ces nœuds supplémentaires sont nécessaires lors des mises à niveau et des mises à jour du cluster, ainsi que lors de la réparation automatique. 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 toutes deux 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

Outre les adresses IP des nœuds de votre cluster et de l'accès au déploiement, vous devez également spécifier les plages d'adresses pouvant être utilisées dans chaque cluster pour le trafic au sein du 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. Ceux-ci sont spécifiés dans le cadre de la configuration du cluster, comme vous le verrez dans la prochaine partie de ce guide.

Dans le cadre de la planification d'adresses IP, déterminez les plages CIDR que vous souhaitez utiliser pour les pods et les services. Sauf raison 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 aurez probablement besoin d'une plage CIDR des pods plus grande que celle 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 de l'une de ces plages sera traité comme faisant partie du cluster et n'atteindra 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 est traité comme du trafic au sein du cluster et n'atteint 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 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 GKE sur VMware requis, en respectant les règles de proxy et de pare-feu. Vous aurez besoin des adresses IP des nœuds du cluster que vous avez identifiées à la section précédente pour effectuer cette tâche. É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 pertinentes s'appliquent à toutes les adresses IP de chaque cluster.

5. Configurer des ressources Google Cloud

Les projets Google Cloud constituent la base permettant de créer, d'activer et d'utiliser tous les services Google Cloud, y compris ceux utilisés pour installer et gérer GKE sur VMware. Si vous ne savez pas comment utiliser des projets Google Cloud, vous trouverez beaucoup d'informations sur la page 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

La Google Cloud CLI est un outil de ligne de commande que vous pouvez utiliser pour 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 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 votre administrateur de 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 GKE sur VMware 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éer manuellement)
  • Compte de service d'accès au composant (créer manuellement)

Compte de service de journalisation d'audit

  1. Dans votre projet Google Cloud, créez un compte de service que GKE sur VMware 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 \
  --project PROJECT_ID

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

Remplacez SERVICE_ACCOUNT_EMAIL 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 GKE sur VMware 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 au composant.

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

    Remplacez SERVICE_ACCOUNT_EMAIL par l'adresse e-mail d'identification unique de votre compte de service.

  3. 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" \
    --role "roles/serviceusage.serviceUsageViewer"

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

    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:SERVICE_ACCOUNT_EMAIL" \
    --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 à GKE sur VMware 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 \
    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 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