Risoluzione dei problemi relativi alla creazione e all'upgrade dei cluster

Questa pagina mostra come esaminare i problemi relativi alla creazione, all'upgrade e al ridimensionamento dei cluster nei cluster Anthos su VMware (GKE on-prem).

Comportamento di registrazione predefinito per `gkectl` e `gkeadm`

Per gkectl e gkeadm è sufficiente utilizzare le impostazioni di logging predefinite:

Per gkectl, il file di log predefinito è /home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log e il file è collegato automaticamente al file logs/gkectl-$(date).log nella directory locale in cui viene eseguito gkectl.
Per gkeadm, il file di log predefinito è logs/gkeadm-$(date).log nella directory locale in cui esegui gkeadm.
Il livello di dettaglio predefinito di -v5 copre tutte le voci di log necessarie al team di assistenza.

Il file di log include il comando eseguito e il messaggio di errore.

Quando hai bisogno di aiuto, ti consigliamo di inviare il file di log al team di assistenza.

Specificare posizioni diverse da quelle predefinite per i file di log

Per specificare una posizione non predefinita per il file di log gkectl, utilizza il flag --log_file. Il file di log specificato non viene collegato direttamente alla directory locale.

Per specificare una posizione non predefinita per il file di log gkeadm, utilizza il flag --log_file.

Localizzazione dei log dell'API Cluster nel cluster di amministrazione

Se l'avvio di una VM non riesce dopo l'avvio del piano di controllo dell'amministratore, puoi esaminare il problema esaminando i log dal pod del controller dell'API Cluster nel cluster di amministrazione.

Trova il nome del pod dei controller dell'API Cluster:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \
    get pods | grep clusterapi-controllers

Visualizza i log di vsphere-controller-manager. Per iniziare, specifica il pod, ma nessun container:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \
    logs POD_NAME

L'output indica che devi specificare un container e i nomi dei container nel pod. Ad esempio:

... a container name must be specified ...,
choose one of: [clusterapi-controller-manager vsphere-controller-manager rbac-proxy]

Scegli un container e visualizza i relativi log:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \
    logs POD_NAME --container CONTAINER_NAME

Utilizzo di `govc` per risolvere i problemi relativi a vSphere

Puoi utilizzare govc per esaminare i problemi relativi a vSphere. Ad esempio, puoi confermare le autorizzazioni e l'accesso per i tuoi account utente vCenter e puoi raccogliere i log vSphere.

Debug utilizzando i log del cluster di bootstrap

Durante l'installazione, i cluster Anthos su VMware creano un cluster di bootstrap temporaneo. Una volta completata l'installazione, i cluster Anthos su VMware eliminano il cluster di bootstrap, lasciando il cluster di amministrazione e il cluster utente. In genere, non dovrebbe esserci alcun motivo per interagire con il cluster di bootstrap.

Se passi --cleanup-external-cluster=false a gkectl create cluster, il cluster di bootstrap non viene eliminato e puoi utilizzare i log del cluster di bootstrap per eseguire il debug dei problemi di installazione.

Trova i nomi dei pod in esecuzione nello spazio dei nomi kube-system:

kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl get pods -n kube-system

Visualizza i log di un pod:

kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl -n kube-system get logs POD_NAME

Debug dei problemi BIG-IP di F5 utilizzando il file kubeconfig interno

Dopo l'installazione, Cluster Anthos su VMware genera un file kubeconfig denominato internal-cluster-kubeconfig-debug nella home directory della workstation di amministrazione. Questo file kubeconfig è identico al file kubeconfig del cluster di amministrazione, ad eccezione del fatto che rimanda direttamente al nodo del piano di controllo del cluster di amministrazione, dove viene eseguito il server API Kubernetes. Puoi utilizzare il file internal-cluster-kubeconfig-debug per eseguire il debug dei problemi relativi a BIG-IP di F5.

Ridimensionamento di un cluster utente non riuscito

Se un ridimensionamento di un cluster utente non riesce:

Trova i nomi dei MachineDeployment e dei Machines:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get machinedeployments --all-namespaces
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get machines --all-namespaces

Descrivi un MachineDeployment per visualizzare i relativi log:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machinedeployment MACHINE_DEPLOYMENT_NAME

Verifica la presenza di errori sui computer appena creati:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machine MACHINE_NAME

Non è possibile assegnare indirizzi per il ridimensionamento del cluster

Questo problema si verifica se non sono disponibili indirizzi IP sufficienti per ridimensionare un cluster utente.

kubectl describe machine mostra il seguente errore:

Events:
Type     Reason  Age                From                    Message
----     ------  ----               ----                    -------
Warning  Failed  9s (x13 over 56s)  machineipam-controller  ipam: no addresses can be allocated

Per risolvere il problema, alloca più indirizzi IP per il cluster. Quindi, elimina il computer interessato:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete machine MACHINE_NAME

I cluster Anthos su VMware creano una nuova macchina e gli assegna uno degli indirizzi IP appena disponibili.

Numero sufficiente di indirizzi IP allocati, ma la macchina non riesce a registrarsi con il cluster

Questo problema può verificarsi in caso di conflitto di indirizzi IP. Ad esempio, un indirizzo IP specificato per una macchina viene utilizzato per un bilanciatore del carico.

Per risolvere questo problema, aggiorna il file di blocco IP del cluster in modo che gli indirizzi delle macchine non siano in conflitto con gli indirizzi specificati nel file di configurazione del cluster o nel file di blocco IP di Seesaw.

Lo snapshot viene creato automaticamente quando la creazione o l'upgrade del cluster di amministrazione non riesce

Se provi a creare o eseguire l'upgrade di un cluster di amministrazione e l'operazione non riesce, Cluster Anthos su VMware crea uno snapshot esterno del cluster di bootstrap, ovvero un cluster temporaneo utilizzato per creare o eseguire l'upgrade del cluster di amministrazione. Anche se questo snapshot del cluster di bootstrap è simile allo snapshot eseguito eseguendo il comando gkectl diagnose snapshot sul cluster di amministrazione, viene attivato automaticamente. Questo snapshot del cluster di bootstrap contiene informazioni di debug importanti per il processo di creazione e upgrade del cluster di amministrazione. Se necessario, puoi fornire questo snapshot all'assistenza Google Cloud.

Il processo di upgrade si blocca

I cluster Anthos su VMware, dietro le quinte, utilizzano il comando drain di Kubernetes durante un upgrade. Questa procedura di drain può essere bloccata da un deployment con una sola replica creata mediante un PodDisruptionBudget (PDB) con minAvailable: 1.

In tal caso, salva il PDB e rimuovilo dal cluster prima di tentare l'upgrade. Potrai quindi aggiungere nuovamente il PDB al termine dell'upgrade.

Ricrea il file kubeconfig del cluster utente mancante

Potresti voler ricreare un file kubeconfig del cluster utente in un paio di situazioni:

Se tenti di creare un cluster utente e l'operazione di creazione non riesce, vuoi che il file kubeconfig del cluster utente sia configurato.
Se il file kubeconfig del cluster utente risulta mancante, ad esempio dopo essere stato eliminato.

Esegui questi comandi per ricreare il file kubeconfig del cluster utente:

KUBECONFIG_SECRET_NAME=$(kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secrets -n USER_CLUSTER_NAME | grep admin-kubeconfig | cut -d' ' -f1)

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secrets -n USER_CLUSTER_NAME $KUBECONFIG_SECRET_NAME \
  -o jsonpath='{.data.kubeconfig\.conf}' | base64 -d | sed -r "s/kube-apiserver.*local\./USER_CLUSTER_VIP/" > new_user_kubeconfig

Sostituisci quanto segue:

USER_CLUSTER_VIP: il valore VIP principale dell'utente.
USER_CLUSTER_NAME: il nome del cluster utente.
ADMIN_CLUSTER_KUBECONFIG: il percorso del file kubeconfig per il cluster di amministrazione.