Questa pagina mostra come esaminare i problemi relativi alla creazione, all'upgrade e al ridimensionamento dei cluster in GKE su VMware.
Comportamento di logging predefinito per gkectl e gkeadm
Per gkectl e gkeadm è sufficiente utilizzare le impostazioni di logging predefinite:
Per
gkectl, il file di log predefinito è/home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).loge il file è collegato in modo simbolico al filelogs/gkectl-$(date).lognella directory locale in cui eseguigkectl.Per
gkeadm, il file di log predefinito èlogs/gkeadm-$(date).lognella directory locale in cui eseguigkeadm.Il livello di dettaglio predefinito
-v5copre tutte le voci di log necessarie al team di assistenza.Il file di log include il comando eseguito e il messaggio di errore.
Quando hai bisogno di aiuto, ti consigliamo di inviare il file di log al team di assistenza.
Specifica di posizioni non predefinite per i file di log
Per specificare una posizione non predefinita per il file di log gkectl, utilizza il flag --log_file. Il file di log specificato non sarà collegato alla directory locale.
Per specificare una posizione non predefinita per il file di log gkeadm, utilizza il flag --log_file.
Individuazione dei log dell'API Cluster nel cluster di amministrazione
Se una VM non si avvia dopo l'avvio del piano di controllo dell'amministratore, puoi analizzare il problema ispezionando i log del pod dei controller API del cluster nel cluster di amministrazione.
Trova il nome del pod dei controller API del 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 container:kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \ logs POD_NAMEL'output ti indica che devi specificare un container 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 visualizza i relativi log:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \ logs POD_NAME --container CONTAINER_NAME
Il cluster tipo non viene eliminato
Quando crei un cluster di amministrazione, nell'ambito del processo viene creato anche un cluster kind (detto anche cluster di boot). Al termine dell'operazione, il cluster kind viene eliminato automaticamente.
Se viene visualizzato il messaggio di errore Failed to delete the kind cluster, puoi eseguire i seguenti passaggi sulla workstation di amministrazione per eliminare manualmente il cluster kind:
Ottieni l'ID contenitore
kind:docker inspect --format="{{.Id}}" gkectl-control-planeOttieni l'ID processo
containerd-shim:sudo ps awx | grep containerd-shim | grep CONTAINER_ID | awk '{print $1}'Termina il processo:
sudo kill -9 PROCESS_ID
Utilizzo di govc per risolvere i 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 di vSphere.
Debug mediante i log del cluster di bootstrap
Durante l'installazione, GKE su VMware crea un cluster di bootstrap temporaneo. Dopo l'installazione, GKE su VMware elimina il cluster di bootstrap, lasciandoti il cluster di amministrazione e il cluster utente. In genere, non dovresti avere motivi per interagire con il cluster di bootstrap.
Se passi --cleanup-external-cluster=false a gkectl create cluster, il cluster di bootstrap non viene eliminato e puoi utilizzare i log del cluster di bootstrap per eseguire il debug dei problemi di installazione.
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-system
Visualizza i log per un pod:
kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl -n kube-system get logs POD_NAME
Per ottenere i log direttamente dal cluster di bootstrap, puoi eseguire il comando seguente durante la creazione, l'aggiornamento e l'upgrade del cluster:
docker exec -it gkectl-control-plane bash
Il comando apre un terminale all'interno del container gkectl-control-plane in esecuzione nel cluster di bootstrap.
Per esaminare i log kubelet e containerd, utilizza i comandi seguenti e cerca errori o avvisi nell'output:
systemctl status -l kubelet journalctl --utc -u kubelet systemctl status -l containerd journalctl --utc -u containerd
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 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
Supponi di aver recentemente eseguito l'upgrade dei nodi worker e del piano di controllo del cluster utente dalla versione 1.13.1-gke.35 alla versione 1.14.0 e di scoprire un problema con i nodi worker aggiornati. Decidi quindi di eseguire il rollback di uno o più pool di nodi alla versione che stavi eseguendo in precedenza: 1.13.1-gke.35.
Verifica che la versione precedente sia disponibile per il rollback:
gkectl version --cluster-name USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
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 dei pool di nodi
Puoi eseguire il rollback di un pool di nodi alla volta oppure di diversi pool di nodi in un singolo passaggio.
Nel file di configurazione del cluster utente, in uno o più pool di nodi, imposta il valore di gkeOnPremVersion sulla versione precedente: 1.13.1-gke.35 in questo
esempio:
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_KUBECONFIG
Verifica che il rollback:
gkectl version --cluster-name USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
pool-1 alla 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
Supponiamo che il problema sia stato risolto in una nuova versione della patch, diciamo 1.14.1. Ora puoi eseguire l'upgrade di tutti i pool di nodi e del piano di controllo alla nuova versione patch.
Nel file di configurazione del cluster utente:
Imposta il valore di
gkeOnPremVersionsulla nuova versione della patch: 1.14.1-gke.x in questo esempio.Per ogni pool di nodi, rimuovi il campo
gkeOnPremVersiono impostalo sulla stringa vuota. Quando non viene specificata alcuna versione per un pool di nodi, per impostazione predefinita la versione del pool di nodi corrisponde a quella specificata per il cluster.
Esempio:
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 prepare e gkectl upgrade cluster come descritto in
Upgrade di GKE su VMware.
Verifica la nuova versione del cluster e visualizza le versioni ora disponibili per il rollback:
gkectl version --cluster-name USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
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
Debug dei problemi BIG-IP di F5 mediante il file kubeconfig interno
Dopo un'installazione, GKE su VMware genera un file kubeconfig
denominato internal-cluster-kubeconfig-debug nella home directory della tua workstation
di amministrazione. Questo file kubeconfig è identico al file kubeconfig del tuo cluster di amministrazione, ma rimanda direttamente al nodo del piano di controllo del cluster di amministrazione, dove è in esecuzione il server API Kubernetes. Puoi usare il file internal-cluster-kubeconfig-debug per eseguire il debug dei problemi BIG-IP di F5.
Il ridimensionamento di un cluster utente non va a buon fine
Se il ridimensionamento di un cluster utente non va a buon fine:
Trova i nomi dei deployment di macchine e delle macchine:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get machinedeployments --all-namespaces kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get machines --all-namespaces
Descrivi un MachineDeployment per visualizzarne i log:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machinedeployment MACHINE_DEPLOYMENT_NAMEVerifica la presenza di errori sui computer appena creati:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machine MACHINE_NAME
Nessun indirizzo può essere allocato per il ridimensionamento del cluster
Questo problema si verifica se non sono disponibili indirizzi IP sufficienti per ridimensionare un cluster utente.
kubectl describe machine mostra il seguente errore:
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning Failed 9s (x13 over 56s) machineipam-controller ipam: no addresses can be allocated
Per risolvere il problema, alloca più indirizzi IP per il cluster. Quindi, elimina il computer interessato:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete machine MACHINE_NAMEGKE su VMware crea una nuova macchina a cui assegna uno dei nuovi indirizzi IP disponibili.
Numero sufficiente di indirizzi IP allocati, ma la registrazione della macchina non riesce 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 questo problema, aggiorna il file dei blocchi IP del cluster in modo che gli indirizzi della macchina non siano in conflitto con gli indirizzi specificati nel file di configurazione del cluster o nel file dei blocchi IP di Seesaw.
Lo snapshot viene creato automaticamente quando la creazione o l'upgrade del cluster di amministrazione non va a buon fine
Se provi a creare o eseguire l'upgrade di un cluster di amministrazione e l'operazione non riesce, GKE su VMware crea uno snapshot esterno del cluster di bootstrap, che è un cluster temporaneo utilizzato per creare o eseguire l'upgrade del cluster di amministrazione. Sebbene questo snapshot del cluster di bootstrap sia simile a quello acquisito eseguendo il comando gkectl diagnose snapshot nel cluster di amministrazione, viene attivato automaticamente. Questo 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 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
I controlli di integrità vengono eseguiti automaticamente quando l'upgrade del cluster non va a buon fine
Se provi a eseguire l'upgrade di un cluster di amministrazione o di un cluster utente e l'operazione non riesce, GKE su VMware 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
GKE su VMware, in background, 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.
A partire dalla versione 1.13 di GKE su VMware, puoi verificare gli errori tramite gli eventi pod Kubernetes.
Trova i nomi delle macchine:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get machines --all-namespaces
Verifica l'eventuale presenza di errori utilizzando il comando
kubectl describe machine:kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machine MACHINE_NAME
Ecco un output di esempio:
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning PodEvictionTooLong 3m49s machine-controller Waiting too long(12m10.284294321s) for pod(default/test-deployment-669b85c4cc-z8pz7) eviction.
Per un'analisi più dettagliata dello stato degli oggetti macchina, esegui gkectl diagnose cluster:
...
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. Puoi quindi aggiungere di nuovo il PDB al termine dell'upgrade.
Diagnosi 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.
Ecco un output di esempio:
- 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
Per ulteriori informazioni, consulta Diagnostica dei problemi relativi ai cluster.
Ricrea il file kubeconfig del cluster utente mancante
Potresti voler ricreare un file kubeconfig del cluster utente in un paio di situazioni:
- Se provi a creare un cluster utente e l'operazione di creazione non riesce, vuoi avere il file kubeconfig del relativo cluster utente.
- Se il file kubeconfig del cluster utente non è presente, 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 file kubeconfig per il cluster utente.
- ADMIN_CLUSTER_KUBECONFIG: il percorso del file kubeconfig per il cluster di amministrazione.
Rimuovi le modifiche non supportate per sbloccare l'upgrade
Quando esegui l'upgrade dei cluster alla 1.16 o alle versioni precedenti, le modifiche alla maggior parte dei campi vengono ignorate durante l'upgrade, il che significa che queste modifiche non hanno effetto durante e dopo l'upgrade.
Quando esegui l'upgrade dei cluster utente alla versione 1.28 o successiva, convalidiamo tutte le modifiche apportate nel file di configurazione e restituiamo un errore per le modifiche non supportate, anziché ignorarle. 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 andrà a buon fine e verrà visualizzato il messaggio di errore seguente:
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 ignorare questo errore, hai a disposizione le seguenti soluzioni alternative:
- Ripristina la modifica tentata ed esegui nuovamente l'upgrade. Ad esempio, nello
scenario precedente, dovevi annullare le modifiche apportate alla configurazione di
AutoRepaire poi eseguire nuovamentegkectl upgrade. - In alternativa, puoi generare file di configurazione che corrispondono 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.
gkectl errori del comando durante l'utilizzo dei Controlli di servizio VPC
Se utilizzi Controlli di servizio VPC, potresti visualizzare errori quando esegui alcuni comandi gkectl, ad esempio "Validation Category: GCP - [UNKNOWN] GCP
service: [Stackdriver] could not get GCP services". Per evitare questi errori, aggiungi
il parametro --skip-validation-gcp ai tuoi comandi.