Dépannage : diagnostiquer et réinitialiser des clusters

Vous pouvez diagnostiquer ou vérifier les clusters pour déboguer les problèmes et capturer un instantané de l'état du cluster. En outre, si une installation est partiellement réussie, mais que le cluster renvoie des erreurs ou ne fonctionne pas correctement, vous pouvez essayer de réinitialiser le cluster.

Diagnostiquer les clusters avec bmctl check cluster

Vous pouvez capturer l'état de vos clusters à l'aide de la commande bmctl check cluster. Les options de la commande vous permettent de choisir son champ d'application afin d'obtenir des informations précises.

Les informations de diagnostic peuvent vous aider à détecter les problèmes et à déboguer vos déploiements plus efficacement. La commande capture tous les fichiers de configuration des clusters et de nœuds pertinents pour le champ d'application défini, puis regroupe les informations dans une archive tar unique.

bmctl check cluster --snapshot --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG

Cette commande génère une archive tar contenant les informations de débogage pertinentes de tous les composants et machines système du cluster que vous avez spécifié.

ADMIN_KUBECONFIG spécifie le chemin d'accès au fichier kubeconfig, et CLUSTER_NAME spécifie le nom du cluster.

Vous pouvez modifier le champ d'application des informations de diagnostic collectées à l'aide des options de commande suivantes :

  • L'option --snapshot-scenario all augmente le champ d'application de l'instantané de diagnostic pour inclure tous les pods du cluster spécifié :
bmctl check cluster --snapshot --snapshot-scenario all --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG
  • L'option --snapshot-dry-run fonctionne conjointement avec l'option --snapshot-config string. L'option --snapshot-dry-run permet de générer un fichier de configuration que vous pouvez modifier afin de définir un champ d'application de diagnostic personnalisé. Votre champ d'application peut inclure des pods, des espaces de noms ou des commandes de nœud spécifiques.

Après avoir modifié le fichier de sortie créé avec l'option --snapshot-dry-run, vous pouvez l'utiliser comme entrée pour diagnostiquer le champ d'application spécifique avec l'option --snapshot-config string, décrite ci-dessous. Si vous omettez cette option, une configuration par défaut est appliquée.

bmctl check cluster --snapshot --snapshot-dry-run --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG
  • L'option --snapshot-config indique à la commande bmctl d'utiliser les options de champ d'application spécifiées dans un fichier de configuration d'instantané. En règle générale, vous créez le fichier de configuration de l'instantané avec l'option --snapshot-dry-run.
bmctl check cluster --snapshot --snapshot-config SNAPSHOT_CONFIG_FILE --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG

Réinitialiser les clusters avec bmctl reset cluster

Lorsqu'un cluster ne s'installe pas correctement, vous pouvez essayer de rétablir l'état propre des nœuds en le réinitialisant. Vous pouvez ensuite réinstaller le cluster après avoir modifié la configuration.

Pour réinitialiser un cluster, exécutez la commande suivante :

bmctl reset --cluster CLUSTER_NAME

La commande reset s'applique à l'ensemble du cluster. Il n'existe aucune option permettant de cibler un sous-ensemble de nœuds dans un cluster.

Le résultat de la commande ressemble à ceci :

bmctl reset -c cluster1
Creating bootstrap cluster... OK
Deleting GKE Hub member admin in project my-gcp-project...
Successfully deleted GKE Hub member admin in project my-gcp-project
Loading images... OK
Starting reset jobs...
Resetting: 1    Completed: 0    Failed: 0
...
Resetting: 0    Completed: 1    Failed: 0
Flushing logs... OK

Réinitialiser les détails du cluster

Lors de la réinitialisation, bmctl tente d'abord de supprimer l'enregistrement de l'abonnement GKE Hub, puis nettoie les nœuds concernés.

Lors de la réinitialisation, les installations de stockage et les données provenant de anthos-system StorageClass sont également supprimées.

Pour tous les nœuds, bmctl exécute kubeadm reset, supprime les interfaces de tunnel utilisées pour la mise en réseau du cluster, puis supprime les répertoires suivants :

  • /etc/kubernetes
  • /etc/cni/net.d
  • /root/.kube
  • /var/lib/kubelet

Pour les nœuds d'équilibreur de charge, bmctl effectue également les actions suivantes :

  • désactive les services keepalived et haproxy ;
  • supprime les fichiers de configuration pour keepalived et haproxy.

L'outil de réinitialisation s'attend à ce que le fichier de configuration du cluster se trouve à l'emplacement suivant dans le répertoire de travail actuel : 

bmctl-workspace/cluster name/cluster name.yaml