Version 1.14. This version is no longer supported. For more information see the version support policy.

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 in GKE su VMware.

Comportamento di logging 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 in modo simbolico al file logs/gkectl-$(date).log nella directory locale in cui esegui gkectl.
Per gkeadm, il file di log predefinito è logs/gkeadm-$(date).log nella directory locale in cui esegui gkeadm.
Il livello di dettaglio predefinito -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.

Specifica di posizioni non 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 sarà collegato alla directory locale.

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

Individuazione dei log dell'API Cluster nel cluster di amministrazione

Se una VM non si avvia dopo l'avvio del piano di controllo dell'amministratore, puoi analizzare il problema ispezionando i log del pod dei controller API del cluster nel cluster di amministrazione.

Trova il nome del pod dei controller API del cluster:

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

Visualizza i log da vsphere-controller-manager. Inizia specificando il pod, ma nessun container:

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

L'output ti indica che devi specificare un container e ti fornisce 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 con 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 di vSphere.

Debug mediante i log del cluster di bootstrap

Durante l'installazione, GKE su VMware crea un cluster di bootstrap temporaneo. Dopo l'installazione, GKE su VMware elimina il cluster di bootstrap, lasciandoti il cluster di amministrazione e il cluster utente. In genere, non dovresti avere motivi 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 per un pod:

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

Per ottenere i log direttamente dal cluster di bootstrap, puoi eseguire il comando seguente durante la creazione, l'aggiornamento e l'upgrade del cluster:
```
docker exec -it gkectl-control-plane bash
```
Il comando apre un terminale all'interno del container gkectl-control-plane in esecuzione nel cluster di bootstrap.

Per esaminare i log kubelet e containerd, utilizza i comandi seguenti e cerca errori o avvisi nell'output:
```
systemctl status -l kubelet
journalctl --utc -u kubelet
systemctl status -l containerd
journalctl --utc -u containerd
```

Rollback di un pool di nodi dopo un upgrade

Se esegui l'upgrade di un cluster utente e poi rilevi un problema con i nodi del cluster, puoi eseguire il rollback dei pool di nodi selezionati alla versione precedente.

Il rollback dei pool di nodi selezionati è supportato per i pool di nodi Ubuntu e COS, ma non per i pool di nodi Windows.

La versione di un pool di nodi può essere la stessa o una versione secondaria precedente alla versione del piano di controllo del cluster utente. Ad esempio, se il piano di controllo è alla versione 1.14, i pool di nodi possono essere alla versione 1.14 o 1.13.

Visualizza le versioni dei pool di nodi disponibili

Supponi di aver recentemente eseguito l'upgrade dei nodi worker e del piano di controllo del cluster utente dalla versione 1.13.1-gke.35 alla versione 1.14.0 e di scoprire un problema con i nodi worker aggiornati. Decidi quindi di eseguire il rollback di uno o più pool di nodi alla versione che stavi eseguendo in precedenza: 1.13.1-gke.35.

Verifica che la versione precedente sia disponibile per il rollback:

gkectl version --cluster-name USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG

L'output mostra la versione corrente e quella precedente per ogni pool di nodi. Ad esempio:

user cluster version: 1.14.0-gke.x

node pools:
- pool-1:
  - version: 1.14.0-gke.x
  - previous version: 1.13.1-gke.35
- pool-2:
  - version: 1.14.0-gke.x
  - previous version: 1.13.1-gke.35

available node pool versions:
- 1.13.1-gke.35
- 1.14.0-gke.x

Esegui il rollback dei pool di nodi

Puoi eseguire il rollback di un pool di nodi alla volta oppure di diversi pool di nodi in un singolo passaggio.

Nel file di configurazione del cluster utente, in uno o più pool di nodi, imposta il valore di gkeOnPremVersion sulla versione precedente: 1.13.1-gke.35 in questo esempio:

nodePools:
- name: pool-1
  cpus: 4
  memoryMB: 8192
  replicas: 3
  gkeOnPremVersion: 1.13.1-gke.35
  ...

Aggiorna il cluster per eseguire il rollback dei pool di nodi:

gkectl update cluster --config USER_CLUSTER_CONFIG --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Verifica che il rollback:

gkectl version --cluster-name USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Ad esempio, l'output seguente mostra che è stato eseguito il rollback di pool-1 alla versione 1.13.1-gke.35.

user cluster version: 1.14.0-gke.x

node pools:
- pool-1:
  - version: 1.13.1-gke.35
  - previous version: 1.14.0-gke.x
- pool-2:
  - version: 1.14.0-gke.x
  - previous version: 1.13.1-gke.35

available node pool versions:
- 1.13.1-gke.35
- 1.14.0-gke.x

Esegui l'upgrade a una nuova versione della patch

Supponiamo che il problema sia stato risolto in una nuova versione della patch, diciamo 1.14.1. Ora puoi eseguire l'upgrade di tutti i pool di nodi e del piano di controllo alla nuova versione patch.

Nel file di configurazione del cluster utente:

Imposta il valore di gkeOnPremVersion sulla nuova versione della patch: 1.14.1-gke.x in questo esempio.
Per ogni pool di nodi, rimuovi il campo gkeOnPremVersion o impostalo sulla stringa vuota. Quando non viene specificata alcuna versione per un pool di nodi, per impostazione predefinita la versione del pool di nodi corrisponde a quella specificata per il cluster.

Esempio:

gkeOnPremVersion: 1.14.1-gke.x

nodePools:
- name: pool-1
  cpus: 4
  memoryMB: 8192
  replicas: 3
  gkeOnPremVersion: ""
- name: pool-2
  cpus: 8
  memoryMB: 8192
  replicas: 2
  gkeOnPremVersion: ""

Esegui gkectl prepare e gkectl upgrade cluster come descritto in Upgrade di GKE su VMware.

Verifica la nuova versione del cluster e visualizza le versioni ora disponibili per il rollback:

gkectl version --cluster-name USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Output di esempio:

user cluster version: 1.14.1-gke.y

node pools:
- pool-1:
  - version: 1.14.1-gke.y
  - previous version: 1.13.1-gke.35
- pool-2:
  - version: 1.14.1-gke.y
  - previous version: 1.13.1-gke.35

available node pool versions:
- 1.13.1-gke.35
- 1.14.0-gke.x
- 1.14.1-gke.y

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

Dopo un'installazione, GKE su VMware genera un file kubeconfig denominato internal-cluster-kubeconfig-debug nella home directory della tua workstation di amministrazione. Questo file kubeconfig è identico al file kubeconfig del tuo cluster di amministrazione, ma rimanda direttamente al nodo del piano di controllo del cluster di amministrazione, dove è in esecuzione il server API Kubernetes. Puoi usare il file internal-cluster-kubeconfig-debug per eseguire il debug dei problemi BIG-IP di F5.

Il ridimensionamento di un cluster utente non va a buon fine

Se il ridimensionamento di un cluster utente non va a buon fine:

Trova i nomi dei deployment di macchine e delle macchine:

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

Descrivi un MachineDeployment per visualizzarne i 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

Nessun indirizzo può essere allocato 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

GKE su VMware crea una nuova macchina a cui assegna uno dei nuovi indirizzi IP disponibili.

Numero sufficiente di indirizzi IP allocati, ma la registrazione della macchina non riesce 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 dei blocchi IP del cluster in modo che gli indirizzi della macchina non siano in conflitto con gli indirizzi specificati nel file di configurazione del cluster o nel file dei blocchi IP di Seesaw.

Lo snapshot viene creato automaticamente quando la creazione o l'upgrade del cluster di amministrazione non va a buon fine

Se provi a creare o eseguire l'upgrade di un cluster di amministrazione e l'operazione non riesce, GKE su VMware crea uno snapshot esterno del cluster di bootstrap, che è un cluster temporaneo utilizzato per creare o eseguire l'upgrade del cluster di amministrazione. Sebbene questo snapshot del cluster di bootstrap sia simile a quello acquisito eseguendo il comando gkectl diagnose snapshot nel cluster di amministrazione, viene attivato automaticamente. Questo snapshot del cluster di bootstrap contiene importanti informazioni di debug per il processo di creazione e upgrade del cluster di amministrazione. Se necessario, puoi fornire questo snapshot all'assistenza Google Cloud.

Lo snapshot esterno include i log dei pod di onprem-admin-cluster-controller, che puoi visualizzare per eseguire il debug dei problemi di creazione o upgrade del cluster. I log vengono archiviati in un file separato, ad esempio:

kubectl_logs_onprem-admin-cluster-controller-6767f6597-nws8g_--container_onprem-admin-cluster-controller_--kubeconfig_.home.ubuntu..kube.kind-config-gkectl_--namespace_kube-system

I controlli di integrità vengono eseguiti automaticamente quando l'upgrade del cluster non va a buon fine

Se provi a eseguire l'upgrade di un cluster di amministrazione o di un cluster utente e l'operazione non riesce, GKE su VMware esegue automaticamente il comando gkectl diagnose cluster sul cluster.

Per saltare la diagnostica automatica, passa il flag --skip-diagnose-cluster a gkectl upgrade.

Il processo di upgrade si blocca

GKE su VMware, in background, utilizza il comando drain Kubernetes durante un upgrade. Questa procedura drain può essere bloccata da un deployment con una sola replica per cui è stato creato un PodDisruptionBudget (PDB) con minAvailable: 1.

A partire dalla versione 1.13 di GKE su VMware, puoi verificare gli errori tramite gli eventi pod Kubernetes.

Trova i nomi delle macchine:

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

Verifica l'eventuale presenza di errori utilizzando il comando kubectl describe machine:
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machine MACHINE_NAME
```

Ecco un output di esempio:

Events:
  Type     Reason              Age    From                Message
  ----     ------              ----   ----                -------
  Warning  PodEvictionTooLong  3m49s  machine-controller  Waiting too long(12m10.284294321s) for pod(default/test-deployment-669b85c4cc-z8pz7) eviction.

Per un'analisi più dettagliata dello stato degli oggetti macchina, esegui gkectl diagnose cluster:

...
Checking machineset...SUCCESS
Checking machine objects...FAILURE
    Reason: 1 machine objects error(s).
    Unhealthy Resources:
    Pod test-deployment-669b85c4cc-7zjpq: Pod cannot be evicted successfully. There is 1 related PDB.
...
Checking all poddisruptionbudgets...FAILURE
    Reason: 1 pod disruption budget error(s).
    Unhealthy Resources:
    PodDisruptionBudget test-pdb: default/test-pdb might be configured incorrectly, the total replicas(3) should be larger than spec.MinAvailable(3).
...
Some validation results were FAILURE or UNKNOWN. Check report above.

Per risolvere il problema, salva il PDB e rimuovilo dal cluster prima di tentare l'upgrade. Puoi quindi aggiungere di nuovo il PDB al termine dell'upgrade.

Diagnosi dello stato della macchina virtuale

Se si verifica un problema con la creazione di macchine virtuali, esegui gkectl diagnose cluster per ottenere una diagnosi dello stato della macchina virtuale.