Upgrade di GKE On-Prem

Questa pagina spiega come eseguire l'upgrade di GKE On-Prem.

Versioni target

A partire da GKE On-Prem versione 1.3.2, puoi eseguire l'upgrade direttamente a qualsiasi versione presente nella stessa release secondaria o nella release secondaria successiva. Ad esempio, puoi eseguire l'upgrade da 1.3.2 a 1.3.5 o da 1.5.2 a 1.6.1.

Se la versione corrente è precedente alla 1.3.2, devi prima eseguire gli upgrade sequenziali per raggiungere la versione 1.3.2. Ad esempio, per eseguire l'upgrade da 1.3.0 a 1.3.2, devi prima eseguire l'upgrade da 1.3.0 a 1.3.1 e poi da 1.3.1 a 1.3.2.

Se esegui l'upgrade dalla versione 1.3.2 o successiva a una versione che non fa parte della prossima release secondaria, devi eseguire l'upgrade tramite una versione di ogni release secondaria tra la versione corrente e la versione desiderata. Ad esempio, se esegui l'upgrade dalla versione 1.3.2 alla versione 1.6.1, non è possibile eseguire direttamente l'upgrade. Devi prima eseguire l'upgrade dalla versione 1.3.2 alla versione 1.4.x, dove x rappresenta qualsiasi release della patch in quella release secondaria. Puoi quindi eseguire l'upgrade alla versione 1.5.x e infine alla versione 1.6.1.

Panoramica della procedura di upgrade

1. Scarica lo strumento gkeadm. La versione di gkeadm deve essere uguale alla versione di destinazione dell'upgrade.

2. Utilizza gkeadm per eseguire l'upgrade della workstation di amministrazione.

3. Dalla workstation di amministrazione, esegui l'upgrade del cluster di amministrazione.

4. Dalla workstation di amministrazione, esegui l'upgrade dei cluster utente.

Criterio di upgrade

Dopo aver eseguito l'upgrade del cluster di amministrazione:

• Eventuali nuovi cluster utente creati devono avere la stessa versione del cluster di amministrazione.

• Se esegui l'upgrade di un cluster utente esistente, devi eseguire l'upgrade alla stessa versione del tuo cluster di amministrazione.

• Prima di eseguire nuovamente l'upgrade del cluster di amministrazione, devi eseguire l'upgrade di tutti i cluster utente nella stessa versione del cluster di amministrazione attuale.

Individuare la configurazione e i file di informazioni

Quando hai creato la workstation di amministrazione attuale, hai compilato un file di configurazione della workstation di amministrazione generato da gkeadm create config. Il nome predefinito di questo file è admin-ws-config.yaml.

Quando hai creato la tua workstation di amministrazione attuale, gkeadm ha creato un file informativo per te. Il nome predefinito di questo file corrisponde al nome della workstation di amministrazione corrente.

Individua il file di configurazione della workstation di amministrazione e il file delle informazioni. Devi seguire i passaggi illustrati in questa guida. Se questi file si trovano nella directory attuale e hanno i loro nomi predefiniti, non li dovrai specificare quando esegui gkeadm upgrade admin-workstation. Se i file si trovano in un'altra directory o se hai modificato i nomi file, li specifichi utilizzando i flag --config e --info-file.

Upgrade della workstation di amministrazione

Per eseguire l'upgrade della workstation di amministrazione, scarica prima una nuova versione dello strumento gkeadm, quindi utilizzala per eseguire l'upgrade della configurazione della workstation di amministrazione. La versione di gkeadm deve corrispondere alla versione di destinazione dell'upgrade.

Download della lingua gkeadm in corso...

Per scaricare la versione corrente di gkeadm, segui le istruzioni per il download di gkeadm nella pagina GKE On-Prem.

Upgrade della configurazione della workstation di amministrazione

gkeadm upgrade admin-workstation --config [AW_CONFIG_FILE] --info-file [INFO_FILE]

dove:

• [AW_CONFIG_FILE] è il percorso del file di configurazione della workstation di amministrazione. Puoi omettere questo flag se il file si trova nella directory attuale e ha il nome admin-ws-config.yaml.

• [INFO_FILE] è il percorso del file delle informazioni. Puoi omettere questo flag se il file si trova nella directory attuale. Il nome predefinito di questo file corrisponde al nome della tua workstation di amministrazione.

Il comando precedente esegue le attività seguenti:

• Esegui il backup di tutti i file nella home directory della workstation di amministrazione corrente. Sono inclusi:

  • Il tuo file di configurazione GKE On-Prem. Il nome predefinito di questo file è config.yaml.

  • I file kubeconfig per il cluster di amministrazione e i cluster utente.

  • Il certificato radice per il server vCenter. Tieni presente che questo file deve avere l'autorizzazione di lettura e scrittura del proprietario.

  • Il file della chiave JSON dell'account di servizio incluso nella lista consentita. Tieni presente che questo file deve disporre dell'autorizzazione di lettura e scrittura del proprietario.

  • I file della chiave JSON per gli account di servizio Connect-Agent, connect-agent e logging-monitoring.

• Crea una nuova workstation di amministrazione e copia tutti i file di cui è stato eseguito il backup nella nuova workstation.

• Elimina la vecchia workstation di amministrazione.

Rimozione della vecchia workstation di amministrazione da known_hosts in corso...

Se la tua workstation di amministrazione ha un indirizzo IP statico, devi rimuovere la vecchia workstation di amministrazione dal file known_hosts dopo aver eseguito l'upgrade della workstation di amministrazione.

Per rimuovere la workstation di amministrazione precedente da known_hosts:

ssh-keygen -R [ADMIN_WS_IP]

dove [ADMIN_WS_IP] è l'indirizzo IP della tua workstation di amministrazione.

Impostazione del percorso del bundle nel file di configurazione GKE On-Prem

Nella nuova workstation di amministrazione, apri il file di configurazione GKE On-Prem. Imposta il valore di bundlepath sul percorso del file del bundle sulla nuova workstation di amministrazione:

bundlepath: "/var/lib/gke/bundles/gke-onprem-vsphere-[VERSION]-full.tgz"

dove [VERSION] è la versione target dell'upgrade.

Aggiornamento dell'immagine del sistema operativo del nodo e delle immagini Docker in corso...

Nella nuova workstation di amministrazione, esegui il comando seguente:

gkectl prepare --config [CONFIG_FILE] [FLAGS]

dove:

• [CONFIG_FILE] è il file di configurazione GKE On-Prem sulla tua nuova workstation di amministrazione.

• [FLAGS] è un insieme facoltativo di flag. Ad esempio, puoi includere il flag --skip-validation-infra per saltare il controllo della tua infrastruttura vSphere.

Il comando precedente esegue le attività seguenti:

• Se necessario, copia una nuova immagine del sistema operativo nodo nel tuo ambiente vSphere e contrassegna l'immagine sistema operativo come modello.

• Se hai configurato un registro Docker privato, esegui il push di immagini Docker aggiornate al tuo registro Docker privato.

Verifica che siano disponibili indirizzi IP sufficienti

Esegui i passaggi descritti in questa sezione sulla nuova workstation di amministrazione.

Prima di eseguire l'upgrade, assicurati di avere a disposizione un numero sufficiente di indirizzi IP per i tuoi cluster.

DHCP

Durante un upgrade, GKE On-Prem crea un nodo temporaneo nel cluster di amministrazione e un nodo temporaneo in ogni cluster utente associato. Assicurati che il tuo server DHCP possa fornire un numero di indirizzi IP sufficiente per questi nodi temporanei. Per ulteriori informazioni, consulta gli indirizzi IP necessari per i cluster di amministrazione e utente.

IP statici

Durante un upgrade, GKE On-Prem crea un nodo temporaneo nel cluster di amministrazione e un nodo temporaneo in ogni cluster utente associato. Per il cluster di amministrazione e ciascuno dei cluster utente, verifica di aver prenotato un numero sufficiente di indirizzi IP. Per ogni cluster, è necessario prenotare almeno un indirizzo IP in più rispetto al numero di nodi del cluster. Per ulteriori informazioni, consulta Configurazione di indirizzi IP statici.

Determina il numero di nodi nel cluster di amministrazione:

kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] get nodes

dove [ADMIN_CLUSTER_KUBECONFIG] è il percorso del file kubeconfig del cluster di amministrazione.

Quindi, visualizza gli indirizzi riservati al cluster di amministrazione:

kubectl get cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -o yaml

Nell'output, nel campo reservedAddresses, puoi vedere il numero di indirizzi IP riservati ai nodi del cluster di amministrazione. Ad esempio, il seguente output mostra che sono presenti cinque indirizzi IP riservati per i nodi del cluster di amministrazione:

...
reservedAddresses:
- gateway: 21.0.135.254
  hostname: admin-node-1
  ip: 21.0.133.41
  netmask: 21
- gateway: 21.0.135.254
  hostname: admin-node-2
  ip: 21.0.133.50
  netmask: 21
- gateway: 21.0.135.254
  hostname: admin-node-3
  ip: 21.0.133.56
  netmask: 21
- gateway: 21.0.135.254
  hostname: admin-node-4
  ip: 21.0.133.47
  netmask: 21
- gateway: 21.0.135.254
  hostname: admin-node-5
  ip: 21.0.133.44
  netmask: 21

Il numero di indirizzi IP riservati deve essere almeno uno superiore al numero di nodi nel cluster di amministrazione. In caso contrario, puoi prenotare un indirizzo aggiuntivo modificando l'oggetto Cluster.

Apri l'oggetto Cluster per la modifica:

kubectl edit cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG]

In reservedAddresses, aggiungi un blocco aggiuntivo con gateway, hostname, ip e netmask.

Segui la stessa procedura per ciascuno dei tuoi cluster utente.

Per determinare il numero di nodi in un cluster utente:

kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] get nodes

dove [USER_CLUSTER_KUBECONFIG] è il percorso del file kubeconfig del cluster utente.

Per visualizzare gli indirizzi riservati a un cluster utente:

kubectl get cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
-n [USER_CLUSTER_NAME] [USER_CLUSTER_NAME] -o yaml

dove:

• [ADMIN_CLUSTER_KUBECONFIG] è il percorso del file kubeconfig del cluster di amministrazione.

• [USER_CLUSTER_NAME] è il nome del cluster utente.

Per modificare l'oggetto Cluster di un cluster utente:

kubectl edit cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
-n [USER_CLUSTER_NAME] [USER_CLUSTER_NAME]

(Facoltativo) Disattivare le nuove funzionalità di vSphere

Una nuova versione di GKE On-Prem potrebbe includere nuove funzionalità o supporto per specifiche funzionalità VMware vSphere. A volte l'upgrade a una versione GKE On-Prem abilita automaticamente tali funzionalità. Scopri di più sulle nuove funzionalità nelle Note di rilascio di GKE On-Prem. Nel nuovo file di configurazione GKE On-Prem sono presenti nuove funzionalità.

Se devi disabilitare una nuova funzionalità abilitata automaticamente in una nuova versione di GKE On-Prem e basata sul file di configurazione, esegui i passaggi riportati di seguito prima di eseguire l'upgrade del cluster:

1. Dalla workstation di amministrazione aggiornata, crea un nuovo file di configurazione con un nome diverso da quello in uso:

   gkectl create-config --config [CONFIG_NAME]

2. Apri il nuovo file di configurazione e prendi nota del campo della funzionalità. Chiudi il file.

3. Apri il file di configurazione corrente e aggiungi il campo della nuova funzionalità. Imposta il valore del campo su false o equivalente.

4. Salva il file di configurazione.

Consulta le Note di rilascio prima di eseguire l'upgrade dei cluster. Non puoi modificare in modo dichiarativo la configurazione di un cluster esistente dopo aver eseguito l'upgrade.

Upgrade del cluster di amministrazione

Esegui i passaggi descritti in questa sezione sulla nuova workstation di amministrazione.

Ricorda che la versione di destinazione del tuo upgrade deve essere la stessa della versione di gkeadm.

Esegui questo comando:

gkectl upgrade admin \
--kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
--config [ADMIN_CLUSTER_CONFIG_FILE] \
[FLAGS]

dove:

• [ADMIN_CLUSTER_KUBECONFIG] è il file kubeconfig del cluster di amministrazione.

• [ADMIN_CLUSTER_CONFIG_FILE] è il file di configurazione del cluster di amministrazione GKE on-prem sulla tua nuova workstation di amministrazione.

• [FLAGS] è un insieme facoltativo di flag. Ad esempio, puoi includere il flag --skip-validation-infra per saltare il controllo della tua infrastruttura vSphere.

Nota: non esegue l'upgrade di tutti i nodi del cluster di amministrazione perché alcuni dei nodi del cluster di amministrazione sono i nodi principali dei cluster utente. Questi verranno aggiornati all'avvio dei cluster utente.

Upgrade di un cluster utente

Esegui i passaggi descritti in questa sezione sulla nuova workstation di amministrazione.

Ricorda che la versione di destinazione del tuo upgrade deve essere la stessa della versione di gkeadm.

Gkectl

gkectl upgrade cluster \
--kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
--config [USER_CLUSTER_CONFIG_FILE] \
--cluster-name [CLUSTER_NAME] \
[FLAGS]

dove:

• [ADMIN_CLUSTER_KUBECONFIG] è il file kubeconfig del cluster di amministrazione.

• [CLUSTER_NAME] è il nome del cluster utente di cui stai eseguendo l'upgrade.

• [USER_CLUSTER_CONFIG_FILE] è il file di configurazione del cluster utente on-prem di GKE sulla tua nuova workstation di amministrazione.

• [FLAGS] è un insieme facoltativo di flag. Ad esempio, puoi includere il flag --skip-validation-infra per saltare il controllo della tua infrastruttura vSphere.

console

Puoi scegliere di registrare i tuoi cluster utente con Google Cloud Console durante l'installazione o dopo averli creati. Puoi visualizzare e accedere ai tuoi cluster GKE on-prem registrati e ai tuoi cluster Google Kubernetes Engine dal menu GKE di Google Cloud Console.

Quando diventa disponibile un upgrade per i cluster utente GKE On-Prem, viene visualizzata una notifica in Google Cloud Console. Se fai clic su questa notifica viene visualizzato un elenco delle versioni disponibili e un comando gkectl che puoi eseguire per eseguire l'upgrade del cluster:

1. Vai al menu GKE in Google Cloud Console.

   Vai al menu GKE

2. Nella colonna Notifiche per il cluster utente, fai clic su Upgrade disponibile, se disponibile.

3. Copia il comando gkectl upgrade cluster.

4. Dalla workstation, esegui il comando gkectl upgrade cluster, dove [ADMIN_CLUSTER_KUBECONFIG] è il file kubeconfig del cluster di amministrazione, [CLUSTER_NAME] è il nome del cluster utente di cui stai eseguendo l'upgrade e [USER_CLUSTER_CONFIG_FILE] è il file di configurazione del cluster utente GKE On-Prem nella nuova workstation di amministrazione.

Ripresa dell'upgrade

Se un upgrade del cluster utente viene interrotto dopo aver eseguito correttamente l'upgrade del cluster di amministrazione, puoi riprendere l'upgrade del cluster utente eseguendo lo stesso comando di upgrade con il flag --skip-validation-all:

gkectl upgrade cluster \
--kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
--config [USER_CLUSTER_CONFIG_FILE] \
--cluster-name [CLUSTER_NAME] \
--skip-validation-all

Ripresa dell'upgrade del cluster di amministrazione

Non interrompere un upgrade del cluster di amministrazione. Al momento, gli upgrade dei cluster di amministrazione non sono sempre ripristinabili. Se un upgrade del cluster di amministrazione viene interrotto per qualsiasi motivo, devi contattare l'assistenza.

Creazione di un nuovo cluster utente dopo un upgrade.

Dopo aver eseguito l'upgrade della workstation di amministrazione e del cluster di amministrazione, tutti i nuovi cluster utente creati devono avere la stessa versione della versione di destinazione di upgrade.

Problemi noti

I seguenti problemi noti interessano l'upgrade dei cluster.

Versione 1.1.0-gke.6, 1.2.0-gke.6: campo stackdriver.proxyconfigsecretname rimosso

Il campo stackdriver.proxyconfigsecretname è stato rimosso nella versione 1.1.0-gke.6. I controlli preliminari di GKE on-prem restituiranno un errore se il campo è presente nel file di configurazione.

Per risolvere questo problema, prima di eseguire l'upgrade a 1.2.0-gke.6, elimina il campo proxyconfigsecretname dal file di configurazione.

Stackdriver fa riferimento alla versione precedente

Prima della versione 1.2.0-gke.6, un problema noto impedisce a Stackdriver di aggiornare la propria configurazione dopo gli upgrade del cluster. Stackdriver fa ancora riferimento a una versione precedente, che impedisce a Stackdriver di ricevere le funzionalità più recenti della pipeline di telemetria. Questo problema può rendere difficile per l'Assistenza Google risolvere i problemi dei cluster.

Dopo aver eseguito l'upgrade dei cluster a 1.2.0-gke.6, esegui il seguente comando sui cluster di amministrazione e utente:

kubectl --kubeconfig=[KUBECONFIG] \
-n kube-system --type=json patch stackdrivers stackdriver \
-p '[{"op":"remove","path":"/spec/version"}]'

dove [KUBECONFIG] è il percorso del file kubeconfig del cluster.

Interruzione per i carichi di lavoro con PodDisruptionBudget

Attualmente, l'upgrade dei cluster può causare interruzioni o tempi di inattività per i carichi di lavoro che utilizzano PodDisruptionBudget (PDB).

Versione 1.2.0-gke.6: Prometheus e Grafana disattivati dopo l'upgrade

Nei cluster utente, Prometheus e Grafana vengono disattivati automaticamente durante l'upgrade. Tuttavia, i dati di configurazione e delle metriche non andranno persi. Nei cluster di amministrazione, Prometheus e Grafana rimangono attivi.

Per istruzioni, consulta le note di rilascio di GKE On-Prem.

Versione 1.1.2-gke.0: i nodi del cluster utente eliminati non vengono rimossi dal datastore vSAN

Per istruzioni, consulta le note di rilascio di GKE On-Prem.

Versione 1.1.1-gke.2: il disco dati nella cartella del datastore vSAN può essere eliminato

Se utilizzi un datastore vSAN, devi creare una cartella in cui salvare il VMDK. Un problema noto richiede che il percorso UUID (Universal Unique Identifier) della cartella, anziché il suo percorso file, venga inviato a vcenter.datadisk. Questa mancata corrispondenza può causare errori degli upgrade.

Per istruzioni, consulta le note di rilascio di GKE On-Prem.

Upgrade alla versione 1.1.0-gke.6 dalla versione 1.0.2-gke.3: problema OIDC

Non è possibile eseguire l'upgrade dei cluster della versione 1.0.11, 1.0.1-gke.5 e 1.0.2-gke.3 in cui è configurato OpenID Connect (OIDC) alla versione 1.1.0-gke.6. Questo problema è stato risolto nella versione 1.1.1-gke.2.

Se hai configurato un cluster versione 1.0.11, 1.0.1-gke.5 o 1.0.2-gke.3 con OIDC durante l'installazione, non puoi eseguirne l'upgrade. Devi invece creare nuovi cluster.

Upgrade alla versione 1.0.2-gke.3 dalla versione 1.0.11

La versione 1.0.2-gke.3 introduce i seguenti campi OIDC (usercluster.oidc). Questi campi consentono di accedere a un cluster da Google Cloud Console:

• usercluster.oidc.kubectlredirecturl
• usercluster.oidc.clientsecret
• usercluster.oidc.usehttpproxy

Se vuoi utilizzare OIDC, il campo clientsecret è obbligatorio anche se non vuoi accedere a un cluster da Google Cloud Console. Per utilizzare OIDC, potrebbe essere necessario fornire un valore segnaposto per clientsecret:

oidc:
  clientsecret: "secret"

I nodi non riescono a completare il processo di upgrade

Se hai configurato PodDisruptionBudget oggetti che non sono in grado di consentire ulteriori interruzioni, dopo gli ripetuti tentativi gli upgrade dei nodi potrebbero non riuscire a eseguire la versione del piano di controllo. Per evitare questo errore, ti consigliamo di fare lo scale up di Deployment o HorizontalPodAutoscaler per consentire lo svuotamento del nodo pur continuando a rispettare la configurazione di PodDisruptionBudget.

Per visualizzare tutti gli oggetti PodDisruptionBudget che non consentono interruzioni:

kubectl get poddisruptionbudget --all-namespaces -o jsonpath='{range .items[?(@.status.disruptionsAllowed==0)]}{.metadata.name}/{.metadata.namespace}{"\n"}{end}'

Appendice

Informazioni sulle regole DRS di VMware abilitate nella versione 1.1.0-gke.6

A partire dalla versione 1.1.0-gke.6, GKE On-Prem crea automaticamente le regole anti-affinità di Distributed Resource Scheduler (VMS) VMware per i nodi del cluster utente, determinando la loro distribuzione in almeno tre host fisici del data center. A partire dalla versione 1.1.0-gke.6, questa funzionalità è abilitata automaticamente per i nuovi cluster e i cluster esistenti.

Prima di eseguire l'upgrade, assicurati che il tuo ambiente vSphere soddisfi le seguenti condizioni:

• VMware DRS è abilitato. VMware DRS richiede la versione di licenza vSphere Enterprise Plus. Per informazioni su come abilitare gli DRS, consulta Abilitare DRS VMware in un cluster
• L'account utente vSphere fornito nel campo vcenter dispone dell'autorizzazione Host.Inventory.EditCluster.
• Sono disponibili almeno tre host fisici.

Se il tuo ambiente vSphere non soddisfa le condizioni precedenti, puoi eseguire l'upgrade, ma per eseguire l'upgrade di un cluster utente da 1.3.x a 1.4.x devi disabilitare i gruppi anti-affinità. Per ulteriori informazioni, consulta questo problema noto nelle note di rilascio di GKE On-Prem.

Tempo di riposo

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 sui cluster utente continuano a essere eseguiti, a meno che non siano stati interessati da un errore che ha causato il tempo di inattività
Piano di controllo del cluster utente	In genere, non sono previsti tempi di inattività visibili per i piani di controllo del cluster utente. Tuttavia, le connessioni a lunga durata al server API Kubernetes potrebbero interrompersi e dovrebbero essere ripristinate. In questi casi, il chiamante dell'API deve riprovare finché non stabilisce una connessione. Nel peggiore dei casi, può essere necessario fino a un minuto di tempo di inattività durante un upgrade. Nota: se i nodi del cluster utente non sono in grado di raggiungere il piano di controllo dell'utente durante l'upgrade, i nuovi carichi di lavoro non vengono pianificati nel cluster. I carichi di lavoro esistenti non sono interessati.
Nodi del 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. Puoi evitare l'impatto sui tuoi carichi di lavoro configurando PodDisruptionBudget e regole di affinità appropriati.

Risolvere i problemi

Per saperne di più, consulta la sezione Risoluzione dei problemi.

Nuovi nodi creati ma non integri

Sintomi

I nuovi nodi non vengono registrati nel piano di controllo del cluster utente quando utilizzi la modalità di bilanciamento del carico manuale.

Cause possibili

La convalida di Ingress in-node può essere abilitata che blocca il processo di avvio dei nodi.

Risoluzione

Per disattivare la convalida, esegui:

kubectl patch machinedeployment [MACHINE_DEPLOYMENT_NAME] -p '{"spec":{"template":{"spec":{"providerSpec":{"value":{"machineVariables":{"net_validation_ports": null}}}}}}}' --type=merge

Diagnostica dei problemi del cluster utilizzando gkectl

Utilizza i comandi gkectl diagnoseper identificare i problemi del cluster e condividere le informazioni sul cluster con Google. Consulta la sezione Diagnosi dei problemi del cluster.

Esecuzione di gkectl comandi in modo dettagliato

-v5

Registrazione di gkectl errori in stderr

--alsologtostderr

Individuare i log di gkectl nella workstation di amministrazione

Anche se non passi i flag di debug, puoi visualizzare i log gkectl nella seguente directory della workstation di amministrazione:

/home/ubuntu/.config/gke-on-prem/logs

Individuare i log dell'API del cluster nel cluster di amministrazione

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

1. Trova il nome del pod dei controller dell'API 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. Facoltativamente, utilizza grep o uno strumento simile per cercare gli errori:

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