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
Scarica lo strumento
gkeadm
. La versione digkeadm
deve essere uguale alla versione di destinazione dell'upgrade.Utilizza
gkeadm
per eseguire l'upgrade della workstation di amministrazione.Dalla workstation di amministrazione, esegui l'upgrade del cluster di amministrazione.
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 Download.
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 di accesso ai componenti. 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. Puoi riservare ulteriori IP come necessario, come descritto per ciascuno di DHCP e IP statici.
DHCP
Quando esegui l'upgrade del cluster di amministrazione, GKE On-Prem crea un nodo temporaneo nel cluster di amministrazione. Quando esegui l'upgrade di un cluster utente, GKE On-Prem crea un nodo temporaneo nel cluster utente. Lo scopo del nodo temporaneo è garantire una disponibilità senza interruzioni. Prima di eseguire l'upgrade di un cluster, assicurati che il tuo server DHCP possa fornire un numero di indirizzi IP sufficiente per il nodo temporaneo. Per saperne di più, vedi Indirizzi IP necessari per cluster di amministrazione e utente.
IP statici
Quando esegui l'upgrade del cluster di amministrazione, GKE On-Prem crea un nodo temporaneo nel cluster di amministrazione. Quando esegui l'upgrade di un cluster utente, GKE On-Prem crea un nodo temporaneo nel cluster utente. Lo scopo del nodo temporaneo è garantire una disponibilità senza interruzioni. Prima di eseguire l'upgrade di un cluster, verifica di aver prenotato un numero sufficiente di indirizzi IP. Per ciascun cluster, è necessario prenotare almeno un indirizzo IP in più rispetto al numero di nodi del cluster. Per ulteriori informazioni, consulta la pagina Configurare 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
.
Importante: a partire dalla versione 1.5.0, la stessa procedura non funziona per i cluster utente e devi utilizzare gkectl update cluster
per ciascuno di essi.
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.
Il numero di indirizzi IP riservati deve essere almeno uno superiore al numero di nodi nel cluster utente. In caso contrario, puoi aprire il file hostconfig del cluster utente per modificarlo:
Se uno degli indirizzi riservati per un cluster utente è incluso nel file hostconfig, aggiungilo al blocco corrispondente in base a
netmask
egateway
.Aggiungi tutti gli indirizzi IP statici aggiuntivi che vuoi al blocco corrispondente, quindi esegui il cluster di aggiornamento gkectl.
(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:
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]
Apri il nuovo file di configurazione e prendi nota del campo della funzionalità. Chiudi il file.
Apri il file di configurazione corrente e aggiungi il campo della nuova funzionalità. Imposta il valore del campo su
false
o equivalente.Salva il file di configurazione.
Controlla 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.
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:
Vai al menu GKE in Google Cloud Console.
Nella colonna Notifiche per il cluster utente, fai clic su Upgrade disponibile, se disponibile.
Copia il comando
gkectl upgrade cluster
.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'autorizzazioneHost.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. |
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 ulteriori informazioni, consulta la sezione Risoluzione dei problemi.
Diagnostica dei problemi del cluster utilizzando gkectl
Utilizza i comandi gkectl diagnose
per identificare i problemi del cluster e condividere le informazioni sul cluster con Google. Consulta la sezione 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 automaticamente al filelogs/gkectl-$(date).log
nella directory locale in cui eseguigkectl
. -
Per
gkeadm
, il file di log predefinito èlogs/gkeadm-$(date).log
nella directory locale in cui eseguigkeadm
.
-
Per
- Tutte le voci di log vengono salvate nel file di log, anche se non vengono 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.
Ti consigliamo di inviare il file del log al team di assistenza quando hai bisogno di aiuto.
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 alla directory locale.
Per specificare una posizione non predefinita per il file di log gkeadm
, utilizza il flag --log_file
.
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:
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
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