Cette page explique comment installer GKE On-Prem dans un environnement VMware vSphere 6.5 ou 6.7 Update 3 à l'aide d'adresses IP statiques. Vous pouvez également l'installer à l'aide d'un serveur DHCP.
Présentation
Les instructions de cette page vous expliquent comment créer un cluster d'administrateur et un cluster d'utilisateur avec trois nœuds. Après avoir créé les clusters, vous pouvez créer des clusters d'utilisateur supplémentaires et ajouter ou supprimer des nœuds dans un cluster d'utilisateur.
Avant de commencer
Configurez votre environnement comme décrit dans les rubriques suivantes :
Créez un poste de travail administrateur dans vSphere.
Découvrez comment activer l'équilibrage de charge manuel si vous souhaitez l'utiliser.
Connectez-vous en SSH à votre poste de travail administrateur :
ssh -i ~/.ssh/vsphere_workstation ubuntu@[IP_ADDRESS]
-
Si vous êtes protégé par un proxy, toutes les commandes
gkectl
utilisent automatiquement le même proxy que celui défini dans votreconfig.yaml
pour les requêtes Internet provenant du poste de travail administrateur. Il s'agit de l'environnement recommandé, dans lequel votre poste de travail administrateur et tous vos clusters utilisent le même proxy. Dans ce cas d'utilisation, vous n'avez pas besoin de définir de variables d'environnement proxy.Options de proxy manuel : si votre poste de travail administrateur n'est pas situé derrière le même proxy, vous devez configurer manuellement votre environnement pour qu'il ait accès à Internet. Vous pouvez définir la variable d'environnement
HTTPS_PROXY
pour qu'elle relaie par proxy toutes les requêtesHTTPS
, y compris vos commandesgkectl
, mais vous devez également configurer la variable d'environnementNO_PROXY
pour toutes les requêtes que vous souhaitez exclure du proxy.Si vous devez également exécuter individuellement les commandes
gcloud
etgsutil
, vous pouvez configurer Google Cloud CLI de manière à toujours utiliser un proxy spécifique. Pour obtenir des instructions, consultez la page Configurer gcloud CLI pour une utilisation derrière un proxy/pare-feu.Utilisez les options suivantes pour définir manuellement un proxy pour vos commandes
gkectl
:- Toutes les commandes
gkectl
:Vous pouvez utiliser les variables d'environnement
HTTPS_PROXY
etNO_PROXY
pour définir manuellement la manière dont toutes vos commandesgkectl
sont transmises par proxy :- Définissez un proxy différent pour vos commandes
gkectl
. Exemple :HTTPS_PROXY="http://my.other.proxy" NO_PROXY="10.0.1.0/24,private-registry.example,10.0.2.1"
- Excluez vos commandes
gkectl
du proxy. Exemple :HTTPS_PROXY=""
export HTTP_PROXY="http://[PROXY_ADDRESS]" export HTTPS_PROXY="http://[PROXY_ADDRESS]" export NO_PROXY="[NO_PROXY_ADDRESSES]"
Où :
- [PROXY_ADDRESS] peut être vide (
""
), une adresse IP de proxy ou le nom d'hôte du proxy. - [NO_PROXY_ADDRESSES] peut être une liste d'URL, d'adresses IP ou de noms d'hôte séparés par une virgule que vous souhaitez exclure du proxy.
- Définissez un proxy différent pour vos commandes
- Commandes
gkectl
uniques :Vous pouvez également ajouter la variable d'environnement en tant que préfixe à une commande
gkectl
individuelle pour utiliser un proxy spécifié uniquement pour cet appel.Exemples :
Pour relayer vos commandes
gkectl
via un proxy différent de celui spécifié dans votre fichier de configuration (config.yaml
), utilisez la variable d'environnementHTTPS_PROXY
:- Pour utiliser le proxy
http://my.other.proxy
:-
HTTPS_PROXY="http://my.other.proxy" gkectl create cluster --config config.yaml
-
HTTPS_PROXY="http://my.other.proxy" gkectl prepare --config config.yaml
-
- Utilisez une valeur vide pour exclure un proxy :
HTTPS_PROXY="" gkectl create cluster --config config.yaml
HTTPS_PROXY="" gkectl check-config --config config.yaml
- Pour utiliser le proxy
- Toutes les commandes
Connectez-vous à Google Cloud à l'aide des identifiants de votre compte utilisateur Google Cloud. Le compte utilisateur doit détenir au moins le rôle IAM de lecteur :
gcloud auth login
Définir un projet par défaut La définition d'un projet Google Cloud par défaut entraîne l'exécution de toutes les commandes de gcloud CLI sur le projet. Vous n'avez ainsi pas besoin de spécifier votre projet pour chaque commande :
gcloud config set project [PROJECT_ID]
Remplacez
[PROJECT_ID]
par votre ID de projet. (Vous trouverez l'ID de votre projet dans la console Google Cloud ou en exécutantgcloud config get-value project
.)
Choisir un registre d'image de conteneur pour l'installation
Pour l'installation, GKE On-Prem doit savoir d'où extraire ses composants de cluster en conteneur. Deux possibilités s'offrent à vous :
Container Registry
Par défaut, GKE On-Prem utilise un registre d'images de conteneur existant appartenant à Google et hébergé par Container Registry.
Hormis la configuration de votre proxy pour autoriser le trafic provenant de gcr.io
, aucune configuration supplémentaire n'est nécessaire.
Registre Docker privé
Vous pouvez choisir d'utiliser un registre Docker privé pour l'installation. GKE On-Prem transfère ses composants de cluster vers ce registre Docker. Pour spécifier un registre Docker privé, définissez le champ privateregistryconfig
.
Configurer un registre Docker privé pour l'installation (facultatif)
Cette section explique comment configurer un registre Docker existant pour installer GKE On-Prem. Pour savoir comment créer un registre Docker, consultez la section Run an externally-accessible registry (Exécuter un registre accessible en externe).
Après avoir configuré le registre, renseignez le champ privateregistryconfig
du fichier de configuration GKE On-Prem.
Si vous souhaitez utiliser votre registre Docker privé pour l'installation, la VM de votre poste de travail administrateur doit approuver l'autorité de certification qui a signé votre certificat. GKE On-Prem n'est pas compatible avec les registres Docker non sécurisés. Lorsque vous démarrez votre registre Docker, vous devez fournir un certificat et une clé. Le certificat peut être signé par une autorité de certification publique ou peut être autosigné.
Pour établir cette relation de confiance, procédez comme suit à partir de la VM de votre poste de travail administrateur :
Créez un dossier pour conserver le certificat :
sudo mkdir -p /etc/docker/certs.d/[REGISTRY_SERVER]
où [REGISTRY_SERVER] est l'adresse IP ou le nom d'hôte de la VM qui exécute votre registre Docker.
Copiez le fichier de certificat dans
/etc/docker/certs.d/[REGISTRY_SERVER]/ca.crt
. Vous devez nommer le fichierca.crt
, même si son nom était différent à l'origine.Redémarrez le service Docker :
sudo service docker restart
Vérifiez que vous pouvez vous connecter à Docker :
docker login -u [USERNAME] -p [PASSWORD] [REGISTRY_SERVER]
où [USERNAME] et [PASSWORD] sont les identifiants de connexion au registre Docker.
Désormais, lorsque vous exécutez gkectl prepare
pendant l'installation, les images nécessaires à l'installation sont transférées vers votre registre Docker.
Résoudre les problèmes de configuration du registre
GET https://[REGISTRY_SERVER]/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
: assurez-vous d'avoir la bonne adresse IP pour la VM qui exécute votre registre Docker.login attempt to https://[REGISTRY_SERVER]/v2/ failed with status: 401 Unauthorized
: assurez-vous que votre nom d'utilisateur et votre mot de passe sont corrects.GET https://[REGISTRY_SERVER]/v1/users/: x509: certificate signed by unknown authority
: la VM de votre poste de travail administrateur ne fait pas confiance au certificat.
Configurer des adresses IP statiques
Si vous souhaitez utiliser des adresses IP statiques, vous devez créer deux fichiers de configuration d'hôte : un pour votre cluster d'administrateur et un autre pour votre cluster d'utilisateur. Les fichiers de configuration d'hôte indiquent à GKE On-Prem les adresses IP et les noms d'hôte à attribuer à vos nœuds de cluster.
Adresses IP statiques pour le cluster d'administrateur
Le cluster d'administrateur a besoin d'adresses pour les nœuds suivants :
- Un nœud pour le plan de contrôle du cluster d'administrateur
- Deux nœuds pour les modules complémentaires dans le cluster d'administrateur
- Un nœud temporaire occasionnel lors de la mise à niveau du cluster d'administrateur
- Pour chaque cluster d'utilisateur associé, un ou trois nœuds
Pour un cluster d'utilisateur à haute disponibilité, le cluster d'administrateur dispose de trois nœuds qui exécutent les composants du plan de contrôle pour le cluster d'utilisateur. Pour un cluster d'utilisateur standard, le cluster d'administrateur dispose d'un nœud qui exécute les composants du plan de contrôle pour le cluster d'utilisateur.
Supposons que N représente le nombre de clusters d'utilisateur standards que vous avez l'intention de créer et H le nombre de clusters d'utilisateur à haute disponibilité que vous avez l'intention de créer. Dans le fichier de configuration d'hôte de votre cluster d'administrateur, vous devez alors spécifier au moins cette quantité d'adresses IP :
4 + N + 3 x H
Supposons, par exemple, que vous ayez l'intention de créer un cluster d'administrateur et un cluster d'utilisateur à haute disponibilité. Vous devez alors réserver sept adresses IP pour votre cluster d'administrateur. Voici un exemple de fichier de configuration d'hôte d'administrateur qui spécifie sept adresses IP :
hostconfig: dns: 172.16.255.1 tod: 216.239.35.0 otherdns: - 8.8.8.8 - 8.8.4.4 othertod: - ntp.ubuntu.com blocks: - netmask: 255.255.252.0 gateway: 172.16.23.254 ips: - ip: 172.16.20.10 hostname: admin-host1 - ip: 172.16.20.11 hostname: admin-host2 - ip: 172.16.20.12 hostname: admin-host3 - ip: 172.16.20.13 hostname: admin-host4 - ip: 172.16.20.14 hostname: admin-host5 - ip: 172.16.20.15 hostname: admin-host6 - ip: 172.16.20.16 hostname: admin-host7
Comme vous pouvez le voir dans l'exemple précédent, un fichier de configuration d'hôte contient une structure de données YAML.
Le champ ips
est un tableau d'adresses IP et de noms d'hôte. Il s'agit des adresses IP et des noms d'hôte que GKE On-Prem va affecter à vos nœuds de cluster d'administrateur.
Dans le fichier de configuration de l'hôte, spécifiez également les adresses des serveurs DNS, des serveurs de temps et de la passerelle par défaut que les nœuds du cluster d'administrateur utiliseront.
Adresses IP statiques pour un cluster d'utilisateur
Un cluster d'utilisateur a besoin d'une adresse IP pour chaque nœud et d'une adresse IP supplémentaire à utiliser pour un nœud temporaire lors d'une mise à niveau du cluster d'utilisateur.
Supposons, par exemple, que vous ayez l'intention de créer un cluster d'utilisateur doté de cinq nœuds. Vous devez alors réserver six adresses IP pour votre cluster d'utilisateur. Voici un exemple de fichier de configuration d'hôte d'utilisateur qui spécifie six paires IP/nom d'hôte.
hostconfig: dns: 172.16.255.1 tod: 216.239.35.0 otherdns: - 8.8.8.8 - 8.8.4.4 othertod: - ntp.ubuntu.com blocks: - netmask: 255.255.252.0 gateway: 172.16.23.254 ips: - ip: 172.16.20.17 hostname: user-host1 - ip: 172.16.20.18 hostname: user-host2 - ip: 172.16.20.19 hostname: user-host3 - ip: 172.16.20.20 hostname: user-host4 - ip: 172.16.20.21 hostname: user-host5 - ip: 172.16.20.22 hostname: user-host6
Chaque hostname
est interprété comme un nom d'hôte local sans son domaine. Si vous spécifiez un nom de domaine complet, le domaine est tronqué. Par exemple, host1.enterprise.net
devient host1
. La valeur d'un champ hostname
doit être en minuscules.
Créer des clés privées de comptes de service sur votre poste de travail administrateur
Dans la section Préparer l'installation, vous avez créé quatre comptes de service. À présent, vous devez créer un fichier de clé privée JSON pour chacun de ces comptes de service. Vous devrez fournir ces clés lors de l'installation.
Répertorier les adresses e-mail des comptes de service
Commencez par répertorier les comptes de service dans votre projet Google Cloud :
gcloud iam service-accounts list
Pour un projet Google Cloud nommé my-gcp-project
, le résultat de cette commande se présente comme suit :
gcloud iam service-accounts list ... EMAIL allowlisted-service-account@my-gcp-project.iam.gserviceaccount.com connect-register-service-account@my-gcp-project.iam.gserviceaccount.com connect-agent-service-account@my-gcp-project.iam.gserviceaccount.com log-mon-service-account@my-gcp-project.iam.gserviceaccount.com
Notez l'adresse e-mail de chaque compte. Pour chacune des sections suivantes, indiquez l'adresse e-mail du compte concerné.
Compte de service sur liste d'autorisation
gcloud iam service-accounts keys create whitelisted-key.json --iam-account [ALLOWLISTED_SERVICE_ACCOUNT_EMAIL]
où [ALLOWLISTED_SERVICE_ACCOUNT_EMAIL] est l'adresse e-mail du compte de service sur liste d'autorisation.
Compte de service d'enregistrement
gcloud iam service-accounts keys create register-key.json \ --iam-account [REGISTER_SERVICE_ACCOUNT_EMAIL]
où [REGISTER_SERVICE_ACCOUNT_EMAIL] est l'adresse e-mail du compte de service d'enregistrement.
Compte de service de connexion
gcloud iam service-accounts keys create connect-key.json \ --iam-account [CONNECT_SERVICE_ACCOUNT_EMAIL]
où [CONNECT_SERVICE_ACCOUNT_EMAIL] est l'adresse e-mail du compte de service de connexion.
Compte de service Cloud Monitoring
gcloud iam service-accounts keys create stackdriver-key.json \ --iam-account [STACKDRIVER_SERVICE_ACCOUNT_EMAIL]
où [STACKDRIVER_SERVICE_ACCOUNT_EMAIL] est l'adresse e-mail du compte de service Cloud Monitoring.
Générer un fichier de configuration
Pour démarrer une installation, vous devez exécuter gkectl create-config
afin de générer un fichier de configuration. Vous devez modifier le fichier en fonction des spécifications de votre environnement et des spécifications du cluster que vous souhaitez.
Pour générer le fichier, exécutez la commande suivante, où --config [PATH]
est facultatif et accepte un chemin d'accès et un nom pour le fichier de configuration. Si vous omettez --config
, config.yaml
est créé dans le répertoire de travail actuel :
gkectl create-config [--config [PATH]]
Modifier le fichier de configuration
Maintenant que vous avez généré le fichier de configuration, vous devez le modifier pour l'adapter à votre environnement et pour répondre à vos attentes concernant vos clusters. Les sections suivantes décrivent chaque champ, les valeurs attendues et l'emplacement des informations. Certains champs sont commentés par défaut. Si l'un de ces champs est pertinent pour votre installation, annulez la mise en commentaire et fournissez des valeurs.
Les instructions de cette section expliquent comment créer un cluster d'administrateur et un cluster d'utilisateur à l'aide d'une seule commande. À partir de la version 1.2, vous pouvez créer vos clusters d'administrateur et d'utilisateur séparément.
bundlepath
Le fichier de groupe GKE On-Prem contient tous les composants d'une version particulière de GKE On-Prem.
Lorsque vous créez un poste de travail administrateur, il contient un groupe complet dans /var/lib/gke/bundles/gke-onprem-vsphere-[VERSION]-full.tgz
. La version de ce groupe correspond à celle de l'OVA que vous avez importée pour créer le poste de travail administrateur.
Définissez la valeur de bundlepath
sur le chemin d'accès du fichier de groupe de votre poste de travail administrateur. Autrement dit, définissez bundlepath
sur :
/var/lib/gke/bundles/gke-onprem-vsphere-[VERSION]-full.tgz
où [VERSION] est la version de GKE On-Prem que vous installez. La dernière version est 1.3.2-gke.1.
Notez que vous êtes libre de conserver votre fichier de groupe à un autre emplacement ou de lui attribuer un autre nom. Assurez-vous simplement que dans votre fichier de configuration, la valeur de bundlepath
correspond au chemin d'accès de votre fichier de groupe, quel qu'il soit.
Spécification vCenter
La spécification vcenter
contient des informations sur votre instance vCenter Server.
GKE On-Prem a besoin de ces informations pour communiquer avec votre serveur vCenter.
vcenter.credentials.address
Le champ vcenter.credentials.address
contient l'adresse IP ou le nom d'hôte de votre serveur vCenter.
Avant de remplir le champ vsphere.credentials.address field
, téléchargez et inspectez le certificat de diffusion de votre serveur vCenter. Saisissez la commande suivante pour télécharger le certificat et l'enregistrer dans un fichier nommé vcenter.pem
.
true | openssl s_client -connect [VCENTER_IP]:443 -showcerts 2>/dev/null | sed -ne '/-BEGIN/,/-END/p' > vcenter.pem
Ouvrez le fichier de certificat pour afficher le nom commun d'objet et le nom alternatif d'objet :
openssl x509 -in vcenter.pem -text -noout
Le résultat indique le nom commun (CN) d'objet (Subject
). Il peut s'agir d'une adresse IP ou d'un nom d'hôte. Exemple :
Subject: ... CN = 203.0.113.100
Subject: ... CN = my-host.my-domain.example
Le résultat peut également inclure un ou plusieurs noms DNS sous Subject Alternative Name
:
X509v3 Subject Alternative Name: DNS:vcenter.my-domain.example
Choisissez le nom commun Subject
ou l'un des noms DNS sous Subject Alternative Name
pour l'utiliser comme valeur du champ vcenter.credentials.address
dans votre fichier de configuration. Exemple :
vcenter: credentials: address: "203.0.113.1" ...
vcenter: credentials: address: "my-host.my-domain.example" ...
Vous devez choisir une valeur qui apparaît dans le certificat. Par exemple, si l'adresse IP n'apparaît pas dans le certificat, vous ne pouvez pas l'utiliser pour vcenter.credentials.address
.
vcenter.credentials
GKE On-Prem doit connaître le nom d'utilisateur et le mot de passe de votre serveur vCenter. Pour fournir ces informations, définissez les valeurs username
et password
sous vcenter.credentials
. Exemple :
vcenter: credentials: ... username: "my-name" password: "my-password"
vcenter.datacenter, .datastore, .cluster, .network
GKE On-Prem a besoin d'informations sur la structure de votre environnement vSphere. Définissez les valeurs sous vcenter
pour fournir ces informations.
Exemple :
vcenter: ... datacenter: "MY-DATACENTER" datastore: "MY-DATASTORE" cluster: "MY-VSPHERE-CLUSTER" network: "MY-VIRTUAL-NETWORK"
vcenter.resourcepool
Un pool de ressources vSphere est un regroupement logique de machines virtuelles vSphere dans votre cluster vSphere. Si vous utilisez un pool de ressources différent de celui par défaut, indiquez son nom à vcenter.resourcepool
. Exemple :
vcenter: ... resourcepool: "my-pool"
Si vous souhaitez que GKE On-Prem déploie ses nœuds dans le pool de ressources par défaut du cluster vSphere, fournissez une chaîne vide à vcenter.resourcepool
. Exemple :
vcenter: ... resourcepool: ""
vcenter.datadisk
GKE On-Prem crée un disque de machine virtuelle (VMDK) afin d'y stocker les données de l'objet Kubernetes pour le cluster d'administrateur. Le programme d'installation crée le VMDK, mais vous devez lui attribuer un nom dans le champ vcenter.datadisk
.
Exemple :
vcenter: ... datadisk: "my-disk.vmdk"
- Datastore vSAN : créer un dossier pour le VMDK
Si vous utilisez un datastore vSAN, vous devez placer le VMDK dans un dossier. Vous devez créer le dossier manuellement à l'avance. Pour ce faire, vous pouvez utiliser
govc
:govc datastore.mkdir -namespace=true my-gke-on-prem-folder
Définissez ensuite
vcenter.datadisk
sur le chemin d'accès du VMDK, en y incluant le nom du dossier. Exemple :vcenter: ... datadisk: "my-gke-on-prem-folder/my-disk.vmdk"
Dans les versions 1.1.1 et antérieures, un problème connu nécessite que vous fournissiez le chemin UUID (Universally Unique Identifier) du dossier, et non le chemin du fichier, à
vcenter.datadisk
. Copiez ces informations à partir de la sortie de la commandegovc
ci-dessus.Indiquez ensuite l'UUID du dossier dans le champ
vcenter.datadisk
. Ne placez pas de barre oblique devant l'UUID. Exemple :vcenter: ... datadisk: "14159b5d-4265-a2ba-386b-246e9690c588/my-disk.vmdk"
Ce problème a été résolu à partir de la version 1.1.2.
vcenter.cacertpath
Lorsqu'un client, tel que GKE On-Prem, envoie une requête au serveur vCenter, celui-ci doit prouver son identité au client en présentant un certificat ou un groupe de certificats. Pour valider le certificat ou le groupe, le certificat racine doit se trouver dans la chaîne de confiance de GKE On-Prem.
Définissez vcenter.cacertpath
sur le chemin d'accès du certificat racine. Exemple :
vcenter: ... cacertpath: "/my-cert-folder/the-root.crt"
Votre installation VMware comporte une autorité de certification qui émet un certificat sur votre serveur vCenter. Le certificat racine de la chaîne de confiance est un certificat autosigné créé par VMware.
Si vous ne souhaitez pas utiliser l'autorité de certification VMWare, qui est définie par défaut, vous pouvez configurer VMware de sorte à utiliser une autre autorité de certification.
Si votre serveur vCenter utilise un certificat émis par l'autorité de certification VMware par défaut, vous pouvez obtenir le certificat racine de plusieurs manières :
curl -k "https://[SERVER_ADDRESS]/certs/download.zip" > download.zip
où [SERVER_ADDRESS] est l'adresse de votre serveur vCenter.
Dans un navigateur, saisissez l'adresse de votre serveur vCenter. Dans la zone grisée située à droite, cliquez sur le bouton pour télécharger les certificats racines des autorités de certification de confiance.
Saisissez cette commande pour obtenir le certificat de diffusion :
true | openssl s_client -connect [SERVER_ADDRESS]:443 -showcerts
Dans le résultat, recherchez une URL semblable à celle-ci : https://[SERVER_ADDRESS]/afd/vecs/ca. Saisissez l'URL dans un navigateur. Le certificat racine est alors téléchargé.
Le fichier téléchargé est nommé downloads.zip
.
Décompressez le fichier.
unzip downloads.zip
Si la commande de décompression ne fonctionne pas au premier essai, saisissez à nouveau la commande.
Recherchez le fichier de certificat dans certs/lin
.
Spécification du proxy
Si votre réseau se trouve derrière un serveur proxy, remplissez le champ proxy
avec le proxy HTTPS et les adresses à exclure de la transmission via proxy. Exemple :
proxy: url: "https://username:password@domain" noproxy: "10.0.1.0/24,private-registry.example,10.0.2.1"
proxy.url
est l'URL du proxy HTTPS.proxy.noproxy
inclut les plages CIDR, les adresses IP, les domaines et les noms d'hôte qui ne doivent pas être transmis par proxy. Par exemple, les appels aux adresses IP des nœuds de cluster ne doivent pas être transmis par proxy. Ainsi, si votre sous-réseau ne contient que des nœuds de cluster, vous pouvez indiquer la plage CIDR du sous-réseau dans le champnoproxy
. Notez que siprivateregistryconfig
est spécifié, cette adresse est automatiquement ajoutée pour empêcher les appels vers votre registre privé.
Spécification du cluster d'administrateur
La spécification admincluster
contient les informations dont GKE On-Prem a besoin pour créer le cluster d'administrateur.
admincluster.vcenter.network
Dans admincluster.vcenter.network
, vous pouvez spécifier un réseau vCenter pour vos nœuds de cluster d'administrateur. Notez que cette action remplace le paramètre général que vous avez fourni dans vcenter
. Exemple :
admincluster: vcenter: network: MY-ADMIN-CLUSTER-NETWORK
admincluster.ipblockfilepath
Étant donné que vous utilisez des adresses IP statiques, vous devez disposer d'un fichier de configuration d'hôte comme décrit dans la section Configurer des adresses IP statiques. Indiquez le chemin d'accès de votre fichier de configuration d'hôte dans le champ admincluster.ipblockfilepath
. Exemple :
admincluster: ipblockfilepath: "/my-config-folder/my-admin-hostconfig.yaml"
admincluster.manuallbspec (manual load balancing mode)
Le contrôleur d'entrée du cluster d'administrateur est mis en œuvre en tant que service de type NodePort.
Ce service dispose d'un ServicePort pour HTTP et d'un autre ServicePort pour HTTPS. Si vous utilisez le mode d'équilibrage de charge manuel, vous devez sélectionner des valeurs nodePort
pour ces ports de service.
Spécifiez les valeurs de nodePort
dans ingresshttpnodeport
et ingresshttpsnodeport
. Exemple :
admincluster: ... manuallbspec: ingresshttpnodeport: 32527 ingresshttpsnodeport: 30139
Le serveur d'API Kubernetes du cluster d'administrateur est mis en œuvre en tant que service de type NodePort
. Si vous utilisez l'équilibrage de charge manuel, vous devez choisir une valeur nodePort
pour le service. Spécifiez la valeur nodePort
dans controlplanenodeport
. Exemple :
admincluster: ... manuallbspec: ... controlplanenodeport: 30968
Le serveur de modules complémentaires du cluster d'administrateur est mis en œuvre en tant que service de type NodePort
. Si vous utilisez l'équilibrage de charge manuel, vous devez choisir une valeur nodePort
pour le service. Spécifiez la valeur nodePort
dans controlplanenodeport
. Exemple :
admincluster: manuallbspec: ... addonsnodeport: 30562
admincluster.bigip.credentials (mode d'équilibrage de charge intégré)
Si vous n'utilisez pas le mode d'équilibrage de charge intégré, laissez admincluster.bigip
commenté.
Si vous utilisez le mode d'équilibrage de charge intégré, GKE On-Prem doit connaître l'adresse IP ou le nom d'hôte, le nom d'utilisateur et le mot de passe de votre équilibreur de charge F5 BIG-IP. Définissez les valeurs sous admincluster.bigip
pour fournir ces informations.
Exemple :
admincluster: ... bigip: credentials: address: "203.0.113.2" username: "my-admin-f5-name" password: "rJDlm^%7aOzw"
admincluster.bigip.partition (mode d'équilibrage de charge intégré)
Si vous utilisez le mode d'équilibrage de charge intégré, vous devez créer une partition BIG-IP pour votre cluster d'administrateur. Définissez admincluster.bigip.partition
sur le nom de votre partition. Exemple :
admincluster: ... bigip: partition: "my-admin-f5-partition"
admincluster.vips
Que vous utilisiez l'équilibrage de charge intégré ou manuel pour le cluster d'administrateur, vous devez renseigner le champ admincluster.vips
.
Définissez la valeur de admincluster.vips.controlplanevip
sur l'adresse IP que vous avez choisi de configurer sur l'équilibreur de charge pour le serveur d'API Kubernetes du cluster d'administrateur. Définissez la valeur de ingressvip
sur l'adresse IP que vous avez choisi de configurer sur l'équilibreur de charge pour le contrôleur d'entrée du cluster d'administrateur. Exemple :
admincluster: ... vips: controlplanevip: 203.0.113.3 ingressvip: 203.0.113.4
admincluster.serviceiprange et admincluster.podiprange
Le cluster d'administrateur doit disposer d'une plage d'adresses IP à utiliser pour les services et d'une plage d'adresses IP à utiliser pour les pods. Ces plages sont spécifiées par les champs admincluster.serviceiprange
et admincluster.podiprange
. Ces champs sont remplis lorsque vous exécutez gkectl create-config
. Si vous le souhaitez, vous pouvez remplacer les valeurs renseignées par celles de votre choix.
Les plages de services et de pods ne doivent pas se chevaucher. En outre, les plages de services et de pods ne doivent pas chevaucher les adresses IP utilisées pour les nœuds d'un cluster.
Exemple :
admincluster: ... serviceiprange: 10.96.232.0/24 podiprange: 192.168.0.0/16
Spécification du cluster d'utilisateur
La spécification du cluster d'utilisateur, usercluster
, contient les informations dont GKE On-Prem a besoin pour créer le cluster d'utilisateur initial.
Désactiver les règles anti-affinité VMware DRS (facultatif)
GKE On-Prem crée automatiquement des règles anti-affinités VMware DRS (Distributed Resource Scheduler) 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.
Cette fonctionnalité nécessite que votre environnement vSphere remplisse les conditions suivantes :
- La fonctionnalité VMware DRS est activée. VMware DRS nécessite l'édition de licence vSphere Enterprise Plus. Pour en savoir plus sur l'activation de DRS, consultez l'article Enabling VMware DRS in a cluster (Activer VMware DRS dans un cluster).
- Le compte utilisateur vSphere fourni dans le champ
vcenter
dispose de l'autorisationHost.Inventory.EditCluster
. - Au moins trois hôtes physiques sont disponibles.
Rappelez-vous que si vous disposez d'une licence vSphere standard, vous ne pouvez pas activer VMware DRS.
Si vous n'avez pas activé DRS ou si vous n'avez pas au moins trois hôtes sur lesquels les VM vSphere peuvent être planifiées, ajoutez usercluster.antiaffinitygroups.enabled: false
à votre fichier de configuration.
Exemple :
usercluster: ... antiaffinitygroups: enabled: false
Pour en savoir plus, consultez les notes de version pour la version 1.1.0-gke.6.
- Pour les clusters exécutant plus de trois nœuds
- Si vSphere vMotion déplace un nœud vers un autre hôte, les charges de travail du nœud doivent être redémarrées avant d'être à nouveau réparties entre les hôtes.
usercluster.vcenter.network
Dans usercluster.vcenter.network
, vous pouvez spécifier un réseau vCenter pour vos nœuds de cluster d'utilisateur. Notez que cette action remplace le paramètre général que vous avez fourni dans vcenter
. Exemple :
usercluster: vcenter: network: MY-USER-CLUSTER-NETWORK
usercluster.ipblockfilepath
Étant donné que vous utilisez des adresses IP statiques, vous devez disposer d'un fichier de configuration d'hôte comme décrit dans la section Configurer des adresses IP statiques.
Indiquez le chemin d'accès de votre fichier de configuration d'hôte dans le champ usercluster.ipblockfilepath
. Exemple :
usercluster: ipblockfilepath: "/my-config-folder/my-user-hostconfig.yaml"
usercluster.manuallbspec
(mode d'équilibrage de charge manuel)
Le contrôleur d'entrée du cluster d'utilisateur est mis en œuvre en tant que service de type NodePort.
Le service dispose d'un port de service (ServicePort) pour HTTP et d'un autre pour HTTPS. Si vous utilisez le mode d'équilibrage de charge manuel, vous devez sélectionner des valeurs nodePort
pour ces ports de service.
Spécifiez les valeurs de nodePort
dans ingresshttpnodeport
et ingresshttpsnodeport
. Exemple :
usercluster: manuallbspec: ingresshttpnodeport: 30243 ingresshttpsnodeport: 30879
Le serveur d'API Kubernetes du cluster d'utilisateur est mis en œuvre en tant que service de type NodePort
. Si vous utilisez l'équilibrage de charge manuel, vous devez choisir une valeur nodePort
pour le service. Spécifiez la valeur nodePort
dans controlplanenodeport
. Exemple :
usercluster: ... manuallbspec: ... controlplanenodeport: 30562
usercluster.bigip.credentials
(mode d'équilibrage de charge intégré)
Si vous utilisez le mode d'équilibrage de charge intégré, GKE On-Prem doit connaître l'adresse IP ou le nom d'hôte, le nom d'utilisateur et le mot de passe de l'équilibreur de charge F5 BIG-IP que vous souhaitez utiliser pour le cluster d'utilisateur. Définissez les valeurs sous usercluster.bigip
pour fournir ces informations.
Exemple :
usercluster: ... bigip: credentials: address: "203.0.113.5" username: "my-user-f5-name" password: "8%jfQATKO$#z" ...
usercluster.bigip.partition
(mode d'équilibrage de charge intégré)
Si vous utilisez le mode d'équilibrage de charge intégré, vous devez créer une partition BIG-IP pour votre cluster d'utilisateur. Définissez usercluster.bigip.partition
sur le nom de votre partition. Exemple :
usercluster: ... bigip: partition: "my-user-f5-partition" ...
usercluster.vips
Que vous utilisiez l'équilibrage de charge intégré ou manuel pour le cluster d'utilisateur, vous devez renseigner le champ usercluster.vips
.
Définissez la valeur de usercluster.vips.controlplanevip
sur l'adresse IP que vous avez choisi de configurer sur l'équilibreur de charge pour le serveur d'API Kubernetes du cluster d'utilisateur. Définissez la valeur de ingressvip
sur l'adresse IP que vous avez choisi de configurer sur l'équilibreur de charge pour le contrôleur d'entrée du cluster d'utilisateur. Exemple :
usercluster: ... vips: controlplanevip: 203.0.113.6 ingressvip: 203.0.113.7
usercluster.serviceiprange
et usercluster.podiprange
Le cluster d'utilisateur doit disposer d'une plage d'adresses IP à utiliser pour les services et d'une plage d'adresses IP à utiliser pour les pods. Ces plages sont spécifiées par les champs usercluster.serviceiprange
et usercluster.podiprange
. Ces champs sont remplis lorsque vous exécutez gkectl create-config
. Si vous le souhaitez, vous pouvez remplacer les valeurs renseignées par celles de votre choix.
Les plages de services et de pods ne doivent pas se chevaucher. En outre, les plages de services et de pods ne doivent pas chevaucher les adresses IP utilisées pour les nœuds d'un cluster.
Exemple :
usercluster: ... serviceiprange: 10.96.233.0/24 podiprange: 172.16.0.0/12
usercluster.clustername
Définissez la valeur de usercluster.clustername
sur le nom de votre choix. Choisissez un nom ne comportant pas plus de 40 caractères. Exemple :
usercluster: ... clustername: "my-user-cluster-1"
usercluster.masternode.replicas
Le champ usercluster.masternode.replicas
spécifie le nombre de nœuds de plan de contrôle que le cluster d'utilisateur doit avoir. Le nœud de plan de contrôle d'un cluster d'utilisateur exécute le plan de contrôle d'utilisateur, à savoir les composants du plan de contrôle Kubernetes. Cette valeur doit être 1
ou 3
:
- Définissez ce champ sur
1
pour exécuter un plan de contrôle d'utilisateur. - Définissez ce champ sur
3
si vous souhaitez disposer d'un plan de contrôle d'utilisateur à haute disponibilité, composé de trois nœuds de plan de contrôle exécutant chacun un plan de contrôle d'utilisateur.
usercluster.masternode.cpus
et usercluster.masternode.memorymb
Les champs usercluster.masternode.cpus
et usercluster.masternode.memorymb
spécifient le nombre de processeurs et la quantité de mémoire, en mégaoctets, alloués à chaque nœud de plan de contrôle du cluster d'utilisateur. Exemple :
usercluster: ... masternode: cpus: 4 memorymb: 8192
usercluster.workernode.replicas
Le champ usercluster.workernode.replicas
spécifie le nombre de nœuds de calcul que le cluster d'utilisateur doit avoir. Les nœuds de calcul exécutent les charges de travail du cluster.
usercluster.workernode.cpus
et usercluster.workernode.memorymb
Les champs usercluster.masternode.cpus
et usercluster.masternode.memorymb
spécifient le nombre de processeurs et la quantité de mémoire, en mégaoctets, alloués à chaque nœud de calcul du cluster d'utilisateur. Exemple :
usercluster: ... workernode: cpus: 4 memorymb: 8192 replicas: 3
usercluster.oidc
Si vous souhaitez que les clients du cluster d'utilisateur utilisent l'authentification OIDC, définissez des valeurs pour les champs sous usercluster.oidc
. La configuration d'OIDC est facultative.
Pour savoir comment configurer OIDC, consultez la page sur l'authentification avec OIDC.
- À propos de l'installation de la version 1.0.2-gke.3
La version 1.0.2-gke.3 introduit les champs OIDC suivants (
usercluster.oidc
), qui champs permettent de se connecter à un cluster à partir de la console Google Cloud :- usercluster.oidc.kubectlredirecturl
- usercluster.oidc.clientsecret
- usercluster.oidc.usehttpproxy
Dans la version 1.0.2-gke.3, si vous souhaitez utiliser OIDC, le champ
clientsecret
est obligatoire même si vous ne souhaitez pas vous connecter à un cluster depuis la console Google Cloud. Dans ce cas, vous pouvez fournir une valeur d'espace réservé pourclientsecret
:oidc: clientsecret: "secret"
usercluster.sni
L'indication de nom de serveur (Server Name Indication, SNI) qui est une extension de TLS, permet aux serveurs de présenter plusieurs certificats sur une seule adresse IP et un seul port TCP, selon le nom d'hôte indiqué par le client.
Si votre autorité de certification est déjà distribuée en tant qu'autorité de certification de confiance à des clients extérieurs à votre cluster d'utilisateur et que vous souhaitez utiliser cette chaîne pour identifier les clusters de confiance, vous pouvez configurer le serveur d'API Kubernetes avec un certificat supplémentaire de l'adresse IP de l'équilibreur de charge qui est présenté aux clients externes.
Pour utiliser la SNI avec vos clusters d'utilisateur, vous devez posséder votre propre autorité de certification et votre propre infrastructure à clé publique (Public Key Infrastructure, PKI). Vous provisionnez un certificat de diffusion distinct pour chaque cluster d'utilisateur, et GKE On-Prem ajoute chaque certificat de diffusion supplémentaire à son cluster d'utilisateur respectif.
Pour configurer la SNI pour le serveur d'API Kubernetes du cluster d'utilisateur, indiquez les valeurs de usercluster.sni.certpath
(chemin d'accès au certificat externe) et de usercluster.sni.keypath
(chemin d'accès au fichier de clé privée du certificat externe).
Exemple :
usercluster: ... sni: certpath: "/my-cert-folder/example.com.crt" keypath: "/my-cert-folder/example.com.key"
lbmode
Vous pouvez utiliser l'équilibrage de charge intégré ou l'équilibrage de charge manuel. Le choix du mode d'équilibrage de charge s'applique à votre cluster d'administrateur et à votre cluster d'utilisateur initial. Il s'applique également aux clusters d'utilisateur supplémentaires que vous créerez ultérieurement.
Spécifiez votre choix d'équilibrage de charge en définissant la valeur de lbmode
sur Integrated
ou Manual
. Exemple :
lbmode: Integrated
gkeconnect
La spécification gkeconnect
contient les informations dont GKE On-Prem a besoin pour configurer la gestion de vos clusters sur site à partir de Google Cloud Console.
Définissez gkeconnect.projectid
sur l'ID du projet Google Cloud dans lequel vous souhaitez gérer vos clusters sur site.
Définissez la valeur de gkeconnect.registerserviceaccountkeypath
sur le chemin d'accès du fichier de clé JSON pour votre compte de service d'enregistrement.
Définissez la valeur de gkeconnect.agentserviceaccountkeypath
sur le chemin d'accès du fichier de clé JSON pour votre compte de service de connexion.
Exemple :
gkeconnect: projectid: "my-project" registerserviceaccountkeypath: "/my-key-folder/register-key.json" agentserviceaccountkeypath: "/my-key-folder/connect-key.json"
stackdriver
La spécification stackdriver
contient les informations dont GKE On-Prem a besoin pour stocker les entrées de journal générées par vos clusters sur site.
Définissez stackdriver.projectid
sur l'ID du projet Google Cloud dans lequel vous souhaitez afficher les journaux Stackdriver relatifs à vos clusters sur site.
Définissez stackdriver.clusterlocation
sur une région Google Cloud où vous souhaitez stocker les journaux Stackdriver. Nous vous recommandons de choisir une région à proximité de votre centre de données sur site.
Définissez stackdriver.enablevpc
sur true
si le réseau de votre cluster est contrôlé par un VPC. Ainsi, toute la télémétrie passe par les adresses IP restreintes de Google.
Définissez stackdriver.serviceaccountkeypath
sur le chemin d'accès du fichier de clé JSON pour votre compte de service Stackdriver Logging.
Exemple :
stackdriver: projectid: "my-project" clusterlocation: "us-west1" enablevpc: false serviceaccountkeypath: "/my-key-folder/stackdriver-key.json"
privateregistryconfig
Si vous disposez d'un registre Docker privé, le champ privateregistryconfig
contient des informations utilisées par GKE On-Prem pour transférer des images vers votre registre privé. Si vous ne spécifiez pas de registre privé, gkectl
extrait les images de conteneur de GKE On-Prem à partir de son dépôt Container Registry (gcr.io/gke-on-prem-release
) lors de l'installation.
Sous privatedockerregistry.credentials
, définissez address
sur l'adresse IP de la machine qui exécute votre registre Docker privé. Définissez username
et password
sur le nom d'utilisateur et le mot de passe de votre registre Docker privé. La valeur que vous définissez pour address
est automatiquement ajoutée à proxy.noproxy
.
Lorsque Docker extrait une image de votre registre privé, celui-ci doit prouver son identité en présentant un certificat. Le certificat du registre est signé par une autorité de certification (CA). Docker utilise le certificat de l'autorité de certification pour valider le certificat du registre.
Définissez privateregistryconfig.cacertpath
sur le chemin d'accès du certificat de l'autorité de certification. Exemple :
privateregistryconfig ... cacertpath: /my-cert-folder/registry-ca.crt
gcrkeypath
Définissez la valeur de gcrkeypath
sur le chemin d'accès du fichier de clé JSON pour votre compte de service sur liste d'autorisation.
Exemple :
gcrkeypath: "/my-key-folder/whitelisted-key.json"
cloudauditlogging
Si vous souhaitez envoyer vos journaux d'audit Kubernetes à votre projet Google Cloud, remplissez la spécification cloudauditlogging
. Exemple :
cloudauditlogging: projectid: "my-project" # A GCP region where you would like to store audit logs for this cluster. clusterlocation: "us-west1" # The absolute or relative path to the key file for a GCP service account used to # send audit logs from the cluster serviceaccountkeypath: "/my-key-folder/audit-logging-key.json"
Découvrez comment utiliser les journaux d'audit.
Valider le fichier de configuration
Effectuez cette étape depuis votre poste de travail administrateur.
Après avoir modifié le fichier de configuration, exécutez gkectl check-config
pour vérifier que le fichier est valide et peut être utilisé pour l'installation :
gkectl check-config --config [PATH_TO_CONFIG] --fast
Si la commande renvoie des messages FAILURE
, corrigez les problèmes et vérifiez à nouveau le fichier. Utilisez l'option --fast
pour ignorer les vérifications qui créent des VM de test, ce qui dépend de l'image de l'OS du nœud importée du poste de travail administrateur vers vCenter par gkectl prepare
.
Ignorer les validations
Les commandes gkectl
suivantes exécutent automatiquement des validations sur votre fichier de configuration :
gkectl prepare
gkectl create cluster
gkectl upgrade
Pour ignorer les validations d'une commande, transmettez --skip-validation-all
. Par exemple, pour ignorer toutes les validations pour gkectl prepare
, utilisez :
gkectl prepare --config [PATH_TO_CONFIG] --skip-validation-all
Pour afficher toutes les options disponibles permettant d'ignorer des validations spécifiques, utilisez :
gkectl check-config --help
Exécuter gkectl prepare
Avant l'installation vous devez exécuter gkectl prepare
sur votre poste de travail administrateur pour initialiser votre environnement vSphere. La commande gkectl prepare
effectue les tâches suivantes :
Importation de l'image de l'OS du nœud dans vSphere et la marque comme modèle.
Transfert des images GKE On-Prem vers votre registre, si vous utilisez un registre Docker privé.
Validation éventuelle des attestations de version des images de conteneur, vérifiant ainsi que les images ont été conçues et signées par Google, et sont prêtes pour le déploiement.
Exécutez gkectl prepare
avec le fichier de configuration GKE On-Prem, où --validate-attestations
est facultatif :
gkectl prepare --config [CONFIG_FILE] --validate-attestations
La sortie positive de --validate-attestations
est Image [IMAGE_NAME] validated
.
Valider à nouveau le fichier de configuration
Après avoir importé l'image de l'OS du nœud en exécutant gkectl prepare
, exécutez gkectl check-config
sans l'option --fast
, afin que les contrôles supplémentaires créant des VM de test puissent être exécutés.
gkectl check-config --config [PATH_TO_CONFIG]
Si la commande renvoie des messages FAILURE
, corrigez les problèmes et validez à nouveau le fichier.
Installer GKE On-Prem
Vous avez créé un fichier de configuration qui spécifie l'apparence de votre environnement et l'apparence que vous souhaitez donner à vos clusters, et vous avez validé le fichier. Vous avez exécuté gkectl prepare
pour initialiser votre environnement avec le logiciel GKE On-Prem. Vous êtes maintenant prêt à lancer une nouvelle installation de GKE On-Prem.
Pour installer GKE On-Prem, vous devez créer les clusters d'administrateur et d'utilisateur. Les étapes suivantes permettent de créer le cluster d'administrateur et le cluster d'utilisateur au cours du même processus. Si vous souhaitez créer chaque cluster séparément, consultez la section Créer des clusters d'administrateur et d'utilisateur séparément pour plus d'informations.
Pour créer les clusters d'administrateur et d'utilisateur, procédez comme suit :
Créez le cluster d'administrateur et le cluster d'utilisateur en exécutant la commande
gkectl create cluster
.gkectl create cluster --config [CONFIG_FILE]
où [CONFIG_FILE] est le fichier de configuration que vous avez créé précédemment.
La commande
gkectl create cluster
crée les fichierskubeconfig
nommés[CLUSTER_NAME]-kubeconfig
dans le répertoire actuel, où [CLUSTER_NAME] est le nom que vous avez défini pourcluster
. Example :MY-VSPHERE-CLUSTER-kubeconfig
La documentation GKE On-Prem utilise les espaces réservés suivants pour faire référence à ces fichiers
kubeconfig
:- Cluster d'administrateur : [ADMIN_CLUSTER_KUBECONFIG]
- Cluster d'utilisateur : [USER_CLUSTER_KUBECONFIG]
Vérifiez que les clusters sont créés et en cours d'exécution.
Pour le cluster d'administrateur, exécutez la commande suivante :
kubectl get nodes --kubeconfig [ADMIN_CLUSTER_KUBECONFIG]
Le résultat affiche les nœuds du cluster d'administrateur.
Pour le cluster d'utilisateur, exécutez la commande suivante :
kubectl get nodes --kubeconfig [USER_CLUSTER_KUBECONFIG]
Le résultat affiche les nœuds du cluster d'utilisateur. Exemple :
NAME STATUS ROLES AGE VERSION xxxxxx-1234-ipam-15008527 Ready <none> 12m v1.14.7-gke.24 xxxxxx-1234-ipam-1500852a Ready <none> 12m v1.14.7-gke.24 xxxxxx-1234-ipam-15008536 Ready <none> 12m v1.14.7-gke.24
Apprenez à réutiliser le fichier de configuration pour créer des clusters d'utilisateur supplémentaires.
Reprendre une installation
Si votre installation est interrompue après la création du cluster d'administrateur, vous pouvez reprendre la procédure en procédant comme suit :
- Supprimez la spécification
admincluster
du fichier de configuration. Exécutez
gkectl create cluster
avec les options--kubeconfig
et--skip-validation-all
pour transmettre le fichier kubeconfig du cluster d'administrateur et ignorer les vérifications préliminaires :gkectl create cluster \ --config [CONFIG_FILE] \ --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \ --skip-validation-all
où [ADMIN_CLUSTER_NAME] est le fichier kubeconfig du cluster d'administrateur, qui a été créé dans le répertoire de travail lorsque vous avez démarré l'installation.
Associer des clusters à Google
Lorsque vous remplissez la spécification
gkeconnect
, votre cluster d'utilisateur est automatiquement enregistré dans la console Google Cloud. Vous pouvez afficher un cluster GKE On-Prem enregistré dans le menu Clusters Kubernetes de la console Google Cloud. Vous pouvez ensuite vous connecter au cluster pour afficher ses charges de travail.Si votre cluster ne s'affiche pas dans la console Google Cloud dans l'heure qui suit sa création, consultez la page de dépannage des problèmes de connexion.
Activer l'entrée
Une fois votre cluster d'utilisateur en cours d'exécution, vous devez activer l'entrée en créant un objet Gateway. La première partie du fichier manifeste Gateway est toujours la suivante :
apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: istio-autogenerated-k8s-ingress namespace: gke-system spec: selector: istio: ingress-gke-system
Vous pouvez personnaliser le reste du fichier manifeste en fonction de vos besoins. Par exemple, ce fichier manifeste indique que les clients peuvent envoyer des requêtes sur le port 80 à l'aide du protocole HTTP/2 et de tout nom d'hôte :
apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: istio-autogenerated-k8s-ingress namespace: gke-system spec: selector: istio: ingress-gke-system servers: - port: number: 80 protocol: HTTP2 name: http hosts: - "*"
Si vous souhaitez accepter les requêtes HTTPS, vous devez fournir un ou plusieurs certificats que votre contrôleur d'entrée peut présenter aux clients.
Pour fournir un certificat, procédez comme suit :
- Créez un secret contenant votre certificat et votre clé.
- Créez un objet Gateway ou modifiez un objet Gateway existant qui fait référence à votre secret. Le nom de l'objet Gateway doit être
istio-autogenerated-k8s-ingress
.
Par exemple, supposons que vous ayez déjà créé un fichier de certificat, ingress-wildcard.crt
, et un fichier de clé, ingress-wildcard.key
.
Créez un secret nommé ingressgateway-wildcard-certs
:
kubectl create secret tls \ --namespace gke-system \ ingressgateway-wildcard-certs \ --cert ./ingress-wildcard.crt \ --key ./ingress-wildcard.key
Voici un fichier manifeste pour un objet Gateway qui fait référence à votre secret. Les clients peuvent appeler le port 443 via le protocole HTTPS et tout nom d'hôte correspondant à *.example.com. Notez que le nom d'hôte dans le certificat doit correspondre au nom d'hôte dans le fichier manifeste, *.example.com dans cet exemple :
apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: istio-autogenerated-k8s-ingress namespace: gke-system spec: selector: istio: ingress-gke-system servers: - port: number: 80 protocol: HTTP2 name: http hosts: - "*" - hosts: - "*.example.com" port: name: https-demo-wildcard number: 443 protocol: HTTPS tls: mode: SIMPLE credentialName: ingressgateway-wildcard-certs
Vous pouvez créer plusieurs certificats TLS pour différents hôtes en modifiant votre fichier manifeste Gateway.
Enregistrez votre fichier manifeste dans un fichier nommé my-gateway.yaml
et créez l'objet Gateway :
kubectl apply -f my-gateway.yaml
Vous pouvez désormais utiliser les objets Ingress Kubernetes de manière standard.
Créer des clusters d'administrateur et d'utilisateur séparément
À partir de la version 1.2 de GKE On-Prem, vous pouvez créer vos clusters d'administrateur et d'utilisateur séparément. Autrement dit, vous pouvez commencer par créer un cluster d'administrateur, puis créer un ou plusieurs clusters d'utilisateur selon vos besoins.
Avant la version 1.2 :
Votre premier cluster d'utilisateur utilisait toujours le datastore du cluster d'administrateur. Les clusters d'utilisateur créés par la suite pouvaient utiliser un datastore distinct de celui du cluster d'administrateur.
Si vous définissiez un datastore distinct pour un cluster d'utilisateur, les nœuds de calcul de ce cluster et les volumes persistants (PersistentVolumes, PV) de ces nœuds utilisaient le datastore distinct. Toutefois, les VM du plan de contrôle d'utilisateur et les PV associés utilisaient le datastore du cluster d'administrateur.
À partir de la version 1.2 :
Tout cluster d'utilisateur, même le premier que vous utilisez, peut utiliser un datastore distinct de celui du cluster d'administrateur.
Si vous spécifiez un datastore distinct pour un cluster d'utilisateur, les nœuds de calcul du cluster, les PV pour les nœuds de travail du cluster, les VM du plan de contrôle d'utilisateur et les PV pour les VM du plan de contrôle d'utilisateur utilisent tous le datastore distinct.
Pour créer uniquement un cluster d'administrateur, supprimez l'intégralité de la section usercluster
du fichier de configuration du cluster. Saisissez ensuite la commande gkectl create
:
gkectl create --config [ADMIN_CONFIG_FILE]
où [ADMIN_CONFIG_FILE] est le chemin d'accès de votre fichier de configuration dans lequel la section usercluster
a été supprimée.
Ensuite, créez un fichier de configuration dans lequel l'intégralité de la section admincluster
a été supprimée. Dans ce fichier, vous pouvez spécifier un datastore vSphere différent du datastore du cluster d'administrateur. Pour spécifier un datastore, saisissez une valeur pour vcenter.credentials.datastore
. Exemple :
vcenter: credentials: ... ... datastore: "my-user-cluster-datastore"
Pour créer un cluster d'utilisateur, saisissez la commande suivante :
gkectl create --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] --config [USER_CLUSTER_CONFIG]
où :
- [ADMIN_CLUSTER_KUBECONFIG] est le fichier kubeconfig de votre cluster d'administrateur ;
- [USER_CLUSTER_CONFIG] est le fichier de configuration pour votre cluster d'utilisateur.
Limites de GKE On-Prem
Limite | Description |
---|---|
Limites maximale et minimale pour les clusters et les nœuds | Consultez la page Quotas et limites pour en savoir plus. Les performances de votre environnement peuvent avoir un impact sur ces limites. |
Unicité pour les noms de cluster d'utilisateur | Tous les clusters d'utilisateur enregistrés dans le même projet Google Cloud doivent avoir des noms uniques. |
Impossibilité de déployer sur plusieurs centres de données vCenter et/ou vSphere | Actuellement, vous ne pouvez déployer qu'un cluster d'administrateur et un ensemble de clusters d'utilisateur associés sur un seul centre de données vCenter ou vSphere. Vous ne pouvez pas déployer les mêmes clusters d'administrateur et d'utilisateur sur plusieurs centres de données vCenter ou vSphere. |
Impossible de modifier de manière déclarative les configurations de cluster après la création | Bien que vous puissiez créer des clusters supplémentaires et redimensionner des clusters existants, vous ne pouvez pas modifier un cluster existant via son fichier de configuration. |
Dépannage
Pour en savoir plus, consultez la section Dépannage.
Diagnostiquer des problèmes de cluster à l'aide de gkectl
Utilisez les commandes gkectl diagnose
pour identifier les problèmes de cluster et partager des informations de cluster avec Google. Consultez la page Diagnostiquer les problèmes de cluster.
Exécuter des commandes gkectl
de manière détaillée
-v5
Consigner des erreurs gkectl
dans stderr
--alsologtostderr
Localiser les journaux gkectl
sur le poste de travail administrateur
Même si vous ne transmettez pas ses options de débogage, vous pouvez afficher les journaux gkectl
dans le répertoire du poste de travail administrateur suivant :
/home/ubuntu/.config/gke-on-prem/logs
Localiser des journaux de l'API Cluster dans le cluster d'administrateur
Si une VM ne démarre pas après le démarrage du plan de contrôle d'administrateur, vous pouvez essayer de la déboguer en inspectant les journaux des contrôleurs de l'API Cluster dans le cluster d'administrateur :
Recherchez le nom du pod des contrôleurs d'API Cluster dans l'espace de noms
kube-system
, où [ADMIN_CLUSTER_KUBECONFIG] est le chemin d'accès au fichier kubeconfig du cluster d'administrateur :kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system get pods | grep clusterapi-controllers
Ouvrez les journaux du pod, où [POD_NAME] correspond au nom du pod. Vous pouvez éventuellement utiliser
grep
ou un outil similaire pour rechercher les erreurs :kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system logs [POD_NAME] vsphere-controller-manager
Résoudre les problèmes F5 BIG-IP à l'aide du fichier kubeconfig du nœud de plan de contrôle du cluster d'administrateur
Après une installation, GKE On-Prem génère un fichier kubeconfig nommé internal-cluster-kubeconfig-debug
dans le répertoire d'accueil de votre poste de travail administrateur. Ce fichier kubeconfig est identique à celui de votre cluster d'administrateur, sauf qu'il pointe directement vers le nœud de plan de contrôle du cluster d'administrateur, où s'exécute le plan de contrôle d'administrateur. Vous pouvez utiliser le fichier internal-cluster-kubeconfig-debug
pour résoudre les problèmes F5 BIG-IP.
Échec de la validation de gkectl check-config
: impossible de trouver les partitions F5 BIG-IP
- Symptômes
La validation échoue, car les partitions F5 BIG-IP sont introuvables, même si elles existent.
- Causes probables
Un problème avec l'API F5 BIG-IP peut entraîner l'échec de la validation.
- Solution
Essayez d'exécuter
gkectl check-config
à nouveau.
Échec de gkectl prepare --validate-attestations
: impossible de valider l'attestation de version
- Symptômes
L'exécution de
gkectl prepare
avec l'option facultative--validate-attestations
renvoie l'erreur suivante :could not validate build attestation for gcr.io/gke-on-prem-release/.../...: VIOLATES_POLICY
- Causes probables
Une attestation peut ne pas exister pour la ou les images affectées.
- Solution
Essayez à nouveau de télécharger et de déployer le fichier OVA du poste de travail administrateur, comme indiqué sur la page Créer un poste de travail administrateur. Si le problème persiste, contactez Google pour obtenir de l'aide.
Déboguer à l'aide des journaux du cluster d'amorçage
Lors de l'installation, GKE On-Prem crée un cluster d'amorçage temporaire. Après une installation réussie, GKE On-Prem supprime le cluster d'amorçage, vous laissant ainsi votre cluster d'administrateur et votre cluster d'utilisateur. En règle générale, vous ne devriez avoir aucune raison d'interagir avec ce cluster.
Si une erreur se produit lors d'une installation et que vous avez transmis --cleanup-external-cluster=false
à gkectl create cluster
, il peut être utile d'effectuer un débogage à l'aide des journaux du cluster d'amorçage. Vous pouvez rechercher le pod, puis obtenir ses journaux :
kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl get pods -n kube-system
kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl -n kube-system get logs [POD_NAME]
Étapes suivantes
- Apprenez à créer des clusters d'utilisateur supplémentaires.
- Affichez vos clusters dans la console Google Cloud.
- Connectez-vous à vos clusters.