Risolvere i problemi

Le sezioni seguenti descrivono i problemi che potresti riscontrare durante l'utilizzo di GKE On-Prem e come risolverli.

Prima di iniziare

Prima di iniziare a risolvere un problema, consulta le sezioni seguenti.

Diagnostica dei problemi del cluster con gkectl

Utilizza i comandi gkectl diagnoseper identificare i problemi del cluster e condividerli con Google. Consulta Diagnosi dei problemi del cluster.

Comportamento di logging predefinito

Per gkectl e gkeadm è sufficiente utilizzare le impostazioni di logging predefinite:

• Per impostazione predefinita, le voci di log vengono salvate come segue:

  • Per gkectl, il file di log predefinito è /home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log e il file è collegato direttamente al file logs/gkectl-$(date).log nella directory locale in cui viene eseguito gkectl.
  • Per gkeadm, il file di log predefinito è logs/gkeadm-$(date).log nella directory locale in cui esegui gkeadm.
• Tutte le voci di log vengono salvate nel file di log, anche se non sono stampate nel terminale (quando --alsologtostderr è false).
• Il livello di dettaglio -v5 (predefinito) copre tutte le voci di log necessarie al team di assistenza.
• Il file di log contiene anche il comando eseguito e il messaggio di errore.

Se hai bisogno di aiuto, ti consigliamo di inviare il file di log al team di assistenza.

Specificare una posizione non predefinita per il 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 verrà collegato direttamente alla directory locale.

Per specificare una posizione non predefinita per il file di log gkeadm, utilizza il flag --log_file.

Localizzazione dei log dell'API Cluster nel cluster di amministrazione

Se l'avvio di una VM non riesce dopo l'avvio del piano di controllo dell'amministratore, puoi provare a eseguire il debug controllando i controller dell'API cluster nel log:

1. Trova il nome del pod dei controller API del cluster nello spazio dei nomi kube-system, dove [ADMIN_CLUSTER_KUBECONFIG] è il percorso del file kubeconfig del cluster di amministrazione:

   kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system get pods | grep clusterapi-controllers

2. Apri i log del pod, dove [POD_NAME] è il nome del pod. Se preferisci, utilizza grep o uno strumento simile per cercare errori:

   kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system logs [POD_NAME] vsphere-controller-manager

Installazione

Debug dei problemi BIG-IP di F5 utilizzando il kubeconfig del nodo del piano di controllo del cluster di amministrazione

Dopo un'installazione, GKE On-Prem genera un file kubeconfig nella home directory della workstation di amministrazione denominata internal-cluster-kubeconfig-debug. Il file kubeconfig è identico al kubeconfig del cluster di amministrazione, con la differenza che rimanda direttamente al nodo del piano di controllo del cluster di amministrazione, dove viene eseguito il piano di controllo dell'amministratore. Puoi utilizzare il file internal-cluster-kubeconfig-debug per eseguire il debug dei problemi di BIG-IP di F5.

La convalida di gkectl check-config non riesce: non riesce a trovare le partizioni BIG-IP di F5

Sintomi

La convalida non riesce perché le partizioni BIG-IP di F5 non possono essere trovate, anche se esistono.

Potenziali cause

Un problema con l'API F5 BIG-IP può causare la mancata riuscita della convalida.

Risoluzione

Riprova a eseguire gkectl check-config.

gkectl prepare --validate-attestations non riuscito: impossibile convalidare l'attestazione di build

Sintomi

L'esecuzione di gkectl prepare con il flag --validate-attestations facoltativo restituisce il seguente errore:

could not validate build attestation for gcr.io/gke-on-prem-release/.../...: VIOLATES_POLICY

Potenziali cause

Potrebbe non esistere un'attestazione per le immagini interessate.

Risoluzione

Prova a scaricare e a eseguire nuovamente il deployment dell'OVA della workstation di amministrazione, come indicato nella sezione Creare una workstation di amministrazione. Se il problema persiste, contatta Google per ricevere assistenza.

Debug utilizzando i log del cluster di bootstrap

Durante l'installazione, GKE On-Prem crea un cluster di bootstrap temporaneo. Dopo un'installazione riuscita, GKE On-Prem elimina il cluster di bootstrap, lasciandoti il cluster di amministrazione e il cluster utente. In genere, non dovresti avere motivo di interagire con questo cluster.

Se si verifica un problema durante l'installazione e hai passato --cleanup-external-cluster=false a gkectl create cluster, potrebbe essere utile eseguire il debug utilizzando i log del cluster di bootstrap. Puoi trovare il pod e quindi recuperare i relativi log:

kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl get pods -n kube-system

kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl -n kube-system get logs [POD_NAME]

Workstation di amministrazione

openssl non può convalidare l'OVA della workstation di amministrazione

Sintomi

L'esecuzione di openssl dgst nel file OVA della workstation di amministrazione non restituisce Verified OK

Potenziali cause

Nel file OVA è presente un problema che impedisce una convalida riuscita.

Risoluzione

Prova a scaricare e a eseguire il deployment dell'OVA della workstation di amministrazione, come indicato nell'articolo Scaricare l'OVA della workstation di amministrazione. Se il problema persiste, contatta Google per ricevere assistenza.

Connetti

Impossibile registrare un cluster utente

Se riscontri problemi con la registrazione dei cluster utente, contatta Google per ricevere assistenza.

La registrazione del cluster creato durante la fase alpha è stata annullata

Fai riferimento a Registrazione di un cluster utente nella documentazione di Connect.

Puoi anche scegliere di eliminare e ricreare il cluster.

Upgrade

Informazioni sul tempo di inattività durante gli upgrade

Risorsa	Descrizione
Cluster di amministrazione	Quando un cluster di amministrazione è inattivo, i piani di controllo e i carichi di lavoro dei cluster utente nei cluster utente continuano a essere eseguiti, a meno che non siano stati interessati da un errore che ha causato un tempo di inattività
Piano di controllo del cluster utente	In genere, i tempi di inattività dei piani di controllo del cluster utente non dovrebbero essere visibili. Tuttavia, le connessioni di lunga durata al server API Kubernetes potrebbero non funzionare e dovrebbero essere ripristinate. In questi casi, il chiamante dell'API deve riprovare finché non stabilisce una connessione. Nel caso peggiore, potrebbe verificarsi un tempo di inattività di massimo un minuto durante un upgrade. Nota: se i nodi del cluster utente non riescono a raggiungere il piano di controllo utente durante l'upgrade, non vengono pianificati nuovi carichi di lavoro nel cluster. I carichi di lavoro esistenti non sono interessati.
Nodi cluster utente	Se un upgrade richiede una modifica ai nodi del cluster utente, GKE On-Prem ricrea i nodi in modo continuativo e ripianifica i pod in esecuzione su questi nodi. Per prevenire l'impatto sui tuoi carichi di lavoro, puoi configurare PodDisruptionBudget appropriati e regole di anti-affinità.

Ridimensionare i cluster utente

Ridimensionamento di un cluster utente non riuscito

Sintomi

Un'operazione di ridimensionamento di un cluster utente non riuscita.

Potenziali cause

L'esito negativo delle operazioni di ridimensionamento potrebbe essere diverso.

Risoluzione

Se il ridimensionamento non riesce, segui questi passaggi:

1. Controlla lo stato MachineDeployment del cluster per verificare se sono presenti eventi o messaggi di errore:

   kubectl describe machinedeployments [MACHINE_DEPLOYMENT_NAME]

2. Verifica se sono presenti errori nelle macchine appena create:

   kubectl describe machine [MACHINE_NAME]

Errore: "Impossibile assegnare indirizzi".

Sintomi

Dopo aver ridimensionato un cluster utente, kubectl describe machine [MACHINE_NAME] visualizza il seguente errore:

Events:
   Type     Reason  Age                From                    Message
   ----     ------  ----               ----                    -------
   Warning  Failed  9s (x13 over 56s)  machineipam-controller  ipam: no addresses can be allocated
   

Potenziali cause

Non sono disponibili indirizzi IP sufficienti per il cluster utente.

Risoluzione

Assegna più indirizzi IP per il cluster. Quindi, elimina il computer interessato:

kubectl delete machine [MACHINE_NAME]

Se il cluster è configurato correttamente, viene creata una macchina sostitutiva con un indirizzo IP.

Numero sufficiente di indirizzi IP allocati, ma la macchina non riesce a registrarsi con il cluster

Sintomi

La rete ha un numero sufficiente di indirizzi allocati, ma la macchina non riesce ancora a registrarsi con il cluster utente.

Cause possibili

Potrebbe esserci un conflitto IP. L'IP potrebbe essere richiesto da un'altra macchina o dal tuo bilanciatore del carico.

Risoluzione

Verifica che l'indirizzo IP della macchina interessata non sia stato utilizzato. In caso di conflitto, devi risolvere il conflitto nel tuo ambiente.

Vari

Limite sessione del provider Terraform vSphere

GKE On-Prem utilizza il provider vSphere di Terraform per richiamare le VM nel tuo ambiente vSphere. Il limite per le sessioni del provider è 1000. L'implementazione corrente non chiude le sessioni attive dopo l'utilizzo. Se hai troppe sessioni in esecuzione, potresti visualizzare errori 503.

Le sessioni vengono chiuse automaticamente dopo 300 secondi.

Sintomi

Se sono in esecuzione troppe sessioni, potrebbe verificarsi il seguente errore:

Error connecting to CIS REST endpoint: Login failed: body:
  {"type":"com.vmware.vapi.std.errors.service_unavailable","value":
  {"messages":[{"args":["1000","1000"],"default_message":"Sessions count is
  limited to 1000. Existing sessions are 1000.",
  "id":"com.vmware.vapi.endpoint.failedToLoginMaxSessionCountReached"}]}},
  status: 503 Service Unavailable

Potenziali cause

Nel tuo ambiente sono in esecuzione troppe sessioni del provider Terraform.

Risoluzione

Attualmente funziona come previsto. Le sessioni vengono chiuse automaticamente dopo 300 secondi. Per ulteriori informazioni, consulta il problema di GitHub #618.

Utilizzo di un proxy per Docker: oauth2: cannot fetch token

Sintomi

Quando utilizzi un proxy ricevi il seguente errore:

oauth2: cannot fetch token: Post https://oauth2.googleapis.com/token: proxyconnect tcp: tls: oversized record received with length 20527

Potenziali cause

È possibile che tu abbia fornito un proxy HTTPS anziché HTTP.

Risoluzione

Nella configurazione Docker, modifica l'indirizzo proxy in http:// anziché in https://.

Verifica della validità delle licenze

Ricorda che devi verificare la validità delle licenze, soprattutto se utilizzi licenze di prova. Se le licenze F5, ESXi dell'host o vCenter sono scadute, potresti riscontrare errori imprevisti.