Risoluzione dei problemi: diagnostica e reimpostazione dei cluster

Puoi diagnosticare o controllare i cluster per eseguire il debug dei problemi e acquisire uno snapshot dello stato del cluster. Inoltre, se l'installazione è riuscita parzialmente, ma il cluster restituisce errori o non ha le prestazioni adeguate, puoi provare a reimpostare il cluster.

Diagnostica dei cluster con bmctl check cluster in corso...

Puoi acquisire lo stato dei cluster creati con il comando bmctl check cluster. I flag per il comando ti consentono di scegliere l'ambito diagnostico del comando in modo da ottenere informazioni dettagliate.

Le informazioni di diagnostica possono aiutarti a rilevare i problemi e a eseguire il debug dei deployment in modo più efficace. Il comando acquisisce tutti i file di configurazione di cluster e nodi pertinenti per l'ambito definito e poi pacchettizza le informazioni in un singolo archivio tar.

bmctl check cluster --snapshot --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG_PATH

Sostituisci quanto segue:

  • CLUSTER_NAME: il nome del cluster di destinazione.

  • ADMIN_KUBECONFIG_PATH: il percorso del file kubeconfig del cluster di amministrazione.

Questo comando genera un archivio tar che include informazioni di debug pertinenti da tutti i componenti e le macchine di sistema nel cluster specificato.

Puoi modificare l'ambito delle informazioni di diagnostica raccolte con i seguenti flag di comando:

  • Il flag --snapshot-scenario all aumenta l'ambito dello snapshot di diagnostica in modo da includere tutti i pod nel cluster specificato:
bmctl check cluster --snapshot --snapshot-scenario all --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG_PATH
  • Il flag --snapshot-dry-run funziona in combinazione con il flag --snapshot-config string. Utilizza il flag --snapshot-dry-run per generare un file di configurazione che puoi modificare per definire un ambito diagnostico personalizzato. L'ambito può includere pod, spazi dei nomi o comandi nodo specifici.

Dopo aver modificato il file di output creato con il flag --snapshot-dry-run, puoi utilizzarlo come input per diagnosticare l'ambito specifico con il flag --snapshot-config string, descritto di seguito. Se ometti questo flag, viene applicata una configurazione predefinita.

bmctl check cluster --snapshot --snapshot-dry-run --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG_PATH
  • Il flag --snapshot-config indica al comando bmctl di utilizzare le opzioni dell'ambito specificate in un file di configurazione degli snapshot. In genere, crei il file di configurazione dello snapshot con il flag --snapshot-dry-run.
bmctl check cluster --snapshot --snapshot-config SNAPSHOT_CONFIG_FILE --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG_PATH

Diagnostica dei cluster quando il cluster di amministrazione non è raggiungibile

Quando il cluster di amministrazione è inattivo o non è raggiungibile, utilizza un file di configurazione snapshot per acquisire uno snapshot del cluster. Un file di configurazione degli snapshot è in formato YAML. Il file di configurazione include i seguenti campi per specificare il modo in cui le informazioni vengono acquisite per il cluster:

  • numOfParallelThreads: in genere, la routine snapshot esegue numerosi comandi. Più thread paralleli aiutano la routine a essere eseguita più velocemente. Ti consigliamo di impostare numOfParallelThreads su 10, come mostrato nell'esempio seguente. Se gli snapshot 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 lo snapshot. Ad esempio, escludi password in modo che non sia possibile identificare le stringhe di password corrispondenti.

  • nodeCommands: in questa sezione sono specificate le seguenti informazioni:

    • nodes: un elenco di indirizzi IP per i nodi del cluster da cui vuoi raccogliere informazioni. Per 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 ciascun nodo. Lo output di ogni comando è incluso nello snapshot.

  • nodeFiles: in questa sezione sono specificate le seguenti informazioni:

    • nodes: un elenco di indirizzi IP per i nodi del cluster da cui vuoi raccogliere i file. Per creare uno snapshot quando il cluster di amministrazione non è raggiungibile, specifica almeno un indirizzo IP del nodo .

    • files: un elenco dei file da recuperare da ciascun nodo. Quando i file specificati vengono rilevati su un nodo, vengono inclusi nello snapshot.

  • nodeSSHKey: percorso del file della chiave SSH per i tuoi nodi. Questo campo è obbligatorio per creare uno snapshot quando il cluster di amministrazione non è raggiungibile.

Utilizza il comando seguente per creare uno snapshot utilizzando un file di configurazione snapshot:

bmctl check cluster --snapshot --snapshot-config SNAPSHOT_CONFIG

Sostituisci SNAPSHOT_CONFIG con il percorso del file di configurazione dello snapshot.

Il seguente file di configurazione degli snapshot mostra i comandi e i file standard utilizzati per la creazione di uno snapshot. Puoi aggiungere altri comandi e file quando sono necessarie ulteriori informazioni di diagnostica.

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 to each nodes

Crea uno snapshot per l'installazione/l'upgrade bloccati del cluster di amministrazione

Quando installi cluster di amministrazione/ibridi/autonome, se bmctl è bloccato al seguente output

  • In attesa che il cluster kubeconfig sia pronto
  • In attesa che il cluster sia pronto
  • In attesa che i pool di nodi siano pronti

o quando esegui l'upgrade di cluster di amministrazione/ibridi/standalone,

  • In attesa del completamento dell'upgrade

puoi eseguire il comando seguente per creare uno snapshot utilizzando il cluster bootstrap.

bmctl check cluster --snapshot --kubeconfig <var>WORKSPACE_DIR</var>/.kindkubeconfig --cluster <var>CLUSTER_NAME</var>

Reimpostazione dei cluster con bmctl reset cluster in corso...

Se l'installazione di un cluster non va a buon fine, puoi provare a ripristinare lo stato pulito dei nodi reimpostandolo. Quindi puoi reinstallare il cluster dopo aver apportato modifiche alla configurazione.

Reimpostazione dei cluster autogestiti

Per reimpostare un cluster che si gestisce da solo, ad esempio un cluster di amministrazione, esegui il comando seguente:

bmctl reset --cluster CLUSTER_NAME

Sostituisci CLUSTER_NAME con il nome del cluster che stai reimpostando.

Reimpostazione dei cluster utente

Per reimpostare un cluster utente, esegui il comando seguente:

bmctl reset --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG_PATH

Sostituisci CLUSTER_NAME con il nome del cluster utente che stai reimpostando e sostituisci ADMIN_KUBECONFIG_PATH con il percorso del file kubeconfig del cluster di amministrazione associato. bmctl supporta l'utilizzo di --kubeconfig come alias del flag --admin-kubeconfig.

Reimposta dettagli cluster

Indipendentemente dal tipo di cluster, il comando di reimpostazione viene applicato all'intero cluster. Non esiste un'opzione per scegliere come target un sottoinsieme di nodi in un cluster.

L'output del comando bmctl cluster reset è simile al seguente esempio:

bmctl reset --cluster cluster1
Creating bootstrap cluster... OK
Deleting GKE Hub member admin in project my-gcp-project...
Successfully deleted GKE Hub member admin in project my-gcp-project
Loading images... OK
Starting reset jobs...
Resetting: 1    Completed: 0    Failed: 0
...
Resetting: 0    Completed: 1    Failed: 0
Flushing logs... OK

Durante l'operazione di reimpostazione, bmctl tenta di eliminare la registrazione dell'abbonamento all'hub GKE, quindi pulisce i nodi interessati. Durante il ripristino, vengono eliminati anche i supporti di archiviazione e i dati di anthos-system StorageClass.

Per tutti i nodi, bmctl esegue kubeadm reset, rimuove le interfacce del tunnel utilizzate per il networking del cluster ed elimina le seguenti directory:

  • /etc/kubernetes
  • /etc/cni/net.d
  • /root/.kube
  • /var/lib/kubelet

Per i nodi del bilanciatore del carico, bmctl esegue anche le seguenti azioni:

  • Disattiva i servizi keepalived e haproxy
  • Elimina i file di configurazione per keepalived e haproxy

Lo strumento di reimpostazione prevede che il file di configurazione del cluster si trovi nella seguente posizione all'interno della directory di lavoro attuale:

bmctl-workspace/cluster name/cluster name.yaml