Risolvere i problemi di creazione o upgrade del cluster

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

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

Problemi di installazione

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

Messaggi di errore temporanei

La procedura di installazione di Google Distributed Cloud è un loop di riconciliazione continuo. Di conseguenza, potresti visualizzare messaggi di errore temporanei nel log durante l'installazione.

Se l'installazione viene completata correttamente, questi errori possono essere tranquillamente ignorati. Di seguito è riportato un elenco di messaggi di log di errori transitori tipici:

  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, visualizzi i seguenti messaggi di errore da 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.

Utilizzare il cluster di bootstrap per risolvere i problemi

Quando Google Distributed Cloud crea cluster autogestiti (di amministrazione, ibridi o autonomi), esegue il deployment di un cluster (tipo) Kubernetes in Docker per ospitare temporaneamente i controller Kubernetes necessari per creare i cluster. Questo cluster transitorio è chiamato cluster di bootstrap. I cluster utente vengono creati ed eseguiti l'upgrade dal cluster ibrido o di amministrazione che li gestisce senza l'utilizzo di un cluster di bootstrap.

Se al momento del tentativo di installazione nel tuo deployment esiste già un cluster di tipi, Google Distributed Cloud elimina il cluster di tipi esistente. L'eliminazione avviene solo dopo l'installazione o l'upgrade. Per preservare il cluster di tipi esistente anche dopo il successo, utilizza il --keep-bootstrap-cluster flag di bmctl.

Google Distributed Cloud crea un file di configurazione per il cluster di bootstrap in WORKSPACE_DIR/.kindkubeconfig. Puoi connetterti al cluster 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. Il registro predefinito è 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 le credenziali account di servizio Google Cloud per l'accesso al registry. Le credenziali vengono ottenute dal gcrKeyPath campo nel file di configurazione del cluster.

  • bmctl-workspace/config.toml: contiene la configurazione di containerd nel cluster kind.

Esaminare i log del cluster di bootstrap

Per eseguire il debug del cluster di bootstrap, puoi procedere nel seguente modo:

  • 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 nelle seguenti directory:

  • 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 recuperare direttamente i log dal cluster di bootstrap, puoi eseguire il seguente 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 viene eseguito nel cluster di bootstrap.

Per controllare i log kubelet e containerd, utilizza 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 controllare lo stato dei cluster e dei nodi.

Le seguenti indicazioni possono aiutarti a determinare se l'upgrade sta procedendo normalmente o se si è verificato 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 cluster.
  • CLUSTER_NAMESPACE: lo spazio dei nomi del tuo cluster.
  • ADMIN_KUBECONFIG: il file kubeconfig di amministrazione.
    • Per impostazione predefinita, i cluster di amministrazione, ibridi e autonomi utilizzano un upgrade in situ. 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 file kubeconfig del cluster di bootstrap, .kindkubeconfig. Questo file si trova nella directory dello spazio di lavoro.

Esamina la sezione Status dell'output, che mostra un'aggregazione dello stato dell'upgrade del cluster. Se il cluster segnala un errore, utilizza le seguenti 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 la procedura di upgrade, controlla le colonne VERSION e AGE nella risposta del comando. VERSION è la versione di Kubernetes per il cluster. Per visualizzare la versione di Kubernetes per una determinata versione di Google Distributed Cloud, consulta Versionamento.

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

systemctl status kubelet

Puoi anche esaminare i log di kubelet:

journalctl -u kubelet

Esamina l'output dello stato di kubelet e i log per individuare i messaggi che indicano il motivo del problema del nodo.

Controlla su quale nodo è in corso l'upgrade

Per controllare quale nodo del cluster è in fase di upgrade, utilizza il comando kubectl get baremetalmachines:

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

Sostituisci i seguenti valori:

  • CLUSTER_NAMESPACE: lo spazio dei nomi del tuo cluster.
  • ADMIN_KUBECONFIG: il file kubeconfig di amministrazione.
    • Se viene utilizzato un cluster di bootstrap per un upgrade amministrativo, ibrido o autonomo, specifica il file kubeconfig del cluster di bootstrap (bmctl-workspace/.kindkubeconfig).

L'esempio di output seguente mostra che il nodo di cui viene eseguito l'upgrade ha un valore 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 la procedura di upgrade, i pod vengono rimossi dai nodi e la pianificazione viene disattivata fino al completamento dell'upgrade del nodo. Per vedere quali nodi sono in svuotamento, utilizza 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 registrano SchedulingDisabled. Questo stato indica che i nodi vengono svuotati.

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: lo spazio dei nomi del tuo cluster.
  • ADMIN_KUBECONFIG: il file kubeconfig di amministrazione.
    • Se viene utilizzato un cluster di bootstrap per un upgrade amministrativo, ibrido o autonomo, specifica il file kubeconfig del cluster di bootstrap (bmctl-workspace/.kindkubeconfig).

Lo stato del nodo sottoposto a svuotamento viene visualizzato nella colonna MAINTENANCE.

Controllare il motivo per cui lo stato di un nodo è in svuotamento da molto tempo

Utilizza uno dei metodi descritti nella sezione precedente per identificare il nodo in cui si verifica il problema utilizzando 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 nodo sottoposto a svuotamento. L'output restituisce un elenco di pod bloccati o con svuotamento lento. L'upgrade procede, anche con i pod bloccati, quando il processo di svuotamento su un nodo richiede più di 20 minuti.

A partire dalla release 1.29, il processo di svuotamento dei nodi utilizza l'API Eviction, che rispetta i PodDisruptionBudgets (PDB).

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

  • Pod gestiti da più PDB

  • Configurazioni PDB statiche come la seguente:

    • 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 un Deployment, ReplicaSet o StatefulSet. I PDB vengono associati ai pod in base al selector solo nella loro configurazione. Un buon approccio per diagnosticare se una configurazione PDB statica sta causando un problema è verificare se pdb.Status.ExpectPods <= pdb.Status.DesiredHealthy e se una delle configurazioni statiche menzionate lo consente.

Anche le violazioni di runtime, ad esempio il valore DisruptionsAllowed calcolato per una risorsa PDB che è 0, possono bloccare lo svuotamento dei nodi. Se hai configurato oggetti PodDisruptionBudget che non possono consentire interruzioni aggiuntive, l'upgrade dei nodi alla versione del control plane potrebbe non riuscire dopo ripetuti tentativi. Per evitare questo errore, ti consigliamo di eseguire l'upgrade di Deployment o HorizontalPodAutoscaler per consentire lo svuotamento del nodo rispettando al contempo la configurazione PodDisruptionBudget.

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

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

Controlla perché i pod non sono in stato corretto

Gli upgrade possono non riuscire se un pod contiene indirizzi IP del piano di controllo upgrade-first-node o upgrade-node. Questo comportamento si verifica in genere perché i pod statici non sono in stato di salute.

  1. Controlla i pod statici con il comando crictl ps -a e cerca eventuali pod Kubernetes o etcd in crash. Se ci sono pod con errori, controlla i log dei pod per capire perché si verificano arresti anomali.

    Ecco alcune possibilità per il comportamento di crashloop:

    • Le autorizzazioni o il proprietario dei file montati su 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 lo stato di kubelet e containerd. Utilizza i comandi systemctl status SERVICE e journalctl -u SERVICE per esaminare i log.

Passaggi successivi

  • <>