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

Cette page explique comment examiner les problèmes de création, de mise à niveau et de redimensionnement de Anthos clusters on VMware (GKE On-Prem).

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, Anthos clusters on VMware crée un cluster d'amorçage temporaire. Après une installation réussie, Anthos clusters on VMware 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 le cluster d'amorçage.

Si vous transmettez --cleanup-external-cliuster=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

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

Après une installation, Anthos clusters on VMware génère un fichier kubeconfig nommé internal-cluster-kubeconfig-debug dans le répertoire d'accueil du 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

Anthos Clusters on VMware crée une machine et l'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 l'opération échoue, Anthos clusters on 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.

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, Anthos clusters on 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é

En arrière-plan, Anthos clusters on VMware 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.

Dans ce cas, enregistrez le PDB et supprimez-le du cluster avant de tenter la mise à niveau. Vous pourrez ensuite rajouter le PDB une fois la mise à niveau terminée.

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 ces commandes pour recréer le fichier kubeconfig de cluster d'utilisateur :

KUBECONFIG_SECRET_NAME=$(kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secrets -n USER_CLUSTER_NAME | grep admin-kubeconfig | cut -d' ' -f1)

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secrets -n USER_CLUSTER_NAME $KUBECONFIG_SECRET_NAME \
  -o jsonpath='{.data.kubeconfig\.conf}' | base64 -d | sed -r "s/kube-apiserver.*local\./USER_CLUSTER_VIP/" > new_user_kubeconfig

Remplacez les éléments suivants :

USER_CLUSTER_VIP : adresse IP virtuelle principale de l'utilisateur.
USER_CLUSTER_NAME : nom du cluster d'utilisateur.
ADMIN_CLUSTER_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur.