Lo strumento gkectl include 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
che con i cluster utente. Questo documento illustra come utilizzare
gkectl diagnose per diagnosticare i problemi nei cluster.
Per ulteriori informazioni su come utilizzare il comando gkectl diagnose snapshot per
creare snapshot che consentano all'assistenza clienti Google Cloud di diagnosticare i problemi,
Crea snapshot per diagnosticare i cluster.
gkectl diagnose cluster
Questo comando esegue controlli di integrità sul cluster e segnala gli errori. La esegue controlli di integrità sui componenti seguenti:
- vCenter
- Credenziale
- DRS
- Gruppi anti-affinità
- Rete
- Versione
- Data center
- Datastore
- ResourcePool
- Cartella
- Rete
- Bilanciatore del carico (F5, Seesaw o manuale)
- Cluster utente e pool di nodi
- Oggetti cluster
- Idoneità del server Konnectivity del cluster utente
- Oggetti macchina e nodi cluster corrispondenti
- Pod negli spazi dei nomi
kube-systemegke-system - Piano di controllo
- Volumi permanenti vSphere nel cluster
- Indicatori di conflitto di memoria e vCPU del cluster utente e di amministrazione (CPU virtuale)
- Cluster di amministrazione e utente ESXi allarmi Utilizzo CPU host e Utilizzo memoria preconfigurati.
- Ora del giorno (TOD)
- Criterio di rete dei nodi per un cluster con Dataplane V2 abilitato
- Integrità complessiva dell'agente Dataplane V2
Diagnosticare un cluster di amministrazione
Per eseguire la diagnostica di 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 di
il file kubeconfig del cluster di amministrazione.
Il seguente output di esempio viene restituito dall'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 a
per fornire altre informazioni di debug.
gkectl diagnose cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config CLUSTER_CONFIG
Sostituisci CLUSTER_CONFIG con il percorso dell'amministratore
di configurazione del cluster utente o del cluster.
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]"...
...
Esegui la diagnostica di un cluster utente
Per eseguire la diagnosi di un cluster utente, devi specificare il nome del cluster utente. Se hai bisogno per ottenere il nome di un cluster utente, esegui questo comando:
kubectl get cluster --kubeconfig=USER_CLUSTER_KUBECONFIG
Sostituisci USER_CLUSTER_KUBECONFIG con il percorso di
il file kubeconfig del cluster utente.
Specifica il nome del cluster utente insieme al file di configurazione come segue:
gkectl diagnose cluster --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
--cluster-name=USER_CLUSTER_NAME
Sostituisci USER_CLUSTER_NAME con il nome dell'utente
in un cluster Kubernetes.
Il seguente output di esempio viene restituito dall'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!
Esegui la diagnostica dello stato della macchina virtuale
Se si verifica un problema con la creazione di macchine virtuali, 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
Nella tabella che segue vengono indicate alcune possibili soluzioni dei problemi di esecuzione
il comando gkectl diagnose cluster:
| Problema | Cause possibili | Risoluzione |
|---|---|---|
| Il server API Kubernetes non è raggiungibile per il cluster di amministrazione o per i cluster utente. | Controlla i grafici di latenza della memoria OOB (out-of-box) dell'integrità delle macchine virtuali, che idealmente dovrebbero avere una latenza della memoria intorno allo zero. Il conflitto di memoria può anche aumentare il conflitto di CPU e i grafici di idoneità della CPU potrebbero avere un picco in quanto sarà coinvolto lo scambio. | Aumenta la memoria fisica. Per altre opzioni, consulta i suggerimenti per la risoluzione dei problemi di VMware. |
| Timeout della creazione del pool di nodi. | Latenza elevata di lettura/scrittura VMDK. Controlla l'OOB di integrità della VM 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 Cluster Kubernetes gestita da un bundle Google Distributed Cloud potrebbero essere stati modificati accidentalmente, causando così il malfunzionamento dei componenti di sistema. di upgrade o aggiornamento del cluster.
In Google Distributed Cloud 1.13 e versioni successive, la classe
onprem-user-cluster-controller verifica periodicamente lo stato degli oggetti e
segnala eventuali differenze impreviste rispetto allo stato desiderato tramite i log
eventi. Questi oggetti includono il piano di controllo del cluster utente e componenti aggiuntivi come
Services 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
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 le operazioni del cluster. Oggetti con le differenze impreviste rispetto allo stato desiderato vengono sovrascritte nel dell'upgrade del cluster.