Mettre à jour GKE On-Prem

Cette page explique comment mettre à niveau GKE On-Prem.

Versions cibles

À partir de la version 1.3.2 de GKE On-Prem, vous pouvez passer directement à n'importe quelle version de la même version mineure ou de la version mineure suivante. Par exemple, vous pouvez passer de la version 1.3.2 à la version 1.3.5, ou de la version 1.5.2 à la version 1.6.1.

Si la version actuelle est antérieure à la version 1.3.2, vous devez d'abord effectuer des mises à niveau séquentielles pour atteindre la version 1.3.2. Par exemple, pour passer de la version 1.3.0 à la version 1.3.2, vous devez d'abord passer de la version 1.3.0 à la version 1.3.1, puis de la version 1.3.1 à la version 1.3.2.

Si vous passez de la version 1.3.2 ou ultérieure à une version qui ne fait pas partie de la prochaine version mineure, vous devez effectuer une mise à niveau via une version de chaque version mineure entre votre version actuelle et la version souhaitée. Par exemple, il n'est pas possible de procéder à une mise à niveau directe pour passer de la version 1.3.2 à la version 1.6.1. Vous devez d'abord mettre à niveau la version 1.3.2 vers la version 1.4.x, où x représente une version de correctif antérieure à cette version mineure. Vous pouvez ensuite passer à la version 1.5.x, et enfin à la version 1.6.1.

Présentation du processus de mise à niveau

  1. Téléchargez l'outil gkeadm. La version de gkeadm doit être identique à la version cible de la mise à niveau.

  2. Mettez à niveau votre poste de travail administrateur à l'aide de gkeadm.

  3. Mettez à niveau votre cluster d'administrateur à partir de votre poste de travail administrateur.

  4. Mettez à niveau vos clusters d'utilisateurs depuis votre poste de travail administrateur.

Règles de mise à niveau

Après avoir mis à niveau votre cluster d'administrateur :

  • Tous les clusters d'utilisateur que vous créez doivent disposer de la même version que votre cluster d'administrateur.

  • Si vous mettez à niveau un cluster d'utilisateur existant, vous devez passer à la même version que votre cluster d'administrateur.

  • Avant de mettre à niveau votre cluster d'administrateur, vous devez mettre à niveau tous vos clusters d'utilisateur vers la même version que votre cluster d'administrateur actuel.

Localiser les fichiers de configuration et d'informations

Lorsque vous avez créé votre poste de travail administrateur actuel, vous avez rempli un fichier de configuration généré par gkeadm create config pour ce poste de travail. Le nom par défaut de ce fichier est admin-ws-config.yaml.

Lorsque vous avez créé votre poste de travail administrateur actuel, gkeadm a créé automatiquement un fichier d'informations. Le nom par défaut de ce fichier est identique à celui de votre poste de travail administrateur actuel.

Localisez le fichier de configuration de votre poste de travail administrateur et le fichier d'informations. Vous en aurez besoin pour suivre la procédure décrite dans ce guide. Si ces fichiers se trouvent dans votre répertoire actuel et qu'ils possèdent un nom par défaut, vous n'aurez pas besoin de les spécifier lors de l'exécution de gkeadm upgrade admin-workstation. Si ces fichiers se trouvent dans un autre répertoire ou si vous avez modifié les noms de fichiers, spécifiez-les à l'aide des options --config et --info-file.

Mettre à niveau le poste de travail administrateur

Pour mettre à niveau votre poste de travail administrateur, commencez par télécharger une nouvelle version de l'outil gkeadm, puis utilisez-la pour mettre à niveau la configuration de votre poste de travail administrateur. La version de gkeadm doit correspondre à la version cible de votre mise à niveau.

Télécharger gkeadm

Pour télécharger la version actuelle de gkeadm, suivez les instructions de téléchargement de gkeadm sur la page GKE On-Prem.

Mettre à niveau la configuration de votre poste de travail administrateur

gkeadm upgrade admin-workstation --config [AW_CONFIG_FILE] --info-file [INFO_FILE]

où :

  • [AW_CONFIG_FILE] est le chemin d'accès au fichier de configuration de votre poste de travail administrateur. Vous pouvez omettre cette option si le fichier se trouve dans votre répertoire actuel sous le nom admin-ws-config.yaml.

  • [INFO_FILE] est le chemin d'accès au fichier d'informations. Vous pouvez omettre cette option si le fichier se trouve dans votre répertoire actuel. Le nom par défaut de ce fichier est identique à celui de votre poste de travail administrateur actuel.

La commande précédente exécute les tâches suivantes :

  • Elle sauvegarde tous les fichiers du répertoire d'accueil de votre poste de travail administrateur actuel. y compris :

    • Le fichier de configuration GKE On-Prem. Le nom par défaut de ce fichier est config.yaml.

    • Les fichiers kubeconfig du cluster d'administrateur et des clusters d'utilisateur.

    • le certificat racine du serveur vCenter. Notez que ce fichier doit disposer des autorisations de propriétaire en lecture et en écriture ;

    • le fichier de clé JSON de votre compte de service sur liste d'autorisation. Notez que ce fichier doit disposer des autorisations de propriétaire en lecture et en écriture ;

    • les fichiers de clé JSON des comptes de service connect-register, connect-agent et logging-monitoring.

  • Elle crée un poste de travail administrateur et copie tous les fichiers sauvegardés sur le nouveau poste de travail administrateur.

  • Elle supprime l'ancien poste de travail administrateur.

Supprimer l'ancien poste de travail administrateur du fichier known_hosts

Si votre poste de travail administrateur dispose d'une adresse IP statique, vous devez supprimer l'ancien poste de travail administrateur du fichier known_hosts après avoir mis à niveau le poste de travail administrateur.

Pour supprimer l'ancien poste de travail administrateur du fichier known_hosts, procédez comme suit :

ssh-keygen -R [ADMIN_WS_IP]

[ADMIN_WS_IP] est l'adresse IP de votre poste de travail administrateur.

Définir le chemin d'accès au groupe dans le fichier de configuration GKE On-Prem

Sur votre nouveau poste de travail administrateur, ouvrez le fichier de configuration GKE On-Prem. Définissez la valeur de bundlepath sur le chemin d'accès au fichier de groupe sur votre nouveau poste de travail administrateur :

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

[VERSION] est la version cible de votre mise à niveau.

Mettre à jour l'image d'OS et les images Docker du nœud

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

gkectl prepare --config [CONFIG_FILE] [FLAGS]

où :

  • [CONFIG_FILE] est le fichier de configuration GKE On-Prem de votre nouveau poste de travail administrateur.

  • [FLAGS] est un ensemble facultatif d'options. Par exemple, vous pouvez inclure l'option --skip-validation-infra pour ignorer la vérification de votre infrastructure vSphere.

La commande précédente 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.

  • Si vous avez configuré un registre Docker privé, elle transfère les images Docker mises à jour à ce registre.

Vérifier que suffisamment d'adresses IP sont disponibles

Suivez les étapes décrites dans cette section sur votre nouveau poste de travail administrateur.

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

DHCP

Lors d'une mise à niveau, GKE On-Prem crée un nœud temporaire dans le cluster d'administrateur et un nœud temporaire dans chaque cluster d'utilisateur associé. Assurez-vous que votre serveur DHCP peut fournir suffisamment d'adresses IP pour ces nœuds temporaires. Pour en savoir plus, consultez la section Adresses IP requises pour les clusters d'administrateur et d'utilisateur.

IP statiques

Lors d'une mise à niveau, GKE On-Prem crée un nœud temporaire dans le cluster d'administrateur et un nœud temporaire dans chaque cluster d'utilisateur associé. Pour votre cluster d'administrateur et chacun de vos clusters d'utilisateur, vérifiez que vous avez réservé suffisamment d'adresses IP. Pour chaque cluster, vous devez avoir réservé au moins une adresse IP de plus que le nombre de nœuds de cluster. Pour en savoir plus, consultez la section Configurer des adresses IP statiques.

Déterminez le nombre de nœuds dans votre cluster d'administrateur :

kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] get nodes

[ADMIN_CLUSTER_KUBECONFIG] est le chemin d'accès au fichier kubeconfig de votre cluster d'administrateur.

Ensuite, affichez les adresses réservées pour votre cluster d'administrateur :

kubectl get cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -o yaml

Dans le résultat, dans le champ reservedAddresses, vous pouvez voir le nombre d'adresses IP réservées pour les nœuds du cluster d'administrateur. Par exemple, le résultat suivant indique que cinq adresses IP sont réservées aux nœuds du cluster d'administrateur :

...
reservedAddresses:
- gateway: 21.0.135.254
  hostname: admin-node-1
  ip: 21.0.133.41
  netmask: 21
- gateway: 21.0.135.254
  hostname: admin-node-2
  ip: 21.0.133.50
  netmask: 21
- gateway: 21.0.135.254
  hostname: admin-node-3
  ip: 21.0.133.56
  netmask: 21
- gateway: 21.0.135.254
  hostname: admin-node-4
  ip: 21.0.133.47
  netmask: 21
- gateway: 21.0.135.254
  hostname: admin-node-5
  ip: 21.0.133.44
  netmask: 21

Le nombre d'adresses IP réservées doit être supérieur (au minimum +1) au nombre de nœuds du cluster d'administrateur. Si ce n'est pas le cas, vous pouvez réserver une adresse supplémentaire en modifiant l'objet Cluster.

Ouvrez l'objet Cluster pour le modifier :

kubectl edit cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG]

Sous reservedAddresses, ajoutez un bloc supplémentaire comportant gateway, hostname, ip et netmask.

Suivez la même procédure pour chacun de vos clusters d'utilisateur.

Pour déterminer le nombre de nœuds dans un cluster d'utilisateur :

kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] get nodes

[USER_CLUSTER_KUBECONFIG] est le chemin d'accès au fichier kubeconfig de votre cluster d'utilisateur.

Pour afficher les adresses réservées pour un cluster d'utilisateur :

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

où :

  • [ADMIN_CLUSTER_KUBECONFIG] est le chemin d'accès au fichier kubeconfig de votre cluster d'administrateur.

  • [USER_CLUSTER_NAME] est le nom du cluster d'utilisateur.

Pour modifier l'objet Cluster d'un cluster d'utilisateur :

kubectl edit cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
-n [USER_CLUSTER_NAME] [USER_CLUSTER_NAME]

(Facultatif) Désactiver les nouvelles fonctionnalités vSphere

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.

Si vous devez désactiver une nouvelle fonctionnalité qui a été automatiquement activée dans une nouvelle version de GKE On-Prem et qui est pilotée par le fichier de configuration, effectuez la procédure ci-après 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 notez le champ de la fonctionnalité. Fermez le fichier.

  3. Ouvrez le fichier de configuration actuel et ajoutez le champ de la nouvelle fonctionnalité. Définissez la valeur du champ sur false ou une valeur équivalente.

  4. Enregistrez le fichier de configuration.

Consultez les notes de version avant de mettre à niveau vos clusters. Vous ne pouvez pas modifier de manière déclarative la configuration d'un cluster existant après sa mise à niveau.

Mettre à niveau votre cluster d'administrateur

Suivez les étapes décrites dans cette section sur votre nouveau poste de travail administrateur.

Rappelez-vous que la version cible de la mise à niveau doit être identique à la version gkeadm.

Exécutez la commande suivante :

gkectl upgrade admin \
--kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
--config [ADMIN_CLUSTER_CONFIG_FILE] \
[FLAGS]

où :

  • [ADMIN_CLUSTER_KUBECONFIG] est le fichier kubeconfig du cluster d'administrateur.

  • [ADMIN_CLUSTER_CONFIG_FILE] est le fichier de configuration du cluster d'administrateur GKE On-Prem sur votre nouveau poste de travail administrateur.

  • [FLAGS] est un ensemble facultatif d'options. Par exemple, vous pouvez inclure l'option --skip-validation-infra pour ignorer la vérification de votre infrastructure vSphere.

Mettre à niveau un cluster d'utilisateur

Suivez les étapes décrites dans cette section sur votre nouveau poste de travail administrateur.

Rappelez-vous que la version cible de la mise à niveau doit être identique à la version gkeadm.

gkectl

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

où :

  • [ADMIN_CLUSTER_KUBECONFIG] est le fichier kubeconfig du cluster d'administrateur.

  • [CLUSTER_NAME] est le nom du cluster utilisateur que vous mettez à niveau.

  • [USER_CLUSTER_CONFIG_FILE] est le fichier de configuration de cluster d'utilisateur GKE On-Prem sur votre nouveau poste de travail administrateur.

  • [FLAGS] est un ensemble facultatif d'options. Par exemple, vous pouvez inclure l'option --skip-validation-infra pour ignorer la vérification de votre infrastructure vSphere.

Console

Vous pouvez choisir d'enregistrer vos clusters d'utilisateur avec lq console Google Cloud lors de l'installation ou après les avoir créés. Depuis le menu GKE de la console Google Cloud, vous pouvez afficher vos clusters GKE On-Prem enregistrés et vos clusters Google Kubernetes Engine et vous y connecter.

Lorsqu'une mise à niveau devient disponible pour les clusters d'utilisateur GKE On-Prem, une notification s'affiche dans la console Google Cloud. 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 la console Google Cloud.

    Accéder au menu de GKE

  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 [USER_CLUSTER_CONFIG_FILE] est le fichier de configuration de cluster d'utilisateur GKE On-Prem sur votre nouveau poste de travail administrateur.

Reprendre une mise à niveau

Si la mise à niveau d'un cluster d'utilisateur est interrompue après la mise à niveau du cluster d'administrateur, vous pouvez la reprendre en exécutant la même commande de mise à niveau avec l'option --skip-validation-all :

gkectl upgrade cluster \
--kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
--config [USER_CLUSTER_CONFIG_FILE] \
--cluster-name [CLUSTER_NAME] \
--skip-validation-all

Reprendre une mise à niveau d'un 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.

Créer un cluster d'utilisateur après une mise à niveau

Après avoir mis à niveau votre poste de travail et votre cluster d'administrateur, tous les clusters d'utilisateur que vous créez doivent disposer de la même version que la version cible de la mise à niveau.

Problèmes connus

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

Version 1.1.0-gke.6, 1.2.0-gke.6 : champ stackdriver.proxyconfigsecretname supprimé

Le champ stackdriver.proxyconfigsecretname a été supprimé dans la version 1.1.0-gke.6. Les vérifications préliminaires de GKE On-Prem renvoient une erreur si le champ est présent dans votre fichier de configuration.

Pour contourner ce problème, avant de procéder à la mise à niveau vers la version 1.2.0-gke.6, supprimez le champ proxyconfigsecretname de votre fichier de configuration.

Stackdriver fait référence à une ancienne version

Avant la version 1.2.0-gke.6, un problème connu empêchait Stackdriver de mettre à jour sa configuration après les mises à niveau du cluster. Stackdriver fait toujours référence à une ancienne version, ce qui empêche Stackdriver de recevoir les dernières fonctionnalités de son pipeline de télémétrie. Ce problème peut compliquer le dépannage des clusters pour l'assistance Google.

Après avoir mis à niveau les clusters vers la version 1.2.0-gke.6, exécutez la commande suivante sur les clusters d'administrateur et d'utilisateur :

kubectl --kubeconfig=[KUBECONFIG] \
-n kube-system --type=json patch stackdrivers stackdriver \
-p '[{"op":"remove","path":"/spec/version"}]'

[KUBECONFIG] est le chemin d'accès au fichier kubeconfig du cluster.

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.2.0-gke.6 : Prometheus et Grafana désactivés après la mise à niveau

Lors de la mise à niveau des clusters d'utilisateur, Prometheus et Grafana sont automatiquement désactivés. Cependant, les données de configuration et de métriques sont conservées. Dans les clusters d'administrateur, Prometheus et Grafana restent activés.

Pour obtenir des instructions, consultez les notes de version de GKE On-Prem.

Version 1.1.2-gke.0 : les nœuds de cluster d'utilisateur supprimés ne sont pas retirés du datastore vSAN

Pour obtenir des instructions, consultez les notes de version de GKE On-Prem.

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. Un problème connu nécessite que vous fournissiez le chemin UUID (Universally Unique Identifier) du dossier, et non le chemin du fichier, à vcenter.datadisk. Cette incohérence peut entraîner l'échec des mises à niveau.

Pour obtenir des instructions, consultez les notes de version de GKE On-Prem.

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 à partir de la console Google Cloud :

  • 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 la console Google Cloud. Pour utiliser OIDC, vous devrez peut-être fournir une valeur d'espace réservé pour clientsecret :

oidc:
  clientsecret: "secret"

Les nœuds ne parviennent pas à terminer leur processus de mise à niveau

Si des objets PodDisruptionBudget sont configurés pour ne pas autoriser d'autres interruptions, les mises à niveau de nœuds peuvent échouer à passer à la version du plan de contrôle après plusieurs tentatives. Pour éviter cet échec, nous vous recommandons d'effectuer un scaling à la hausse de Deployment ou HorizontalPodAutoscaler afin de permettre au nœud de se drainer tout en respectant la configuration PodDisruptionBudget.

Pour afficher tous les objets PodDisruptionBudget qui n'autorisent aucune interruption, procédez comme suit :

kubectl get poddisruptionbudget --all-namespaces -o jsonpath='{range .items[?(@.status.disruptionsAllowed==0)]}{.metadata.name}/{.metadata.namespace}{"\n"}{end}'

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 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 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 sont disponibles.

Si votre environnement vSphere ne remplit pas les conditions précédentes, vous pouvez toujours mettre à niveau un cluster d'utilisateur de la version 1.3.x à la version 1.4.x, mais vous devez désactiver les groupes d'anti-affinité. Pour en savoir plus, consultez ce problème connu dans les notes de version de GKE On-Prem.

Temps d'arrêt

À 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 et les charges de travail des clusters d'utilisateur continuent de 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 des clusters d'utilisateur ne font pas l'objet de temps d'arrêt significatifs. 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 effectuer de nouvelles tentatives 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 d'anti-affinité appropriées.

Dépannage

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

Nouveaux nœuds créés, mais non opérationnels

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 page Diagnostiquer les problèmes de cluster.

Exécuter des commandes gkectl de manière détaillée

-v5

Consigner des erreurs gkectl dans stderr

--alsologtostderr

Localiser les journaux gkectl sur le poste de travail administrateur

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

/home/ubuntu/.config/gke-on-prem/logs

Localiser des journaux de l'API Cluster dans le cluster d'administrateur

Si une VM ne démarre pas après le démarrage du plan de contrôle d'administrateur, vous pouvez essayer de la déboguer en inspectant les journaux des contrôleurs de l'API Cluster dans le cluster d'administrateur :

  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