Il s'agit de la première partie d'un guide qui vous présente une petite démonstration de faisabilité de l'installation de GKE sur VMware avec un seul cluster d'utilisateur.
Ce document explique comment configurer des environnements vSphere et Google Cloud minimaux pour cette installation et comment planifier vos adresses IP. Le deuxième document, 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 vos 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
Lisez la présentation de GKE sur VMware, qui présente le fonctionnement de GKE sur VMware, y compris le rôle de chaque composant que vous allez installer dans cette configuration.
Consultez les versions compatibles avec vSphere.
Consultez les exigences relatives aux licences vSphere. Pour cette installation minimale, une licence vSphere standard est suffisante.
Vous avez besoin d'une instance en cours d'exécution de vCenter Server.
Vous avez besoin d'un compte utilisateur vCenter avec des droits suffisants. Notez le nom d'utilisateur et le mot de passe de ce compte.
Vous devez connaître certains concepts de base de Google Cloud, comme les projets, les autorisations IAM et les comptes de service. Si ce n'est pas le cas, consultez les guides suivants pour en savoir plus:
Présentation de la procédure
Voici les principales étapes de cette configuration:
- 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 répondant aux exigences de cette installation.
- Configurez des objets vSphere. Les composants GKE sur VMware s'exécutent dans une hiérarchie d'objets vSphere.
- 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 pour l'accès administrateur et utilisateur à 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 afin qu'il vous aide à choisir des adresses adaptées à votre réseau.
- Configurer vos règles de pare-feu et de proxy
- Configurez les ressources Google Cloud, y compris un projet Google Cloud que vous utiliserez pour configurer et gérer GKE sur VMware, ainsi qu'un compte de service disposant des autorisations nécessaires pour accéder au logiciel des composants de GKE sur VMware et le télécharger.
1. Configurer votre environnement
Pour cette installation minimale, vous pouvez utiliser un seul hôte physique exécutant ESXi.
Assurez-vous que votre hôte dispose des capacités minimales de processeur, de RAM et de stockage suivantes:
- 8 processeurs physiques avec hyperthreading à 2,7 GHz activé
- 80 gibioctets (Gio) de RAM
- 470 Gio d'espace de stockage
Assurez-vous qu'ESXi version 7.0u2 ou ultérieure est installé.
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 :
Prenez note des noms de votre centre de données, cluster, datastore et réseau vSphere, car vous en aurez besoin lorsque vous configurerez 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 à utiliser 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:
- Adresses IP de 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 de ne pas créer de conflits de résolution. Vous devrez peut-être demander à votre administrateur réseau de vous aider à trouver les valeurs appropriées à configurer, même dans le cas d'une installation aussi 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.
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 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 pas affichées associées à un 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.
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 du 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 du cluster d'administrateur. | 172.16.20.59 |
| Adresse IP virtuelle d'entrée | Configuré sur l'équilibreur de charge du 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 pour les adresses ClusterIP des services Kubernetes. Ceux-ci sont spécifiés lors de la configuration du cluster, comme vous le verrez dans la prochaine partie de ce guide.
Dans le cadre de la planification de vos 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:
| Objectif | Plage CIDR par défaut |
|---|---|
| Pods du cluster d'administrateur | 192.168.0.0/16 |
| Pods du cluster d'utilisateur | 192.168.0.0/16 |
| Services du cluster d'administrateur | 10.96.232.0/24 |
| Services du cluster d'utilisateur | 10.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.
En règle générale, 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 le 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 étant intégré au cluster et n'atteindra aucune destination en dehors de celui-ci.
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 au sein du 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 qui peut ê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 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 à 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 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.
Choisissez un projet Google Cloud existant ou créez-en un.
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 qui vous permet de 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 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 du projet devez vous assurer que votre compte Google dispose des autorisations nécessaires.
Dans la deuxième partie de cette configuration, 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:
resourcemanager.projectIamAdminserviceusage.serviceUsageAdminiam.serviceAccountCreatoriam.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 CloudACCOUNT: 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. Vous devez toutefois 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 aux composants (créer manuellement)
Compte de service de journalisation d'audit
Dans votre projet Google Cloud, créez un compte de service que GKE sur VMware peut utiliser pour envoyer des journaux d'audit Kubernetes depuis votre cluster vers Cloud Audit Logs. Il s'agit du compte de service de journalisation d'audit.
gcloud iam service-accounts create audit-logging-sa \ --project PROJECT_ID
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
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 du cluster en votre nom à partir de Container Registry. Il s'agit du 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.
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.
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
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.comSi 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 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