Version 1.8. Cette version n'est plus compatible. Pour plus d'informations, consultez la politique de compatibilité avec les versions. Pour en savoir plus sur la mise à niveau vers la version 1.9, consultez la page Mettre à niveau Anthos sur solution Bare Metal dans la documentation de la version 1.9.

Versions compatibles : 1.14 | 1.13 | 1.12

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 le champ d'application de diagnostic de la commande afin d'obtenir des informations ciblées.

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_PATH

Remplacez les éléments suivants :

CLUSTER_NAME : nom du cluster cible.
ADMIN_KUBECONFIG_PATH : chemin d'accès au fichier kubeconfig du cluster d'administrateur

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é.

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_PATH

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_PATH

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_PATH

Diagnostiquer les clusters lorsque le cluster d'administrateur est inaccessible

En cas d'indisponibilité ou d'inaccessibilité du cluster d'administrateur, utilisez un fichier de configuration d'instantané pour prendre un instantané de cluster. Un fichier de configuration d'instantané est au format YAML. Le fichier de configuration inclut les champs suivants pour spécifier la manière dont les informations sont capturées pour votre cluster :

numOfParallelThreads : la routine d'instantané exécute généralement de nombreuses commandes. Plusieurs threads parallèles permettent d'assurer une exécution plus rapide de la routine. Nous vous recommandons de définir numOfParallelThreads sur 10, comme indiqué dans l'exemple suivant. Si vos instantanés prennent trop de temps, augmentez cette valeur.
excludeWords : l'instantané contient une grande quantité de données pour vos nœuds de cluster. Utilisez excludeWords pour réduire les risques de sécurité lorsque vous partagez votre instantané. Par exemple, excluez password pour que les chaînes de mot de passe correspondantes ne puissent pas être identifiées.
nodeCommands : cette section spécifie les informations suivantes :
- nodes : liste des adresses IP des nœuds de cluster à partir desquels vous souhaitez recueillir des informations. Pour créer un instantané lorsque le cluster d'administrateur n'est pas accessible, spécifiez au moins une adresse IP de nœud.
- commands : liste des commandes (et des arguments) à exécuter sur chaque nœud. Le résultat de chaque commande est inclus dans l'instantané.
nodeFiles : cette section spécifie les informations suivantes :
- nodes : liste des adresses IP des nœuds de cluster à partir desquels vous souhaitez collecter des fichiers. Pour créer un instantané lorsque le cluster d'administrateur n'est pas accessible, spécifiez au moins une adresse IP de nœud.
- files : liste de fichiers à récupérer à partir de chaque nœud. Lorsque les fichiers spécifiés se trouvent sur un nœud, ils sont inclus dans l'instantané.
nodeSSHKey : chemin d'accès à votre fichier de clé SSH pour vos nœuds. Ce champ est obligatoire pour créer un instantané lorsque le cluster d'administrateur n'est pas accessible.

Utilisez la commande suivante pour créer un instantané à l'aide d'un fichier de configuration d'instantané :

bmctl check cluster --snapshot --snapshot-config SNAPSHOT_CONFIG

Remplacez SNAPSHOT_CONFIG par le chemin d'accès à votre fichier de configuration d'instantané.

L'exemple de fichier de configuration d'instantané suivant affiche les commandes et les fichiers standards utilisés pour créer un instantané. Vous pouvez ajouter d'autres commandes et fichiers lorsque des informations de diagnostic supplémentaires sont nécessaires.

numOfParallelThreads: 10
excludeWords:
- password
nodeCommands:
- nodes:
  - 10.200.0.3
  - 10.200.0.4
  commands:
  - uptime
  - df --all --inodes
  - ip addr
  - ip neigh
  - iptables-save --counters
  - mount
  - ip route list table all
  - top -bn1 || true
  - docker info || true
  - docker ps -a || true
  - crictl ps -a || true
  - docker ps -a | grep anthos-baremetal-haproxy | cut -d ' ' -f1 | head -n 1 | xargs
    sudo docker logs || true
  - docker ps -a | grep anthos-baremetal-keepalived | cut -d ' ' -f1 | head -n 1 |
    xargs sudo docker logs || true
  - crictl ps -a | grep anthos-baremetal-haproxy | cut -d ' ' -f1 | head -n 1 | xargs
    sudo crictl logs || true
  - crictl ps -a | grep anthos-baremetal-keepalived | cut -d ' ' -f1 | head -n 1 |
    xargs sudo crictl logs || true
  - ps -edF
  - ps -eo pid,tid,ppid,class,rtprio,ni,pri,psr,pcpu,stat,wchan:14,comm,args,cgroup
  - conntrack --count
  - dmesg
  - systemctl status -l docker || true
  - journalctl --utc -u docker
  - journalctl --utc -u docker-monitor.service
  - systemctl status -l kubelet
  - journalctl --utc -u kubelet
  - journalctl --utc -u kubelet-monitor.service
  - journalctl --utc --boot --dmesg
  - journalctl --utc -u node-problem-detector
  - systemctl status -l containerd || true
  - journalctl --utc -u containerd
  - systemctl status -l docker.haproxy || true
  - journalctl --utc -u docker.haproxy
  - systemctl status -l docker.keepalived || true
  - journalctl --utc -u docker.keepalived
  - systemctl status -l container.haproxy || true
  - journalctl --utc -u container.haproxy
  - systemctl status -l container.keepalived || true
  - journalctl --utc -u container.keepalived
nodeFiles:
- nodes:
  - 10.200.0.3
  - 10.200.0.4
  files:
  - /proc/sys/fs/file-nr
  - /proc/sys/net/netfilter/nf_conntrack_max
  - /proc/sys/net/ipv4/conf/all/rp_filter
  - /lib/systemd/system/kubelet.service
  - /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
  - /lib/systemd/system/docker.service || true
  - /etc/systemd/system/containerd.service || true
  - /etc/docker/daemon.json || true
  - /etc/containerd/config.toml || true
  - /etc/systemd/system/container.keepalived.service || true
  - /etc/systemd/system/container.haproxy.service || true
  - /etc/systemd/system/docker.keepalived.service || true
  - /etc/systemd/system/docker.haproxy.service || true
nodeSSHKey: ~/.ssh/id_rsa # path to your ssh key file to each nodes

Créer un instantané pour l'installation/la mise à niveau bloquée du cluster d'administrateur

Lors de l'installation de clusters d'administrateur/hybrides/autonomes, si bmctl est bloqué sur la sortie suivante

Préparation du cluster kubeconfig
Préparation du cluster
Préparation des pools de nœuds

ou lors de la mise à niveau de clusters d'administrateur, hybrides, autonomes,

Mise à niveau en cours

vous pouvez exécuter la commande suivante pour prendre un instantané à l'aide du cluster d'amorçage.

bmctl check cluster --snapshot --kubeconfig <var>WORKSPACE_DIR</var>/.kindkubeconfig --cluster <var>CLUSTER_NAME</var>

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.

Réinitialiser des clusters autogérés

Pour réinitialiser un cluster autogéré, tel qu'un cluster d'administrateur, exécutez la commande suivante :

bmctl reset --cluster CLUSTER_NAME

Remplacez CLUSTER_NAME par le nom du cluster que vous réinitialisez.

Réinitialiser des clusters d'utilisateur

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

bmctl reset --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG_PATH

Remplacez CLUSTER_NAME par le nom du cluster d'utilisateur que vous réinitialisez et remplacez ADMIN_KUBECONFIG_PATH par le chemin d'accès au fichier kubeconfig du cluster d'administrateur associé. bmctl accepte l'utilisation de --kubeconfig comme alias pour l'option --admin-kubeconfig.

Réinitialiser les détails du cluster

Quel que soit le type de cluster, la commande de réinitialisation 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 bmctl cluster reset ressemble à ceci :

bmctl reset --cluster 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

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