Questa pagina è stata tradotta dall'API Cloud Translation.

Diagnostica dei problemi relativi ai cluster

Lo strumento gkectl ha due comandi per la risoluzione dei problemi relativi ai cluster: gkectl diagnose cluster e gkectl diagnose snapshot. I comandi funzionano sia con i cluster di amministrazione sia con quelli utente. Questo documento mostra come utilizzare il comando gkectl diagnose per diagnosticare i problemi nei cluster.

Tieni presente la seguente limitazione relativa ai cluster avanzati:

Versione 1.31: i comandi gkectl diagnose non sono supportati nei cluster avanzati.
Versione 1.32 e successive: i comandi gkectl diagnose sono supportati sui cluster avanzati.

Per saperne di più su come utilizzare il comando gkectl diagnose snapshot per creare snapshot che possono aiutare l'assistenza clienti Google Cloud a diagnosticare i problemi, consulta Creare snapshot per diagnosticare i cluster.

`gkectl diagnose cluster`

Questo comando esegue controlli di integrità sul cluster e segnala gli errori. Il comando esegue controlli di integrità sui seguenti componenti:

vCenter
- Credenziale
- DRS
- Gruppi anti-affinità
- Rete
- Versione
- Data center
- Datastore
- ResourcePool
- Cartella
- Rete
Bilanciatore del carico (F5, Seesaw o manuale)
Cluster utente e node pool
Oggetti cluster
Stato di preparazione del server Konnectivity del cluster utente
Oggetti macchina e i nodi del cluster corrispondenti
Pod negli spazi dei nomi kube-system e gke-system
Piano di controllo
Volumi permanenti vSphere nel cluster
Segnali di contesa di vCPU (CPU virtuale) e memoria del cluster utente e amministratore
ESXi del cluster utente e di amministrazione allarmi preconfigurati per l'utilizzo della CPU e della memoria dell'host.
Ora del giorno (TOD)
Policy di rete dei nodi per un cluster con Dataplane V2 abilitato
Integrità complessiva dell'agente del nodo Dataplane V2

Diagnostica di un cluster di amministrazione

Per diagnosticare un cluster di amministrazione, specifica il percorso del cluster di amministrazione:

gkectl diagnose cluster --kubeconfig=ADMIN_CLUSTER_KUBECONFIG

Sostituisci ADMIN_CLUSTER_KUBECONFIG con il percorso del file kubeconfig del cluster di amministrazione.

Il seguente output di esempio viene restituito dal comando gkectl diagnose cluster:

Preparing for the diagnose tool...
Diagnosing the cluster......DONE

- Validation Category: Admin Cluster Connectivity
Checking VMs TOD (availability)...SUCCESS
Checking Konnectivity Server (readiness)...SUCCESS

- Validation Category: Admin Cluster F5 BIG-IP
Checking f5 (credentials, partition)...SUCCESS

- Validation Category: Admin Cluster VCenter
Checking Credentials...SUCCESS
Checking DRS enabled...SUCCESS
Checking Hosts for AntiAffinityGroups...SUCCESS
Checking Version...SUCCESS
Checking Datacenter...SUCCESS
Checking Datastore...SUCCESS
Checking Resource pool...SUCCESS
Checking Folder...SUCCESS
Checking Network...SUCCESS

- Validation Category: Admin Cluster
Checking cluster object...SUCCESS
Checking machine deployment...SUCCESS
Checking machineset...SUCCESS
Checking machine objects...SUCCESS
Checking kube-system pods...SUCCESS
Checking anthos-identity-service pods...SUCCESS
Checking storage...SUCCESS
Checking resource...SUCCESS
Checking virtual machine resource contention...SUCCESS
Checking host resource contention...SUCCESS
All validation results were SUCCESS.
Cluster is healthy!

Se si verifica un problema con un indirizzo IP virtuale (VIP) nel cluster di destinazione, utilizza il flag --config per fornire il file di configurazione del cluster di amministrazione e ottenere ulteriori informazioni per il debug.

gkectl diagnose cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config CLUSTER_CONFIG

Sostituisci CLUSTER_CONFIG con il percorso del file di configurazione del cluster di amministrazione o utente.

L'output di esempio seguente mostra che il comando gkectl diagnose cluster ora può connettersi correttamente al cluster e verificare la presenza di problemi:

Failed to access the api server via LB VIP "...": ...
Try to use the admin master IP instead of problematic VIP...
Reading config with version "[CONFIG_VERSION]"
Finding the admin master VM...
Fetching the VMs in the resource pool "[RESOURCE_POOL_NAME]"...
Found the "[ADMIN_MASTER_VM_NAME]" is the admin master VM.
Diagnosing admin|user cluster "[TARGET_CLUSTER_NAME]"...
...

Diagnostica di un cluster utente

Per diagnosticare un cluster utente, devi specificare il nome del cluster utente. Se devi ottenere il nome di un cluster utente, esegui questo comando:

kubectl get cluster --kubeconfig=USER_CLUSTER_KUBECONFIG

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

Specifica il nome del cluster utente insieme al file di configurazione nel seguente modo:

gkectl diagnose cluster --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
    --cluster-name=USER_CLUSTER_NAME

Sostituisci USER_CLUSTER_NAME con il nome del cluster utente.

Il seguente output di esempio viene restituito dal comando gkectl diagnose cluster:

Preparing for the diagnose tool...
Diagnosing the cluster......DONE

Diagnose result is saved successfully in <DIAGNOSE_REPORT_JSON_FILE>

- Validation Category: User Cluster Connectivity
Checking Node Network Policy...SUCCESS
Checking VMs TOD (availability)...SUCCESS
Checking Dataplane-V2...Success

- Validation Category: User Cluster F5 BIG-IP
Checking f5 (credentials, partition)...SUCCESS

- Validation Category: User Cluster VCenter
Checking Credentials...SUCCESS
Checking DRS enabled...SUCCESS
Checking Hosts for AntiAffinityGroups...SUCCESS
Checking VSphere CSI Driver...SUCCESS
Checking Version...SUCCESS
Checking Datacenter...SUCCESS
Checking Datastore...SUCCESS
Checking Resource pool...SUCCESS
Checking Folder...SUCCESS
Checking Network...SUCCESS

- Validation Category: User Cluster
Checking user cluster and node pools...SUCCESS
Checking cluster object...SUCCESS
Checking machine deployment...SUCCESS
Checking machineset...SUCCESS
Checking machine objects...SUCCESS
Checking control plane pods...SUCCESS
Checking kube-system pods...SUCCESS
Checking gke-system pods...SUCCESS
Checking gke-connect pods...SUCCESS
Checeking anthos-identity-service pods...SUCCESS
Checking storage...SUCCESS
Checking resource...SUCCESS
Checking virtual machine resource contention...SUCCESS
Checking host resource contention...SUCCESS
All validation results were SUCCESS.
Cluster is healthy!

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

L'output è simile al seguente:


- Validation Category: Cluster Healthiness
Checking cluster object...SUCCESS
Checking machine deployment...SUCCESS
Checking machineset...SUCCESS
Checking machine objects...SUCCESS
Checking machine VMs...FAILURE
    Reason: 1 machine VMs error(s).
    Unhealthy Resources:
    Machine [NODE_NAME]: The VM's UUID "420fbe5c-4c8b-705a-8a05-ec636406f60" does not match the machine object's providerID "420fbe5c-4c8b-705a-8a05-ec636406f60e".
    Debug Information:
    null
...
Exit with error:
Cluster is unhealthy!
Run gkectl diagnose cluster automatically in gkectl diagnose snapshot
Public page https://cloud.google.com/anthos/clusters/docs/on-prem/latest/diagnose#overview_diagnose_snapshot

Risoluzione dei problemi

La seguente tabella descrive alcune possibili soluzioni ai problemi relativi all'esecuzione del comando gkectl diagnose cluster:

Problema	Cause possibili	Risoluzione
Il server API Kubernetes non è raggiungibile, né per il cluster di amministrazione né per i cluster utente.	Controlla i grafici della latenza della memoria OOB (out-of-box) dell'integrità della macchina virtuale, che idealmente dovrebbe avere una latenza della memoria pari a zero. La contesa della memoria può anche aumentare la contesa della CPU e i grafici di preparazione della CPU potrebbero presentare un picco, poiché sarà coinvolto lo swapping.	Aumenta la memoria fisica. Per altre opzioni, consulta Suggerimenti per la risoluzione dei problemi di VMware.
La creazione del node pool scade.	Latenza di lettura/scrittura elevata di VMDK. Controlla l'integrità della VM OOB per la latenza di lettura e scrittura del disco virtuale. Secondo VMware, una latenza totale superiore a 20 ms indica un problema.	Consulta Soluzioni VMware per i problemi di prestazioni del disco.

`BundleUnexpectedDiff` errore

La risorsa API Kubernetes Cluster gestita da un bundle Google Distributed Cloud potrebbe essere modificata accidentalmente, causando l'errore dei componenti di sistema o l'errore di upgrade o aggiornamento del cluster.

In Google Distributed Cloud versione 1.13 e successive, il onprem-user-cluster-controller controlla periodicamente lo stato degli oggetti e segnala eventuali differenze impreviste rispetto allo stato desiderato tramite log ed eventi. Questi oggetti includono il control plane del cluster utente e componenti aggiuntivi come Servizi e DaemonSet.

L'output di esempio seguente mostra un evento di differenza imprevisto:

 Type     Reason                 Age    From                              Message
 ----     ------                 ----   ----                              -------
 Warning  BundleUnexpectedDiff   13m    onpremusercluster/ci-bundle-diff  Detected unexpected difference of user control plane objects: [ConfigMap/istio], please check onprem-user-cluster-controller logs for more details.

L'output di esempio seguente mostra i log generati da onprem-user-cluster-controller:

2022-08-06T02:54:42.701352295Z W0806 02:54:42.701252       1 update.go:206] Detected unexpected difference of user addon object(ConfigMap/istio), Diff:   map[string]string{
2022-08-06T02:54:42.701376406Z -    "mesh": (
2022-08-06T02:54:42.701381190Z -        """
2022-08-06T02:54:42.701385438Z -        defaultConfig:
2022-08-06T02:54:42.701389350Z -          discoveryAddress: istiod.gke-system.svc:15012
...
2022-08-06T02:54:42.701449954Z -        """
2022-08-06T02:54:42.701453099Z -    ),
2022-08-06T02:54:42.701456286Z -    "meshNetworks": "networks: {}",
2022-08-06T02:54:42.701459304Z +    "test-key":     "test-data",
2022-08-06T02:54:42.701462434Z   }

Gli eventi e i log non bloccheranno l'operazione del cluster. Gli oggetti che presentano differenze impreviste rispetto allo stato desiderato vengono sovrascritti nel successivo upgrade del cluster.

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:

Requisiti per l'apertura di una richiesta di assistenza.
Strumenti per aiutarti a risolvere i problemi, come log e metriche.
Componenti supportati, versioni e funzionalità di Google Distributed Cloud per VMware (solo software).