Questa pagina mostra come esaminare i problemi relativi alla creazione e all'upgrade dei cluster in Google Distributed Cloud (solo software) per VMware.
Se hai bisogno di ulteriore assistenza, contatta l'assistenza clienti Google Cloud.Problemi di installazione
Le sezioni seguenti potrebbero aiutarti a risolvere i problemi di installazione di 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 motivo di 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 utilizzarlo 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 di 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 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-planeeseguito 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 va a buon fine,
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 informazioni importanti per il debug della procedura 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 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 comunica 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 contenitore e visualizza i relativi 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 al cluster
Questo problema può verificarsi se esiste un 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 di blocco IP del cluster in modo che gli indirizzi delle macchine non siano in conflitto con quelli specificati nel file di configurazione del cluster o nel file di blocco IP di Seesaw
Il cluster di tipi non viene eliminato
Quando crei un cluster di amministrazione, nell'ambito del processo viene creato un cluster kind (chiamato anche cluster di bootstrap). Al termine dell'operazione sul cluster amministrativo, il cluster kind viene eliminato automaticamente.
Se visualizzi il messaggio di errore Failed to delete the kind cluster, puoi eseguire i seguenti passaggi sulla tua workstation di amministrazione per eliminare manualmente il cluster kind:
Recupera l'ID contenitore
kind:docker inspect --format="{{.Id}}" gkectl-control-planeRecupera l'ID processo
containerd-shim:sudo ps awx | grep containerd-shim | grep CONTAINER_ID | awk '{print $1}'Interrompi il processo:
sudo kill -9 PROCESS_ID
Problemi di upgrade del cluster
Le sezioni seguenti forniscono suggerimenti su come risolvere i problemi che potresti riscontrare durante un upgrade del cluster.
Eseguire 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 di node pool 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 uguale o una versione secondaria precedente rispetto alla versione 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 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 la versione precedente sia disponibile per il rollback.
Per visualizzare le versioni disponibili, esegui il seguente 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 pool di nodi
Puoi eseguire il rollback della versione di un pool di nodi alla volta o di più node pool in un unico passaggio.
Per eseguire il rollback di una versione del pool di nodi:
Nel file di configurazione del cluster utente, in uno o più pool di nodi, imposta il valore di
gkeOnPremVersionsulla 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 andato a buon fine:
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 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:
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 sulla 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 riportato di seguito:
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 una sola replica per cui è stato creato un PodDisruptionBudget (PDB) 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-namespacesControlla 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.
Rimuovere le modifiche non supportate per sbloccare l'upgrade
Quando esegui l'upgrade dei cluster alla versione 1.16 o precedente, le modifiche alla maggior parte dei campi vengono ignorate silenziosamente durante l'upgrade, il che significa che non vengono applicate durante e dopo l'upgrade.
Quando esegui l'upgrade dei cluster di utenti alle versioni 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à è solo per i cluster di utenti. Durante l'upgrade dei cluster di amministrazione, le modifiche alla maggior parte dei campi vengono ignorate silenziosamente e non avranno effetto dopo l'upgrade.
Ad esempio, se provi a disattivare la riparazione automatica dei nodi durante l'upgrade di un cluster utente alla versione 1.28, l'upgrade non va a buon fine con 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
}
Se devi aggirare questo errore, puoi utilizzare una delle seguenti soluzioni alternative:
- Ripristina la modifica tentata e poi esegui di nuovo l'upgrade. Ad esempio, nello scenario precedente, dovresti ripristinare le modifiche apportate alla configurazione
AutoRepaire poi eseguire di nuovogkectl 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 rimanda 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.
Risolvere i problemi relativi a 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
Ti consigliamo di ricreare un file kubeconfig del cluster utente nelle seguenti
situazioni:
- 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 del filekubeconfigper il cluster di amministrazione.USER_CONTROLPLANEVIP: ilcontrolPlaneVIPdel cluster dell'utente. Questo valore può essere recuperato dal file manifest del cluster utente.
Genera il file kubeconfig:
Esegui il comando seguente 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.