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. La commande bmctl check cluster
ne peut pas être utilisée sur les clusters d'utilisateur.
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 commandebmctl
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
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. La commande bmctl reset cluster
ne peut pas être utilisée sur les clusters d'utilisateur.
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
ethaproxy
; - supprime les fichiers de configuration pour
keepalived
ethaproxy
.
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