Diagnostica dei problemi relativi ai cluster

In questa pagina viene spiegato come utilizzare lo strumento con l'interfaccia a riga di comando (CLI) di gkectl per diagnosticare i problemi nei tuoi cluster Anthos sui cluster VMware (GKE on-prem).

Panoramica

Lo strumento gkectl prevede due comandi per la risoluzione dei problemi relativi ai cluster: gkectl diagnose cluster e gkectl diagnose snapshot. I comandi funzionano sia con i cluster amministratore sia con i cluster utente.

gkectl diagnose cluster

Esegue controlli di integrità sui cluster Anthos sul cluster VMware e segnala errori. Esegue controlli di integrità sui seguenti componenti:

• VCenter
  • Credenziale
  • DRS
  • Gruppi di affinità
  • Rete
  • Versione
  • Data center
  • Datastore
  • Pool di risorse
  • Cartella
  • Rete
• Cluster di utenti e pool di nodi
• Oggetti cluster
• Oggetti macchina e nodi cluster corrispondenti
• Pod negli spazi dei nomi kube-system e gke-system
• Piano di controllo utente se il cluster di destinazione è un cluster utente
• Volumi permanenti vSphere nel cluster

gkectl diagnose snapshot

Comprimi lo stato, le configurazioni e i log di un cluster in un file tarball. In particolare, la configurazione predefinita del comando acquisisce le seguenti informazioni sul tuo cluster:

• Versione di Kubernetes

• Stato delle risorse Kubernetes negli spazi dei nomi kube-system e gke-system: cluster, machine, nodes, Services, Endpoints, ConfigMap, ReplicaSets, CronJobs, Pods e i proprietari di tali pod, inclusi Deployment, DaemonSets e StatefulSet

• Lo stato del piano di controllo utente se il cluster di destinazione è un cluster utente (il piano di controllo del cluster utente viene eseguito nel cluster di amministrazione)

• Dettagli su ogni configurazione dei nodi, inclusi indirizzi IP, regole iptables, punti di montaggio, file system, connessioni di rete e processi in esecuzione.

• Informazioni vSphere inclusi gli oggetti VM e i relativi eventi in base al pool di risorse. Inoltre, oggetti Datacenter, Cluster, Network e Datastore associati alle VM

• Informazioni sul bilanciatore del carico BIG-IP di F5, inclusi server virtuale, indirizzo virtuale, pool, nodo e monitor

• Log dal comando gkectl diagnose snapshot

• Facoltativamente, il file di configurazione dei cluster Anthos su VMware per installare ed eseguire l'upgrade del cluster

Le credenziali, incluse le credenziali vSphere e F5, vengono rimosse prima della creazione del tarball.

Diagnostica dei cluster

Puoi eseguire gke diagnose cluster per cercare problemi comuni con il cluster.

Nota: il flag --kubeconfig deve sempre puntare al file kubeconfig del cluster di amministrazione. gkectl diagnose restituisce un errore se fornisci il file kubeconfig del cluster utente.

Nota: in caso di problemi VIP con il cluster di targeting, puoi utilizzare --config per fornire il file di configurazione del cluster di amministrazione. Questo fornisce più informazioni di debug.

gkectl diagnose cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG

Output di esempio:

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 user cluster "[TARGET_CLUSTER_NAME]"...
...

Diagnostica di un cluster di amministrazione

Puoi diagnosticare un cluster di amministrazione passando il suo nome o passando solo alla sua kubeconfig.

Utilizzo del cluster di amministrazione kubeconfig

L'utilizzo del kubeconfig del cluster di amministrazione fa sì che gkectl scelga automaticamente il cluster di amministrazione:

gkectl diagnose cluster --kubeconfig=[ADMIN_CLUSTER_KUBECONFIG]

Utilizzo del nome del cluster di amministrazione

Per ottenere il nome del cluster di amministrazione, esegui il comando seguente:

kubectl get cluster --kubeconfig=[ADMIN_CLUSTER_KUBECONFIG]

Quindi, passa il nome del cluster di amministrazione a gkectl diagnose cluster:

gkectl diagnose cluster --kubeconfig=[ADMIN_CLUSTER_KUBECONFIG] \
--cluster-name=[ADMIN_CLUSTER_NAME]

Se il tuo cluster di amministrazione funziona correttamente, gkectl diagnose cluster restituisce il seguente output:

Diagnosing admin cluster "[ADMIN_CLUSTER_NAME]" ...
- Validation Category: Admin 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
Checking Node Pool Datastore...SUCCESS
- Validation Category: Admin Cluster
Checking Cluster Object...SUCCESS
Checking Machine Deployment...SUCCESS
Checking Machineset...SUCCESS
Checking Machine Objects...SUCCESS
Checking Control Plane Pods...SUCCESS
Checking [NAMESPACES] Pods...SUCCESS
Checking Storage...SUCCESS
Checking Resource...SUCCESS
Cluster is healthy.

Diagnostica di un cluster utente

Per diagnosticare un cluster, ottieni prima il nome del cluster utente:

kubectl get cluster --kubeconfig=[USER_CLUSTER_KUBECONFIG]

Quindi, passa a kubeconfig del cluster di amministrazione e al nome del cluster utente:

gkectl diagnose cluster --kubeconfig=[ADMIN_CLUSTER_KUBECONFIG] \
  --cluster-name=[USER_CLUSTER_NAME]

Nota: gkectl diagnose restituisce un errore se fornisci il kubeconfig del cluster utente.

Se il tuo cluster utente funziona correttamente, gkectl diagnose cluster restituisce il seguente output:

Diagnosing user cluster "[USER_CLUSTER_NAME]" ...
- 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 [NAMESPACES] pods...SUCCESS
Checking storage...SUCCESS
Checking resource...SUCCESS
Cluster is healthy.

Acquisizione dello stato del cluster

Se gkectl diagnose cluster rileva errori, devi acquisire lo stato del cluster e fornire le informazioni a Google. Puoi farlo utilizzando il comando gkectl diagnose snapshot.

gkectl diagnose snapshot ha un flag facoltativo, --config. Oltre alla raccolta delle informazioni sul cluster, questo flag raccoglie i cluster Anthos su un file di configurazione VMware utilizzato per creare o eseguire l'upgrade del cluster.

Nota: il flag --kubeconfig deve sempre puntare al file kubeconfig del cluster di amministrazione. gkectl diagnose restituisce un errore se fornisci il kubeconfig del cluster utente.

Acquisizione dello stato del cluster di amministrazione

Per acquisire lo stato di un cluster di amministrazione, esegui il comando seguente, dove --config è facoltativo:

gkectl diagnose snapshot --kubeconfig=[ADMIN_CLUSTER_KUBECONFIG] [--config]

L'output include un elenco di file e il nome di un file 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.

Per estrarre il file tarball in una directory, esegui il comando seguente:

tar -zxf [TARBALL_FILE_NAME] --directory [EXTRACTION_DIRECTORY_NAME]

Per controllare l'elenco dei file prodotti dallo snapshot, esegui i comandi seguenti:

cd [EXTRACTION_DIRECTORY_NAME]/[EXTRACTED_SNAPSHOT_DIRECTORY]
ls kubectlCommands
ls nodes/[NODE_NAME]/commands
ls nodes/[NODE_NAME]/files

Per visualizzare i dettagli di un'operazione specifica, apri uno dei file.

Specifica la chiave SSH per il cluster di amministrazione

Quando ricevi uno snapshot del cluster di amministrazione, gkectl trova automaticamente la chiave SSH privata per il cluster di amministrazione. Puoi anche specificare esplicitamente la chiave utilizzando il parametro --admin-ssh-key-path.

Segui le istruzioni sull'utilizzo di SSH per connetterti a un nodo del cluster per scaricare le chiavi SSH.

Nel comando gkectl diagnose snapshot, imposta --admin-ssh-key-path sul percorso del file della chiave decodificato:

gkectl diagnose snapshot --kubeconfig=[ADMIN_CLUSTER_KUBECONFIG] \
--admin-ssh-key-path=[PATH_TO_DECODED_KEY]

Acquisizione dello stato del cluster utente

Per acquisire lo stato di un cluster utente, esegui il comando seguente:

gkectl diagnose snapshot --kubeconfig=[ADMIN_CLUSTER_KUBECONFIG] \
--cluster-name=[USER_CLUSTER_NAME]

L'output include un elenco di file e il nome di un file 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.

Scenari snapshot

Il comando gkectl diagnose snapshot supporta quattro scenari. Per specificare uno scenario, utilizza il flag --scenario. Il seguente elenco mostra i possibili valori:

• system: (impostazione predefinita) raccogli uno snapshot per gli spazi dei nomi di sistema: kube-system e gke-system.

• system-with-logs: raccogli un'istantanea system con i log.

• all: raccogli uno snapshot per tutti gli spazi dei nomi.

• all-with-logs: raccogli un'istantanea all con i log.

Puoi utilizzare ognuno dei quattro scenari con un cluster di amministrazione o un cluster utente, poiché sono disponibili otto possibili permutazioni. I seguenti esempi mostrano alcune delle possibilità.

Per creare uno snapshot del cluster di amministrazione utilizzando lo scenario system:

gkectl diagnose snapshot \
--kubeconfig=[ADMIN_CLUSTER_KUBECONFIG] \
--scenario=system

Per creare uno snapshot di un cluster utente utilizzando lo scenario system-with-logs:

gkectl diagnose snapshot \
--kubeconfig=[ADMIN_CLUSTER_KUBECONFIG] \
--cluster-name=[USER_CLUSTER_NAME] \
--scenario=system-with-logs

Per creare uno snapshot di un cluster utente utilizzando lo scenario all:

gkectl diagnose snapshot \
--kubeconfig=[ADMIN_CLUSTER_KUBECONFIG] \
--cluster-name=[USER_CLUSTER_NAME] \
--scenario=all

Per creare uno snapshot del cluster di amministrazione utilizzando lo scenario all-with-logs:

gkectl diagnose snapshot \
--kubeconfig=[ADMIN_CLUSTER_KUBECONFIG] \
--scenario=all-with-logs

Viene utilizzato --log-since per limitare uno snapshot

Negli scenari system-with-logs e all-with-logs, puoi utilizzare il flag --log-since per limitare la raccolta dei log a un periodo di tempo recente. Ad esempio, potresti raccogliere solo i log degli ultimi due giorni o delle ultime tre ore. Per impostazione predefinita, diagnose snapshot raccoglie tutti i log.

Per limitare il periodo di tempo per la raccolta dei log:

gkectl diagnose snapshot --kubeconfig=[ADMIN_CLUSTER_KUBECONFIG] \
--cluster-name=[CLUSTER_NAME] \
--scenario=system-with-logs \
--log-since=[DURATION]

Sostituisci [DURATION] con un valore di tempo come 120m o 48h.

Note:

• Il flag --log-since è supportato solo per i log kubectl e journalctl.
• I flag di comando come --log-since non sono consentiti nella configurazione dello snapshot personalizzato.

Esecuzione di un'esecuzione di prova per uno snapshot

Puoi utilizzare il flag --dry-run per mostrare le azioni da intraprendere e la configurazione della istantanea.

Per eseguire una prova sul cluster di amministrazione, inserisci il seguente comando:

gkectl diagnose snapshot --kubeconfig=[ADMIN_CLUSTER_KUBECONFIG] \
--cluster-name=[ADMIN_CLUSTER_NAME] \
--dry-run

Per eseguire una prova su un cluster utente, inserisci il seguente comando:

gkectl diagnose snapshot --kubeconfig=[ADMIN_CLUSTER_KUBECONFIG] \
--cluster-name=[USER_CLUSTER_NAME] \
--dry-run

usando una configurazione di snapshot.

Se i quattro scenari non soddisfano le tue esigenze, puoi creare un'istantanea personalizzata passando in un file di configurazione dello snapshot utilizzando il flag --snapshot-config:

gkectl diagnose snapshot --kubeconfig=[ADMIN_CLUSTER_KUBECONFIG] \
--cluster-name=[USER_CLUSTER_NAME] \
--snapshot-config=[SNAPSHOT_CONFIG_FILE]

Generazione di una configurazione snapshot

Puoi generare una configurazione dello snapshot per un determinato scenario passando nei flag --scenario e --dry-run. Ad esempio, per visualizzare la configurazione dello snapshot per lo scenario predefinito (system) di un cluster utente, inserisci il seguente comando:

gkectl diagnose snapshot \
--kubeconfig=[ADMIN_CLUSTER_KUBECONFIG] \
--cluster-name=[USER_CLUSTER_NAME] \
--scenario=system
--dry-run

L'output è simile al seguente:

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: numero di thread paralleli utilizzati per acquisire gli snapshot.

• excludeWords: elenco di parole da escludere dallo snapshot (senza distinzione tra maiuscole e minuscole). Le righe che contengono queste parole vengono rimosse dai risultati degli snapshot. "password" è sempre esclusa, indipendentemente dal fatto che tu la specifichi o meno.

• kubectlCommands: elenco di comandi kubectl da eseguire. I risultati vengono salvati. I comandi vengono eseguiti sugli spazi dei nomi corrispondenti. Per i comandi kubectl logs, tutti i pod e i container negli spazi dei nomi corrispondenti vengono aggiunti automaticamente. Le espressioni regolari sono supportate per la specifica degli spazi dei nomi. Se non specifichi uno spazio dei nomi, viene utilizzato lo spazio dei nomi default.

• nodeCommands: elenco di comandi da eseguire sui nodi corrispondenti. I risultati vengono salvati. Se i nodi non sono specificati, vengono presi in considerazione tutti i nodi nel cluster di destinazione.

• nodeFiles: elenco dei file da raccogliere dai nodi corrispondenti. I file vengono salvati. Se i nodi non sono specificati, vengono presi in considerazione tutti i nodi nel cluster di destinazione.

• seesawCommands: elenco di comandi da eseguire per raccogliere informazioni sul bilanciatore del carico di Seesaw. I risultati vengono salvati se il cluster utilizza il bilanciatore del carico di Seesaw.

• seesawFiles: elenco di file da raccogliere per il bilanciatore del carico di Seesaw.

• nodeCollectors: un raccoglitore che esegue i nodi Cilium per raccogliere informazioni eBPF.

• f5: un flag per consentire la raccolta di informazioni relative al bilanciatore del carico BIG-IP di F5.

• vCenter: un flag per consentire la raccolta di informazioni relative a vCenter.

• prometheusRequests: elenco di richieste di Prometheus. I risultati vengono salvati.

Problemi noti

Versione 1.1.2-gke.0: il percorso si risolve in più data center

Fai riferimento alle note di rilascio di Cluster Anthos su VMware.

Versioni 1.1.x: volume non collegato alla macchina

Fai riferimento alle note di rilascio di Cluster Anthos su VMware.