Risolvi i problemi relativi alla creazione o all'upgrade del cluster

Questa pagina mostra come esaminare i problemi relativi alla creazione e all'upgrade dei cluster in GKE su VMware.

Se hai bisogno di ulteriore aiuto, contatta l'assistenza clienti Google Cloud.

Problemi di installazione

Le sezioni seguenti potrebbero aiutarti a risolvere i problemi di installazione di GKE su VMware.

Usa il cluster di bootstrap per eseguire il debug dei problemi

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 motivo di interagire con il cluster di bootstrap. Tuttavia, se si verificano problemi durante l'installazione, puoi utilizzare i log del cluster di bootstrap per eseguire il debug del problema.

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

Esamina i log del cluster di bootstrap

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

Sostituisci POD_NAME con il nome del pod che vuoi visualizzare.

Per ottenere i log direttamente dal cluster di bootstrap, esegui questo comando durante la creazione, l'aggiornamento e l'upgrade del cluster:
```
docker exec -it gkectl-control-plane bash
```
Questo 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

Esamina lo snapshot del cluster di bootstrap

Se tenti di creare o eseguire l'upgrade di un cluster di amministrazione e questa operazione non riesce, GKE su VMware crea uno snapshot esterno del cluster di bootstrap. Questo snapshot del cluster di bootstrap è simile a quello acquisito eseguendo il comando gkectl diagnose snapshot sul cluster di amministrazione, ma il processo si attiva automaticamente. Lo 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 clienti 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 del cluster o upgrade. 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

La VM non si avvia dopo l'avvio del piano di controllo dell'amministratore

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

Numero sufficiente di indirizzi IP allocati, ma la registrazione della macchina non riesce a essere registrata 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 blocchi 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 blocchi IP di Seesaw.

Problemi di upgrade del cluster

Le sezioni seguenti forniscono suggerimenti su come risolvere i problemi che potresti riscontrare durante un upgrade del cluster.

Rollback di un pool di nodi dopo un upgrade

Se esegui l'upgrade di un cluster utente e poi scopri un problema relativo ai 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 disponibili dei pool di nodi

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. Prima di poter avviare il rollback, devi verificare che la versione precedente sia disponibile per il rollback.

Per visualizzare le versioni disponibili, esegui questo comando:

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 della versione del pool di nodi

Puoi eseguire il rollback della versione di un pool di nodi un pool di nodi alla volta oppure su diversi pool di nodi in un unico passaggio.

Per eseguire il rollback di una versione di pool di nodi, completa i seguenti passaggi:

Nel file di configurazione del cluster utente, in uno o più pool di nodi, imposta il valore di gkeOnPremVersion sulla versione precedente. L'esempio seguente mostra come eseguire il rollback alla versione 1.13.1-gke.35:
```
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 sia stato eseguito correttamente:

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

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

Puoi eseguire l'upgrade di tutti i pool di nodi e del piano di controllo a una nuova versione di patch. Questo può essere utile se hai eseguito il rollback a una versione precedente e vuoi eseguire l'upgrade a una versione che include una correzione.

Per eseguire l'upgrade a una nuova versione, segui questi passaggi:

Apporta le seguenti modifiche al file di configurazione del cluster utente:
1. Imposta il valore di gkeOnPremVersion su una nuova versione della patch. In questo esempio viene utilizzato 1.14.1-gke.x.
2. 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 del pool di nodi corrisponde per impostazione predefinita alla versione specificata per il cluster.
  
  Queste modifiche sono simili al seguente 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 disponibili per il rollback:

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

L'output è simile al seguente:

 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
 ```

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 un utente e questa 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

Dietro le quinte, GKE su VMware utilizza il comando drain di 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.

Da GKE su VMware versione 1.13, puoi verificare gli errori tramite gli eventi dei pod Kubernetes.

Trova i nomi delle macchine:

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

Verifica la presenza di errori utilizzando il comando kubectl describe machine:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machine MACHINE_NAME

L'output è simile al seguente:

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

(Facoltativo) Per un'analisi più dettagliata dello stato degli oggetti macchina, esegui gkectl diagnose cluster.

L'output è simile al seguente:

...
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. Potrai quindi aggiungere nuovamente il PDB al termine dell'upgrade.

Rimuovi le modifiche non supportate per sbloccare l'upgrade

Quando esegui l'upgrade dei cluster alla versione 1.16 o precedenti, le modifiche alla maggior parte dei campi vengono ignorate in silenzio durante l'upgrade, il che significa che queste modifiche non vengono applicate durante e dopo l'upgrade.

Quando esegui l'upgrade dei cluster utente alla versione 1.28 o successive, convalidiamo tutte le modifiche apportate nel file di configurazione e restituisca un errore per le modifiche non supportate, anziché semplicemente ignorarle. Questa funzionalità è disponibile solo per i cluster utente. Durante l'upgrade dei cluster di amministrazione, le modifiche alla maggior parte dei campi vengono ignorate in modo invisibile e non verranno applicate dopo l'upgrade.

Ad esempio, se tenti di disabilitare la riparazione automatica dei nodi durante l'upgrade di un cluster utente alla versione 1.28, l'upgrade non riesce e viene visualizzato il seguente messaggio di errore:

failed to generate desired create config: failed to generate desired OnPremUserCluster from seed config: failed to apply validating webhook to OnPremUserCluster: the following changes on immutable fields are forbidden during upgrade: (diff: -before, +after):
   v1alpha1.OnPremUserClusterSpec{
    ... // 20 identical fields
    UsageMetering:         nil,
    CloudAuditLogging:     &{ProjectID: "syllogi-partner-testing", ClusterLocation: "us-central1", ServiceAccountKey: &{KubernetesSecret: &{Name: "user-cluster-creds", KeyName: "cloud-audit-logging-service-account-key"}}},
-   AutoRepair:            &v1alpha1.AutoRepairConfig{Enabled: true},
+   AutoRepair:            &v1alpha1.AutoRepairConfig{},
    CARotation:            &{Generated: &{CAVersion: 1}},
    KSASigningKeyRotation: &{Generated: &{KSASigningKeyVersion: 1}},
    ... // 8 identical fields
  }

Se devi bypassare questo errore, puoi procedere in uno dei seguenti modi:

Ripristina la modifica tentata, quindi esegui nuovamente l'upgrade. Ad esempio, nello scenario precedente, dovevi annullare le modifiche apportate alla configurazione di AutoRepair e poi eseguire nuovamente gkectl upgrade.
In alternativa, puoi generare file di configurazione che corrispondano allo stato attuale del cluster eseguendo gkectl get-config, aggiornare i campi gkeOnPremVersion per il cluster e i pool di nodi nel file di configurazione, quindi eseguire nuovamente gkectl upgrade.

Esegui il debug dei problemi BIG-IP di F5 con 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, ad eccezione del fatto che rimanda direttamente al nodo del piano di controllo del cluster di amministrazione, su cui è in esecuzione il server API Kubernetes. Puoi utilizzare il file internal-cluster-kubeconfig-debug per eseguire il debug dei problemi BIG-IP di F5.

Esegui il debug dei problemi con vSphere

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

Ricrea il file kubeconfig del cluster utente mancante

Ti consigliamo di ricreare un file kubeconfig del cluster utente nelle seguenti situazioni:

Se provi a creare un cluster utente e l'operazione di creazione non riesce e vuoi avere il file kubeconfig del relativo cluster utente.
Se il file del cluster utente kubeconfig non è presente, ad esempio dopo l'eliminazione.

Esegui questo comando per ricreare il file kubeconfig del cluster utente:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secrets -n admin \
  -o jsonpath='{.data.admin\.conf}' | base64 -d  > USER_CLUSTER_KUBECONFIG

Sostituisci quanto segue:

USER_CLUSTER_KUBECONFIG: il nome del nuovo file kubeconfig per il tuo cluster utente.
ADMIN_CLUSTER_KUBECONFIG: il percorso del file kubeconfig per il cluster di amministrazione.

Passaggi successivi

Se hai bisogno di ulteriore aiuto, contatta l'assistenza clienti Google Cloud.