Lo strumento gkectl
include due comandi per la risoluzione dei problemi relativi ai cluster: gkectl diagnose snapshot
e gkectl diagnose cluster
. I comandi funzionano sia con i cluster di amministrazione
che con i cluster utente. Questo documento mostra come utilizzare il comando gkectl diagnose
per creare snapshot diagnostici per la risoluzione dei problemi nei cluster.
Per ulteriori informazioni su come utilizzare il comando gkectl diagnose cluster
per diagnosticare i problemi del cluster, consulta Diagnosticare i problemi del cluster.
gkectl diagnose snapshot
Questo comando comprime lo stato, le configurazioni e i log di un cluster in un
file tar. Quando esegui gkectl diagnose snapshot
, il comando esegue automaticamente gkectl diagnose cluster
come parte del processo e i file di output vengono inseriti in una nuova cartella nello snapshot denominato /diagnose-report
.
Snapshot predefinito
La configurazione predefinita del comando gkectl diagnose snapshot
acquisisce le seguenti informazioni sul cluster:
la versione di Kubernetes.
Stato delle risorse Kubernetes negli spazi dei nomi kube-system e gke-system: cluster, macchina, nodi, servizi, endpoint, ConfigMap, ReplicaSet, CroJob, pod e i proprietari di questi pod, inclusi Deployment, DaemonSet e StatefulSet.
Stato del piano di controllo.
Dettagli relativi alla configurazione di ogni nodo, inclusi indirizzi IP, regole iptables, punti di montaggio, file system, connessioni di rete e processi in esecuzione.
Log dei container dal nodo del piano di controllo del cluster di amministrazione, quando il server API Kubernetes non è disponibile.
Informazioni vSphere, inclusi oggetti VM e relativi eventi basati sul pool di risorse. Raccoglie anche informazioni sugli oggetti Datacenter, Cluster, Network e Datastore associati alle VM.
Informazioni sul bilanciatore del carico BIG-IP di F5, tra cui server virtuale, indirizzo virtuale, pool, nodo e monitoraggio.
Log dal comando
gkectl diagnose snapshot
.Log dei job preflight.
Log dei container negli spazi dei nomi basati sugli scenari.
Informazioni sulla scadenza del certificato Kubernetes del cluster di amministrazione nel file snapshot
/nodes/<admin_master_node_name>/sudo_kubeadm_certs_check-expiration
.Un file indice HTML per tutti i file nell'istantanea.
Facoltativamente, il file di configurazione del cluster di amministrazione utilizzato per installare ed eseguire l'upgrade del cluster con il flag
--config
.
Le credenziali, incluse quelle per vSphere e F5, vengono rimosse prima della creazione del file tar.
Snapshot leggero
In Google Distributed Cloud versione 1.29 e successive, è disponibile una versione leggera di gkectl diagnose snapshot
sia per i cluster di amministrazione che per i cluster utente.
Questo semplice snapshot velocizza il processo
perché acquisisce meno informazioni sul cluster. Quando aggiungi --scenario=lite
al comando, nello snapshot sono incluse solo le seguenti informazioni:
Stato delle risorse Kubernetes negli spazi dei nomi kube-system e gke-system: cluster, macchina, nodi, servizi, endpoint, ConfigMap, ReplicaSet, CroJob, pod e i proprietari di questi pod, inclusi Deployment, DaemonSet e StatefulSet
Log dal comando
gkectl diagnose snapshot
Acquisisci stato del cluster
Se i comandi gkectl diagnose cluster
rilevano errori, devi acquisire lo stato del cluster e fornire le informazioni all'assistenza clienti Google Cloud. Puoi acquisire queste informazioni utilizzando il comando gkectl diagnose snapshot
.
gkectl diagnose snapshot
ha un flag facoltativo per --config
. Oltre a raccogliere informazioni sul cluster, questo flag raccoglie il file di configurazione di GKE on VMware utilizzato per creare o eseguire l'upgrade del cluster.
Acquisisci lo stato del cluster di amministrazione
Per acquisire lo stato di un cluster di amministrazione, esegui questo comando:
gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG --config
Il parametro --config
è facoltativo:
Se si verifica un problema con un indirizzo IP virtuale (VIP) nel cluster di destinazione, utilizza il flag --config
per fornire il file di configurazione del cluster di amministrazione e fornire ulteriori informazioni di debug.
Nella versione 1.29 e successive, puoi includere --scenario=lite
se non hai
bisogno di tutte le informazioni nello snapshot predefinito.
L'output include un elenco di file e il nome di un file tar, come mostrato nell'output di esempio seguente:
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 [TAR_FILE_NAME].tar.gz.
Per estrarre il file tar in una directory, esegui questo comando:
tar -zxf TAR_FILE_NAME --directory EXTRACTION_DIRECTORY_NAME
Sostituisci quanto segue:
TAR_FILE_NAME
: il nome del file tar.EXTRACTION_DIRECTORY_NAME
: la directory in cui vuoi estrarre l'archivio dei file tar.
Per esaminare l'elenco dei file prodotti dallo snapshot, esegui questi comandi:
cd EXTRACTION_DIRECTORY_NAME/EXTRACTED_SNAPSHOT_DIRECTORY ls kubectlCommands ls nodes/NODE_NAME/commands ls nodes/NODE_NAME/files
Sostituisci NODE_NAME
con il nome del nodo
per cui vuoi visualizzare i file.
Per visualizzare i dettagli di una determinata operazione, apri uno dei file.
Specifica la chiave SSH per il cluster di amministrazione
Quando ottieni uno snapshot del cluster di amministrazione, gkectl
trova automaticamente la chiave SSH privata per il cluster di amministrazione. Puoi anche specificare la chiave in modo esplicito
utilizzando il parametro --admin-ssh-key-path
.
Segui le istruzioni per utilizzare 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 della chiave decodificato:
gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \ --admin-ssh-key-path=PATH_TO_DECODED_KEY
Acquisisci lo stato del cluster utente
Per acquisire lo stato di un cluster utente, esegui questo comando:
gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \ --cluster-name=USER_CLUSTER_NAME
L'output di esempio seguente include un elenco di file e il nome di un file tar:
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 di snapshot
Gli scenari di snapshot consentono di controllare le informazioni incluse in uno snapshot. Per specificare uno scenario, utilizza il flag --scenario
. Nell'elenco seguente vengono mostrati i valori possibili:
system
(predefinito): raccogli snapshot con log negli spazi dei nomi di sistema supportati.all
: raccogli snapshot con log in tutti gli spazi dei nomi, inclusi quelli definiti dall'utente.lite
(1.29 e versioni successive): raccogli snapshot solo con risorse Kubernetes e log digkectl
. Sono esclusi tutti gli altri log, ad esempio i log dei container e i log dei kernel dei nodi.
Gli scenari di snapshot disponibili variano a seconda della versione Google Distributed Cloud.
Versioni precedenti alla 1.13:
system
,system-with-logs
,all
eall-with-logs
.Versioni 1.13-1.28:
system
eall
. Lo scenariosystem
è uguale al vecchio scenariosystem-with-logs
. Lo scenarioall
è lo stesso del vecchio scenarioall-with-logs
.Versioni 1.29 e successive:
system
,all
elite
.
Per creare uno snapshot del cluster di amministrazione, non è necessario specificare uno scenario:
gkectl diagnose snapshot \ --kubeconfig=ADMIN_CLUSTER_KUBECONFIG
Per creare uno snapshot di un cluster utente utilizzando lo scenario system
:
gkectl diagnose snapshot \ --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \ --cluster-name=USER_CLUSTER_NAME \ --scenario=system
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 di un cluster utente utilizzando lo scenario lite
:
gkectl diagnose snapshot \ --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \ --cluster-name=USER_CLUSTER_NAME \ --scenario=lite
Usa --log-since
per limitare uno snapshot
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.
gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \ --cluster-name=CLUSTER_NAME \ --scenario=system \ --log-since=DURATION
Sostituisci <var>DURATION</var>
con un valore relativo all'ora come 120m
o 48h
.
Si applicano le seguenti considerazioni:
- Il flag
--log-since
è supportato solo per i logkubectl
ejournalctl
. - I flag di comando come
--log-since
non sono consentiti nella configurazione dello snapshot personalizzata.
Esegui una prova per uno snapshot
Puoi utilizzare il flag --dry-run
per mostrare le azioni da intraprendere e la
configurazione dello snapshot.
Per eseguire una prova sul cluster di amministrazione, inserisci il comando seguente:
gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \ --cluster-name=ADMIN_CLUSTER_NAME \ --dry-run
Per eseguire una prova su un cluster utente, inserisci il comando seguente:
gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \ --cluster-name=USER_CLUSTER_NAME \ --dry-run
Utilizza una configurazione snapshot
Se questi due scenari (--scenario system
o all
) non soddisfano le tue esigenze, puoi
creare uno snapshot personalizzato passando 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
Genera una configurazione di snapshot
Puoi generare una configurazione di snapshot per un determinato scenario passando i flag --scenario
e --dry-run
. Ad esempio, per visualizzare la configurazione dello snapshot per lo scenario predefinito (system
) di un cluster utente, inserisci il comando seguente:
gkectl diagnose snapshot \ --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \ --cluster-name=USER_CLUSTER_NAME \ --scenario=system --dry-run
L'output è simile all'esempio 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
Nell'output vengono visualizzate le seguenti informazioni:
numOfParallelThreads
: numero di thread paralleli utilizzati per creare 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 la specifichi o meno.kubectlCommands
: elenco di comandi kubectl da eseguire. I risultati vengono salvati. I comandi vengono eseguiti in base agli spazi dei nomi corrispondenti. Per i comandikubectl logs
, tutti i pod e i container negli spazi dei nomi corrispondenti vengono aggiunti automaticamente. Per specificare gli spazi dei nomi sono supportate espressioni regolari. Se non specifichi uno spazio dei nomi, viene usato lo spazio dei nomidefault
.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 di 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 Seesaw. I risultati vengono salvati se il cluster utilizza il bilanciatore del carico Seesaw.seesawFiles
: elenco dei file da raccogliere per il bilanciatore del carico Seesaw.nodeCollectors
: un raccoglitore in esecuzione per i nodi Cilium per raccogliere informazioni su eBPF.f5
: un flag per abilitare 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 Prometheus. I risultati vengono salvati.
carica snapshot in un bucket Cloud Storage
Per semplificare la conservazione, l'analisi e l'archiviazione dei record, puoi caricare tutti gli snapshot di un cluster specifico in un bucket Cloud Storage. Ciò è particolarmente utile se hai bisogno dell'assistenza dell'assistenza clienti Google Cloud.
Prima di caricare gli snapshot in un bucket Cloud Storage, esamina e completa i seguenti requisiti iniziali:
Abilita
storage.googleapis.com
nel progetto host del parco risorse. Anche se puoi utilizzare un progetto diverso, è consigliabile utilizzare il progetto host del parco risorse.gcloud services enable --project=FLEET_HOST_PROJECT_ID storage.googleapis.com
Concedi
roles/storage.admin
all'account di servizio nel progetto padre e passa il file chiave JSON dell'account di servizio utilizzando il parametro--service-account-key-file
. Puoi utilizzare qualsiasi account di servizio, ma consigliamo di usare l'account di servizio Connect Register. Per ulteriori informazioni, consulta Account di servizio.gcloud projects add-iam-policy-binding FLEET_HOST_PROJECT_ID \ --member "serviceAccount:CONNECT_REGISTER_SERVICE_ACCOUNT" \ --role "roles/storage.admin"
Sostituisci
CONNECT_REGISTER_SERVICE_ACCOUNT
con l'account di servizio Registrato.
Una volta soddisfatti questi requisiti, ora puoi caricare lo snapshot nel bucket Cloud Storage:
gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \ --cluster-name CLUSTER_NAME \ --upload \ --share-with GOOGLE_SUPPORT_SERVICE_ACCOUNT
Il flag --share-with
può accettare un elenco di nomi di account di servizio. Sostituisci GOOGLE_SUPPORT_SERVICE_ACCOUNT
con l'account del servizio dell'assistenza clienti Google Cloud fornito dall'assistenza clienti Google Cloud, insieme a eventuali altri account di servizio forniti dall'assistenza clienti Google Cloud.
Quando utilizzi il flag --upload
, il comando cerca nel progetto un bucket di archiviazione il cui nome inizia con "anthos-snapshot-
". Se esiste un bucket di questo tipo, il comando carica lo snapshot in quel bucket. Se il comando non trova un bucket con un nome corrispondente, crea un nuovo bucket con il nome anthos-snapshot-UUID
, dove UUID
è un identificatore univoco universale di 32 cifre.
Quando utilizzi il flag --share-with
, non devi condividere manualmente l'accesso al bucket con l'assistenza clienti Google Cloud.
L'output di esempio seguente viene visualizzato quando carichi uno snapshot in un bucket Cloud Storage:
Using "system" snapshot configuration...
Taking snapshot of user cluster <var>CLUSTER_NAME</var>...
Setting up <var>CLUSTER_NAME</var> 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 "<var>SNAPSHOT_FILE_PATH</var>".
Uploading snapshot to Google Cloud Storage...... DONE
Uploaded the snapshot successfully to gs://anthos-snapshot-a4b17874-7979-4b6a-a76d-e49446290282/<var>xSNAPSHOT_FILE_NAME</var>.
Shared successfully with service accounts:
<var>GOOGLE_SUPPORT_SERVICE_ACCOUNT</var>