Questa pagina mostra come esaminare i problemi relativi alla creazione e all'upgrade di cluster in Google Distributed Cloud.
Se hai bisogno di ulteriore aiuto, contatta l'assistenza clienti Google Cloud.Problemi di installazione
Le sezioni seguenti potrebbero aiutarti a risolvere i problemi di installazione di Google Distributed Cloud.
Usa il cluster di bootstrap per eseguire il debug dei problemi
Durante l'installazione, GKE on VMware crea un cluster di bootstrap temporaneo. Dopo un'installazione corretta, GKE on VMware 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 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 cluster di bootstrap 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 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, 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.
Questo snapshot del cluster di bootstrap è simile allo snapshot acquisito eseguendo il comando gkectl diagnose snapshot nel cluster di amministrazione, ma il processo si attiva automaticamente. Lo snapshot del cluster di bootstrap contiene importanti informazioni di debug per il processo di creazione e upgrade del cluster di amministrazione. Se necessario, puoi fornire questo snapshot all'assistenza clienti Google Cloud.
Lo snapshot esterno include i log dei pod di onprem-admin-cluster-controller, che puoi visualizzare per eseguire il debug dei problemi di creazione o upgrade del cluster. 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 si avvia dopo l'avvio del piano di controllo dell'amministratore, puoi esaminare il problema ispezionando 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 di
vsphere-controller-manager. Inizia specificando il pod, ma nessun container:kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \ logs POD_NAMEL'output indica che devi specificare un container e 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
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 utilizzato per un bilanciatore del carico.
Per risolvere il problema, aggiorna il file dei blocchi IP del cluster in modo che gli indirizzi delle macchine non siano in conflitto con gli indirizzi specificati nel file di configurazione del cluster o nel file dei blocchi IP di Seesaw
Problemi di upgrade del cluster
Le sezioni seguenti forniscono suggerimenti su come risolvere i problemi che potresti riscontrare durante un upgrade del cluster.
Esegui il rollback di un pool di nodi dopo un upgrade
Se esegui l'upgrade di un cluster utente e poi rilevi 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 versione del piano di controllo del cluster utente. Ad esempio, se la versione del piano di controllo è 1.14, i pool di nodi possono essere alla versione 1.14 o 1.13.
Visualizza le versioni disponibili del pool di nodi
Supponi di aver eseguito l'upgrade dei nodi worker e del piano di controllo del cluster utente di recente dalla versione 1.13.1-gke.35 alla versione 1.14.0 e di scoprire un problema con i nodi worker di cui è stato eseguito l'upgrade. Decidi quindi di eseguire il rollback di uno o più pool di nodi alla versione che stavi utilizzando in precedenza: 1.13.1-gke.35. Prima di poter iniziare il rollback, devi verificare che la versione precedente sia 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 attuale e quella 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 di un pool di nodi della versione di un pool di nodi alla volta oppure 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 il valore
gkeOnPremVersionsulla versione precedente. L'esempio seguente 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-1alla 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 versione delle 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 di patch. In questo esempio viene utilizzato 1.14.1-gke.x.Per ogni pool di nodi, rimuovi il campo
gkeOnPremVersiono impostalo sulla stringa vuota. Se non viene specificata alcuna versione per un pool di nodi, la versione predefinita del pool di nodi sarà 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 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 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 il comando 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
In background, Google Distributed Cloud utilizza il comando Kubernetes drain durante un upgrade. La procedura drain può essere bloccata da un deployment
con 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 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 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 di tentare l'upgrade. Potrai quindi aggiungere nuovamente il PDB al termine dell'upgrade.
Rimuovi le modifiche non supportate per sbloccare l'upgrade
Quando esegui l'upgrade dei cluster alla versione 1.16 o versioni precedenti, le modifiche alla maggior parte dei campi vengono ignorate silenziosamente durante l'upgrade, il che significa che queste modifiche non vengono applicate durante e dopo l'upgrade.
Quando esegui l'upgrade dei cluster utente alla versione 1.28 o successive, convalidiamo tutte le modifiche apportate al file di configurazione e restituiamo un errore per le modifiche non supportate, anziché ignorarle. Questa funzionalità è riservata ai cluster utente. Quando esegui l'upgrade dei cluster di amministrazione, le modifiche apportate alla maggior parte dei campi vengono ignorate automaticamente e non avranno effetto dopo l'upgrade.
Ad esempio, se tenti di disabilitare la riparazione automatica dei nodi durante l'upgrade di un cluster utente alla versione 1.28, l'upgrade non riesce e viene visualizzato il seguente messaggio di errore:
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, nello
scenario precedente, dovresti annullare le modifiche apportate alla configurazione di
AutoRepaired eseguire nuovamentegkectl upgrade. - In alternativa, puoi generare file di configurazione corrispondenti allo stato attuale del cluster eseguendo
gkectl get-config, aggiornare i campigkeOnPremVersionper il cluster e i pool di nodi nel file di configurazione, quindi eseguire nuovamentegkectl upgrade.
Esegui il debug dei problemi di BIG-IP di F5 con il file kubeconfig interno
Dopo un'installazione, GKE su VMware genera un file kubeconfig denominato internal-cluster-kubeconfig-debug nella home directory della workstation di amministrazione. Questo file kubeconfig è identico al file kubeconfig del cluster di amministrazione, tranne per il fatto che punta direttamente al nodo del piano di controllo del cluster di amministrazione, dove viene eseguito il server API Kubernetes. Puoi utilizzare il
file 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 govc per esaminare i problemi relativi a vSphere. Ad esempio, puoi confermare le autorizzazioni e l'accesso per i tuoi account utente vCenter e puoi raccogliere i log vSphere.
Ricrea il file kubeconfig del cluster utente mancante
Potresti voler ricreare un file kubeconfig del cluster utente nelle seguenti
situazioni:
- Se tenti di creare un cluster utente, ma 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 nuovo filekubeconfigper il cluster utente.ADMIN_CLUSTER_KUBECONFIG: il percorso del filekubeconfigper il cluster di amministrazione.
Passaggi successivi
- Se hai bisogno di ulteriore aiuto, contatta l'assistenza clienti Google Cloud.