Questa pagina mostra come esaminare i problemi relativi alla creazione e all'upgrade del cluster in Google Distributed Cloud (solo software) per VMware.
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.
Usa il cluster di bootstrap per eseguire il debug dei problemi
Durante l'installazione, Google Distributed Cloud crea un bootstrap temporaneo in un cluster Kubernetes. Al termine dell'installazione, Google Distributed Cloud elimina il cluster di bootstrap, lasciando a te il cluster di amministrazione e il cluster utente. In genere, non dovresti avere alcun motivo per interagire con il cluster di bootstrap. Tuttavia, se riscontri problemi durante l'installazione, puoi utilizzare dei log del cluster di bootstrap per aiutarti a eseguire il debug del problema.
Se passi --cleanup-external-cluster=false a gkectl create cluster:
il cluster di bootstrap non viene eliminato e puoi utilizzare il file
per eseguire il debug dei problemi di installazione.
Esamina i log del cluster di bootstrap
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-systemVisualizza i log per un pod:
kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl -n kube-system get logs POD_NAMESostituisci
POD_NAMEcon il nome del pod di cui che vuoi visualizzare.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 bashQuesto comando apre un terminale all'interno del container
gkectl-control-planein esecuzione nel cluster di bootstrap.Per esaminare i log
kubeletecontainerd, usa 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 riesce,
Google Distributed Cloud acquisisce uno snapshot esterno del cluster di bootstrap.
Questo snapshot del cluster di bootstrap è simile allo snapshot acquisito
eseguendo gkectl diagnose snapshot
sul cluster di amministrazione,
ma il processo si attiva automaticamente. Lo snapshot del cluster di bootstrap
contiene importanti informazioni di debug per la creazione del cluster di amministrazione
processo di upgrade. Puoi fornire questo snapshot
all'assistenza clienti Google Cloud, se necessario.
Lo snapshot esterno include i log dei pod
onprem-admin-cluster-controller che puoi visualizzare per eseguire il debug della creazione del cluster
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 viene avviata dopo l'avvio del piano di controllo dell'amministratore
Se una VM non viene avviata dopo l'avvio del piano di controllo amministratore, puoi: Esamina il problema esaminando i log dei controller API Cluster Pod nel cluster di amministrazione:
Trova il nome del pod dei controller API Cluster:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \ get pods | grep clusterapi-controllersVisualizza i log di
vsphere-controller-manager. Per iniziare, specifica il pod, ma nessun container:kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \ logs POD_NAMEL'output indica che è necessario specificare un container e dei container nel pod. Ad esempio:
... a container name must be specified ..., choose one of: [clusterapi-controller-manager vsphere-controller-manager rbac-proxy]
Scegli un container e visualizzane i 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 con il cluster
Questo problema può verificarsi in caso di conflitto di indirizzi IP. Ad esempio, un indirizzo IP specificato per una macchina viene usato per un bilanciatore del carico.
Per risolvere il problema, aggiorna file dei blocchi IP del cluster in modo che la macchina non siano in conflitto con gli indirizzi specificati nel file di configurazione del cluster o il tuo File di blocchi IP di Seesaw
Problemi di upgrade del cluster
Le seguenti sezioni forniscono suggerimenti su come risolvere i problemi che potresti durante l'upgrade del cluster.
Esegui il rollback di un pool di nodi dopo un upgrade
Se esegui l'upgrade di un cluster utente e poi scopri un problema con i nodi del cluster, puoi eseguire il rollback dei pool di nodi 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 la stessa o una versione secondaria precedente alla del piano di controllo del cluster utente. Ad esempio, se il piano di controllo alla versione 1.14, i pool di nodi possono essere alla versione 1.14 o 1.13.
Visualizza le versioni disponibili del pool di nodi
Immagina di aver eseguito l'upgrade del cluster utente di recente nodi worker e piano di controllo dalla versione 1.13.1-gke.35 alla versione 1.14.0 e scopri un problema con i nodi worker aggiornati. Decidi quindi di eseguire il rollback uno o più pool di nodi alla versione che stavi eseguendo in precedenza: 1.13.1-gke.35. Prima di poter iniziare il rollback, devi verificare che precedente è 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 corrente e la precedente per ciascun nodo piscina. 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 del pool di nodi
Puoi eseguire il rollback del pool di nodi della versione di un pool di nodi alla volta oppure eseguire il rollback di diversi pool di nodi in un solo passaggio.
Per eseguire il rollback di una versione del pool di nodi, completa i seguenti passaggi:
Nel file di configurazione del cluster utente, in uno o più pool di nodi, imposta valore
gkeOnPremVersionalla versione precedente. Nell'esempio che segue 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 ...Aggiorna il cluster per eseguire il rollback dei pool di nodi:
gkectl update cluster --config USER_CLUSTER_CONFIG \ --kubeconfig ADMIN_CLUSTER_KUBECONFIGVerifica che il rollback sia stato eseguito correttamente:
gkectl version --cluster-name USER_CLUSTER_NAME \ --kubeconfig ADMIN_CLUSTER_KUBECONFIGL'output seguente mostra che è stato eseguito il rollback di
pool-1a 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 della patch
Puoi eseguire l'upgrade di tutti i pool di nodi e del piano di controllo a una nuova patch completamente gestita. Questa operazione potrebbe essere utile se hai eseguito il rollback a una versione precedente e vuoi di eseguire l'upgrade a una versione che include una correzione.
Per eseguire l'upgrade a una nuova versione, completa i seguenti passaggi:
Apporta le seguenti modifiche al file di configurazione del cluster utente:
Imposta il valore di
gkeOnPremVersionsu una nuova versione di patch. Questo esempio usa 1.14.1-gke.x.Per ogni pool di nodi, rimuovi il campo
gkeOnPremVersiono impostalo su la stringa vuota. Se non viene specificata alcuna versione per un pool di nodi, per il pool di nodi viene impostato sul valore predefinito in un cluster Kubernetes.Queste modifiche sono simili all'esempio seguente:
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: ""
Esegui
gkectl prepareegkectl upgrade clustercome descritto in Upgrade di Google Distributed Cloud.Verifica la nuova versione del cluster e controlla le versioni disponibili per rollback:
gkectl version --cluster-name USER_CLUSTER_NAME \ --kubeconfig ADMIN_CLUSTER_KUBECONFIGL'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 di un cluster utente e l'operazione non riesce,
Google Distributed Cloud esegue automaticamente gkectl diagnose cluster
sul cluster.
Per saltare la diagnostica automatica, passa il flag --skip-diagnose-cluster a
gkectl upgrade.
Il processo di upgrade si blocca
Dietro le quinte, Google Distributed Cloud utilizza Kubernetes drain
comando
durante un upgrade. Questa procedura drain può essere bloccata da un deployment con
viene creata una sola replica con un PodDisruptionBudget (PDB) creato con
minAvailable: 1.
A partire da Google Distributed Cloud versione 1.13, puoi controllare gli errori tramite e gli eventi di pod di Kubernetes.
Trova i nomi delle macchine:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get machines --all-namespacesVerifica la presenza di errori utilizzando il comando
kubectl describe machine:kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machine MACHINE_NAMEL'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.(Facoltativo) Per un'analisi più dettagliata sullo 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 durante il tentativo di upgrade. Potrai quindi aggiungere nuovamente il PDB al termine dell'upgrade completato.
Rimuovi le modifiche non supportate per sbloccare l'upgrade
Quando esegui l'upgrade dei cluster alla versione 1.16 o alle versioni precedenti, le modifiche alla maggior parte dei campi vengono ignorati automaticamente durante l'upgrade, il che significa che queste modifiche durante e dopo l'upgrade.
Quando esegui l'upgrade dei cluster utente alla versione 1.28 o successive, convalidiamo tutte le modifiche apportate nel file di configurazione e restituiscono un errore per le modifiche non supportate, anziché ignorarli. Questa funzionalità è limitata solo ai cluster utente. Durante l'upgrade dei cluster di amministrazione, le modifiche apportate alla maggior parte dei campi vengono ignorate automaticamente e non avrà effetto dopo l'upgrade.
Ad esempio, se tenti di disabilitare la riparazione automatica dei nodi quando eseguendo l'upgrade di un cluster utente alla versione 1.28, l'upgrade non riesce e viene generato il seguente errore messaggio:
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
UsageMetering: nil,
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
}
Per aggirare questo errore, puoi adottare le seguenti soluzioni:
- Ripristina la modifica che hai tentato di apportare ed esegui nuovamente l'upgrade. Ad esempio, nel
scenario precedente, le modifiche apportate allo
AutoRepairverranno annullate ed esegui nuovamentegkectl upgrade. - In alternativa, puoi generare file di configurazione corrispondenti
stato del cluster eseguendo
gkectl get-config, aggiorna i campigkeOnPremVersionper il cluster e i pool di nodi in il file di configurazione ed esegui nuovamentegkectl upgrade.
Esegui il debug dei problemi di BIG-IP di F5 con il file kubeconfig interno
Al termine di un'installazione, Google Distributed Cloud genera un file kubeconfig
denominato internal-cluster-kubeconfig-debug nella home directory dell'amministratore
la workstation. Questo file kubeconfig è identico a quello del cluster di amministrazione
kubeconfig, con l'eccezione che punta direttamente al controllo del cluster di amministrazione
su cui viene eseguito il server API Kubernetes. Puoi utilizzare lo
internal-cluster-kubeconfig-debug per eseguire il debug dei problemi relativi a BIG-IP di F5.
Esegui il debug dei problemi con vSphere
Puoi utilizzare
Da govc a
e analizza i problemi relativi a vSphere. Ad esempio, puoi confermare le autorizzazioni
l'accesso per i tuoi account utente vCenter e potrai raccogliere i log vSphere.
Ricrea il file kubeconfig del cluster utente mancante
Potrebbe essere utile ricreare il file kubeconfig del cluster utente nel seguente modo
situazioni seguenti:
- Se tenti di creare un cluster utente e l'operazione di creazione non riesce e
vuoi avere il file
kubeconfigdel cluster utente. - Se il file del cluster utente
kubeconfigmanca, ad esempio dopo essere stato eliminato.
Esegui questo comando per ricreare il file kubeconfig del cluster utente:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secrets -n admin \
-o jsonpath='{.data.admin\.conf}' | base64 -d > USER_CLUSTER_KUBECONFIG
Sostituisci quanto segue:
USER_CLUSTER_KUBECONFIG: il nome del nuovokubeconfigper il cluster utente.ADMIN_CLUSTER_KUBECONFIG: il percorso dikubeconfigper il cluster di amministrazione.
Passaggi successivi
- Se hai bisogno di ulteriore assistenza, contatta Assistenza clienti Google Cloud.