Risolvere i problemi di installazione o upgrade dei cluster

Version 1.16 

• Ultimi
• Versione 1.16
• Versioni precedenti (non supportate)

Questa pagina fornisce informazioni per la risoluzione dei problemi in caso di problemi durante l'installazione o l'upgrade di cluster GKE su Bare Metal.

Problemi relativi al cluster di bootstrap

Quando GKE su Bare Metal crea cluster autogestiti (amministrati, ibridi o autonomi), esegue il deployment di un cluster Kubernetes in Docker (kind) per ospitare temporaneamente i controller Kubernetes necessari alla creazione dei cluster. Questo cluster temporaneo è chiamato cluster di bootstrap. I cluster utente vengono creati e aggiornati dall'amministratore di gestione o dal cluster ibrido senza utilizzare un cluster di bootstrap.

Nota: a partire da GDCV per Bare Metal versione 1.15.0, il comportamento di upgrade predefinito per i cluster autogestiti (amministratori, ibridi o autonomi) è un upgrade in loco. Gli upgrade in loco utilizzano controller del ciclo di vita, anziché un cluster di bootstrap, per gestire l'intera operazione di upgrade. Questa modifica semplifica il processo e riduce i requisiti di risorse, rendendo più affidabili e scalabili gli upgrade dei cluster. Sebbene non sia consigliato, impostando il flag --use-bootstrap=true con il comando bmctl upgrade, hai comunque la possibilità di utilizzare un cluster di bootstrap.

Se un cluster di tipo esiste già nel deployment quando tenti di installarlo, GKE su Bare Metal elimina il cluster di tipo esistente. L'eliminazione avviene solo dopo che l'installazione o l'upgrade sono andati a buon fine. Per conservare il cluster di tipo esistente anche dopo l'esito positivo, utilizza il flag --keep-bootstrap-cluster di bmctl.

GKE su Bare Metal crea un file di configurazione per il cluster di bootstrap in WORKSPACE_DIR/.kindkubeconfig. Puoi connetterti al cluster di bootstrap solo durante la creazione e l'upgrade del cluster.

Il cluster di bootstrap deve accedere a un repository Docker per eseguire il pull delle immagini. Per impostazione predefinita, il registro è Container Registry, a meno che non utilizzi un registro privato. Durante la creazione del cluster,bmctl crea i seguenti file:

• bmctl-workspace/config.json: contiene le credenziali dell'account di servizio Google Cloud per l'accesso al registry. Le credenziali sono ottenute dal campo gcrKeyPath nel file di configurazione del cluster.

• bmctl-workspace/config.toml: contiene la configurazione containerd nel cluster di tipo.

Esegui il debug del cluster di bootstrap

Per eseguire il debug del cluster di bootstrap, puoi seguire questi passaggi:

• Connettiti al cluster di bootstrap durante la creazione e l'upgrade del cluster.
• Recupera i log del cluster di bootstrap.

Puoi trovare i log nella macchina che utilizzi per eseguire bmctl nelle seguenti cartelle:

• bmctl-workspace/CLUSTER_NAME/log/create-cluster-TIMESTAMP/bootstrap-cluster/
• bmctl-workspace/CLUSTER_NAME/log/upgrade-cluster-TIMESTAMP/bootstrap-cluster/

Sostituisci CLUSTER_NAME e TIMESTAMP con il nome del cluster e l'ora del sistema corrispondente.

Per ottenere i log direttamente dal cluster di bootstrap, puoi eseguire il seguente comando durante la creazione e l'upgrade del cluster:

docker exec -it bmctl-control-plane bash

Il comando apre un terminale all'interno del container del piano di controllo bmctl in esecuzione nel cluster di bootstrap.

Per esaminare i log kubelet e containerd, utilizza i comandi seguenti e cerca errori o avvisi nell'output:

journalctl -u kubelet
journalctl -u containerd

Problemi di upgrade del cluster

Quando esegui l'upgrade di GDCV per Bare Metal, puoi monitorare l'avanzamento e controllare lo stato dei cluster e dei nodi.

• Se riscontri problemi durante un upgrade, prova a determinare in quale fase si verifica l'errore. Per scoprire di più su cosa succede a un cluster durante il processo di upgrade, consulta Ciclo di vita e fasi degli upgrade del cluster.
• Per saperne di più sull'impatto di un problema durante gli upgrade del cluster, consulta Comprendere l'impatto degli errori in GDCV per Bare Metal.

Le indicazioni seguenti possono aiutarti a determinare se l'upgrade continua normalmente o se si è verificato un problema.

Monitorare l'avanzamento dell'upgrade

Utilizza il comando kubectl describe cluster per visualizzare lo stato di un cluster durante il processo di upgrade:

kubectl describe cluster CLUSTER_NAME \
    --namespace CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG

Sostituisci i seguenti valori:

• CLUSTER_NAME: nome del cluster.
• CLUSTER_NAMESPACE: lo spazio dei nomi del cluster.
• ADMIN_KUBECONFIG: il file kubeconfig di amministrazione.
  • Per impostazione predefinita, i cluster amministrativi, ibridi e autonomi utilizzano un upgrade in loco. Se usi il flag --use-bootstrap=true con il comando bmctl upgrade, l'operazione di upgrade utilizza un cluster di bootstrap. Per monitorare l'avanzamento dell'upgrade quando viene utilizzato un cluster di bootstrap, specifica il percorso del file kubeconfig del cluster di bootstrap, .kindkubeconfig. Questo file si trova nella directory dell'area di lavoro.

Osserva la sezione Status dell'output, che mostra un'aggregazione dello stato dell'upgrade del cluster. Se il cluster segnala un errore, usa le seguenti sezioni per capire dov'è il problema.

Controlla se i nodi sono pronti

Utilizza il comando kubectl get nodes per visualizzare lo stato dei nodi in un cluster durante il processo di upgrade:

kubectl get nodes --kubeconfig KUBECONFIG

Per verificare se un nodo ha completato correttamente il processo di upgrade, osserva le colonne VERSION e AGE nella risposta del comando. VERSION è la versione di Kubernetes per il cluster. Per visualizzare la versione di Kubernetes per una determinata versione di GDCV per Bare Metal, consulta la tabella in Criteri di supporto delle versioni.

Se il nodo mostra NOT READY, prova a connetterlo e controlla lo stato di kubelet:

systemctl status kubelet

Puoi anche esaminare i log di kubelet:

journalctl -u kubelet

Esamina l'output dello stato kubelet e i log dei messaggi che indicano il motivo per cui il nodo presenta un problema.

Verifica quale nodo è attualmente in fase di upgrade

Per verificare quale nodo del cluster è in fase di upgrade, utilizza il comando kubectl get baremetalmachines:

kubectl get baremetalmachines --namespace CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG

Sostituisci i seguenti valori:

• CLUSTER_NAMESPACE: lo spazio dei nomi del cluster.
• ADMIN_KUBECONFIG: il file kubeconfig di amministrazione.
  • Se per un upgrade amministrativo, ibrido o autonomo viene utilizzato un cluster di bootstrap, specifica il file kubeconfig del cluster di bootstrap (bmctl-workspace/.kindkubeconfig).

L'output di esempio seguente mostra che il nodo in fase di upgrade ha un valore ABM VERSION diverso da DESIRED ABM VERSION:

NAME         CLUSTER    READY   INSTANCEID               MACHINE      ABM VERSION   DESIRED ABM VERSION
10.200.0.2   cluster1   true    baremetal://10.200.0.2   10.200.0.2   1.13.0        1.14.0
10.200.0.3   cluster1   true    baremetal://10.200.0.3   10.200.0.3   1.13.0        1.13.0

Controlla quali nodi vengono svuotati

Durante il processo di upgrade, i nodi vengono svuotati dai nodi e la pianificazione viene disabilitata fino a quando l'upgrade del nodo non viene eseguito correttamente. Per vedere quali nodi vengono svuotati dai pod, utilizza il comando kubectl get nodes:

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG | grep "SchedulingDisabled"

Sostituisci USER_CLUSTER_KUBECONFIG con il percorso del file kubeconfig del cluster utente.

La colonna STATUS viene filtrata utilizzando grep per mostrare solo i nodi che segnalano SchedulingDisabled. Questo stato indica che è in corso lo svuotamento dei nodi.

Puoi anche controllare lo stato del nodo dal cluster di amministrazione:

kubectl get baremetalmachines -n CLUSTER_NAMESPACE \
  --kubeconfig ADMIN_KUBECONFIG

Sostituisci i seguenti valori:

• CLUSTER_NAMESPACE: lo spazio dei nomi del cluster.
• ADMIN_KUBECONFIG: il file kubeconfig di amministrazione.
  • Se per un upgrade amministrativo, ibrido o autonomo viene utilizzato un cluster di bootstrap, specifica il file kubeconfig del cluster di bootstrap (bmctl-workspace/.kindkubeconfig).

Il nodo che viene svuotato mostra lo stato nella colonna MAINTENANCE.

Verificare perché lo stato di svuotamento di un nodo è prolungato

Utilizza uno dei metodi della sezione precedente per identificare il nodo che viene svuotato utilizzando il comando kubectl get nodes. Utilizza il comando kubectl get pods e filtra in base a questo nome nodo per visualizzare ulteriori dettagli:

kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=NODE_NAME

Sostituisci NODE_NAME con il nome del nodo che viene svuotato. L'output restituisce un elenco di pod bloccati o lenti. L'upgrade procede, anche con i pod bloccati, quando il processo di svuotamento su un nodo richiede più di 20 minuti.

verifica perché i pod non sono integri

Gli upgrade possono non riuscire se un pod contiene indirizzi IP del piano di controllo upgrade-first-node o upgrade-node. In genere questo comportamento è dovuto al fatto che i pod statici non sono integri.

1. Controlla i pod statici con il comando crictl ps -a e cerca eventuali pod di Kubernetes o etcd con arresto anomalo. Se hai pod con errori, esamina i log dei pod per capire perché si arrestano in modo anomalo.

   Di seguito sono riportate alcune possibili cause di comportamento degli arresti anomali:

   • Le autorizzazioni o il proprietario dei file montati sui pod statici non sono corretti.
   • La connettività all'indirizzo IP virtuale non funziona.
   • Problemi relativi a etcd.

2. Se il comando crictl ps non funziona o non restituisce nulla, controlla lo stato kubelet e containerd. Usa i comandi systemctl status SERVICE e journalctl -u SERVICE per esaminare i log.