Résoudre les problèmes d'installation ou de mise à niveau du cluster

Cette page fournit des informations de dépannage si vous rencontrez des problèmes lors de l'installation ou de la mise à niveau de GKE sur Bare Metal.

Problèmes liés au cluster d'amorçage

Lorsque GKE sur Bare Metal crée ou met à niveau des clusters, il déploie un cluster Kubernetes dans Docker (genre) pour héberger temporairement les contrôleurs Kubernetes nécessaires à la création ou à la mise à niveau des clusters. Ce cluster temporaire est appelé cluster d'amorçage.

Si un cluster de genre existe déjà dans votre déploiement lorsque vous tentez de procéder à l'installation, GKE sur Bare Metal supprime ce cluster. La suppression ne se produit qu'après la réussite de l'installation ou de la mise à niveau. Pour conserver le cluster de genre existant même après une opération réussie, utilisez l'option --keep-bootstrap-cluster de bmctl.

GKE sur Bare Metal crée un fichier de configuration pour le cluster d'amorçage sous WORKSPACE_DIR/.kindkubeconfig. Vous ne pouvez vous connecter au cluster d'amorçage que lors de la création et de la mise à niveau du cluster.

Le cluster d'amorçage doit accéder à un dépôt Docker pour extraire des images. Par défaut, le registre est défini sur Container Registry, sauf si vous utilisez un registre privé. Lors de la création du cluster, bmctl crée les fichiers suivants :

  • bmctl-workspace/config.json : contient les identifiants du compte de service Google Cloud pour l'accès au registre. Les identifiants sont obtenus à partir du champ gcrKeyPath du fichier de configuration du cluster.

  • bmctl-workspace/config.toml : contient la configuration containerd dans le cluster de genre.

Déboguer le cluster d'amorçage

Pour déboguer le cluster d'amorçage, procédez comme suit :

  • Connectez-vous au cluster d'amorçage lors de sa création et de sa mise à niveau.
  • Récupérez les journaux du cluster d'amorçage.

Vous pouvez trouver les journaux de la machine que vous utilisez pour exécuter bmctl dans les dossiers suivants :

  • bmctl-workspace/CLUSTER_NAME/log/create-cluster-TIMESTAMP/bootstrap-cluster/
  • bmctl-workspace/CLUSTER_NAME/log/upgrade-cluster-TIMESTAMP/bootstrap-cluster/

Remplacez CLUSTER_NAME et TIMESTAMP par le nom de votre cluster et l'heure du système correspondant.

Pour obtenir les journaux directement à partir du cluster d'amorçage, vous pouvez exécuter la commande suivante lors de la création et de la mise à niveau du cluster :

docker exec -it bmctl-control-plane bash

La commande ouvre un terminal dans le conteneur de plan de contrôle bmctl qui s'exécute dans le cluster d'amorçage.

Pour inspecter les journaux kubelet et containerd, utilisez les commandes suivantes et recherchez toute erreur ou tout avertissement dans le résultat :

journalctl -u kubelet
journalctl -u containerd

Problèmes de mise à niveau des clusters

Lorsque vous mettez à niveau GKE sur Bare Metal, vous pouvez surveiller la progression et vérifier l'état de vos clusters et de vos nœuds. Les conseils suivants peuvent vous aider à déterminer si la mise à niveau se poursuit normalement ou s'il y a un problème.

Surveiller la progression de la mise à niveau

Utilisez la commande kubectl describe cluster pour afficher l'état d'un cluster pendant le processus de mise à niveau:

kubectl describe cluster CLUSTER_NAME \
    --namespace CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG

Remplacez les valeurs suivantes :

  • CLUSTER_NAME: nom de votre cluster.
  • CLUSTER_NAMESPACE: espace de noms de votre cluster.
  • ADMIN_KUBECONFIG: fichier kubeconfig d'administrateur
    • Par défaut, un cluster d'amorçage est utilisé pour les mises à niveau de clusters d'administrateur, hybrides et autonomes. Pour surveiller la progression de la mise à niveau lorsqu'un cluster d'amorçage est utilisé, spécifiez le chemin d'accès au fichier kubeconfig du cluster d'amorçage, .kindkubeconfig. Ce fichier se trouve dans le répertoire de l'espace de travail.

Examinez la section Status du résultat, qui présente une agrégation de l'état de mise à niveau du cluster. Si le cluster signale une erreur, consultez les sections suivantes pour identifier l'origine du problème.

Vérifier si les nœuds sont prêts

Utilisez la commande kubectl get nodes pour afficher l'état des nœuds d'un cluster lors du processus de mise à niveau:

kubectl get nodes --kubeconfig KUBECONFIG

Pour vérifier si un nœud a correctement terminé le processus de mise à niveau, consultez les colonnes VERSION et AGE dans la réponse de la commande. VERSION correspond à la version Kubernetes du cluster. Pour savoir quelle version de Kubernetes correspond à une version de GKE sur bare metal donnée, consultez le tableau dans la section Règles de compatibilité avec les versions.

Si le nœud affiche NOT READY, essayez de le connecter et vérifiez l'état du kubelet:

systemctl status kubelet

Vous pouvez également consulter les journaux de kubelet:

journalctl -u kubelet

Examinez la sortie de l'état du kubelet et consignez dans les messages les messages indiquant la raison pour laquelle le nœud présente un problème.

Vérifier le nœud en cours de mise à niveau

Pour vérifier quel nœud du cluster est en cours de mise à niveau, utilisez la commande kubectl get baremetalmachines:

kubectl get baremetalmachines --namespace CLUSTER_NAMESPACE \
  --kubeconfig ADMIN_KUBECONFIG

Remplacez les valeurs suivantes :

  • CLUSTER_NAMESPACE: espace de noms de votre cluster.
  • ADMIN_KUBECONFIG: fichier kubeconfig d'administrateur
    • Si un cluster d'amorçage est utilisé pour une mise à niveau administrateur, hybride ou autonome, spécifiez le fichier kubeconfig du cluster d'amorçage (bmctl-workspace/.kindkubeconfig).

L'exemple de résultat suivant montre que le nœud en cours de mise à niveau possède un ABM VERSION différent de DESIRED ABM VERSION:

NAME         CLUSTER    READY   INSTANCEID               MACHINE      ABM VERSION   DESIRED ABM VERSION
10.200.0.2   cluster1   true    baremetal://10.200.0.2   10.200.0.2   1.13.0        1.14.0
10.200.0.3   cluster1   true    baremetal://10.200.0.3   10.200.0.3   1.13.0        1.13.0

Vérifier quels nœuds sont en cours de drainage

Au cours du processus de mise à niveau, les nœuds sont drainés des pods et la planification est désactivée jusqu'à ce que le nœud soit correctement mis à niveau. Pour voir quels nœuds sont actuellement drainés des pods, utilisez la commande kubectl get nodes:

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG | grep "SchedulingDisabled"

Remplacez USER_CLUSTER_KUBECONFIG par le chemin d'accès au fichier kubeconfig du cluster d'utilisateur.

La colonne STATUS est filtrée à l'aide de la valeur grep pour n'afficher que les nœuds qui indiquent l'état SchedulingDisabled. Cet état indique que les nœuds sont en cours de drainage.

Vous pouvez également vérifier l'état du nœud à partir du cluster d'administrateur:

kubectl get baremetalmachines -n CLUSTER_NAMESPACE \
  --kubeconfig ADMIN_KUBECONFIG

Remplacez les valeurs suivantes :

  • CLUSTER_NAMESPACE: espace de noms de votre cluster.
  • ADMIN_KUBECONFIG: fichier kubeconfig d'administrateur
    • Si un cluster d'amorçage est utilisé pour une mise à niveau administrateur, hybride ou autonome, spécifiez le fichier kubeconfig du cluster d'amorçage (bmctl-workspace/.kindkubeconfig).

L'état du nœud en cours de drainage s'affiche dans la colonne MAINTENANCE.

Vérifier pourquoi un nœud est à l'état de drainage depuis longtemps

Utilisez l'une des méthodes de la section précédente pour identifier le nœud qui est drainé à l'aide de la commande kubectl get nodes. Exécutez la commande kubectl get pods et filtrez ce nom de nœud pour afficher des détails supplémentaires:

kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=NODE_NAME

Remplacez NODE_NAME par le nom du nœud en cours de drainage. Le résultat renvoie une liste des pods actuellement bloqués ou lents à drainer. La mise à niveau se poursuit, même avec des pods bloqués, lorsque le processus de drainage sur un nœud prend plus de 20 minutes.