Vous consultez la documentation d'une version précédente de GKE On-Prem. Consultez la documentation la plus récente.

Mettre à jour GKE On-Prem

Cet article explique comment mettre à niveau GKE On-Prem.

Pour mettre à niveau GKE On-Prem, vous devez mettre à niveau votre poste de travail administrateur. Ensuite, vous devez mettre à niveau vos clusters.

Avant de commencer

Lisez également les points suivants :

À propos des temps d'arrêt pendant les mises à niveau

Ressource Description
Cluster d'administrateur

En cas de panne d'un cluster d'administrateur, les plans de contrôle des clusters d'utilisateurs et les charges de travail de ces clusters continuent à s'exécuter, sauf s'ils sont affectés par une panne ayant provoqué le temps d'arrêt.

Plan de contrôle du cluster d'utilisateur

En règle générale, les plans de contrôle de cluster d'utilisateur ne font pas l'objet de temps d'arrêt notable. Cependant, les connexions de longue durée au serveur d'API Kubernetes peuvent être interrompues et doivent être rétablies. Dans ce cas, l'appelant de l'API doit réessayer jusqu'à ce qu'il établisse une connexion. Dans le pire des cas, le temps d'arrêt peut durer jusqu'à une minute pendant une mise à niveau.

Nœuds de cluster d'utilisateur

Si une mise à niveau nécessite une modification des nœuds de cluster d'utilisateur, GKE On-Prem recrée les nœuds de manière progressive et replanifie les pods exécutés sur ces nœuds. Vous pouvez éviter l'impact sur vos charges de travail en configurant des règles PodDisruptionBudgets et anti-affinité appropriées.

Mise à niveau séquentielle

GKE On-Prem est compatible avec la mise à niveau séquentielle. Pour mettre à niveau un cluster vers une nouvelle version, il doit déjà être de la dernière version précédente.

Vous ne pouvez pas mettre à niveau vos clusters directement vers la dernière version s'ils sont en retard de plusieurs versions. Le cas échéant, vous devez mettre à niveau le cluster de manière séquentielle.

Exemple

Supposons que les versions suivantes soient disponibles, et que votre poste de travail d'administrateur et vos clusters exécutent la version la plus ancienne :

  • 1.0.1 (version la plus ancienne)
  • 1.0.2
  • 1.1 (dernière version)

Dans ce cas, la version 1.1 est la dernière. Pour passer de la version 1.0.1 à la version 1.1, procédez comme suit :

  1. Mettez à niveau votre poste de travail d'administrateur de la version 1.0.1 à la version 1.0.2.
  2. Mettez à niveau vos clusters de la version 1.0.1 vers la version 1.0.2.
  3. Mettez à niveau votre poste de travail d'administrateur de la version 1.0.2 vers la version 1.1.
  4. Mettez à niveau vos clusters de la version 1.0.2 vers la version 1.1.

Sauvegarder votre fichier de configuration GKE On-Prem et vos fichiers kubeconfig

Lorsque vous mettez à niveau votre poste de travail d'administrateur, Terraform supprime sa VM et la remplace par un poste de travail d'administrateur mis à niveau. Avant de mettre à niveau votre poste de travail d'administrateur, vous devez sauvegarder votre fichier de configuration GKE On-Prem et les fichiers kubeconfig de vos clusters. Ensuite, vous devez copier les fichiers sur votre poste de travail d'administrateur mis à niveau.

Mettre à niveau le poste de travail administrateur

Lorsque vous mettez à niveau votre poste de travail d'administrateur, celui-ci inclut les entités suivantes, qui sont de la même version que le fichier OVA (Open Virtualization Appliance) du poste de travail d'administrateur :

  • gkectl
  • Groupe complet

Après avoir mis à niveau votre poste de travail d'administrateur, vous devez mettre à niveau vos clusters.

Télécharger le fichier OVA

À partir de Téléchargements, téléchargez le fichier OVA du poste de travail administrateur correspondant à la version vers laquelle vous souhaitez effectuer la mise à niveau.

Pour télécharger le dernier fichier OVA, exécutez la commande suivante :

gsutil cp gs://gke-on-prem-release/admin-appliance/1.1.2-gke.0/gke-on-prem-admin-appliance-vsphere-1.1.2-gke.0.{ova,ova.sig} ~/

Importer le fichier OVA dans vSphere et le marquer comme modèle de VM

Dans les sections suivantes, vous allez :

  1. Créer des variables déclarant les éléments de votre environnement vSphere et vCenter Server
  2. Importer l'OVA du poste de travail d'administrateur dans vSphere et le marquer comme modèle de VM.

Créer des variables pour govc

Avant d'importer la variable OVA du poste de travail administrateur dans vSphere, vous devez fournir govc certaines variables déclarant les éléments de votre environnement vSphere et de vCenter Server.

export GOVC_URL=https://[VCENTER_SERVER_ADDRESS]/sdk
export GOVC_USERNAME=[VCENTER_SERVER_USERNAME]
export GOVC_PASSWORD=[VCENTER_SERVER_PASSWORD]
export GOVC_DATASTORE=[VSPHERE_DATASTORE]
export GOVC_DATACENTER=[VSPHERE_DATACENTER]
export GOVC_INSECURE=true

Vous pouvez choisir d'utiliser le pool de ressources par défaut de vSphere ou créer le vôtre :

# If you want to use a resource pool you've configured yourself, export this variable:
export GOVC_RESOURCE_POOL=[VSPHERE_CLUSTER]/Resources/[VSPHERE_RESOURCE_POOL]
# If you want to use vSphere's default resource pool, export this variable instead:
export GOVC_RESOURCE_POOL=[VSPHERE_CLUSTER]/Resources

où :

  • [VCENTER_SERVER_ADDRESS] est le nom d'hôte ou l'adresse IP de votre serveur vCenter.
  • [VCENTER_SERVER_USERNAME] est le nom d'utilisateur d'un compte détenant le rôle d'administrateur ou des droits équivalents dans vCenter Server.
  • [VCENTER_SERVER_PASSWORD] est le mot de passe du compte serveur vCenter.
  • [VSPHERE_DATASTORE] est le nom du datastore que vous avez configuré dans votre environnement vSphere.
  • [VSPHERE_DATACENTER] est le nom du datacenter que vous avez configuré dans votre environnement vSphere.
  • [VSPHERE_CLUSTER] est le nom du cluster que vous avez configuré dans votre environnement vSphere.
  • Pour utiliser un pool de ressources autre que celui par défaut :
  • [VSPHERE_RESOURCE_POOL] est le nom du pool de ressources que vous avez configuré dans votre environnement vSphere.

Importer le fichier OVA dans vSphere : commutateur standard

Si vous utilisez un commutateur standard vSphere, importez le fichier OVA dans vSphere à l'aide de la commande suivante :

govc import.ova -options - ~/gke-on-prem-admin-appliance-vsphere-1.1.2-gke.0.ova <<EOF
{
  "DiskProvisioning": "thin",
  "MarkAsTemplate": true
}
EOF

Importer le fichier OVA dans vSphere : commutateur distribué

Si vous utilisez un commutateur distribué vSphere, importez le fichier OVA dans vSphere à l'aide de cette commande, où [YOUR_DISTRIBUTED_PORT_GROUP_NAME] est le nom de votre groupe de ports distribué :

govc import.ova -options - ~/gke-on-prem-admin-appliance-vsphere-1.1.2-gke.0.ova <<EOF
{
  "DiskProvisioning": "thin",
  "MarkAsTemplate": true,
  "NetworkMapping": [
      {
          "Name": "VM Network",
          "Network": "[YOUR_DISTRIBUTED_PORT_GROUP_NAME]"
      }
  ]
}
EOF

Définir la variable de modèle Terraform pour la nouvelle VM de poste de travail administrateur

Dans le fichier TFVARS de votre poste de travail administrateur, définissez vm_template sur la version vers laquelle vous souhaitez effectuer la mise à niveau. La valeur de vm_template ressemble à ceci, où [VERSION] correspond à la version de l'OVA :

gke-on-prem-admin-appliance-vsphere-[VERSION]

Utiliser Terraform pour mettre à niveau votre poste de travail administrateur

Pour mettre à niveau votre poste de travail administrateur, exécutez la commande ci-après. Cette commande supprime la VM actuelle du poste de travail administrateur et la remplace par une VM mise à niveau :

terraform init && terraform apply -auto-approve -input=false

Se connecter au poste de travail d'administrateur

  1. Connectez-vous en SSH à votre poste de travail d'administrateur :

    ssh -i ~/.ssh/vsphere_workstation ubuntu@[IP_ADDRESS]
    
  2. 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.

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

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

    gcloud auth configure-docker
  5. Créez une clé privée pour votre compte de service sur liste blanche.

    Copiez l'adresse e-mail du compte de service :

    gcloud iam service-accounts list

    Créez la clé privée du compte de service, où [KEY_FILE] est le nom que vous choisissez pour le fichier. Cette commande enregistre le fichier dans le répertoire de travail actuel :

    gcloud iam service-accounts keys create key.json \
    --project [PROJECT_ID] --iam-account [WHITELISTED_SERVICE_ACCOUNT_EMAIL]

    où :

    • [PROJECT_ID] est l'ID de votre projet.
    • [KEY_FILE] est un nom et un chemin dans lesquels enregistrer la clé privée du compte de service, telle que /home/ubuntu/key.json.
    • [WHITELISTED_SERVICE_ACCOUNT_EMAIL] est l'adresse e-mail du compte de service en liste blanche.
  6. Activez votre compte de service sur liste blanche :

    gcloud auth activate-service-account --project [PROJECT_ID] \
    --key-file [KEY_FILE]
    

Copier la configuration sauvegardée et les fichiers kubeconfig

Précédemment, vous avez sauvegardé votre fichier de configuration GKE On-Prem et les fichiers kubeconfig de vos clusters. Vous devez maintenant copier ces fichiers sur votre poste de travail administrateur mis à niveau.

Mettre à niveau les clusters

Après avoir mis à niveau votre poste de travail administrateur et vous y être connecté, procédez comme suit :

Vérifier que suffisamment d'adresses IP sont disponibles

Avant de procéder à la mise à niveau, assurez-vous que vous disposez de suffisamment d'adresses IP pour vos clusters.

DHCP

Si les adresses IP du cluster sont attribuées par un serveur DHCP, vérifiez que le serveur DHCP du réseau dans lequel les nœuds sont créés possède suffisamment d'adresses IP. Il doit y avoir plus d'adresses IP que de nœuds s'exécutant dans le cluster d'utilisateur.

IP statiques

Si le cluster utilise des adresses IP statiques, vérifiez que vous avez alloué suffisamment d'adresses IP au cluster :

kubectl get cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
-n [USER_CLUSTER_NAME] [USER_CLUSTER_NAME] -o yaml

où :

  • [ADMIN_CLUSTER_KUBECONFIG] indique à kubectl d'utiliser le fichier kubeconfig du cluster d'administrateur, qui permet d'afficher et/ou de modifier les configurations de cluster utilisateur.
  • -n [USER_CLUSTER_NAME] indique à kubectl d'examiner un espace de noms nommé d'après le cluster d'utilisateur.
  • [USER_CLUSTER_NAME] -o yaml indique à kubectl le cluster d'utilisateur sur lequel vous exécutez la commande. -o yaml affiche la configuration du cluster d'utilisateur.

Dans le résultat de la commande, recherchez le champ reservedAddresses. Il doit y avoir plus d'adresses IP dans le champ que de nœuds en cours d'exécution dans le cluster d'utilisateur.

Si vous devez ajouter d'autres adresses au champ reservedAddresses, procédez comme suit :

  1. Ouvrez le fichier de configuration du cluster d'utilisateur pour le modifier :

    kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] edit cluster [USER_CLUSTER_NAME] \
    -n [USER_CLUSTER_NAME] --validate=false
    

    La configuration du cluster s'ouvre dans l'éditeur par défaut de votre interface système.

  2. Ajoutez autant de blocs d'adresses IP statiques supplémentaires que nécessaire. Un bloc d'adresses IP comporte les champs gateway, hostname, ip et netmask.

Voici un exemple de champ reservedAddresses avec ses quatre blocs d'adresses IP statiques mis en surbrillance :

...
networkSpec:
  dns:
  - 172.x.x.x
  ntp: 129.x.x.x
  reservedAddresses:
  - gateway: 100.x.x.x
    hostname: host-1
    ip: 100.x.x.x
    netmask: x
  - gateway: 100.x.x.x
    hostname: host-2
    ip: 100.x.x.x
    netmask: x
  - gateway: 100.x.x.x
    hostname: host-3
    ip: 100.x.x.x
    netmask: x
  - gateway: 100.x.x.x
    hostname: host-4
    ip: 100.x.x.x
    netmask: x
...

Modifier le fichier de configuration

Sur la VM de votre poste de travail d'administrateur, modifiez votre fichier de configuration. Définissez la valeur de bundlepath, où [VERSION] est la version de GKE On-Prem vers laquelle vous mettez à niveau vos clusters :

bundlepath: /var/lib/gke/bundles/gke-onprem-vsphere-[VERSION].tgz

À propos des fonctionnalités activées automatiquement

Une nouvelle version de GKE On-Prem peut inclure de nouvelles fonctionnalités ou une compatibilité avec des fonctionnalités VMware vSphere spécifiques. Parfois, la mise à niveau vers une version de GKE On-Prem active automatiquement ces fonctionnalités. Vous pouvez en apprendre plus sur les nouvelles fonctionnalités dans les notes de version de GKE On-Prem. De nouvelles fonctionnalités apparaissent parfois dans le fichier de configuration GKE On-Prem.

Désactiver de nouvelles fonctionnalités via le fichier de configuration

Si vous devez désactiver une nouvelle fonctionnalité activée automatiquement dans une nouvelle version de GKE On-Prem et générée par le fichier de configuration, procédez comme suit avant de mettre à niveau votre cluster :

  1. Depuis votre poste de travail administrateur mis à niveau, créez un fichier de configuration ayant un nom différent de celui de votre fichier de configuration actuel :

    gkectl create-config --config [CONFIG_NAME]
    
  2. Ouvrez le nouveau fichier de configuration et le champ de la fonctionnalité. Fermez le fichier.

  3. Ouvrez votre fichier de configuration actuel et ajoutez le champ de la nouvelle fonctionnalité dans la spécification appropriée.

  4. Dans le champ, indiquez false ou une valeur équivalente.

  5. Enregistrez le fichier de configuration. Procédez à la mise à niveau de vos clusters.

Avant de mettre à niveau vos clusters, vous devez toujours lire les notes de version. Vous ne pouvez pas modifier de manière déclarative la configuration d'un cluster existant après sa mise à niveau.

Exécuter gkectl prepare

Exécutez la commande suivante :

gkectl prepare --config [CONFIG_FILE]

La commande gkectl prepare exécute les tâches suivantes :

  • Si nécessaire, copiez une nouvelle image d'OS de nœud dans votre environnement vSphere et marquez-la comme modèle.

  • Transférez les images Docker mises à jour, spécifiées dans le nouveau groupe, vers votre registre Docker privé, si vous en avez configuré un.

Mettre à niveau votre cluster d'administrateur

Exécutez la commande suivante :

gkectl upgrade admin \
--kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
--config [CONFIG_FILE]

[ADMIN_CLUSTER_KUBECONFIG] est le fichier kubeconfig du cluster d'administrateur et [CONFIG_FILE] est le fichier de configuration GKE On-Prem que vous utilisez pour effectuer la mise à niveau.

Mettre à niveau votre cluster d'utilisateur

Pour mettre à niveau un cluster d'utilisateur, la version de votre cluster d'administrateur doit être au moins aussi récente que la version cible de la mise à niveau. Si la version de votre cluster d'administrateur n'est pas aussi récente, mettez d'abord ce cluster à niveau.

gkectl

Depuis votre poste de travail administrateur, exécutez la commande suivante :

gkectl upgrade cluster \
--kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
--config [CONFIG_FILE] \
--cluster-name [CLUSTER_NAME]

[ADMIN_CLUSTER_KUBECONFIG] est le fichier kubeconfig du cluster d'administrateur, [CLUSTER_NAME] est le nom du cluster d'utilisateur que vous mettez à niveau et [CONFIG_FILE] est le fichier de configuration GKE On-Prem que vous utilisez pour effectuer la mise à niveau.

Console

Vous pouvez choisir d'enregistrer vos clusters d'utilisateur avec Cloud Console lors de l'installation ou après les avoir créés. Vous pouvez afficher vos clusters GKE On-Prem enregistrés et vos clusters Google Kubernetes Engine et vous y connecter à partir du menu GKE de Cloud Console.

Lorsqu'une mise à niveau devient disponible pour les clusters d'utilisateur GKE On-Prem, une notification s'affiche dans Cloud Console. Cliquer sur cette notification permet d'afficher la liste des versions disponibles et une commande gkectl que vous pouvez exécuter pour mettre à niveau le cluster :

  1. Accédez au menu GKE dans Cloud Console.

    Accéder au menu GKE On-Prem

  2. Dans la colonne Notifications du cluster d'utilisateur, cliquez sur Mise à niveau disponible, si cette option est disponible.

  3. Copiez la commande gkectl upgrade cluster.

  4. Depuis votre poste de travail administrateur, exécutez la commande gkectl upgrade cluster, où [ADMIN_CLUSTER_KUBECONFIG] est le fichier kubeconfig du cluster d'administrateur, [CLUSTER_NAME] est le nom du cluster d'utilisateur que vous mettez à niveau, et [CONFIG_FILE] est le fichier GKE On-Prem que vous utilisez pour effectuer la mise à niveau.

Reprendre une mise à niveau

Si une mise à niveau du cluster d'utilisateur est interrompue, mais que le cluster d'administrateur a bien été mis à niveau, vous pouvez reprendre la mise à niveau en exécutant à nouveau gkectl upgrade cluster avec le même fichier de configuration GKE On-Prem et le même cluster d'administrateur kubeconfig.

À propos de la reprise d'une mise à niveau du cluster d'administrateur

Vous ne devez pas interrompre une mise à niveau du cluster d'administrateur. Actuellement, il n'est pas toujours possible de reprendre les mises à niveau du cluster d'administrateur. Si une mise à niveau du cluster d'administrateur est interrompue pour quelque raison que ce soit, contactez l'assistance pour obtenir de l'aide.

Problèmes connus

Les problèmes connus suivants affectent la mise à niveau des clusters.

Perturbation des charges de travail comportant des PodDisruptionBudgets

Actuellement, la mise à niveau de clusters peut entraîner des perturbations ou des temps d'arrêt pour les charges de travail qui utilisent des PodDisruptionBudgets (PDB).

Version 1.1.1-gke.2 : le disque de données du dossier de datastore vSAN peut être supprimé

Si vous utilisez un datastore vSAN, vous devez créer un dossier dans lequel enregistrer le VMDK. Actuellement, un problème connu nécessite que vous fournissiez l'identifiant unique universel (UUID) du dossier à vcenter.datadisk au lieu de son chemin d'accès au fichier. Cette incohérence peut entraîner l'échec des mises à niveau.

Un correctif est prévu pour la version 1.1.2. Avant de procéder à la mise à niveau, procédez comme suit afin d'utiliser le nœud du plan de contrôle administrateur pour contourner ce problème :

  1. Dans l'interface vCenter, obtenez l'UUID du dossier dans votre magasin de données vSAN.
  2. Répertoriez les ressources de la machine figurant dans vos clusters. Ces machines correspondent aux nœuds des clusters :

    kubectl get machines -n all
  3. Pour la Machine du plan de contrôle administrateur (gke-admin-master), ouvrez sa configuration pour la modifier:

    kubectl edit machine [MACHINE_NAME]
    
  4. Modifiez le champ spec.providerSpec.value.machineVariables.data_disk_path. Remplacez le chemin d'accès au fichier VMDK par l'UUID. Exemple :

    spec:
    providerSpec:
     value:
       apiVersion: vsphereproviderconfig.k8s.io/v1alpha1
       kind: VsphereMachineProviderConfig
       machineVariables:
         data_disk_path: 14159b5d-4265-a2ba-386b-246e9690c588/my-disk.vmdk
         datacenter: datacenter
         datastore: datastore
  5. Enregistrez le fichier.

  6. Ouvrez le fichier de configuration GKE On-Prem.

  7. À partir de vcenter.datadisk, remplacez le dossier dans le chemin du fichier par l'UUID du dossier. Exemple :

    vcenter:
     ...
     datadisk: "14159b5d-4265-a2ba-386b-246e9690c588/my-disk.vmdk"
    
  8. Procédez à la mise à niveau de vos clusters.

Mise à niveau vers la version 1.1.0-gke.6 depuis la version 1.0.2-gke.3 : problème OIDC

Les clusters des versions 1.0.11, 1.0.1-gke.5 et 1.0.2-gke.3 pour lesquels OpenID Connect (OIDC) est configuré ne peuvent pas être mis à niveau vers la version 1.1.0-gke.6. Ce problème est résolu dans la version 1.1.1-gke.2.

Si vous avez configuré un cluster de version 1.0.11, 1.0.1-gke.5 ou 1.0.2-gke.3 avec OIDC lors de l'installation, vous ne pouvez pas le mettre à niveau. À la place, vous devez créer d'autres clusters.

Mise à niveau vers la version 1.0.2-gke.3 depuis la version 1.0.11

La version 1.0.2-gke.3 introduit les champs OIDC suivants (usercluster.oidc). Ces champs permettent de se connecter à un cluster depuis Cloud Console :

  • usercluster.oidc.kubectlredirecturl
  • usercluster.oidc.clientsecret
  • usercluster.oidc.usehttpproxy

Si vous souhaitez utiliser OIDC, le champ clientsecret est obligatoire, même si vous ne souhaitez pas vous connecter à un cluster depuis Cloud Console. Pour utiliser OIDC, vous devrez peut-être fournir une valeur factice pour clientsecret :

oidc:
  clientsecret: "secret"

Annexe

À propos des règles VMware DRS activées dans la version 1.1.0-gke.6

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.

Avant de procéder à la mise à niveau, assurez-vous que votre environnement vSphere remplit 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 la page 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 sont disponibles.

Désactiver VMware DRS avant la mise à niveau vers la version 1.1.0-gke.6

Si vous ne souhaitez pas activer cette fonctionnalité pour vos clusters d'utilisateur existants (par exemple, si vous ne disposez pas d'un nombre suffisant d'hôtes pour l'exécuter), effectuez la procédure ci-après avant de mettre à niveau vos clusters d'utilisateur :

  1. Ouvrez votre fichier de configuration GKE On-Prem existant.
  2. Sous la spécification usercluster, ajoutez le champ antiaffinitygroups comme décrit dans la documentation antiaffinitygroups :
    usercluster:
          ...
          antiaffinitygroups:
            enabled: false
    
  3. Enregistrez le fichier.
  4. Utilisez le fichier de configuration pour effectuer la mise à niveau. Vos clusters sont mis à niveau, mais la fonctionnalité n'est pas activée.

Autre scénario de mise à niveau

Cet article décrit le moyen le plus simple de mettre à niveau GKE On-Prem. Le tableau ci-dessous décrit un autre scénario de mise à niveau. Dans ce scénario, vous ne devez mettre à niveau que gkectl et vos clusters, vous ne mettez pas à niveau le poste de travail d'administrateur :

Scénario Étapes
La version ne comporte aucune mise à jour de sécurité pour le poste de travail d'administrateur.
  1. Téléchargez gkectl.
  2. Téléchargez le package.
  3. Suivez les instructions figurant sur cette page.

Dépannage

Pour en savoir plus, consultez la section Dépannage.

Nouveaux nœuds créés, mais non sains

Symptômes

Les nouveaux nœuds ne s'enregistrent pas eux-mêmes dans le plan de contrôle du cluster d'utilisateur lors de l'utilisation du mode d'équilibrage de charge manuel.

Causes possibles :

La validation Ingress dans les nœuds est peut-être activée, ce qui bloque le processus de démarrage des nœuds.

Solution

Pour désactiver la validation, exécutez la commande suivante :

kubectl patch machinedeployment [MACHINE_DEPLOYMENT_NAME] -p '{"spec":{"template":{"spec":{"providerSpec":{"value":{"machineVariables":{"net_validation_ports": null}}}}}}}' --type=merge

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 section Diagnostiquer des 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 d'administrateur

Même si vous ne transmettez pas ses indicateurs de débogage, vous pouvez afficher les journaux gkectl dans le répertoire suivant du poste de travail d'administrateur :

/home/ubuntu/.config/syllogi/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 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 de 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