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.
Utilizzare il cluster di bootstrap per risolvere i problemi
Durante l'installazione, Google Distributed Cloud crea un cluster di bootstrap temporaneo. Dopo un'installazione riuscita, Google Distributed Cloud elimina il cluster di bootstrap, lasciando il cluster di amministrazione e il cluster di utenti. In genere, non dovresti avere alcun motivo per interagire con il cluster di bootstrap. Tuttavia, se si verificano problemi durante l'installazione, puoi utilizzare i log del cluster di bootstrap per 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 recuperare i log direttamente dal cluster di bootstrap, esegui il seguente 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 controllare i log
kubeletecontainerd, utilizza 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.
Questa istantanea del cluster di bootstrap è simile a quella acquisita
eseguendo il gkectl diagnose snapshot
comando 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 si avvia dopo l'avvio del piano di controllo dell'amministratore
Se una VM non si avvia dopo l'avvio del piano di controllo dell'amministratore, puoi esaminare il problema controllando i log del pod dei controller API Cluster 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 da
vsphere-controller-manager. Inizia specificando il pod, ma nessun contenitore:kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \ logs POD_NAMEL'output ti dice che devi specificare un contenitore e ti fornisce i nomi 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
È stato allocato un numero sufficiente di indirizzi IP, ma la macchina non riesce a registrarsi nel 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 dei 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 dei pool di nodi disponibili
Supponiamo che di recente tu abbia eseguito l'upgrade del cluster utente nei nodi worker e nel piano di controllo dalla versione 1.13.1-gke.35 alla versione 1.14.0 e che tu abbia rilevato un problema con i nodi worker di cui è stato eseguito l'upgrade. Pertanto, decidi di eseguire il rollback di uno o più pool di nodi alla versione in esecuzione 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 versione precedente per ogni pool di nodi. 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 della versione di un pool di nodi alla volta o di più pool di nodi in un unico 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. L'esempio seguente illustra 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
Eseguire l'upgrade a una nuova versione del patch
Puoi eseguire l'upgrade di tutti i pool di nodi e del piano di controllo a una nuova versione con patch. Questa operazione potrebbe essere utile se hai eseguito il rollback a una versione precedente e vuoi 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 della patch. Questo esempio utilizza 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, la versione predefinita è quella specificata per il cluster.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 Eseguire l'upgrade di Google Distributed Cloud.Verifica la nuova versione del cluster e controlla le versioni disponibili per il 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 in caso di errore durante l'upgrade del cluster
Se provi ad eseguire l'upgrade di un cluster di amministrazione o utente e l'operazione non va a buon fine, Google Distributed Cloud esegue automaticamente il gkectl diagnose cluster
comando sul cluster.
Per saltare la diagnosi automatica, passa il flag --skip-diagnose-cluster a
gkectl upgrade.
Il processo di upgrade si blocca
Dietro le quinte, Google Distributed Cloud utilizza il comando drain
Kubernetes
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.
Dalla versione 1.13 di Google Distributed Cloud, puoi controllare gli errori tramite gli eventi dei pod 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 dello stato degli oggetti della 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 di tentare l'upgrade. Al termine dell'upgrade, puoi aggiungere nuovamente il PDB.
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 restituisce 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 tentata e poi esegui di nuovo l'upgrade. Ad esempio, nel
scenario precedente, le modifiche apportate allo
AutoRepairverranno annullate config ed esegui nuovamentegkectl upgrade. - In alternativa, puoi generare file di configurazione corrispondenti allo stato corrente del cluster eseguendo
gkectl get-config, aggiornare i campigkeOnPremVersionper il cluster e i pool di nodi nel file di configurazione, quindi eseguire nuovamentegkectl upgrade.
Risolvere i problemi di F5 BIG-IP con il file kubeconfig interno
Dopo un'installazione, Google Distributed Cloud genera un file kubeconfig
denominato internal-cluster-kubeconfig-debug nella home directory della tua workstation
dell'amministratore. Questo file kubeconfig è identico al file kubeconfig del tuo cluster di amministrazione, tranne per il fatto che punta direttamente al nodo del piano di controllo del cluster di amministrazione, in cui viene eseguito il server API Kubernetes. Puoi utilizzare il
internal-cluster-kubeconfig-debug file per eseguire il debug dei problemi di F5 BIG-IP.
Esegui il debug dei problemi con vSphere
Puoi utilizzare
govc per esaminare i problemi relativi a vSphere. Ad esempio, puoi confermare le autorizzazioni e
l'accesso per i tuoi account utente vCenter e raccogliere i log di 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 provi a creare un cluster utente e l'operazione di creazione non riesce, ma vuoi avere il file
kubeconfigdel cluster utente. - Se il file
kubeconfigdel cluster utente non è presente, ad esempio dopo l'eliminazione.
Per generare un nuovo file kubeconfig per il cluster utente, esegui i seguenti passaggi:
Definisci le variabili di ambiente:
Inizia impostando le seguenti variabili di ambiente con i valori appropriati:
USER_CONTROLPLANEVIP=USER_CONTROLPLANEVIP USER_CLUSTER_NAME=USER_CLUSTER_NAME ADMIN_CLUSTER_KUBECONFIG=PATH_TO_ADMIN_KUBECONFIG KUBECONFIG_SECRET_NAME=$(kubectl --kubeconfig $ADMIN_CLUSTER_KUBECONFIG get secrets -n $USER_CLUSTER_NAME | grep ^admin | cut -d' ' -f1 | head -n 1)Sostituisci quanto segue:
ADMIN_CLUSTER_KUBECONFIG: il percorso dikubeconfigper il cluster di amministrazione.USER_CONTROLPLANEVIP: ilcontrolPlaneVIPdel cluster dell'utente. Può essere recuperato dal file manifest del cluster utente.
Genera il file Kubeconfig:
Esegui questo comando per creare il nuovo file kubeconfig:
kubectl --kubeconfig $ADMIN_CLUSTER_KUBECONFIG get secrets $KUBECONFIG_SECRET_NAME \ -n $USER_CLUSTER_NAME -o jsonpath='{.data.admin\.conf}' | base64 -d | \ sed -r "s/ kube-apiserver.*local\./${USER_CONTROLPLANEVIP}/" \ > USER_CLUSTER_KUBECONFIGSostituisci:
USER_CLUSTER_KUBECONFIG: il nome del nuovokubeconfigfile per il cluster di utenti.
Passaggi successivi
- Se hai bisogno di ulteriore assistenza, contatta l'assistenza clienti Google Cloud.