Cette page explique comment installer GKE On-Prem dans vSphere. Les instructions de cette page vous indiquent comment créer un cluster d'administrateur et un cluster d'utilisateur. Après avoir créé le cluster d'administrateur et le cluster d'utilisateur initial, vous pouvez créer des clusters d'utilisateur supplémentaires.
Avant de commencer
Configurez votre environnement sur site comme décrit sur la page concernant la configuration requise.
Suivez les procédures indiquées dans la section Premiers pas.
Créez un poste de travail administrateur dans vSphere.
Créez un registre Docker privé si vous souhaitez en utiliser un.
Découvrez comment activer l'équilibrage de charge manuel si vous souhaitez l'utiliser.
Configurez des adresses IP statiques si vous souhaitez les utiliser.
Connectez-vous en SSH à votre poste de travail administrateur :
ssh -i ~/.ssh/vsphere_workstation ubuntu@[IP_ADDRESS]
Autorisez
gcloud
à accéder à Google Cloud :gcloud auth login
Enregistrez
gcloud
en tant qu'assistant d'identification Docker (en savoir plus sur cette commande) :gcloud auth configure-docker
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
.)
Créer des clés privées de comptes de service sur votre poste de travail administrateur
Dans la section Premiers pas, 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 NAME EMAIL access-service-account@my-gcp-project.iam.gserviceaccount.com register-service-account@my-gcp-project.iam.gserviceaccount.com connect-service-account@my-gcp-project.iam.gserviceaccount.com stackdriver-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é.
Accéder au compte de service
gcloud iam service-accounts keys create access-key-file \ --iam-account [ACCESS_SERVICE_ACCOUNT_EMAIL]
où [ACCESS_SERVICE_ACCOUNT_EMAIL] est l'adresse e-mail du compte de service d'accès.
Compte de service d'enregistrement
gcloud iam service-accounts keys create register-key \ --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 \ --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 \ --iam-account [STACKDRIVER_SERVICE_ACCOUNT_EMAIL]
où [STACKDRIVER_SERVICE_ACCOUNT_EMAIL] est l'adresse e-mail du compte de service Cloud Monitoring.
Activer votre compte de service d'accès pour Google Cloud CLI
L'activation de votre compte de service d'accès pour gcloud CLI entraîne l'exécution de toutes les commandes gcloud
et gsutil
en tant que compte de service. Étant donné que le compte de service d'accès figure sur la liste d'autorisation des binaires GKE On-Prem, l'activation du compte pour gcloud CLI vous donne l'autorisation de télécharger les binaires de GKE On-Prem depuis Cloud Storage.
Pour activer votre compte de service d'accès, exécutez la commande ci-après. Si le chemin d'accès au fichier de clé du compte ne se trouve pas dans le répertoire de travail actuel, veillez à l'indiquer :
gcloud auth activate-service-account --key-file=access-key.json
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.
bundlepath
Un groupe GKE On-Prem est un ensemble de fichiers YAML. Les fichiers YAML décrivent collectivement tous les composants d'une version spécifique de GKE On-Prem.
Lorsque vous créez un poste de travail administrateur, celui-ci est fourni avec un groupe dans /var/lib/gke/bundles/gke-onprem-vsphere-[VERSION]-full.tgz
.
Définissez la valeur de bundlepath
sur le chemin d'accès de votre fichier de groupe. 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.
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.
gkeplatformversion
Le champ gkeplatformversion
contient la version Kubernetes de la version de GKE On-Prem que vous installez. Son format est le suivant :
[KUBERNETES_VERSION]-[GKE_PATCH]
1.12.7-gke.19 est un exemple de version de Kubernetes.
Lorsque vous exécutez gkectl create-config
, ce champ est renseigné pour vous.
Les schémas de gestion des versions pour bundlepath
et gkeplatformversion
sont différents. Cependant, une version de groupe donnée possède une version de plate-forme GKE correspondante. Par exemple, si la version du groupe est 1.0.10, la version de la plate-forme GKE doit être 1.12.7-gke.19.
Pour en savoir plus sur la correspondance entre une version de groupe et la version de la plate-forme GKE, extrayez le fichier du groupe et examinez les fichiers YAML.
Plus spécifiquement, ouvrez gke-onprem-vsphere-[VERSION]-images.yaml
et examinez le champ osImages
. Vous pouvez voir la version de la plate-forme GKE dans le nom du fichier image de l'OS. Par exemple, dans l'image de l'OS suivante, vous pouvez voir que la version de la plate-forme GKE est 1.12.7-gke.19.
osImages: admin: "gs://gke-on-prem-os-ubuntu-release/gke-on-prem-osimage-1.12.7-gke.19-20190516-905ef43658.ova"
vcenter
Utilisez ce champ pour déclarer les paramètres généraux de votre serveur vCenter.
GKE On-Prem doit connaître l'adresse IP, le nom d'utilisateur et le mot de passe de votre instance de serveur vCenter. Définissez les valeurs sous vcenter
pour fournir ces informations. Exemple :
vcenter: credentials: address: "203.0.113.1" username: "my-name" password: "my-password"
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" resourcepool: "my-pool"
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"
Si vous souhaitez que GKE On-Prem place le VMDK dans un répertoire, vous devez créer manuellement le répertoire à l'avance. Par exemple, vous pouvez utiliser govc
pour créer un répertoire :
govc datastore.mkdir my-gke-on-prem-directory
Vous pouvez ensuite inclure le répertoire dans le champ vcenter.datadisk
:
vcenter: ... datadisk: "my-gke-on-prem-directory/my-disk.vmdk"
Lorsqu'un client, tel que GKE On-Prem, envoie une requête au serveur vCenter, le serveur doit prouver son identité au client en présentant un certificat. Le certificat est signé par une autorité de certification (CA). Le client vérifie le certificat du serveur à l'aide du certificat de l'autorité de certification.
Définissez vcenter.cacertpath
sur le chemin d'accès du certificat de l'autorité de certification. Exemple :
vcenter: ... cacertpath: "/my-cert-directory/altostrat.crt"
Pour en savoir plus sur le téléchargement du certificat de l'autorité de certification, consultez la section Télécharger et installer des certificats racine de vCenter Server.
Si votre serveur vCenter utilise un certificat autosigné, vous pouvez extraire le certificat en vous connectant à vCenter avec openssl
à partir du poste de travail administrateur :
true | openssl s_client -connect [VCENTER_IP]:443 -showcerts 2>/dev/null | sed -ne '/-BEGIN/,/-END/p' > vcenter.pem
gcrkeypath
Définissez la valeur de gcrkeypath
sur le chemin d'accès du fichier de clé JSON pour votre compte de service d'accès.
Exemple :
gcrkeypath: "/my-key-directory/access-key.json"
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
Le champ 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.
Si vous souhaitez que l'agent Connect utilise un proxy pour communiquer avec Google Cloud, définissez la valeur de gkeconnect.proxy
sur l'URL du proxy.
Utilisez le format http(s)://[PROXY_ADDRESS]
.
Exemple :
gkeconnect: projectid: "my-project" registerserviceaccountkeypath: "/my-key-directory/register-key.json" agentserviceaccountkeypath: "/my-key-directory/connect-key.json" proxy: https://203.0.113.20
stackdriver
Le champ 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.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" proxyconfigsecretname: "" enablevpc: false serviceaccountkeypath: "/my-key-directory/logging-key.json
privateregistryconfig
Si vous disposez d'un registre Docker privé, le champ privateregistryconfig
contient les 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 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é.
Lorsque Docker extrait une image de votre registre privé, le registre 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-directory/registry-ca.crt
admincluster
Le champ admincluster
contient les informations dont GKE On-Prem a besoin pour créer le cluster d'administrateur.
Réseau vCenter - cluster d'administrateur
Dans admincluster.vcenter.network
, vous pouvez choisir un autre réseau vCenter pour votre 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
Adresses IP statiques ou DHCP - cluster d'administrateur
Déterminez si vous souhaitez utiliser le protocole DHCP (Dynamic Host Configuration Protocol) pour attribuer des adresses IP à vos nœuds de cluster d'administrateur. L'alternative consiste à utiliser des adresses IP statiques pour vos nœuds de cluster. Notez que si vous avez choisi d'utiliser le mode d'équilibrage de charge manuel, vous devez utiliser des adresses IP statiques pour vos nœuds de cluster.
Si vous choisissez d'utiliser DHCP, laissez le champ admincluster.ipblockfilepath
commenté.
Si vous choisissez d'utiliser des adresses IP statiques, vous devez disposer d'un fichier de configuration 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-directory/my-admin-hostconfig.yaml"
Équilibrage de charge intégré - cluster d'administrateur
Si vous utilisez le mode d'équilibrage de charge intégré, GKE On-Prem doit connaître l'adresse IP, le nom d'utilisateur et le mot de passe de votre équilibreur de charge 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"
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"
Équilibrage de charge manuel - cluster d'administrateur
Si vous utilisez le mode d'équilibrage de charge manuel, vous devez utiliser des adresses IP statiques pour vos nœuds de cluster. Vérifiez que vous avez défini une valeur pour admincluster.ipblockfilepath
. Exemple :
admincluster: ipblockfilepath: "/my-config-directory/my-admin-hostconfig.yaml"
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
vip - cluster d'administrateur
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
serviceiprange et podiprange - cluster d'administrateur
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. Pour plus d'informations sur le choix des plages d'adresses IP des services et des pods, consultez la section Optimiser l'allocation d'adresses IP.
Les plages de services et de pods ne doivent pas se chevaucher. De plus, les plages de services et de pods sélectionnées pour le cluster d'administrateur ne doivent pas chevaucher les plages de services et de pods sélectionnées pour le cluster d'utilisateur.
Exemple :
admincluster: ... serviceiprange: 10.96.232.0/24 podiprange: 192.168.0.0/16
usercluster
Le champ usercluster
contient les informations dont GKE On-Prem a besoin pour créer le cluster d'utilisateur initial.
Réseau vCenter - cluster d'administrateur
Dans admincluster.vcenter.network
, vous pouvez choisir un autre réseau vCenter pour vos clusters 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
Adresses IP statiques ou DHCP - cluster d'administrateur
Indiquez si vous souhaitez utiliser DHCP pour attribuer des adresses IP à vos nœuds de cluster d'utilisateur. L'alternative consiste à utiliser des adresses IP statiques pour vos nœuds de cluster. Notez que si vous avez choisi le mode d'équilibrage de charge manuel, vous devez utiliser des adresses IP statiques pour vos nœuds de cluster.
Si vous choisissez d'utiliser DHCP, laissez le champ usercluster.ipblockfilepath
commenté.
Si vous choisissez d'utiliser des adresses IP statiques, vous devez disposer d'un fichier de configuration 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-directory/my-user-hostconfig.yaml"
Équilibrage de charge intégré - cluster d'utilisateur
Si vous utilisez le mode d'équilibrage de charge intégré, GKE On-Prem doit connaître l'adresse IP, le nom d'utilisateur et le mot de passe de l'équilibreur de charge 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" ...
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" ...
Équilibrage de charge manuel - cluster d'utilisateur
Si vous utilisez le mode d'équilibrage de charge manuel, vous devez utiliser des adresses IP statiques pour vos nœuds de cluster. Vérifiez que vous avez défini une valeur pour usercluster.ipblockfilepath
. Exemple :
usercluster: ipblockfilepath: "/my-config-directory/my-user-hostconfig.yaml" ...
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
vip - cluster d'utilisateur
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
serviceiprange et podiprange - cluster d'utilisateur
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. Pour plus d'informations sur le choix des plages d'adresses IP des services et des pods, consultez la section Optimiser l'allocation d'adresses IP.
Les plages de services et de pods ne doivent pas se chevaucher. De plus, les plages de services et de pods sélectionnées pour le cluster d'utilisateur ne doivent pas chevaucher les plages de services et de pods sélectionnées pour le cluster d'administrateur.
Exemple :
usercluster: ... serviceiprange: 10.96.233.0/24 podiprange: 172.16.0.0/12
clustername
Définissez la valeur de usercluster.clustername
sur le nom de votre choix. Exemple :
usercluster: ... clustername: "my-user-cluster-1"
masternode
Le champ usercluster.masternode.replicas
spécifie le nombre de nœuds du plan de contrôle que le cluster d'utilisateur doit avoir. Les nœuds du plan de contrôle pour le cluster d'utilisateur exécutent les composants du plan de contrôle pour le cluster d'utilisateur. 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 à disponibilité élevée. Trois plans de contrôle utilisateur seront créés.
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
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
. Configurer OIDC est facultatif.
Dans la version 1.0.2-gke.3, les champs obligatoires ci-après ont été ajoutés. Ces champs permettent de se connecter à un cluster à partir de la console Google Cloud :
- usercluster.oidc.kubectlredirecturl
- usercluster.oidc.clientsecret
- usercluster.oidc.usehttpproxy
Si vous ne souhaitez pas vous connecter à un cluster depuis la console Google Cloud, mais que vous souhaitez utiliser OIDC, vous pouvez transmettre des valeurs d'espace réservé pour les champs suivants :
oidc: kubectlredirecturl: "redirect.invalid" clientsecret: "secret" usehttpproxy: "false"
Pour plus d'informations, consultez la section S'authentifier avec OIDC.
sni
Si vous souhaitez fournir un certificat de diffusion supplémentaire pour le serveur d'API Kubernetes du cluster d'utilisateur, indiquez les valeurs usercluster.sni.certpath
et usercluster.sni.keypath
. Exemple :
usercluster: ... sni: certpath: "/my-cert-directory/my-second-cert.crt" keypath: "/my-cert-directory/my-second-cert.key"
workernode
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.
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
Valider le fichier de configuration
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]
Si la commande renvoie des messages FAILURE
, corrigez les problèmes et validez à nouveau le fichier.
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 :
Importez l'image d'OS du nœud dans vSphere et marquez-la 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
.
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, exécutez la commande suivante :
gkectl create cluster --config [CONFIG_FILE]
où [CONFIG_FILE] est le fichier de configuration que vous avez généré et modifié.
Vous pouvez réutiliser le fichier de configuration pour créer des clusters d'utilisateur supplémentaires.
Associer des clusters à Google
Lorsque vous créez un cluster d'utilisateur, celui-ci est automatiquement enregistré dans 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.
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.
Comportement de journalisation par défaut
Pour gkectl
et gkeadm
, l'utilisation des paramètres de journalisation par défaut est suffisante :
-
Par défaut, les entrées de journal sont enregistrées comme suit :
-
Pour
gkectl
, le fichier journal par défaut est/home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log
, et le fichier est lié symboliquement au fichierlogs/gkectl-$(date).log
dans le répertoire local où vous exécutezgkectl
. -
Pour
gkeadm
, le fichier journal par défaut estlogs/gkeadm-$(date).log
dans le répertoire local où vous exécutezgkeadm
.
-
Pour
- Toutes les entrées de journal sont enregistrées dans le fichier journal, même si elles ne sont pas affichées sur le terminal (lorsque
--alsologtostderr
a la valeurfalse
). - Le niveau de verbosité
-v5
(par défaut) couvre toutes les entrées de journal requises par l'équipe d'assistance. - Le fichier journal contient également la commande exécutée et le message d'échec.
Nous vous recommandons d'envoyer le fichier journal à l'équipe d'assistance lorsque vous avez besoin d'aide.
Spécifier un emplacement autre que celui par défaut pour le fichier journal
Pour spécifier un emplacement autre que celui par défaut pour le fichier journal gkectl
, utilisez l'option --log_file
. Le fichier journal que vous spécifiez ne sera pas lié symboliquement au répertoire local.
Pour spécifier un emplacement autre que celui par défaut pour le fichier journal gkeadm
, utilisez l'option --log_file
.
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.