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 Cluster Anthos su VMware (GKE On-Prem).

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 correttamente 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 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.

Ti consigliamo di inviare il file di log al team di assistenza quando ti serve aiuto.

Specifica di una posizione non predefinita 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 verrà simbolizzato nella directory locale.

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

Individuare i log dell'API Cluster nel cluster di amministrazione

Se una VM non si avvia dopo l'avvio del piano di controllo amministratore, puoi esaminare il problema esaminando i log dal 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 di vsphere-controller-manager. Inizia specificando 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 che 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 relativi a vSphere

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

Debug tramite i log del cluster di bootstrap

Durante l'installazione, i cluster Anthos su VMware creano un cluster di bootstrap temporaneo. Dopo l'installazione, i cluster Anthos su VMware eliminano il cluster di bootstrap, lasciandoti con il cluster di amministrazione e il cluster utente. In genere, non hai motivo di interagire con il cluster di bootstrap.

Se passi --cleanup-external-cliuster=false a gkectl create cluster, il cluster di bootstrap non viene eliminato e puoi usare 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

Rollback di un pool di nodi dopo un upgrade

Se esegui l'upgrade di un cluster utente e poi riscontri 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 si trova nella versione 1.14, i pool di nodi possono avere la versione 1.14 o 1.13.

Visualizza le versioni del pool di nodi disponibili

Supponi di aver aggiornato di recente i nodi worker e il piano di controllo del cluster utente dalla versione 1.13.1-gke.35 alla versione 1.14.0 e di aver riscontrato un problema con i nodi worker aggiornati. Decidi quindi di eseguire il rollback di uno o più pool di nodi alla versione che utilizzavi 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 attuale e quella precedente di ciascun 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

Rollback dei pool di nodi

Puoi eseguire il rollback di un pool di nodi alla volta oppure eseguire il rollback di più pool di nodi in un solo 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 i cluster per 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, il seguente output 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, ad esempio 1.14.1. Ora puoi eseguire l'upgrade di tutti i pool di nodi e del piano di controllo alla nuova versione della 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. Se non viene specificata alcuna versione per un pool di nodi, la versione predefinita 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 dei cluster Anthos su VMware.

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

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

Risultato 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 utilizzando il file kubeconfig interno

Dopo un'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 tuo cluster di amministrazione, tranne per il 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 F5 BIG-IP.

Ridimensionamento di un cluster utente non riuscito

Se il ridimensionamento di un cluster utente ha esito negativo:

Trova i nomi dei MachineDeployment e delle macchine:

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

Descrivi un deployment per visualizzare i relativi log:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machinedeployment MACHINE_DEPLOYMENT_NAME

Verifica la presenza di errori sulle macchine appena create:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machine MACHINE_NAME

Nessun indirizzo allocabile per il ridimensionamento del cluster

Questo problema si verifica se gli indirizzi IP disponibili non sono 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 questo problema, Assegna più indirizzi IP per il cluster. Quindi, elimina la macchina interessata:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete machine MACHINE_NAME

Cluster Anthos su VMware crea una nuova macchina e le 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 bilanciatore del carico utilizza un indirizzo IP specificato per una macchina.

Per risolvere questo problema, aggiorna il file di blocco IP del cluster in modo che gli indirizzi delle macchine non siano in conflitto con quelli 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 va a buon fine

Se tenti di creare o eseguire l'upgrade di un cluster di amministrazione e l'operazione non riesce, Cluster Anthos su VMware acquisisce 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 allo snapshot eseguito eseguendo il comando gkectl diagnose snapshot sul cluster di amministrazione, viene attivato automaticamente. Questo snapshot del cluster 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 tenti di eseguire l'upgrade di un cluster di amministrazione o di utenti e l'operazione non riesce, i cluster Anthos su VMware eseguono automaticamente il comando gkectl diagnose cluster sul cluster.

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

Il processo di upgrade si blocca

Cluster Anthos su VMware, dietro le quinte, utilizza il comando drain Kubernetes durante un upgrade. Questa procedura di drain può essere bloccata da un deployment con una sola replica e con un PodDisruptionBudget (PDB) creato per minAvailable: 1.

Da Cluster Anthos su VMware versione 1.13, puoi controllare gli errori tramite gli eventi del pod Kubernetes.

Trova i nomi delle macchine:

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

Controlla se si sono verificati errori utilizzando il comando kubectl describe machine:
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machine MACHINE_NAME
```

Ecco un esempio di output:

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 sullo 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 questo problema, salva il PDB e rimuovilo dal cluster prima di tentare l'upgrade. Potrai quindi aggiungere di nuovo il PDB al termine dell'upgrade.

Diagnostica lo stato della macchina virtuale

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