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

Questa pagina mostra come risolvere i problemi relativi all'installazione o all'upgrade Google Distributed Cloud.

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

Problemi di installazione

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

Messaggi di errore temporanei

Il processo di installazione di Google Distributed Cloud è un processo continuo un loop di riconciliazione. Di conseguenza, potresti visualizzare messaggi di errore temporanei nella durante l'installazione.

Se l'installazione viene completata correttamente, questi errori possono da ignorare tranquillamente. Di seguito è riportato un elenco dei tipici messaggi di log degli errori temporanei:

  Internal error occurred: failed calling webhook "webhook.cert-manager.io": Post
  https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s:
  dial tcp IP_ADDRESS:443: connect: connection refused

  Internal error occurred: failed calling webhook "vcluster.kb.io": Post
  https://webhook-service.kube-system.svc:443/validate-baremetal-cluster-gke-io-v1-cluster?timeout=30s:
  dial tcp IP_ADDRESS:443: connect: connection refused

  Failed to register cluster with GKE Hub; gcloud output: error running command
  'gcloud container fleet memberships register CLUSTER_NAME  --verbosity=error --quiet':
  error: exit status 1, stderr: 'ERROR: (gcloud.container.hub.memberships.register)
  Failed to check if the user is a cluster-admin: Unable to connect to the server: EOF

  Get
  https://127.0.0.1:34483/apis/infrastructure.baremetal.cluster.gke.io/v1/namespaces/cluster-
  cluster1/baremetalmachines: dial tcp 127.0.0.1:34483: connect: connection refused"

  Create Kind Cluster "msg"="apply run failed" "error"="unable to recognize \"/tmp/kout088683152\": no matches for kind \"NetworkLogging\" in version \"networking.gke.io/v1alpha1\""
  Create Kind Cluster "msg"="apply run failed" "error"="unable to recognize \"/tmp/kout869681888\": no matches for kind \"Provider\" in version \"clusterctl.cluster.x-k8s.io/v1alpha3\""

Se la chiave dell'account di servizio Google Cloud è scaduta, vedrai quanto segue Messaggi di errore di bmctl:

Error validating cluster config: 3 errors occurred:
        * GKEConnect check failed: Get https://gkehub.googleapis.com/v1beta1/projects/project/locations/global/memberships/admin: oauth2: cannot fetch token: 400 Bad Request
Response: {"error":"invalid_grant","error_description":"Invalid JWT Signature."}
        * ClusterOperations check failed: Post https://cloudresourcemanager.googleapis.com/v1/projects/project:testIamPermissions?alt=json&prettyPrint=false: oauth2: cannot fetch token: 400 Bad Request
Response: {"error":"invalid_grant","error_description":"Invalid JWT Signature."}
        * GCR pull permission for bucket: artifacts.anthos-baremetal-release.appspot.com failed: Get https://storage.googleapis.com/storage/v1/b/artifacts.anthos-baremetal-release.appspot.com/iam/testPermissions?alt=json&permissions=storage.objects.get&permissions=storage.objects.list&prettyPrint=false: oauth2: cannot fetch token: 400 Bad Request
Response: {"error":"invalid_grant","error_description":"Invalid JWT Signature."}

Devi generare una nuova chiave dell'account di servizio.

Usa il cluster di bootstrap per eseguire il debug dei problemi

Quando Google Distributed Cloud crea ambienti autogestiti (per amministratori, ibridi o autonomi) esegue il deployment Kubernetes in Docker (kind) per temporaneamente ospitare i controller Kubernetes necessari per creare i cluster. Questo transitorio è chiamato cluster di bootstrap. I cluster utente vengono creati e aggiornati di amministrazione o ibrido di gestione senza l'utilizzo di un cluster di bootstrap.

Se esiste già un cluster di tipo nel deployment quando tenti di installarlo, Google Distributed Cloud elimina il cluster di tipo esistente. Solo eliminazione una volta completato l'installazione o l'upgrade. Per conservare il cluster di tipo esistente anche dopo l'esito positivo, utilizza il metodo --keep-bootstrap-cluster flag di bmctl.

Google Distributed Cloud crea un file di configurazione per il cluster di bootstrap sotto WORKSPACE_DIR/.kindkubeconfig. Puoi collegarti al di bootstrap solo durante la creazione e l'upgrade del cluster.

Il cluster di bootstrap deve accedere a un repository Docker per eseguire il pull delle immagini. La il registry utilizza per impostazione predefinita Container Registry, a meno che non utilizzi un registro privato. Durante la creazione del cluster,bmctl crea i seguenti file:

  • bmctl-workspace/config.json: contiene l'account di servizio Google Cloud e credenziali per l'accesso al registro. Le credenziali si ottengono Campo gcrKeyPath nel file di configurazione del cluster.

  • bmctl-workspace/config.toml: contiene la configurazione containerd in di tipo cluster.

Esamina i log del cluster di bootstrap

Per eseguire il debug del cluster di bootstrap puoi seguire questi passaggi:

  • Connettiti al cluster di bootstrap durante la creazione e l'upgrade del cluster.
  • Recupera i log del cluster di bootstrap.

Puoi trovare i log nella macchina che utilizzi per eseguire bmctl nel seguente modo cartelle:

  • bmctl-workspace/CLUSTER_NAME/log/create-cluster-TIMESTAMP/bootstrap-cluster/
  • bmctl-workspace/CLUSTER_NAME/log/upgrade-cluster-TIMESTAMP/bootstrap-cluster/

Sostituisci CLUSTER_NAME e TIMESTAMP con il nome del cluster e l'ora del sistema corrispondente.

Per ottenere i log direttamente dal cluster di bootstrap, puoi eseguire questo comando: durante la creazione e l'upgrade del cluster:

docker exec -it bmctl-control-plane bash

Il comando apre un terminale all'interno del container del piano di controllo bmctl che vengono eseguite nel cluster di bootstrap.

Per esaminare i log kubelet e containerd, usa i seguenti comandi e cerca errori o avvisi nell'output:

journalctl -u kubelet
journalctl -u containerd

Problemi di upgrade del cluster

Quando esegui l'upgrade dei cluster Google Distributed Cloud, puoi monitorare l'avanzamento e e controllare lo stato di cluster e nodi.

Le indicazioni seguenti possono aiutarti a determinare se l'upgrade continua normalmente o se c'è un problema.

Monitorare l'avanzamento dell'upgrade

Utilizza il comando kubectl describe cluster per visualizzare lo stato di un cluster durante il processo di upgrade:

kubectl describe cluster CLUSTER_NAME \
    --namespace CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG

Sostituisci i seguenti valori:

  • CLUSTER_NAME: il nome del tuo in un cluster Kubernetes.
  • CLUSTER_NAMESPACE: il valore del tuo cluster.
  • ADMIN_KUBECONFIG: l'amministratore kubeconfig.
    • Per impostazione predefinita, i cluster di amministrazione, ibridi e autonomi utilizzano un upgrade in loco. Se utilizzi il flag --use-bootstrap=true con il comando bmctl upgrade, l'operazione di upgrade utilizza un cluster di bootstrap. Per monitorare l'avanzamento dell'upgrade Quando viene utilizzato un cluster di bootstrap, specifica il percorso del cluster di bootstrap file kubeconfig, .kindkubeconfig. Questo file si trova nell'area di lavoro .

Osserva la sezione Status dell'output, che mostra un'aggregazione del e lo stato di upgrade del cluster. Se il cluster segnala un errore, utilizza quanto segue sezioni per risolvere il problema.

Controlla se i nodi sono pronti

Utilizza il comando kubectl get nodes per visualizzare lo stato dei nodi in un cluster durante il processo di upgrade:

kubectl get nodes --kubeconfig KUBECONFIG

Per verificare se un nodo ha completato correttamente il processo di upgrade, osserva la VERSION e AGE nella risposta al comando. VERSION è il la versione di Kubernetes per il cluster. Per vedere la versione di Kubernetes Per la versione di Google Distributed Cloud, vedi Controllo delle versioni.

Se il nodo mostra NOT READY, prova a connetterlo e controlla il kubelet stato:

systemctl status kubelet

Puoi anche esaminare i log kubelet:

journalctl -u kubelet

Rivedi l'output dello stato del kubelet e i log dei messaggi che indicano il motivo. il nodo presenta un problema.

Controlla quale nodo è in fase di upgrade

Per verificare quale nodo nel cluster è in fase di upgrade, utilizza Comando kubectl get baremetalmachines:

kubectl get baremetalmachines --namespace CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG

Sostituisci i seguenti valori:

  • CLUSTER_NAMESPACE: il valore del tuo cluster.
  • ADMIN_KUBECONFIG: l'amministratore kubeconfig.
    • Se viene utilizzato un cluster di bootstrap per un upgrade amministrativo, ibrido o autonomo, specificare il file kubeconfig del cluster di bootstrap (bmctl-workspace/.kindkubeconfig).

L'output di esempio seguente mostra che il nodo di cui viene eseguito l'upgrade ha un ABM VERSION diverso da DESIRED ABM VERSION:

NAME         CLUSTER    READY   INSTANCEID               MACHINE      ABM VERSION   DESIRED ABM VERSION
10.200.0.2   cluster1   true    baremetal://10.200.0.2   10.200.0.2   1.13.0        1.14.0
10.200.0.3   cluster1   true    baremetal://10.200.0.3   10.200.0.3   1.13.0        1.13.0

Controlla quali nodi sono in fase di svuotamento

Durante il processo di upgrade, i nodi vengono svuotati dai pod e la pianificazione e disabilitato fino al completamento dell'upgrade del nodo. Per vedere quali nodi sono per lo svuotamento, usa il comando kubectl get nodes:

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG | grep "SchedulingDisabled"

Sostituisci USER_CLUSTER_KUBECONFIG con il percorso del file kubeconfig del cluster utente.

La colonna STATUS viene filtrata utilizzando grep per mostrare solo i nodi che generano report SchedulingDisabled. Questo stato indica che i nodi sono in fase di svuotamento.

Puoi anche controllare lo stato del nodo dal cluster di amministrazione:

kubectl get baremetalmachines -n CLUSTER_NAMESPACE \
  --kubeconfig ADMIN_KUBECONFIG

Sostituisci i seguenti valori:

  • CLUSTER_NAMESPACE: il valore del tuo cluster.
  • ADMIN_KUBECONFIG: l'amministratore kubeconfig.
    • Se viene utilizzato un cluster di bootstrap per un upgrade amministrativo, ibrido o autonomo, specificare il file kubeconfig del cluster di bootstrap (bmctl-workspace/.kindkubeconfig).

Il nodo che viene svuotato mostra lo stato nella colonna MAINTENANCE.

Controlla perché un nodo è in stato di svuotamento per molto tempo

Utilizza uno dei metodi della sezione precedente per identificare il nodo che recupera svuotato usando il comando kubectl get nodes. Utilizza il comando kubectl get pods e filtra in base a questo nome del nodo per visualizzare ulteriori dettagli:

kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=NODE_NAME

Sostituisci NODE_NAME con il nome del lo svuotamento del nodo. L'output restituisce un elenco di pod bloccati o lenti a drenare. L'upgrade continua, anche con i pod bloccati, quando il processo di svuotamento un nodo impiega più di 20 minuti.

A partire dalla release 1.29, lo svuotamento dei nodi utilizza la classe di archiviazione che rispetta PodDisruptionBudgets (PDB).

Le seguenti impostazioni PDB possono causare problemi di svuotamento dei nodi:

  • Pod gestiti da più PDB

  • Configurazioni statiche PDB come le seguenti:

    • maxUnavailable == 0
    • minUnavailable >= repliche totali

    Il numero totale di repliche è difficile da determinare dalla risorsa PDB, perché è definito in una risorsa di livello superiore, ad esempio Deployment, ReplicaSet o StatefulSet. I PDB corrispondono ai pod in base selettore solo nella loro configurazione. Un buon approccio per diagnosticare se un PDB statico che la tua configurazione stia causando un problema è verificare se pdb.Status.ExpectPods <= pdb.Status.DesiredHealthy per la prima volta e in fase di visualizzazione che una delle configurazioni statiche menzionate consenta questo passaggio.

Violazioni del runtime, ad esempio il valore DisruptionsAllowed calcolato per un PDB che è 0, può bloccare anche lo svuotamento dei nodi. Se disponi PodDisruptionBudget oggetti configurati che non consentono ulteriori interruzioni, gli upgrade dei nodi potrebbero non eseguire l'upgrade alla versione del piano di controllo dopo ripetuti tentativi. Per evitare errore, ti consigliamo di fare lo scale up di Deployment HorizontalPodAutoscaler per consentire lo svuotamento del nodo rispettando comunque il Configurazione di PodDisruptionBudget.

Per visualizzare tutti gli oggetti PodDisruptionBudget che non consentono interruzioni, usa il seguente comando:

kubectl get poddisruptionbudget --all-namespaces \
    -o jsonpath='{range .items[?(@.status.disruptionsAllowed==0)]}{.metadata.name}/{.metadata.namespace}{"\n"}{end}'

Verifica perché i pod sono in stato non integro

Gli upgrade possono non riuscire se un pod contiene upgrade-first-node o upgrade-node gli indirizzi IP del piano di controllo. Questo comportamento è in genere dovuto al fatto che i pod statici non sono sani.

  1. Controlla i pod statici con il comando crictl ps -a e cerca eventuali che ha causato l'arresto anomalo di Kubernetes o etcd pod. Se esistono pod con errori, rivedi il dei pod per capire perché si arrestano in modo anomalo.

    Ecco alcune possibilità per il comportamento di CrashLoop:

    • Le autorizzazioni o il proprietario dei file montati nei pod statici non sono corretti.
    • La connettività all'indirizzo IP virtuale non funziona.
    • Problemi con etcd.

  2. Se il comando crictl ps non funziona o non restituisce nulla, controlla la Stato kubelet e containerd. Utilizza i comandi systemctl status SERVICE e journalctl -u SERVICE per esaminare i log.

Passaggi successivi