Ce document explique comment diagnostiquer les problèmes au sein de vos clusters à l'aide de gkectl diagnose
.
Présentation
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.
gkectl diagnose cluster
Effectue des vérifications de l'état sur votre cluster et signale les erreurs. Exécute des vérifications de l'état sur les composants suivants :
- VCenter
- Identifiant
- DRS
- Groupes anti-affinité
- Réseau
- Version
- de données moyen
- Datastore
- Pool de ressources
- Dossier
- Réseau
- Équilibreur de charge (F5, Seesaw, manuel)
- Cluster d'utilisateur et pool de nœuds
- Objets du cluster
- Objets machine et nœuds de cluster correspondants
- Pods dans les espaces de noms kube-system et gke-system
- Plan de contrôle utilisateur si le cluster cible est un cluster d'utilisateur
- Volumes persistants vSphere dans le cluster
- Processeur virtuel de cluster d'utilisateur et d'administrateur et signaux de conflit de mémoire
- Utilisation du processeur hôte préconfigurée et alarmes d'utilisation de la mémoire sur 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é
gkectl diagnose snapshot
Compresse l'état, les configurations et les journaux d'un cluster dans un fichier tarball. Plus précisément, la configuration par défaut de la commande capture les informations suivantes concernant votre cluster :
Version de Kubernetes
État des ressources Kubernetes dans les espaces de noms kube-system et gke-system : cluster, machine, nœuds, Services, Endpoints, ConfigMaps, ReplicaSets, CronJobs, Pods et les propriétaires de ces pods, y compris les déploiements, DaemonSets et StatefulSets
État du plan de contrôle utilisateur si le cluster cible est un cluster d'utilisateur (le plan de contrôle du cluster s'exécute dans le cluster d'administrateur)
Détails sur chaque configuration de nœud, y compris les adresses IP, les règles iptables, les points d'installation, le système de fichiers, les connexions réseau et les processus en cours d'exécution
Journaux de conteneur à partir du nœud du plan de contrôle du cluster d'administrateur, lorsque le serveur d'API Kubernetes n'est pas disponible
Informations sur vSphere, y compris les objets de VM et leurs événements basés sur un pool de ressources ; également les objets de centre de données, de cluster, de réseau et de datastore associés à des VM
Informations sur l'équilibreur de charge F5 BIG-IP (y compris, serveur virtuel, adresse virtuelle, pool, nœud et surveillance)
Journaux de la commande
gkectl diagnose snapshot
Fichier d'index HTML pour tous les fichiers de l'instantané
Fichier de configuration de cluster utilisé pour installer et mettre à niveau le cluster (facultatif)
Les identifiants, y compris les identifiants vSphere et F5, sont supprimés avant la création du tarball.
Diagnostiquer des clusters
Vous pouvez exécuter gke diagnose cluster
pour rechercher les problèmes courants liés à votre cluster.
gkectl diagnose cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG
Exemple de résultat :
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'administrateur
Vous pouvez diagnostiquer un cluster d'administrateur en lui transmettant son nom ou en lui transmettant uniquement son kubeconfig.
Utiliser le cluster d'administrateur kubeconfig
La transmission du fichier kubeconfig du cluster d'administrateur oblige gkectl
à choisir automatiquement le cluster d'administrateur :
gkectl diagnose cluster --kubeconfig=[ADMIN_CLUSTER_KUBECONFIG]
Utiliser le nom du cluster d'administrateur
Pour obtenir le nom du cluster d'administrateur, exécutez la commande suivante :
kubectl get cluster --kubeconfig=[ADMIN_CLUSTER_KUBECONFIG]
Transmettez ensuite le nom du cluster d'administrateur à gkectl diagnose cluster
:
gkectl diagnose cluster --kubeconfig=[ADMIN_CLUSTER_KUBECONFIG] \ --cluster-name=[ADMIN_CLUSTER_NAME]
Si votre cluster d'administrateur fonctionne correctement, gkectl diagnose cluster
renvoie un résultat semblable à celui-ci :
Preparing for the diagnose tool... Diagnosing the cluster......DONE - Validation Category: Admin Cluster Connectivity Checking VMs TOD (availability)...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!
Diagnostiquer un cluster d'utilisateur
Pour diagnostiquer un cluster, commencez par obtenir le nom du cluster d'utilisateur :
kubectl get cluster --kubeconfig=[USER_CLUSTER_KUBECONFIG]
Transmettez ensuite le fichier kubeconfig du cluster d'administrateur et le nom du cluster d'utilisateur :
gkectl diagnose cluster --kubeconfig=[ADMIN_CLUSTER_KUBECONFIG] \ --cluster-name=[USER_CLUSTER_NAME]
Si votre cluster d'utilisateur fonctionne correctement, gkectl diagnose cluster
renvoie un résultat semblable à celui-ci :
Preparing for the diagnose tool... Diagnosing the cluster......DONE Diagnose result is saved successfully in- Validation Category: User Cluster Connectivity Checking Node Network Policy...SUCCESS Checking VMs TOD (availability)...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 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!
Résoudre les problèmes de clusters diagnostiqués
Si vous rencontrez les problèmes suivants lors de l'exécution de la commande gke diagnose cluster
, voici quelques solutions possibles.
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. |
Capturer l'état du cluster
Si gkectl diagnose cluster
détecte des erreurs, vous devez capturer l'état du cluster et fournir les informations à Google. Pour ce faire, utilisez la commande gkectl diagnose snapshot
.
gkectl diagnose snapshot
possède une option facultative, --config
. En plus de collecter des informations sur le cluster, cette option collecte le fichier de configuration Anthos clusters on VMware utilisé pour créer ou mettre à jour le cluster.
Capturer l'état du cluster d'administrateur
Pour capturer l'état d'un cluster d'administrateur, exécutez la commande suivante, où --config
est facultatif :
gkectl diagnose snapshot --kubeconfig=[ADMIN_CLUSTER_KUBECONFIG] [--config]
Le résultat inclut une liste de fichiers et le nom d'un fichier tarball :
Taking snapshot of admin cluster "[ADMIN_CLUSTER_NAME]"... Using default snapshot configuration... Setting up "[ADMIN_CLUSTER_NAME]" ssh key file...DONE Taking snapshots... commands/kubectl_get_pods_-o_yaml_--kubeconfig_...env.default.kubeconfig_--namespace_kube-system commands/kubectl_get_deployments_-o_yaml_--kubeconfig_...env.default.kubeconfig_--namespace_kube-system commands/kubectl_get_daemonsets_-o_yaml_--kubeconfig_...env.default.kubeconfig_--namespace_kube-system ... nodes/[ADMIN_CLUSTER_NODE]/commands/journalctl_-u_kubelet nodes/[ADMIN_CLUSTER_NODE]/files/var/log/startup.log ... Snapshot succeeded. Output saved in [TARBALL_FILE_NAME].tar.gz.
Pour extraire le fichier tarball dans un répertoire, exécutez la commande suivante :
tar -zxf [TARBALL_FILE_NAME] --directory [EXTRACTION_DIRECTORY_NAME]
Pour afficher la liste des fichiers générés par l'instantané, exécutez les commandes suivantes :
cd [EXTRACTION_DIRECTORY_NAME]/[EXTRACTED_SNAPSHOT_DIRECTORY] ls kubectlCommands ls nodes/[NODE_NAME]/commands ls nodes/[NODE_NAME]/files
Pour afficher les détails d'une opération spécifique, ouvrez l'un des fichiers.
Spécifier la clé SSH pour le cluster d'administrateur
Lorsque vous obtenez un instantané du cluster d'administrateur, gkectl
trouve automatiquement la clé SSH privée du cluster d'administrateur. Vous pouvez également spécifier la clé explicitement à l'aide du paramètre --admin-ssh-key-path
.
Suivez les instructions pour vous connecter à un nœud de cluster via SSH afin de télécharger les clés SSH.
Ensuite, dans votre commande gkectl diagnose snapshot
, définissez --admin-ssh-key-path
sur le chemin d'accès du fichier de clé décodée :
gkectl diagnose snapshot --kubeconfig=[ADMIN_CLUSTER_KUBECONFIG] \ --admin-ssh-key-path=[PATH_TO_DECODED_KEY]
Capturer l'état du cluster d'utilisateur
Pour capturer l'état d'un cluster d'utilisateur, exécutez la commande suivante :
gkectl diagnose snapshot --kubeconfig=[ADMIN_CLUSTER_KUBECONFIG] \ --cluster-name=[USER_CLUSTER_NAME]
Le résultat inclut une liste de fichiers et le nom d'un fichier tarball :
Taking snapshot of user cluster "[USER_CLUSTER_NAME]"... Using default snapshot configuration... Setting up "[USER_CLUSTER_NAME]" ssh key file...DONE commands/kubectl_get_pods_-o_yaml_--kubeconfig_...env.default.kubeconfig_--namespace_user commands/kubectl_get_deployments_-o_yaml_--kubeconfig_...env.default.kubeconfig_--namespace_user commands/kubectl_get_daemonsets_-o_yaml_--kubeconfig_...env.default.kubeconfig_--namespace_user ... commands/kubectl_get_pods_-o_yaml_--kubeconfig_.tmp.user-kubeconfig-851213064_--namespace_kube-system commands/kubectl_get_deployments_-o_yaml_--kubeconfig_.tmp.user-kubeconfig-851213064_--namespace_kube-system commands/kubectl_get_daemonsets_-o_yaml_--kubeconfig_.tmp.user-kubeconfig-851213064_--namespace_kube-system ... nodes/[USER_CLUSTER_NODE]/commands/journalctl_-u_kubelet nodes/[USER_CLUSTER_NODE]/files/var/log/startup.log ... Snapshot succeeded. Output saved in [FILENAME].tar.gz.
Scénarios d'instantanés
La commande gkectl diagnose snapshot
prend en charge quatre scénarios. Pour spécifier un scénario, utilisez l'option --scenario
. La liste suivante répertorie les valeurs possibles :
system
: (par défaut) collecter un instantané pour les espaces de noms systèmekube-system
etgke-system
system-with-logs
: collecter un instantanésystem
avec des journauxall
: collecter un instantané pour tous les espaces de nomsall-with-logs
: collecter un instantanéall
avec des journaux
Vous pouvez utiliser chacun des quatre scénarios avec un cluster d'administrateur ou un cluster d'utilisateur. Il existe donc huit permutations possibles. Les exemples suivants illustrent certaines possibilités.
Pour créer un instantané du cluster d'administrateur en utilisant le scénario system
:
gkectl diagnose snapshot \ --kubeconfig=[ADMIN_CLUSTER_KUBECONFIG] \ --scenario=system
Pour créer un instantané d'un cluster d'utilisateur en utilisant le scénario system-with-logs
:
gkectl diagnose snapshot \ --kubeconfig=[ADMIN_CLUSTER_KUBECONFIG] \ --cluster-name=[USER_CLUSTER_NAME] \ --scenario=system-with-logs
Pour créer un instantané d'un cluster d'utilisateur en utilisant le scénario all
:
gkectl diagnose snapshot \ --kubeconfig=[ADMIN_CLUSTER_KUBECONFIG] \ --cluster-name=[USER_CLUSTER_NAME] \ --scenario=all
Pour créer un instantané du cluster d'administrateur en utilisant le scénario all-with-logs
:
gkectl diagnose snapshot \ --kubeconfig=[ADMIN_CLUSTER_KUBECONFIG] \ --scenario=all-with-logs
Utiliser --log-since
pour limiter un instantané
Dans les scénarios system-with-logs
et all-with-logs
, vous pouvez utiliser l'option --log-since
pour limiter la collecte de journaux à une période récente. Par exemple, vous pouvez ne collecter que les journaux des deux derniers jours ou des trois dernières heures. Par défaut, diagnose snapshot
collecte tous les journaux.
Pour limiter la période de collecte de journaux, procédez comme suit :
gkectl diagnose snapshot --kubeconfig=[ADMIN_CLUSTER_KUBECONFIG] \ --cluster-name=[CLUSTER_NAME] \ --scenario=system-with-logs \ --log-since=[DURATION]
Remplacez [DURATION] par une valeur temporelle telle que 120m
ou 48h
.
Remarques :
- L'option
--log-since
n'est compatible qu'avec les journauxkubectl
etjournalctl
. - Les options de commande telles que
--log-since
ne sont pas autorisées dans la configuration de l'instantané personnalisée.
Effectuer une simulation pour un instantané
Vous pouvez utiliser l'option --dry-run
pour afficher les actions à effectuer et la configuration de l'instantané.
Pour exécuter une simulation sur votre cluster d'administrateur, saisissez la commande suivante :
gkectl diagnose snapshot --kubeconfig=[ADMIN_CLUSTER_KUBECONFIG] \ --cluster-name=[ADMIN_CLUSTER_NAME] \ --dry-run
Pour exécuter une simulation sur un cluster d'utilisateur, saisissez la commande suivante :
gkectl diagnose snapshot --kubeconfig=[ADMIN_CLUSTER_KUBECONFIG] \ --cluster-name=[USER_CLUSTER_NAME] \ --dry-run
Utiliser une configuration d'instantané
Si aucun des quatre scénarios ne répond pas à vos besoins, vous pouvez créer un instantané personnalisé en transmettant un fichier de configuration d'instantané à l'aide de l'option --snapshot-config
:
gkectl diagnose snapshot --kubeconfig=[ADMIN_CLUSTER_KUBECONFIG] \ --cluster-name=[USER_CLUSTER_NAME] \ --snapshot-config=[SNAPSHOT_CONFIG_FILE]
Générer une configuration d'instantané
Vous pouvez générer une configuration d'instantané pour un scénario donné en transmettant les options --scenario
et --dry-run
. Par exemple, pour afficher la configuration de l'instantané du scénario par défaut (system
) d'un cluster d'utilisateur, saisissez la commande suivante :
gkectl diagnose snapshot \ --kubeconfig=[ADMIN_CLUSTER_KUBECONFIG] \ --cluster-name=[USER_CLUSTER_NAME] \ --scenario=system --dry-run
Le résultat ressemble à ce qui suit :
numOfParallelThreads: 10 excludeWords: - password kubectlCommands: - commands: - kubectl get clusters -o wide - kubectl get machines -o wide - kubectl get clusters -o yaml - kubectl get machines -o yaml - kubectl describe clusters - kubectl describe machines namespaces: - default - commands: - kubectl version - kubectl cluster-info - kubectl get nodes -o wide - kubectl get nodes -o yaml - kubectl describe nodes namespaces: [] - commands: - kubectl get pods -o wide - kubectl get deployments -o wide - kubectl get daemonsets -o wide - kubectl get statefulsets -o wide - kubectl get replicasets -o wide - kubectl get services -o wide - kubectl get jobs -o wide - kubectl get cronjobs -o wide - kubectl get endpoints -o wide - kubectl get configmaps -o wide - kubectl get pods -o yaml - kubectl get deployments -o yaml - kubectl get daemonsets -o yaml - kubectl get statefulsets -o yaml - kubectl get replicasets -o yaml - kubectl get services -o yaml - kubectl get jobs -o yaml - kubectl get cronjobs -o yaml - kubectl get endpoints -o yaml - kubectl get configmaps -o yaml - kubectl describe pods - kubectl describe deployments - kubectl describe daemonsets - kubectl describe statefulsets - kubectl describe replicasets - kubectl describe services - kubectl describe jobs - kubectl describe cronjobs - kubectl describe endpoints - kubectl describe configmaps namespaces: - kube-system - gke-system - gke-connect.* prometheusRequests: [] nodeCommands: - nodes: [] commands: - uptime - df --all --inodes - ip addr - sudo iptables-save --counters - mount - ip route list table all - top -bn1 - sudo docker ps -a - ps -edF - ps -eo pid,tid,ppid,class,rtprio,ni,pri,psr,pcpu,stat,wchan:14,comm,args,cgroup - sudo conntrack --count nodeFiles: - nodes: [] files: - /proc/sys/fs/file-nr - /proc/sys/net/nf_conntrack_max seesawCommands: [] seesawFiles: [] nodeCollectors: - nodes: [] f5: enabled: true vCenter: enabled: true
numOfParallelThreads
: nombre de threads parallèles utilisés pour prendre des instantanés.excludeWords
: liste des mots à exclure de l'instantané (non sensible à la casse). Les lignes contenant ces mots sont supprimées des résultats de l'instantané. "mot de passe" est toujours exclu, que vous le spécifiiez ou non.kubectlCommands
: liste des commandes kubectl à exécuter. Les résultats sont enregistrés. Les commandes s'exécutent sur les espaces de noms correspondants. Pour les commandeskubectl logs
, tous les pods et conteneurs des espaces de noms correspondants sont automatiquement ajoutés. Les expressions régulières sont compatibles avec la spécification des espaces de noms. Si vous ne spécifiez pas d'espace de noms, l'espace de nomsdefault
est utilisé.nodeCommands
: liste des commandes à exécuter sur les nœuds correspondants. Les résultats sont enregistrés. Lorsqu'aucun nœud n'est spécifié, tous les nœuds du cluster cible sont pris en compte.nodeFiles
: liste des fichiers à collecter à partir des nœuds correspondants. Les fichiers sont enregistrés. Lorsqu'aucun nœud n'est spécifié, tous les nœuds du cluster cible sont pris en compte.seesawCommands
: liste des commandes à exécuter pour collecter des informations sur l'équilibreur de charge Seesaw. Les résultats sont enregistrés si le cluster utilise l'équilibreur de charge Seesaw.seesawFiles
: liste des fichiers à collecter pour l'équilibreur de charge Seesaw.nodeCollectors
: collecteur qui exécute les nœuds Cilium pour collecter des informations eBPF.f5
: option permettant de collecter des informations liées à l'équilibreur de charge F5 BIG-IP.vCenter
: option permettant de collecter des informations liées à vCenter.prometheusRequests
: liste des requêtes Prometheus. Les résultats sont enregistrés.
Importer des instantanés dans un bucket Google Cloud Storage
Pour faciliter la conservation, l'analyse et le stockage des enregistrements, vous pouvez importer tous les instantanés d'un cluster d'utilisateur spécifique dans un bucket Google Cloud Storage. Ceci est particulièrement utile si vous avez besoin de l'aide de l'assistance Google Cloud.
Avant d'exécuter cette commande, assurez-vous que vous avez rempli les conditions de configuration ci-dessous.
- Activez
storage.googleapis.com
dans le projet connect. Bien que vous puissiez utiliser un autre projet, le projet connect est recommandé.
gcloud services enable --project=FLEET_HOST_PROJECT_ID \ storage.googleapis.com
- Attribuez le rôle
roles/storage.admin
au compte de service sur son projet parent et transmettez le fichier de clé JSON du compte de service à l'aide du paramètre--service-account-key-file
. Vous pouvez utiliser n'importe quel compte de service, mais le compte de service connect-register est recommandé. Pour en savoir plus, consultez la section Comptes de service.
gcloud projects add-iam-policy-binding FLEET_HOST_PROJECT_ID \ --member "serviceAccount:CONNECT_REGISTER_SERVICE_ACCOUNT" \ --role "roles/storage.admin"
Une fois ces conditions remplies, vous pouvez importer l'instantané à l'aide de la commande suivante :
gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \ --cluster-name CLUSTER_NAME \ --upload-to BUCKET_NAME \ --service-account-key-file SERVICE_ACCOUNT_KEY_FILE
Remplacez SERVICE_ACCOUNT_KEY_FILE
par le nom du fichier de clé du compte de service.
Exemple de résultat :
Using "system" snapshot configuration... Taking snapshot of user cluster CLUSTER_NAME... Setting up CLUSTER_NAME ssh key...DONE Using the gke-connect register service account key... Setting up Google Cloud Storage bucket for uploading the snapshot...DONE Taking snapshots in 10 thread(s)... ... Snapshot succeeded. Snapshots saved in "SNAPSHOT_FILE_PATH". Uploading snapshot to Google Cloud Storage...... DONE Uploaded the snapshot successfully to gs://BUCKET_NAME/CLUSTER_NAME/SNAPSHOT_FILE_NAME.
Problèmes connus
Version 1.1.2-gke.0 : le chemin d'accès pointe vers plusieurs centres de données
Reportez-vous aux notes de version d'Anthos clusters on VMware.
Versions 1.1.x : volume non associé à la machine
Reportez-vous aux notes de version d'Anthos clusters on VMware.