Risolvere i problemi di creazione o upgrade del cluster

Questa pagina mostra come esaminare i problemi relativi alla creazione e all'upgrade dei cluster in Google Distributed Cloud (solo software) per VMware.

Problemi di installazione

Le sezioni seguenti potrebbero aiutarti a risolvere i problemi relativi all'installazione di Google Distributed Cloud.

Utilizzare il cluster di bootstrap per eseguire il debug dei problemi

Durante l'installazione, Google Distributed Cloud crea un cluster di bootstrap temporaneo. Dopo un'installazione riuscita, Google Distributed Cloud 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 riscontri 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 utilizzarlo per eseguire il debug dei problemi di installazione.

Esamina i log del cluster di bootstrap

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

  2. Visualizza i log di 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.

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

  4. Per controllare i log kubelet e containerd, utilizza i seguenti comandi 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 l'operazione non va a buon fine, Google Distributed Cloud acquisisce uno snapshot esterno del cluster di bootstrap. Questo snapshot del cluster di bootstrap è simile a quello creato eseguendo il comando gkectl diagnose snapshot sul cluster di amministrazione, ma il processo viene attivato automaticamente. Lo snapshot del cluster di bootstrap contiene informazioni di debug importanti per la creazione e l'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 della creazione del cluster o dei problemi di 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 control plane di amministrazione

Se una VM non si avvia dopo l'avvio del control plane di amministrazione, puoi analizzare il problema esaminando i log del pod dei controller dell'API Cluster nel cluster di amministrazione:

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

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

  2. 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 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]

  3. Scegli un contenitore 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 macchina non riesce a registrarsi al cluster

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

Per risolvere il 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.

Il cluster Kind non viene eliminato

Quando crei un cluster di amministrazione, viene creato un cluster kind (chiamato anche cluster di bootstrap) nell'ambito della procedura. Al termine dell'operazione del cluster di amministrazione, il cluster kind viene eliminato automaticamente.

Se visualizzi il messaggio di errore Failed to delete the kind cluster, puoi eseguire i seguenti passaggi sulla workstation amministrativa per eliminare manualmente il cluster kind:

  1. Recupera l'ID contenitore kind:

    docker inspect --format="{{.Id}}" gkectl-control-plane

  2. Recupera l'ID processo containerd-shim:

    sudo ps awx | grep containerd-shim | grep CONTAINER_ID | awk '{print $1}'

  3. Termina il processo:

    sudo kill -9 PROCESS_ID

Problemi di upgrade del cluster

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

Esegui il 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 node pool 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 uguale o una versione secondaria precedente a quella del piano di controllo del cluster utente. Ad esempio, se il control plane è alla versione 1.14, i pool di nodi possono essere alla versione 1.14 o 1.13.

Visualizza le versioni pool di nodi disponibili

Supponiamo che di recente tu abbia eseguito l'upgrade dei nodi worker e del control plane del cluster utente dalla versione 1.13.1-gke.35 alla versione 1.14.0 e che tu abbia riscontrato un problema con i nodi worker di cui è stato eseguito l'upgrade. Pertanto, decidi di eseguire il rollback di uno o più node pool alla versione che stavi eseguendo in precedenza: 1.13.1-gke.35. Prima di poter iniziare 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 attuale 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 pool di nodi

Puoi eseguire il rollback della versione di un pool di nodi alla volta oppure puoi eseguire il rollback di più node pool in un unico passaggio.

Per eseguire il rollback di una versione del pool di nodi:

  1. Nel file di configurazione del cluster utente, in uno o più pool di nodi, imposta il valore di gkeOnPremVersion sulla versione precedente. Il seguente esempio 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
  ...

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

    gkectl update cluster --config USER_CLUSTER_CONFIG \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

  3. Verifica che il rollback sia andato a buon fine:

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

    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 patch

Puoi eseguire l'upgrade di tutti i node pool e del control plane a una nuova versione 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, completa i seguenti passaggi:

  1. Apporta le seguenti modifiche al file di configurazione del cluster utente:

    1. Imposta il valore di gkeOnPremVersion su una nuova versione patch. Questo esempio utilizza 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 è quella predefinita 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: ""

  2. Esegui gkectl prepare e gkectl upgrade cluster come descritto in Upgrade di Google Distributed Cloud.

  3. 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 utente e l'operazione non va a buon fine, Google Distributed Cloud esegue automaticamente il comando gkectl diagnose cluster sul cluster.

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

Il processo di upgrade si blocca

Dietro le quinte, Google Distributed Cloud utilizza il comando drain Kubernetes durante un upgrade. Questa procedura di 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 Google Distributed Cloud, puoi controllare gli errori tramite gli eventi dei pod Kubernetes.

  1. Trova i nomi delle macchine:

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

  2. Controlla 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.

  3. (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. Puoi aggiungere nuovamente il PDB al termine dell'upgrade.

Rimuovere 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 automaticamente durante l'upgrade, il che significa che queste modifiche non hanno effetto durante e dopo l'upgrade.

Quando esegui l'upgrade dei cluster utente alla versione 1.28 o successive, convalidiamo tutte le modifiche apportate al file di configurazione e restituiamo un errore per le modifiche non supportate, anziché ignorarle. Questa funzionalità è disponibile solo per i cluster di utenti. Quando esegui l'upgrade dei cluster di amministrazione, le modifiche alla maggior parte dei campi vengono ignorate e non avranno effetto dopo l'upgrade.

Ad esempio, se tenti di disattivare 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
    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 ignorare questo errore, puoi provare le seguenti soluzioni alternative:

  • Annulla la modifica tentata e riesegui l'upgrade. Ad esempio, nello scenario precedente, devi ripristinare le modifiche apportate alla configurazione AutoRepair e poi eseguire di nuovo gkectl upgrade.
  • In alternativa, puoi generare file di configurazione che corrispondono 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 e poi eseguire di nuovo gkectl upgrade.

Problema: immagine sistema operativo non trovata dopo gkectl prepare

Dopo aver eseguito il comando gkectl prepare e aver tentato di eseguire l'upgrade di un cluster utente con gkectl upgrade cluster, potresti riscontrare un errore simile al seguente:

[FAILURE] User OS images exist: OS images [gke-on-prem-ubuntu-VERSION] don't exist, please run `gkectl prepare` to upload OS images.

Questo errore può verificarsi quando il cluster di amministrazione e il cluster utente sono configurati per utilizzare cartelle vSphere diverse. Per impostazione predefinita, il comando gkectl prepare carica l'immagine del sistema operativo nella cartella del cluster di amministrazione. Per caricare l'immagine nella cartella del cluster utente, utilizza il flag --user-cluster-config come mostrato nel comando seguente:

  gkectl prepare --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-VERSION-full.tgz \
    --user-cluster-config USER_CLUSTER_CONFIG

Eseguire il debug dei problemi di F5 BIG-IP con il file kubeconfig interno

Dopo l'installazione, Google Distributed Cloud genera un file kubeconfig denominato internal-cluster-kubeconfig-debug nella home directory della workstation amministrativa. Questo file kubeconfig è identico al file kubeconfig del cluster di amministrazione, tranne per il fatto che punta direttamente al nodo del control plane del cluster di amministrazione, in cui è in esecuzione il server API Kubernetes. Puoi utilizzare il file internal-cluster-kubeconfig-debug per eseguire il debug dei problemi di F5 BIG-IP.

Eseguire il debug dei problemi relativi a 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 puoi raccogliere i log vSphere.

Ricrea il file kubeconfig del cluster utente mancante

Potresti voler ricreare un file kubeconfig del cluster utente nelle seguenti situazioni:

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

Per generare un nuovo file kubeconfig per il cluster utente, esegui questi passaggi:

  1. Definisci le variabili di ambiente:

    Inizia impostando le seguenti variabili di ambiente con i valori appropriati:

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

    Sostituisci quanto segue:

    • ADMIN_CLUSTER_KUBECONFIG: il percorso del file kubeconfig per il cluster di amministrazione.
    • USER_CONTROLPLANEVIP: il controlPlaneVIP del cluster utente. Può essere recuperato dal file manifest del cluster utente.

  2. Genera il file kubeconfig:

    Esegui questo comando per creare il nuovo file kubeconfig:

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

    Sostituisci :

    • USER_CLUSTER_KUBECONFIG: il nome del nuovo file kubeconfig per il cluster utente.

Passaggi successivi

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

Puoi anche consultare la sezione Richiedere assistenza per ulteriori informazioni sulle risorse di assistenza, tra cui: