Anthos clusters on bare metal è ora Google Distributed Cloud (solo software) per bare metal. Per ulteriori informazioni, consulta la panoramica del prodotto.

Questa pagina è stata tradotta dall'API Cloud Translation.

Crea snapshot per diagnosticare i problemi del cluster

Quando si verifica un problema con uno dei cluster, puoi richiedere assistenza dell'assistenza clienti Google Cloud. L'assistenza clienti potrebbe chiederti di acquisire uno "snapshot" del cluster, che potrà utilizzare per diagnosticare il problema. Uno snapshot acquisisce il cluster e il nodo di configurazione e pacchetti con le informazioni in un unico file tar.

Questo documento descrive come creare snapshot predefiniti o più personalizzati di un cluster. Spiega inoltre come creare snapshot quando un cluster riscontrate errori specifici.

Se hai bisogno di ulteriore assistenza, contatta l'assistenza clienti Google Cloud.

Istantanee predefinite

Le seguenti sezioni descrivono i contenuti di uno snapshot standard e come crearli uno. Per informazioni sugli snapshot personalizzati, consulta la sezione snapshot personalizzati.

Quali informazioni contiene un'istantanea predefinita?

Lo snapshot di un cluster è un file tar di file di configurazione e log relativi al cluster. In particolare, la configurazione predefinita del comando acquisisce le seguenti informazioni sul cluster:

la versione di Kubernetes.
Stato delle risorse Kubernetes negli spazi dei nomi kube-system e gke-system: cluster, macchine, nodi, servizi, endpoint, ConfigMap, ReplicaSet, CronJob, pod e i relativi proprietari, inclusi deployment, DaemonSet e StatefulSet.
Dettagli sulla configurazione di ciascun nodo, inclusi indirizzi IP, regole iptables, punti di montaggio, file system, connessioni di rete e processi in esecuzione.
Informazioni sul runtime delle VM su GDC e su eventuali VM e risorse correlate alle VM in esecuzione nel cluster. Per ulteriori informazioni su cosa viene raccolto per impostazione predefinita e su come creare snapshot specifici per le VM, consulta Informazioni sulle VM negli snapshot in questo documento.
Log dal comando bmctl check cluster --snapshot.

Le informazioni sulle credenziali di un cluster non sono incluse nello snapshot predefinito. Se il team di assistenza clienti di Cloud richiede queste informazioni, consulta la sezione Recupero delle informazioni sui cluster.

Per un elenco completo delle informazioni raccolte quando esegui l'istantanea consulta la sezione seguente relativa al dettaglio del file di configurazione. Questo file di configurazione mostra i comandi che vengono eseguiti quando viene acquisita una snapshot predefinita.

Crea uno snapshot predefinito

Il comando bmctl check cluster acquisisce uno snapshot di un cluster. Puoi utilizzare la modalità questo comando per eseguire una delle seguenti azioni:

Creare uno snapshot e caricarlo automaticamente in un bucket Cloud Storage.
Crea uno snapshot di un cluster e salva il file dello snapshot sulla macchina locale su cui stai eseguendo il comando.

Metodo 1: crea uno snapshot predefinito e caricalo automaticamente nel bucket Cloud Storage

Per creare e caricare uno snapshot in un bucket Cloud Storage, segui questi passaggi:

Configura l'API e l'account di servizio come descritto in Configurare un account di servizio che può accedere a un bucket Cloud Storage.

Si tratta di un passaggio da eseguire una sola volta.
Esegui questo comando bmctl per creare e caricare automaticamente un snapshot in un bucket Cloud Storage:
```
bmctl check cluster --snapshot --cluster=CLUSTER_NAME \
    --admin-kubeconfig=ADMIN_KUBECONFIG \
    --service-account-key-file SA_KEY_FILE
```
Sostituisci le seguenti voci con informazioni specifiche per il tuo ambiente in cluster:
- CLUSTER_NAME: il nome del cluster di cui vuoi eseguire lo snapshot.
- ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.
- SA_KEY_FILE: il percorso del file della chiave JSON scaricato per l'account di servizio creato nel passaggio precedente. Se non utilizzi il flag --service-account-key-file, il comando utilizza le credenziali associate alla variabile di ambiente GOOGLE_APPLICATION_CREDENTIALS. La specifica esplicita delle credenziali dell'account di servizio con il flag ha la precedenza.
Questo comando genera un file tar dello snapshot e lo salva localmente. Quando sia configurato correttamente, il comando carica anche il file tar dello snapshot in un bucket di archiviazione ideale in Cloud Storage. Il comando cerca un bucket di archiviazione nel tuo progetto che ha un nome che inizia con "anthos-snapshot-" Se un bucket di questo tipo esistente, il comando carica lo snapshot nel 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.

Nota: puoi utilizzare il flag --upload-to per specificare un nome del bucket in cui viene caricato lo snapshot.
Condividi l'accesso con l'assistenza clienti Google Cloud come descritto in Consentire all'assistenza clienti Google Cloud di visualizzare lo snapshot del cluster caricato.

Metodo 2: crea snapshot predefiniti solo sulla macchina locale

Utilizza il flag --local per assicurarti che lo snapshot del cluster venga salvato solo localmente. Puoi acquisire lo stato dei cluster creati con quanto segue :

bmctl check cluster --snapshot --cluster=CLUSTER_NAME \
    --admin-kubeconfig=ADMIN_KUBECONFIG --local

Sostituisci quanto segue:

CLUSTER_NAME: il nome del cluster di destinazione.
ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.

Questo comando restituisce un file tar sulla tua macchina locale. Il nome di questo file tar è nel formatosnapshot-CLUSTER_NAME-TIMESTAMP.tar.gz, dove TIMESTAMP indica la data e l'ora di creazione del file. Questo file tar include informazioni di debug pertinenti sui componenti di sistema e sulle macchine di un cluster.

Quando esegui questo comando, le informazioni sui pod vengono raccolte i seguenti spazi dei nomi: gke-system, gke-connect, capi-system, capi-webhook-system, cert-manager e capi-kubeadm-bootstrap-system

Tuttavia, è possibile ampliare l'ambito delle informazioni diagnostiche raccolte utilizzando il flag --snapshot-scenario all. Questo flag aumenta l'ambito snapshot diagnostico per includere tutti i pod in un cluster:

bmctl check cluster --snapshot --snapshot-scenario all \
    --cluster=CLUSTER_NAME \
    --kubeconfig=KUBECONFIG_PATH \
    --local

Scenari di snapshot

Il comando bmctl check cluster --snapshot supporta due scenari. Per specificare un scenario, utilizza il flag --scenario. Il seguente elenco mostra le possibili valori:

system: raccogli uno snapshot dei componenti di sistema, inclusi i log.
all: raccogli uno snapshot di tutti i pod, inclusi i log.

Puoi utilizzare ciascuno dei due scenari con un cluster di amministrazione o un utente in un cluster Kubernetes. L'esempio seguente crea uno snapshot del cluster di amministrazione utilizzando il comando system scenario:

bmctl check cluster --snapshot --snapshot-scenario system \
    --cluster=ADMIN_CLUSTER_NAME \
    --kubeconfig=ADMIN_KUBECONFIG_PATH

L'esempio seguente crea uno snapshot di un cluster utente utilizzando all :

bmctl check cluster --snapshot --snapshot-scenario all \
    --cluster=USER_CLUSTER_NAME \
    --kubeconfig=USER_KUBECONFIG_PATH

Eseguire una prova di uno snapshot

Quando utilizzi il flag --snapshot-dry-run, il comando non crea uno snapshot. Mostra invece le azioni che il comando snapshot eseguirà e genera un file di configurazione dello snapshot. Per informazioni sul file di configurazione dell'istantanea, consulta Come creare uno snapshot personalizzato.

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

bmctl check cluster --snapshot --snapshot-dry-run \
    --cluster=ADMIN_CLUSTER_NAME \
    --kubeconfig=ADMIN_KUBECONFIG_PATH

Per eseguire uno snapshot dry run su un cluster utente, inserisci questo comando:

bmctl check cluster --snapshot --snapshot-dry-run \
    --cluster=USER_CLUSTER_NAME \
    --kubeconfig=USER_KUBECONFIG_PATH

Recuperare i log di un determinato periodo

Puoi utilizzare il flag --since per recuperare i log di un periodo di tempo che ti interessa particolarmente. In questo modo, puoi creare istantanee più piccole e mirate dei log che si sono verificati negli ultimi secondi, minuti o ore.

Ad esempio, il seguente comando bmctl crea uno snapshot dei log che si sono verificati nelle ultime tre ore:

bmctl check cluster --snapshot --since=3h \
    --cluster=CLUSTER_NAME \
    --kubeconfig=ADMIN_KUBECONFIG_PATH

Specifica una directory in cui salvare temporaneamente lo snapshot

Puoi utilizzare il flag --snapshot-temp-output-dir per specificare una directory in cui lo snapshot viene salvato temporaneamente:

bmctl check cluster --snapshot --snapshot-temp-output-dir=TEMP_OUTPUT_DIR \
    --cluster=CLUSTER_NAME \
    --kubeconfig=ADMIN_KUBECONFIG_PATH

Se non specifichi una directory, lo snapshot viene salvato temporaneamente nella directory /tmp. L'utilizzo dell'opzione --snapshot-temp-output-dir è consigliabile, ad esempio, quando lo spazio è limitato nella directory /tmp predefinita.

Elimina log della console

Puoi utilizzare il flag --quiet per impedire la visualizzazione dei messaggi di log nel durante l'esecuzione di uno snapshot. I log della console vengono invece salvati "bmctl_diagnose_snapshot.log" come parte dello snapshot.

Esegui questo comando per impedire la visualizzazione dei messaggi di log nella console:

bmctl check cluster --snapshot --quiet \
    --cluster=CLUSTER_NAME \
    --kubeconfig=ADMIN_KUBECONFIG_PATH

Snapshot personalizzati

Ti consigliamo di creare uno snapshot personalizzato di un cluster per motivi:

Per includere più informazioni sul cluster rispetto a quelle fornite nell'istantanea predefinita.
Per escludere alcune informazioni presenti nello snapshot predefinito.

Creare uno snapshot personalizzato

La creazione di uno snapshot personalizzato richiede l'utilizzo di una configurazione snapshot . I passaggi seguenti spiegano come creare il file di configurazione, modificare e usalo per creare uno snapshot personalizzato di un cluster:

Crea un file di configurazione snapshot eseguendo questo comando del cluster e scrivere l'output in un file:

bmctl check cluster \
    --snapshot --snapshot-dry-run --cluster CLUSTER_NAME \
    --kubeconfig KUBECONFIG_PATH

Definisci il tipo di informazioni che vuoi visualizzare nel tuo senza dover creare uno snapshot. Per farlo, modifica il file di configurazione dell'istantanea creato nel passaggio 1. Ad esempio, se vuoi che lo snapshot contenga informazioni aggiuntive, come il tempo di esecuzione di un determinato nodo, aggiungi il comando Linux uptime alla sezione pertinente della configurazione .

Il seguente snippet di un file di configurazione mostra come fare in modo che il comando uptime fornisca informazioni sul nodo 10.200.0.3. Questo non vengono visualizzate in uno snapshot standard.
```
...
nodeCommands:
- nodes:
  - 10.200.0.3
  commands:
  - uptime
...
```
Dopo aver modificato il file di configurazione per definire il tipo di snapshot che vuoi, crea lo snapshot personalizzato eseguendo il seguente comando:
```
bmctl check cluster --snapshot --snapshot-config SNAPSHOT_CONFIG_FILE \
    --cluster CLUSTER_NAME--kubeconfig KUBECONFIG_PATH
```
Il flag --snapshot-config indica al comando bmctl di utilizzare i contenuti del file di configurazione dello snapshot per definire le informazioni visualizzate nello snapshot.

Il file di configurazione nel dettaglio

Il seguente file di configurazione dello snapshot di esempio mostra i comandi standard e usati per creare uno snapshot, ma puoi aggiungere altri comandi e file quando Sono necessarie ulteriori informazioni diagnostiche:

numOfParallelThreads: 10
excludeWords:
- password
nodeCommands:
- nodes:
  - 10.200.0.3
  - 10.200.0.4
  commands:
  - uptime
  - df --all --inodes
  - ip addr
  - ip neigh
  - iptables-save --counters
  - mount
  - ip route list table all
  - top -bn1 || true
  - docker info || true
  - docker ps -a || true
  - crictl ps -a || true
  - docker ps -a | grep anthos-baremetal-haproxy | cut -d ' ' -f1 | head -n 1 | xargs
    sudo docker logs || true
  - docker ps -a | grep anthos-baremetal-keepalived | cut -d ' ' -f1 | head -n 1 |
    xargs sudo docker logs || true
  - crictl ps -a | grep anthos-baremetal-haproxy | cut -d ' ' -f1 | head -n 1 | xargs
    sudo crictl logs || true
  - crictl ps -a | grep anthos-baremetal-keepalived | cut -d ' ' -f1 | head -n 1 |
    xargs sudo crictl logs || true
  - ps -edF
  - ps -eo pid,tid,ppid,class,rtprio,ni,pri,psr,pcpu,stat,wchan:14,comm,args,cgroup
  - conntrack --count
  - dmesg
  - systemctl status -l docker || true
  - journalctl --utc -u docker
  - journalctl --utc -u docker-monitor.service
  - systemctl status -l kubelet
  - journalctl --utc -u kubelet
  - journalctl --utc -u kubelet-monitor.service
  - journalctl --utc --boot --dmesg
  - journalctl --utc -u node-problem-detector
  - systemctl status -l containerd || true
  - journalctl --utc -u containerd
  - systemctl status -l docker.haproxy || true
  - journalctl --utc -u docker.haproxy
  - systemctl status -l docker.keepalived || true
  - journalctl --utc -u docker.keepalived
  - systemctl status -l container.haproxy || true
  - journalctl --utc -u container.haproxy
  - systemctl status -l container.keepalived || true
  - journalctl --utc -u container.keepalived
nodeFiles:
- nodes:
  - 10.200.0.3
  - 10.200.0.4
  files:
  - /proc/sys/fs/file-nr
  - /proc/sys/net/netfilter/nf_conntrack_max
  - /proc/sys/net/ipv4/conf/all/rp_filter
  - /lib/systemd/system/kubelet.service
  - /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
  - /lib/systemd/system/docker.service || true
  - /etc/systemd/system/containerd.service || true
  - /etc/docker/daemon.json || true
  - /etc/containerd/config.toml || true
  - /etc/systemd/system/container.keepalived.service || true
  - /etc/systemd/system/container.haproxy.service || true
  - /etc/systemd/system/docker.keepalived.service || true
  - /etc/systemd/system/docker.haproxy.service || true
nodeSSHKey: ~/.ssh/id_rsa # path to your ssh key file

È probabile che le seguenti voci nel file di configurazione siano diverse da quelle visualizzate nel file di configurazione di esempio precedente:

Gli indirizzi IP dei nodi nelle sezioni nodeCommands e nodeFiles
Il percorso del file nodeSSHKey del cluster

Campi nel file di configurazione

Un file di configurazione dello snapshot è in formato YAML. Il file di configurazione include i seguenti campi:

numOfParallelThreads: in genere la routine di snapshot esegue numerosi comandi. Più thread paralleli consentono un'esecuzione più rapida della routine. Ti consigliamo di impostare numOfParallelThreads su 10 come mostrato nel precedente file di configurazione di esempio. Se gli istantanei richiedono troppo tempo, aumenta questo valore.
excludeWords: lo snapshot contiene una grande quantità di dati per i nodi del cluster. Usa excludeWords per ridurre i rischi per la sicurezza quando condividi contenuti per creare lo snapshot. Ad esempio, escludi password in modo che le stringhe di password corrispondenti non possano essere identificate.
nodeCommands: questa sezione specifica le seguenti informazioni:
- nodes: un elenco di indirizzi IP dei nodi del cluster da cui vuoi raccogliere informazioni. a creare uno snapshot quando il cluster di amministrazione non è raggiungibile, specifica almeno un indirizzo IP del nodo.
- commands: un elenco di comandi (e argomenti) da eseguire su ogni nodo. L'output di ogni comando è incluso nello snapshot.
nodeFiles: questa sezione specifica le seguenti informazioni:
- nodes: un elenco di indirizzi IP dei nodi del cluster da cui vuoi raccogliere i file. Creare uno snapshot quando il cluster di amministrazione non raggiungibile, specifica almeno un indirizzo IP del nodo.
- files: un elenco di file da recuperare da ogni nodo. Quando i file specificati vengono trovati su un nodo, vengono inclusi nell'istantanea.
nodeSSHKey: percorso del file della chiave SSH. Quando il cluster di amministrazione viene non raggiungibile, questo campo è obbligatorio.

Crea snapshot quando si verificano errori specifici

Per creare correttamente potrebbero essere necessari passaggi o parametri di comando aggiuntivi un'istantanea quando si verificano determinati eventi, ad esempio un upgrade bloccato.

Crea uno snapshot predefinito in caso di installazioni o upgrade bloccati

Quando installi o esegui l'upgrade di cluster di amministrazione, ibridi o autonomi, bmctl può a volte si bloccano in punti in cui possono essere visualizzati i seguenti output:

In attesa che il file kubeconfig del cluster sia pronto.
In attesa che il cluster sia pronto.
In attesa che i pool di nodi siano pronti.
In attesa del completamento dell'upgrade.

Se un'installazione o un upgrade si è bloccato, puoi acquisire un'istantanea di un utilizzando il cluster cluster di bootstrap, come mostrato in nell'esempio seguente:

bmctl check cluster --snapshot --cluster=CLUSTER_NAME \
    --kubeconfig=WORKSPACE_DIR/.kindkubeconfig

Crea un'istantanea personalizzata durante le installazioni o gli upgrade in fase di stallo

I passaggi riportati di seguito mostrano come creare uno snapshot personalizzato di un cluster quando un'installazione o un upgrade è in stallo:

Recupera un file di configurazione dell'istantanea del cluster dai tuoi archivi.
Modifica il file di configurazione dello snapshot in modo che quest'ultimo contenga le informazioni desiderate.

Crea lo snapshot personalizzato eseguendo il seguente comando:

bmctl check cluster --snapshot
    --snapshot-config=SNAPSHOT_CONFIG_FILE \
    --cluster=CLUSTER_NAME
    --kubeconfig=WORKSPACE_DIR/.kindkubeconfig

Creare uno snapshot personalizzato quando il cluster di amministrazione non è raggiungibile

Quando il cluster di amministrazione non è raggiungibile, puoi acquisire uno snapshot personalizzato eseguendo questo comando:

bmctl check cluster --snapshot --cluster CLUSTER_NAME
    --node-ssh-key SSH_KEY_FILE
    --nodes NODE_1_IP_ADDRESS, NODE_2_IP_ADDRESS, ...

Nel comando, sostituisci le voci seguenti con informazioni specifiche per il tuo nell'ambiente del cluster:

CLUSTER_NAME: il nome del cluster che vuoi di creare un'istantanea.
SSH_KEY_FILE: il percorso del file della chiave SSH del nodo.
NODE_x_IP_ADDRESS: l'indirizzo IP di un nodo del cluster su cui desideri informazioni.

In alternativa, puoi elencare gli indirizzi IP dei nodi su righe separate:

bmctl check cluster
    --snapshot --cluster CLUSTER_NAME \
    --node-ssh-key SSH_KEY_FILE \
    --nodes NODE_1_IP_ADDRESS \
    --nodes NODE_2_IP_ADDRESS
  ...

Informazioni sulle VM negli snapshot

Se utilizzi il runtime VM su GDC per creare e gestire macchine virtuali (VM) su Google Distributed Cloud, puoi raccogliere informazioni di diagnostica pertinenti negli snapshot. Gli snapshot sono una risorsa fondamentale per diagnosticare e per la risoluzione dei problemi relativi alle VM.

Che cosa viene raccolto per impostazione predefinita

Quando crei uno snapshot predefinito, questo contiene informazioni sul runtime VM in GDC e sulle risorse correlate. Il runtime VM su GDC è in bundle con Google Distributed Cloud e la risorsa personalizzata VMRuntime è disponibile sui cluster che eseguono i carichi di lavoro. Anche se non hai abilitato il runtime VM su GDC, lo snapshot contiene ancora la descrizione YAML della risorsa personalizzata VMRuntime.

Se hai attivato il runtime delle VM su GDC, gli snapshot contengono informazioni sullo stato e sulla configurazione delle risorse correlate alle VM (se gli oggetti sono presenti) nel cluster. Le risorse relative alle VM includono gli oggetti Kubernetes, come pod, deployment, DaemonSet e ConfigMap.

Oggetti nello spazio dei nomi `vm-system`

Le informazioni su stato e configurazione dei seguenti oggetti si trovano in kubectlCommands/vm-system nello snapshot generato:

KubeVirt
VirtualMachineType
VMHighAvailabilityPolicy

Oggetti in altri spazi dei nomi

Quando crei una VM (VirtualMachine), puoi specificare lo spazio dei nomi. Se non specifichi uno spazio dei nomi, la VM ottiene lo spazio dei nomi default. Gli altri oggetti in questa sezione, come VirtualMachineInstance, sono tutti associati allo spazio dei nomi della VM corrispondente.

Le informazioni sullo stato e sulla configurazione dei seguenti oggetti si trovano in kubectlCommands/VM_NAMESPACE nello snapshot generato. Se non hai impostato uno spazio dei nomi specifico per la VM, le informazioni si trovano in kubectlCommands/default:

VirtualMachine
VirtualMachineInstance
VirtualMachineDisk
GuestEnvironmentData
VirtualMachineAccessRequest
VirtualMachinePasswordResetRequest

Oggetti senza spazio dei nomi

Per i seguenti oggetti non è stato impostato uno spazio dei nomi, pertanto le informazioni corrispondenti vengono che si trova direttamente in kubectlCommands nello snapshot generato:

VMRuntime
DataVolume
CDI
GPUAllocation

Utilizzare un file di configurazione dello snapshot per acquisire solo i dettagli della VM

Se stai diagnosticando problemi specifici per le VM, puoi utilizzare un file di configurazione dello snapshot per limitare le informazioni raccolte solo ai dettagli relativi alle VM e personalizzare le informazioni raccolte sulle VM.

Il seguente file di configurazione dello snapshot illustra come costruire una Snapshot specifico per la VM. Puoi includere comandi aggiuntivi per raccogliere più informazioni per lo snapshot.

---
kubectlCommands:
- commands:
    - kubectl get vm -o wide
    - kubectl get vmi -o wide
    - kubectl get gvm -o wide
    - kubectl get vm -o yaml
    - kubectl get vmi -o yaml
    - kubectl get gvm -o yaml
    - kubectl describe vm
    - kubectl describe vmi
    - kubectl describe gvm
  namespaces:
    - .*
- commands:
    - kubectl get virtualmachinetype -o wide
    - kubectl get virtualmachinedisk -o wide
    - kubectl get virtualmachinetype -o yaml
    - kubectl get virtualmachinedisk -o yaml
    - kubectl describe virtualmachinetype
    - kubectl describe virtualmachinedisk
  namespaces:
    - vm-system

Per ulteriori informazioni sull'uso dei file di configurazione degli snapshot, consulta Snapshot personalizzate in questo documento.

Passaggi successivi