Résoudre les problèmes de création et de mise à niveau du cluster

Cette page explique comment examiner les problèmes liés à la création, à la mise à niveau et au redimensionnement des clusters dans GKE sur VMware.

Comportement de journalisation par défaut pour `gkectl` et `gkeadm`

Pour gkectl et gkeadm, l'utilisation des paramètres de journalisation par défaut est suffisante :

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.
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 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 des emplacements autres que ceux par défaut pour les fichiers journaux

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 examiner le problème en inspectant les journaux du pod des contrôleurs d'API Cluster du cluster d'administrateur.

Recherchez le nom du pod des contrôleurs d'API Cluster:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \
    get pods | grep clusterapi-controllers

Affichez les journaux de vsphere-controller-manager. Commencez par spécifier le pod, mais sans le conteneur :

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \
    logs POD_NAME

Le résultat vous indique que vous devez spécifier un conteneur et qu'il vous donne les noms des conteneurs du pod. Exemple :

... a container name must be specified ...,
choose one of: [clusterapi-controller-manager vsphere-controller-manager rbac-proxy]

Choisissez un conteneur et affichez ses journaux:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \
    logs POD_NAME --container CONTAINER_NAME

Résoudre les problèmes liés à vSphere à l'aide de `govc`

Vous pouvez utiliser govc pour examiner les problèmes liés à vSphere. Par exemple, vous pouvez confirmer les autorisations et l'accès de vos comptes utilisateur vCenter, et collecter les journaux vSphere.

Déboguer à l'aide des journaux du cluster d'amorçage

Lors de l'installation, GKE sur VMware crée un cluster d'amorçage temporaire. Après une installation réussie, GKE sur VMware supprime le cluster d'amorçage, vous laissant votre cluster d'administrateur et votre cluster d'utilisateur. En règle générale, vous ne devriez avoir aucune raison d'interagir avec le cluster d'amorçage.

Si vous transmettez --cleanup-external-cluster=false à gkectl create cluster, le cluster d'amorçage n'est pas supprimé et vous pouvez utiliser les journaux du cluster d'amorçage pour déboguer les problèmes d'installation.

Recherchez les noms des pods en cours d'exécution dans l'espace de noms kube-system:

kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl get pods -n kube-system

Affichez les journaux d'un pod:

kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl -n kube-system get logs POD_NAME

Pour obtenir les journaux directement à partir du cluster d'amorçage, vous pouvez exécuter la commande suivante lors de la création, de la mise à jour et de la mise à niveau du cluster:
```
docker exec -it gkectl-control-plane bash
```
La commande ouvre un terminal à l'intérieur du conteneur gkectl-control-plane qui s'exécute dans le cluster d'amorçage.

Pour inspecter les journaux kubelet et containerd, exécutez les commandes suivantes et recherchez les erreurs ou les avertissements dans le résultat:
```
systemctl status -l kubelet
journalctl --utc -u kubelet
systemctl status -l containerd
journalctl --utc -u containerd
```

Effectuer le rollback d'un pool de nœuds après une mise à niveau

Si vous mettez à niveau un cluster d'utilisateur, puis constatez un problème avec les nœuds du cluster, vous pouvez effectuer un rollback des pools de nœuds sélectionnés vers la version précédente.

Le rollback des pools de nœuds sélectionnés est compatible avec les pools de nœuds Ubuntu et COS, mais pas pour les pools de nœuds Windows.

La version d'un pool de nœuds peut être identique à la version du plan de contrôle du cluster d'utilisateur ou une version mineure plus ancienne. Par exemple, si le plan de contrôle est la version 1.14, les pools de nœuds peuvent être la version 1.14 ou 1.13.

Afficher les versions de pool de nœuds disponibles

Supposons que vous ayez récemment mis à niveau les nœuds de calcul et le plan de contrôle de votre cluster d'utilisateur de la version 1.13.1-gke.35 vers la version 1.14.0, et que vous découvriez un problème avec les nœuds de calcul mis à niveau. Vous décidez donc d'effectuer un rollback d'un ou de plusieurs pools de nœuds vers la version que vous exécutiez précédemment : 1.13.1-gke.35.

Vérifiez que la version précédente est disponible pour le rollback:

gkectl version --cluster-name USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Le résultat affiche la version actuelle et la version précédente de chaque pool de nœuds. Exemple :

user cluster version: 1.14.0-gke.x

node pools:
- pool-1:
  - version: 1.14.0-gke.x
  - previous version: 1.13.1-gke.35
- pool-2:
  - version: 1.14.0-gke.x
  - previous version: 1.13.1-gke.35

available node pool versions:
- 1.13.1-gke.35
- 1.14.0-gke.x

Effectuer un rollback des pools de nœuds

Vous pouvez effectuer le rollback d'un pool de nœuds à la fois ou de plusieurs pools de nœuds en une seule étape.

Dans le fichier de configuration de votre cluster d'utilisateur, dans un ou plusieurs pools de nœuds, définissez gkeOnPremVersion sur la version précédente (1.13.1-gke.35 dans cet exemple) :

nodePools:
- name: pool-1
  cpus: 4
  memoryMB: 8192
  replicas: 3
  gkeOnPremVersion: 1.13.1-gke.35
  ...

Mettez à jour le cluster pour effectuer le rollback des pools de nœuds :

gkectl update cluster --config USER_CLUSTER_CONFIG --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Vérifiez que le rollback:

gkectl version --cluster-name USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Par exemple, le résultat suivant montre que pool-1 a été restauré vers la version 1.13.1-gke.35.

user cluster version: 1.14.0-gke.x

node pools:
- pool-1:
  - version: 1.13.1-gke.35
  - previous version: 1.14.0-gke.x
- pool-2:
  - version: 1.14.0-gke.x
  - previous version: 1.13.1-gke.35

available node pool versions:
- 1.13.1-gke.35
- 1.14.0-gke.x

Effectuer la mise à niveau vers une nouvelle version du correctif

Supposons que le problème soit résolu dans une nouvelle version du correctif, par exemple 1.14.1. Vous pouvez maintenant mettre à niveau tous les pools de nœuds et le plan de contrôle vers la nouvelle version du correctif.

Dans le fichier de configuration de votre cluster d'utilisateur:

Définissez la valeur de gkeOnPremVersion sur la nouvelle version du correctif (1.14.1-gke.x) dans cet exemple.
Pour chaque pool de nœuds, supprimez le champ gkeOnPremVersion ou définissez-le sur la chaîne vide. Si aucune version n'est spécifiée pour un pool de nœuds, la version du pool de nœuds est définie par défaut sur la version spécifiée pour le cluster.

Exemple :

gkeOnPremVersion: 1.14.1-gke.x

nodePools:
- name: pool-1
  cpus: 4
  memoryMB: 8192
  replicas: 3
  gkeOnPremVersion: ""
- name: pool-2
  cpus: 8
  memoryMB: 8192
  replicas: 2
  gkeOnPremVersion: ""

Exécutez gkectl prepare et gkectl upgrade cluster comme décrit dans la section Mettre à niveau GKE sur VMware.

Vérifiez la nouvelle version du cluster et affichez les versions désormais disponibles pour le rollback:

gkectl version --cluster-name USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Exemple de résultat :

user cluster version: 1.14.1-gke.y

node pools:
- pool-1:
  - version: 1.14.1-gke.y
  - previous version: 1.13.1-gke.35
- pool-2:
  - version: 1.14.1-gke.y
  - previous version: 1.13.1-gke.35

available node pool versions:
- 1.13.1-gke.35
- 1.14.0-gke.x
- 1.14.1-gke.y

Résoudre les problèmes F5 BIG-IP à l'aide du fichier kubeconfig interne

Après une installation, GKE sur VMware 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 au fichier kubeconfig 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 serveur d'API Kubernetes. Vous pouvez utiliser le fichier internal-cluster-kubeconfig-debug pour résoudre les problèmes F5 BIG-IP.

Impossible de redimensionner un cluster d'utilisateur

Si un redimensionnement de cluster d'utilisateur échoue:

Recherchez les noms des MachineDeployments et des Machines:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get machinedeployments --all-namespaces
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get machines --all-namespaces

Décrivez un MachineDeployment pour afficher ses journaux:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machinedeployment MACHINE_DEPLOYMENT_NAME

Recherchez les erreurs sur les machines nouvellement créées:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machine MACHINE_NAME

Aucune adresse ne peut être allouée au redimensionnement du cluster

Ce problème se produit si le nombre d'adresses IP disponibles est insuffisant pour redimensionner un cluster d'utilisateur.

kubectl describe machine affiche l'erreur suivante:

Events:
Type     Reason  Age                From                    Message
----     ------  ----               ----                    -------
Warning  Failed  9s (x13 over 56s)  machineipam-controller  ipam: no addresses can be allocated

Pour résoudre ce problème, allouez d'autres adresses IP pour le cluster. Supprimez ensuite la machine concernée :

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete machine MACHINE_NAME

GKE sur VMware crée une machine et lui attribue l'une des nouvelles adresses IP disponibles.

Un nombre suffisant d'adresses IP est alloué, mais la machine ne parvient pas à s'enregistrer auprès du cluster

Ce problème peut survenir en cas de conflit d'adresses IP. Par exemple, une adresse IP que vous avez spécifiée pour une machine est utilisée pour un équilibreur de charge.

Pour résoudre ce problème, mettez à jour le fichier de bloc d'adresses IP du cluster afin que les adresses des machines n'entrent pas en conflit avec les adresses spécifiées dans votre fichier de configuration du cluster. ou votre fichier de blocs d'adresses IP Seesaw.

L'instantané est créé automatiquement en cas d'échec de création ou de mise à niveau du cluster d'administrateur.

Si vous tentez de créer ou de mettre à niveau un cluster d'administrateur et que cette opération échoue, GKE sur VMware prend un instantané externe du cluster d'amorçage, qui est un cluster temporaire utilisé pour créer ou mettre à niveau le cluster d'administrateur. Bien que cet instantané du cluster d'amorçage soit semblable à l'instantané pris en exécutant la commande gkectl diagnose snapshot sur le cluster d'administrateur, il présente l'avantage d'être déclenché automatiquement. Cet instantané du cluster d'amorçage contient des informations de débogage importantes pour le processus de création et de mise à niveau du cluster d'administrateur. Vous pouvez fournir cet instantané à l'assistance Google Cloud si nécessaire.

L'instantané externe inclut les journaux de pod de la ressource onprem-admin-cluster-controller que vous pouvez afficher pour déboguer les problèmes de création ou de mise à niveau du cluster. Les journaux sont stockés dans un fichier distinct, par exemple:

kubectl_logs_onprem-admin-cluster-controller-6767f6597-nws8g_--container_onprem-admin-cluster-controller_--kubeconfig_.home.ubuntu..kube.kind-config-gkectl_--namespace_kube-system

Les vérifications d'état sont exécutées automatiquement en cas d'échec de la mise à niveau du cluster.

Si vous tentez de mettre à niveau un cluster d'administrateur ou d'utilisateur et que cette opération échoue, GKE sur VMware exécute automatiquement la commande gkectl diagnose cluster sur le cluster.

Pour ignorer le diagnostic automatique, transmettez l'option --skip-diagnose-cluster à gkectl upgrade.

Le processus de mise à niveau est bloqué

GKE sur VMware, en arrière-plan, utilise la commande Kubernetes drain lors d'une mise à niveau. Cette procédure drain peut être bloquée par un déploiement si une seule instance dupliquée bénéficie d'un PodDisruptionBudget (PDB) créé avec minAvailable: 1.

À partir de la version 1.13 de GKE sur VMware, vous pouvez vérifier les échecs via les événements de pod Kubernetes.

Recherchez les noms des machines:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get machines --all-namespaces

Recherchez les erreurs à l'aide de la commande kubectl describe machine:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machine MACHINE_NAME

Voici un exemple de résultat:

Events:
  Type     Reason              Age    From                Message
  ----     ------              ----   ----                -------
  Warning  PodEvictionTooLong  3m49s  machine-controller  Waiting too long(12m10.284294321s) for pod(default/test-deployment-669b85c4cc-z8pz7) eviction.

Pour une analyse plus détaillée de l'état des objets machine, exécutez gkectl diagnose cluster:

...
Checking machineset...SUCCESS
Checking machine objects...FAILURE
    Reason: 1 machine objects error(s).
    Unhealthy Resources:
    Pod test-deployment-669b85c4cc-7zjpq: Pod cannot be evicted successfully. There is 1 related PDB.
...
Checking all poddisruptionbudgets...FAILURE
    Reason: 1 pod disruption budget error(s).
    Unhealthy Resources:
    PodDisruptionBudget test-pdb: default/test-pdb might be configured incorrectly, the total replicas(3) should be larger than spec.MinAvailable(3).
...
Some validation results were FAILURE or UNKNOWN. Check report above.

Pour résoudre ce problème, enregistrez le budget d'interruption de pod et supprimez-le du cluster avant d'effectuer la mise à niveau. Vous pourrez ensuite rajouter le PDB une fois la mise à niveau terminée.

Diagnostiquer l'état de la machine virtuelle

Si un problème survient lors de la création de la machine virtuelle, exécutez gkectl diagnose cluster pour obtenir un diagnostic de l'état de la machine virtuelle.

Voici un exemple de résultat :


- Validation Category: Cluster Healthiness
Checking cluster object...SUCCESS
Checking machine deployment...SUCCESS
Checking machineset...SUCCESS
Checking machine objects...SUCCESS
Checking machine VMs...FAILURE
    Reason: 1 machine VMs error(s).
    Unhealthy Resources:
    Machine [NODE_NAME]: The VM's UUID "420fbe5c-4c8b-705a-8a05-ec636406f60" does not match the machine object's providerID "420fbe5c-4c8b-705a-8a05-ec636406f60e".
    Debug Information:
    null
...
Exit with error:
Cluster is unhealthy!
Run gkectl diagnose cluster automatically in gkectl diagnose snapshot
Public page https://cloud.google.com/anthos/clusters/docs/on-prem/1.14/diagnose#overview_diagnose_snapshot

Pour en savoir plus, consultez Diagnostiquer les problèmes de cluster.

Recréer le fichier kubeconfig manquant du cluster d'utilisateur

Vous pouvez avoir besoin de recréer un fichier kubeconfig de cluster d'utilisateur dans plusieurs situations :

Si vous tentez de créer un cluster d'utilisateur et que l'opération de création échoue mais que vous souhaitez obtenir le fichier kubeconfig de cluster d'utilisateur.
Si le fichier kubeconfig de cluster d'utilisateur est manquant, par exemple après sa suppression.

Exécutez la commande suivante pour recréer le fichier kubeconfig du cluster d'utilisateur:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secrets -n admin \
  -o jsonpath='{.data.admin\.conf}' | base64 -d  > USER_CLUSTER_KUBECONFIG

Remplacez les éléments suivants :

USER_CLUSTER_KUBECONFIG: nom du nouveau fichier kubeconfig pour votre cluster d'utilisateur.
ADMIN_CLUSTER_KUBECONFIG: chemin d'accès au fichier kubeconfig pour votre cluster d'administrateur.