L'outil gkectl comporte deux commandes permettant de résoudre les problèmes liés aux clusters : gkectl diagnose cluster et gkectl diagnose snapshot. Ces commandes fonctionnent aussi bien avec les clusters d'administrateur que d'utilisateur. Ce document explique comment utiliser la commande gkectl diagnose pour diagnostiquer les problèmes dans vos clusters.
Pour en savoir plus sur l'utilisation de la commande gkectl diagnose snapshot afin de créer des instantanés pouvant aider Cloud Customer Care à diagnostiquer les problèmes, consultez la page Créer des instantanés pour diagnostiquer des clusters.
gkectl diagnose cluster
Cette commande vérifie l'état de votre cluster et signale des erreurs. La commande exécute des vérifications de l'état sur les composants suivants:
- vCenter
- Certificat
- DRS
- Groupes d'anti-affinité
- Réseau
- Version
- de données moyen
- Datastore
- ResourcePool
- Dossier
- Réseau
- Équilibreur de charge (F5, Seesaw ou manuel)
- Cluster d'utilisateur et pool de nœuds
- Objets du cluster
- Disponibilité du serveur Konnectivity du cluster d'utilisateur
- Objets machine et nœuds de cluster correspondants
- Pods dans les espaces de noms
kube-systemetgke-system - Plan de contrôle
- Volumes persistants vSphere dans le cluster
- Processeur virtuel de cluster d'utilisateur et d'administrateur et signaux de conflit de mémoire
- Alarmes préconfigurées d'utilisation du processeur hôte et de mémoire du cluster d'utilisateur et d'administrateur ESXi.
- Heure de la journée
- Règle de réseau de nœud pour un cluster avec Dataplane V2 activé
- État général de l'agent de nœud Dataplane V2
Diagnostiquer un cluster d'administrateur
Pour diagnostiquer un cluster d'administrateur, spécifiez le chemin d'accès à votre cluster d'administrateur:
gkectl diagnose cluster --kubeconfig=ADMIN_CLUSTER_KUBECONFIG
Remplacez ADMIN_CLUSTER_KUBECONFIG par le chemin d'accès au fichier kubeconfig de votre cluster d'administrateur.
L'exemple de résultat suivant est renvoyé par la commande gkectl diagnose cluster:
Preparing for the diagnose tool...
Diagnosing the cluster......DONE
- Validation Category: Admin Cluster Connectivity
Checking VMs TOD (availability)...SUCCESS
Checking Konnectivity Server (readiness)...SUCCESS
- Validation Category: Admin Cluster F5 BIG-IP
Checking f5 (credentials, partition)...SUCCESS
- Validation Category: Admin Cluster VCenter
Checking Credentials...SUCCESS
Checking DRS enabled...SUCCESS
Checking Hosts for AntiAffinityGroups...SUCCESS
Checking Version...SUCCESS
Checking Datacenter...SUCCESS
Checking Datastore...SUCCESS
Checking Resource pool...SUCCESS
Checking Folder...SUCCESS
Checking Network...SUCCESS
- Validation Category: Admin Cluster
Checking cluster object...SUCCESS
Checking machine deployment...SUCCESS
Checking machineset...SUCCESS
Checking machine objects...SUCCESS
Checking kube-system pods...SUCCESS
Checking anthos-identity-service pods...SUCCESS
Checking storage...SUCCESS
Checking resource...SUCCESS
Checking virtual machine resource contention...SUCCESS
Checking host resource contention...SUCCESS
All validation results were SUCCESS.
Cluster is healthy!
En cas de problème avec une adresse IP virtuelle (VIP) dans le cluster cible, utilisez l'option --config pour fournir le fichier de configuration du cluster d'administrateur et fournir plus d'informations de débogage.
gkectl diagnose cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config CLUSTER_CONFIG
Remplacez CLUSTER_CONFIG par le chemin d'accès du fichier de configuration du cluster d'administrateur ou d'utilisateur.
L'exemple de résultat suivant montre que la commande gkectl diagnose cluster peut désormais se connecter correctement au cluster et rechercher les problèmes:
Failed to access the api server via LB VIP "...": ...
Try to use the admin master IP instead of problematic VIP...
Reading config with version "[CONFIG_VERSION]"
Finding the admin master VM...
Fetching the VMs in the resource pool "[RESOURCE_POOL_NAME]"...
Found the "[ADMIN_MASTER_VM_NAME]" is the admin master VM.
Diagnosing admin|user cluster "[TARGET_CLUSTER_NAME]"...
...
Diagnostiquer un cluster d'utilisateur
Pour diagnostiquer un cluster d'utilisateur, vous devez spécifier son nom. Pour obtenir le nom d'un cluster d'utilisateur, exécutez la commande suivante:
kubectl get cluster --kubeconfig=USER_CLUSTER_KUBECONFIG
Remplacez USER_CLUSTER_KUBECONFIG par le chemin d'accès au fichier kubeconfig du cluster d'utilisateur.
Spécifiez le nom du cluster d'utilisateur avec le fichier de configuration comme suit:
gkectl diagnose cluster --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
--cluster-name=USER_CLUSTER_NAME
Remplacez USER_CLUSTER_NAME par le nom du cluster d'utilisateur.
L'exemple de résultat suivant est renvoyé par la commande gkectl diagnose cluster:
Preparing for the diagnose tool...
Diagnosing the cluster......DONE
Diagnose result is saved successfully in <DIAGNOSE_REPORT_JSON_FILE>
- Validation Category: User Cluster Connectivity
Checking Node Network Policy...SUCCESS
Checking VMs TOD (availability)...SUCCESS
Checking Dataplane-V2...Success
- Validation Category: User Cluster F5 BIG-IP
Checking f5 (credentials, partition)...SUCCESS
- Validation Category: User Cluster VCenter
Checking Credentials...SUCCESS
Checking DRS enabled...SUCCESS
Checking Hosts for AntiAffinityGroups...SUCCESS
Checking VSphere CSI Driver...SUCCESS
Checking Version...SUCCESS
Checking Datacenter...SUCCESS
Checking Datastore...SUCCESS
Checking Resource pool...SUCCESS
Checking Folder...SUCCESS
Checking Network...SUCCESS
- Validation Category: User Cluster
Checking user cluster and node pools...SUCCESS
Checking cluster object...SUCCESS
Checking machine deployment...SUCCESS
Checking machineset...SUCCESS
Checking machine objects...SUCCESS
Checking control plane pods...SUCCESS
Checking kube-system pods...SUCCESS
Checking gke-system pods...SUCCESS
Checking gke-connect pods...SUCCESS
Checeking anthos-identity-service pods...SUCCESS
Checking storage...SUCCESS
Checking resource...SUCCESS
Checking virtual machine resource contention...SUCCESS
Checking host resource contention...SUCCESS
All validation results were SUCCESS.
Cluster is healthy!
Diagnostiquer l'état de la machine virtuelle
Si un problème survient lors de la création de la machine virtuelle, exécutez gkectl diagnose cluster pour obtenir un diagnostic de son état.
Le résultat ressemble à ce qui suit :
- Validation Category: Cluster Healthiness
Checking cluster object...SUCCESS
Checking machine deployment...SUCCESS
Checking machineset...SUCCESS
Checking machine objects...SUCCESS
Checking machine VMs...FAILURE
Reason: 1 machine VMs error(s).
Unhealthy Resources:
Machine [NODE_NAME]: The VM's UUID "420fbe5c-4c8b-705a-8a05-ec636406f60" does not match the machine object's providerID "420fbe5c-4c8b-705a-8a05-ec636406f60e".
Debug Information:
null
...
Exit with error:
Cluster is unhealthy!
Run gkectl diagnose cluster automatically in gkectl diagnose snapshot
Public page https://cloud.google.com/anthos/clusters/docs/on-prem/latest/diagnose#overview_diagnose_snapshot
Résoudre les problèmes
Le tableau suivant présente certaines solutions possibles pour les problèmes liés à l'exécution de la commande gkectl diagnose cluster:
| Problème | Causes possibles : | Solution |
|---|---|---|
| Le serveur d'API Kubernetes est inaccessible, pour le cluster d'administrateur comme pour les clusters d'utilisateur. | Vérifiez les graphiques de latence mémoire OOB (out-of-box) de la santé de la machine virtuelle, qui doivent idéalement afficher une latence mémoire autour de zéro. Un conflit de mémoire peut également accroître l'utilisation du processeur. Les graphiques de disponibilité du processeur peuvent présenter un pic d'utilisation, en raison des échanges disque. | Augmentez la mémoire physique. Pour connaître les autres options, consultez Suggestions de dépannage de VMware. |
| Le processus de création du pool de nœuds expire. | Latence de lecture/écriture élevée VMDK. Vérifiez l'état OOB de la VM pour déterminer la latence de lecture et d'écriture du disque virtuel. Selon VMware, une latence totale supérieure à 20 ms indique un problème. | Consultez la page sur les solutions VMware aux problèmes de performances de disque. |
BundleUnexpectedDiff erreur
La ressource d'API Kubernetes Cluster gérée par un groupe Google Distributed Cloud peut être modifiée accidentellement, ce qui peut entraîner l'échec des composants système, ou l'échec de la mise à niveau ou de la mise à jour du cluster.
Dans Google Distributed Cloud 1.13 et versions ultérieures, onprem-user-cluster-controller vérifie régulièrement l'état des objets et signale les différences inattendues par rapport à l'état souhaité à l'aide de journaux et d'événements. Ces objets incluent le plan de contrôle du cluster d'utilisateur et des modules complémentaires tels que les services et les DaemonSets.
L'exemple de résultat suivant montre un événement de différence inattendu:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning BundleUnexpectedDiff 13m onpremusercluster/ci-bundle-diff Detected unexpected difference of user control plane objects: [ConfigMap/istio], please check onprem-user-cluster-controller logs for more details.
L'exemple de résultat suivant montre les journaux générés par onprem-user-cluster-controller:
2022-08-06T02:54:42.701352295Z W0806 02:54:42.701252 1 update.go:206] Detected unexpected difference of user addon object(ConfigMap/istio), Diff: map[string]string{
2022-08-06T02:54:42.701376406Z - "mesh": (
2022-08-06T02:54:42.701381190Z - """
2022-08-06T02:54:42.701385438Z - defaultConfig:
2022-08-06T02:54:42.701389350Z - discoveryAddress: istiod.gke-system.svc:15012
...
2022-08-06T02:54:42.701449954Z - """
2022-08-06T02:54:42.701453099Z - ),
2022-08-06T02:54:42.701456286Z - "meshNetworks": "networks: {}",
2022-08-06T02:54:42.701459304Z + "test-key": "test-data",
2022-08-06T02:54:42.701462434Z }
Les événements et les journaux ne bloquent pas le fonctionnement du cluster. Les objets qui présentent des différences inattendues par rapport à l'état souhaité sont écrasés lors de la prochaine mise à niveau du cluster.