Version 1.1. Cette version n'est plus compatible, comme indiqué dans la politique de compatibilité avec les versions d'Anthos. Pour obtenir les derniers correctifs et mises à jour pour les failles de sécurité, les expositions et les problèmes affectant Anthos Clusters on VMware (GKE On-Prem), passez à une version compatible. Vous trouverez la version la plus récente ici.

Effectuer l'installation à l'aide d'adresses IP statiques

Cette page explique la procédure à suivre pour installer GKE On-Prem dans un environnement VMware vSphere 6.5 à 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

  1. Configurez votre environnement sur site comme décrit sur la page concernant la configuration requise.

  2. Suivez les procédures décrites dans la page Préparer l'installation.

  3. Créez un poste de travail administrateur dans vSphere.

  4. Découvrez comment activer l'équilibrage de charge manuel si vous souhaitez l'utiliser.

  5. Connectez-vous en SSH à votre poste de travail administrateur :

    ssh -i ~/.ssh/vsphere_workstation ubuntu@[IP_ADDRESS]
    
  6. Si vous utilisez un proxy, vous devez configurer le SDK Cloud pour le proxy afin de pouvoir exécuter les commandes gcloud et gsutil. Pour obtenir des instructions, consultez la page Configurer le SDK Cloud pour utilisation derrière un proxy/pare-feu.

  7. Connectez-vous à Google Cloud à l'aide des identifiants de votre compte :

    gcloud auth login
  8. Enregistrez gcloud en tant qu'assistant d'identification Docker (en savoir plus sur cette commande) :

    gcloud auth configure-docker
  9. Définissez 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 du SDK Cloud 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 Cloud Console ou en exécutant gcloud config get-value project.)

Choisir un registre d'image de conteneur pour l'installation

Pour l'installation, GKE On-Prem doit savoir 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.

Avant de procéder à l'installation, vous devez configurer le registre. Lors de l'installation, vous devez renseigner le fichier de configuration GKE On-Prem avec les informations du registre.

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 :

  1. Créez un dossier pour conserver le certificat :

    sudo mkdir -p /etc/docker/certs.d/[REGISTRY_SERVER]
    

    [REGISTRY_SERVER] est l'adresse IP ou le nom d'hôte de la VM qui exécute votre registre Docker.

  2. Copiez le fichier de certificat dans /etc/docker/certs.d/[REGISTRY_SERVER]/ca.crt. Vous devez nommer le fichier ca.crt, même si son nom était différent à l'origine.

  3. Redémarrez le service Docker :

    sudo service docker restart
  4. Vérifiez que vous pouvez vous connecter à Docker :

    docker login -u [USERNAME] -p [PASSWORD] [REGISTRY_SERVER]

    [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 : votre VM de poste de travail administrateur ne fait pas confiance au certificat.

Configurer des adresses IP statiques

Pendant l'installation, vous générez un fichier de configuration GKE On-Prem. Le fichier de configuration que vous générez comprend deux champs ipblockfilepath :

  • admincluster.ipblockfilepath
  • usercluster.ipblockfilepath.

Le champ ipblockfilepath accepte le chemin d'accès vers un fichier YAML contenant un fichier de configuration d'hôte (ou hostconfig), comme décrit ci-dessous.

Si vous souhaitez utiliser des adresses IP statiques, vous devez créer deux fichiers YAML sur votre poste de travail administrateur : un fichier contenant un hostconfig destiné à être utilisé par votre cluster d'administrateur, et un autre destiné à être utilisé par votre cluster d'utilisateur.

Vous avez besoin d'au moins N + 4 paires adresse IP/nom d'hôte dans la configuration IP du cluster d'administrateur, où N est le nombre de clusters d'utilisateur que vous prévoyez de créer.

Vous pouvez choisir de créer un cluster d'utilisateur à haute disponibilité. Un cluster d'utilisateur à haute disponibilité utilise trois plans de contrôle d'utilisateur. Chaque VM qui exécute un plan de contrôle d'utilisateur nécessite sa propre adresse IP statique. Étant donné que les plans de contrôle d'utilisateur sont gérés par le cluster d'administrateur, ces valeurs doivent être fournies dans le fichier hostconfig du cluster d'administrateur.

Exemple

Voici un exemple de fichier hostconfig avec trois hôtes. Votre fichier peut être différent en fonction de votre environnement. Par exemple, vous pouvez développer le tableau ips avec d'autres paires ip/hostname :

hostconfig:
  dns: 172.16.255.1
  tod: 192.138.210.214
  otherdns:
  - 8.8.8.8
  - 8.8.4.4
  othertod:
  - ntp.ubuntu.com
blocks:
  - netmask: 255.255.252.0
    gateway: 110.116.232.1
    ips:
    - ip: 10.116.232.23
      hostname: host1.enterprise.net  # will be trimmed to host1
    - ip: 10.116.232.65
      hostname: host2.enterprise.net  # will be trimmed to host2
    - ip: 10.116.232.66
      hostname: host3.enterprise.net  # will be trimmed to host3

Le fichier YAML contient deux sections, hostconfig et blocks.

hostconfig

La section hostconfig contient des paramètres de mise en réseau qui s'appliquent de manière statique à tous les nœuds d'un cluster. La section hostconfig configure les valeurs suivantes :

  • dns : adresse IP du serveur DNS à utiliser pour les nœuds
  • tod : adresse IP du serveur de temps à utiliser pour les nœuds
  • otherdns : autres serveurs DNS à utiliser pour les nœuds
  • othertod : autres serveurs de temps à utiliser pour les nœuds

blocks

blocks contient un tableau de blocs d'adresses IP statiques. Actuellement, GKE On-Prem ne prend en compte que le premier bloc pour l'allocation d'adresses IP. Chaque bloc représente un réseau et les adresses IP que celui-ci contient.

netmask et gateway

netmask et gateway représentent le masque de réseau et la passerelle par défaut à utiliser pour les nœuds.

blocks:
  - netmask: 255.255.252.0
    gateway: 110.116.232.1

ips

Un tableau ips répertorie les adresses IP que vous avez allouées. Chaque objet du tableau contient une adresse IPv4 et son nom d'hôte :

blocks:
...
  ips:
  - ip: [IPV4_ADDRESS]
    hostname: [HOSTNAME]
  - ip: [IPV4_ADDRESS]
    hostname: [HOSTNAME]
  - ip: [IPV4_ADDRESS]
    hostname: [HOSTNAME]
...

GKE On-Prem garde la trace des adresses IP libres et attribuées dans ce bloc, et alloue une adresse IP disponible à chaque nœud d'un cluster. Assurez-vous que le nombre d'adresses IP du tableau est strictement supérieur au nombre de nœuds du cluster, et que chaque adresse IP est propre au réseau de votre environnement.

hostname est interprété comme le nom d'hôte local sans son domaine. Si vous spécifiez un nom de domaine complet, le nom de domaine est tronqué. Par exemple, host1.enterprise.net devient host1. Les valeurs hostname doivent être en minuscules.

Créer le fichier hostconfig

Voici un exemple de fichier hostconfig pour un cluster d'utilisateur comportant trois nœuds :

  1. Copiez le modèle suivant dans un fichier YAML :

    hostconfig:
      dns:
      tod:
    blocks:
      - netmask:
        gateway:
        ips:
        - ip:
          hostname:
        - ip:
          hostname:
        - ip:
          hostname:
    
  2. Enregistrez les fichiers sous des noms différents, tels que admin-cluster-hostconfig.yaml et user-cluster-hostconfig.yaml.

  3. Pendant l'installation, remplacez les champs admincluster.ipblockfilepath et usercluster.ipblockfilepath du fichier de configuration par les valeurs des fichiers appropriés.

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
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.json \
--iam-account [ACCESS_SERVICE_ACCOUNT_EMAIL]

[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.json \
--iam-account [REGISTER_SERVICE_ACCOUNT_EMAIL]

[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]

[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]

[STACKDRIVER_SERVICE_ACCOUNT_EMAIL] est l'adresse e-mail du compte de service Cloud Monitoring.

Activer votre compte de service d'accès pour le SDK Cloud

L'activation de votre compte de service d'accès pour le SDK Cloud entraîne l'exécution de toutes les commandes gcloud et gsutil avec ce 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 le SDK Cloud 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

Le fichier de groupe GKE On-Prem contient tous les composants d'une release particulière de GKE On-Prem. Lorsque vous créez un poste de travail administrateur, celui-ci est fourni avec un groupe complet dans /var/lib/gke/bundles/gke-onprem-vsphere-[VERSION]-full.tgz. La version de ce groupe correspond à la version 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

[VERSION] est la version de GKE On-Prem que vous installez. La dernière version est 1.1.2-gke.0.

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, virtual machine disk) afin d'y stocker les données d'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 my-gke-on-prem-folder

Actuellement, un problème connu nécessite que vous fournissiez l'identifiant unique universel (Universally Unique Identifier, UUID) du dossier, et non le chemin d'accès du fichier, à vcenter.datadisk. Pour trouver l'UUID du dossier, ouvrez le client vCenter, puis sélectionnez votre datastore et le dossier. Copiez l'UUID du dossier. Vous pouvez également exécuter la commande suivante, où [ADMIN_CONTROL_PLANE_VM] est la VM vSphere qui exécute le plan de contrôle d'administrateur :

govc vm.info -json ./vm/[ADMIN_CONTROL_PLANE_VM] | jq '.VirtualMachines[0].Config.Hardware.Device[] | select(.Backing | has("FileName")) | .Backing.FileName'

Indiquez ensuite l'UUID du dossier dans le champ vcenter.datadisk. Exemple :

vcenter:
...
datadisk: "14159b5d-4265-a2ba-386b-246e9690c588/my-disk.vmdk"

vcenter.cacertpath

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. 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-folder/altostrat.crt"

Que votre serveur vCenter utilise un certificat autosigné ou un certificat signé par une autorité de certification publique, vous pouvez obtenir le certificat de l'autorité de certification en exécutant la commande suivante sur votre poste de travail administrateur :

true | openssl s_client -connect [VCENTER_IP]:443 -showcerts 2>/dev/null | sed -ne '/-BEGIN/,/-END/p' > vcenter.pem

[VCENTER_IP] est l'adresse IP du serveur vCenter.

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://password:username@domain"
  noproxy: "100.151.222.0/24,corp.domain,100.151.2.1"
  • proxy.url est l'URL du proxy HTTPS.
  • proxy.noproxy inclut le CIDR, les domaines et les adresses IP qui ne doivent pas utiliser le proxy. En règle générale, cela inclut le sous-réseau vSphere et l'adresse du registre privé si vous utilisez un registre Docker privé.

Spécifier le 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)

Depuis la version 1.1.0-gke.6, GKE On-Prem crée automatiquement des règles d'anti-affinité VMware Distributed Resource Scheduler (DRS) pour les nœuds de votre cluster d'utilisateur. Ceux-ci sont ainsi répartis sur au moins trois hôtes physiques dans votre centre de données. Depuis la version 1.1.0-gke.6, cette fonctionnalité est automatiquement activée pour les nouveaux clusters et pour les clusters existants.

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'autorisation Host.Inventory.EditCluster.
  • Au moins trois hôtes physiques doivent être disponibles.

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 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 Cloud Console :

  • 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 Cloud Console. Dans ce cas, vous pouvez fournir une valeur d'espace réservé pour clientsecret :

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.

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-folder/register-key.json"
  agentserviceaccountkeypath: "/my-key-folder/connect-key.json"
  proxy: https://203.0.113.20

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 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-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 d'accès. Exemple :

gcrkeypath: "/my-key-folder/access-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]

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]

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

Reprendre une installation

Si votre installation est interrompue après la création du cluster d'administrateur, vous pouvez la reprendre en procédant comme suit :

  • Supprimez la spécification admincluster du fichier de configuration.
  • Exécutez à nouveau gkectl create cluster en transmettant le fichier kubeconfig du cluster d'administrateur.
gkectl create cluster --config [CONFIG_FILE] \
--kubeconfig [ADMIN_CLUSTER_KUBECONFIG]

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

Problèmes connus

Actuellement, vous ne pouvez pas reprendre une installation si vous créez un cluster d'utilisateur à haute disponibilité. Ce problème sera résolu dans une prochaine release.

Associer des clusters à Google

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 :

  1. Créez un secret contenant votre certificat et votre clé.
  2. 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.

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.

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 fichier logs/gkectl-$(date).log dans le répertoire local où vous exécutez gkectl.
    • Pour gkeadm, le fichier journal par défaut est logs/gkeadm-$(date).log dans le répertoire local où vous exécutez gkeadm.
  • 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 valeur false).
  • 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 :

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

Étape suivante