Questo argomento spiega come eseguire l'upgrade di GKE On-Prem.
Per eseguire l'upgrade di GKE On-Prem, esegui l'upgrade della workstation di amministrazione. Quindi, esegui l'upgrade dei cluster.
Prima di iniziare
- Assicurati di seguire queste istruzioni nella workstation o nel laptop locale. Non seguire queste istruzioni dalla workstation di amministrazione esistente.
- Controlla la versione attuale dei cluster.
- Consulta le note di rilascio e i problemi noti relativi all'upgrade.
- Controlla Versioni.
Inoltre, leggi le seguenti considerazioni:
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 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 aspettarti tempi di inattività significativi per i piani di controllo del cluster utente. Tuttavia, le connessioni a lunga esecuzione al server API Kubernetes potrebbero interrompersi e dover essere ristabilite. 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 inattività durante l'upgrade. |
| 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. Puoi prevenire l'impatto sui tuoi carichi di lavoro configurando PodDisruptionBudget e regole di affinità appropriati. |
Upgrade sequenziale
GKE On-Prem supporta l'upgrade sequenziale. Per eseguire l'upgrade di un cluster a una nuova versione, il cluster deve essere già all'ultima versione precedente.
Non puoi eseguire l'upgrade dei tuoi cluster direttamente alla versione più recente da una versione con più versioni precedenti. Se il cluster è indietro di più versioni, devi eseguire l'upgrade del cluster in sequenza.
Esempio
Supponiamo che siano disponibili le versioni seguenti e che la tua workstation di amministrazione e i tuoi cluster eseguano la versione meno recente:
- 1.0.1 (versione precedente)
- 1.0.2
- 1.1 (versione più recente)
In questo caso, è la versione più recente. 1.1. Per eseguire l'upgrade da 1.0.1 a 1.1, segui questi passaggi:
- Aggiorna la tua workstation di amministrazione da 1.0.1 a 1.0.2.
- Esegui l'upgrade dei cluster da 1.0.1 a 1.0.2.
- Aggiorna la tua workstation di amministrazione da 1.0.2 a 1.1.
- Esegui l'upgrade dei cluster da 1.0.2 a 1.1.
Esegui il backup del file di configurazione GKE on-prem e dei file kubeconfig
Quando esegui l'upgrade della workstation di amministrazione, Terraform elimina la VM della workstation di amministrazione e la sostituisce con una workstation di amministrazione aggiornata. Prima di eseguire l'upgrade della workstation di amministrazione, devi eseguire il backup del file di configurazione GKE On-Prem e dei file kubeconfig dei cluster. In seguito, copi i file nella tua workstation di amministrazione di cui è stato eseguito l'upgrade.
Upgrade della workstation di amministrazione
L'upgrade della workstation di amministrazione include le seguenti entità nella stessa versione del file OVA (Open Virtualization Appliance) della workstation di amministrazione:
gkectl- pacchetto completo
Dopo aver eseguito l'upgrade della workstation di amministrazione, esegui l'upgrade dei cluster.
Download dell'OVA
Da Download, scarica il file OVA della workstation di amministrazione per la versione a cui stai eseguendo l'upgrade.
Per scaricare l'OVA più recente, esegui questo comando:
gsutil cp gs://gke-on-prem-release/admin-appliance/1.2.2-gke.2/gke-on-prem-admin-appliance-vsphere-1.2.2-gke.2.{ova,ova.1.sig} ~/
Importazione dell'OVA in vSphere e contrassegno come modello VM
Nelle sezioni seguenti:
- Crea alcune variabili che dichiarino gli elementi del tuo ambiente vCenter Server e vSphere.
- Importa la OVA della workstation di amministrazione in vSphere e contrassegnala come modello di VM.
Creazione delle variabili per govc in corso...
Prima di importare la workstation di amministrazione OVA in vSphere, devi fornire govc
alcune variabili che dichiarino gli elementi del tuo ambiente vCenter Server e vSphere:
export GOVC_URL=https://[VCENTER_SERVER_ADDRESS]/sdk export GOVC_USERNAME=[VCENTER_SERVER_USERNAME] export GOVC_PASSWORD=[VCENTER_SERVER_PASSWORD] export GOVC_DATASTORE=[VSPHERE_DATASTORE] export GOVC_DATACENTER=[VSPHERE_DATACENTER] export GOVC_INSECURE=true
Puoi scegliere di utilizzare il pool di risorse predefinito di vSphere o crearne uno tuo:
# If you want to use a resource pool you've configured yourself, export this variable: export GOVC_RESOURCE_POOL=[VSPHERE_CLUSTER]/Resources/[VSPHERE_RESOURCE_POOL]
# If you want to use vSphere's default resource pool, export this variable instead: export GOVC_RESOURCE_POOL=[VSPHERE_CLUSTER]/Resources
dove:
- [VCENTER_SERVER_ADDRESS] è l'indirizzo o il nome host di vCenter Server.
- [VCENTER_SERVER_USERNAME] è il nome utente di un account con il ruolo Amministratore o privilegi equivalenti in vCenter Server.
- [VCENTER_SERVER_PASSWORD] è la password dell'account vCenter Server.
- [VSPHERE_DATASTORE] è il nome del datastore che hai configurato nell'ambiente vSphere.
- [VSPHERE_DATACENTER] è il nome del data center che hai configurato nell'ambiente vSphere.
- [VSPHERE_CLUSTER] è il nome del cluster che hai configurato nell'ambiente vSphere. Per l'utilizzo di un pool di risorse non predefinito,
- [VSPHERE_RESOURCE_POOL] è il nome del pool di risorse che hai configurato per l'ambiente vSphere.
Importazione dell'OVA in vSphere: sensore standard
Se utilizzi un vSphere Standard Switch, importa l'OVA in vSphere utilizzando questo comando:
govc import.ova -options - ~/gke-on-prem-admin-appliance-vsphere-1.2.2-gke.2.ova <<EOF
{
"DiskProvisioning": "thin",
"MarkAsTemplate": true
}
EOF
Importazione dell'OVA in vSphere: sensore distribuito
Se utilizzi uno scambio distribuito vSphere, importa l'OVA in vSphere utilizzando questo comando, dove [YOUR_DISTRIBUTED_PORT_GROUP_NAME] è il nome del tuo gruppo di porte distribuito:
govc import.ova -options - ~/gke-on-prem-admin-appliance-vsphere-1.2.2-gke.2.ova <<EOF
{
"DiskProvisioning": "thin",
"MarkAsTemplate": true,
"NetworkMapping": [
{
"Name": "VM Network",
"Network": "[YOUR_DISTRIBUTED_PORT_GROUP_NAME]"
}
]
}
EOF
Impostazione della variabile del modello Terraform per la nuova VM della workstation di amministrazione
Nel file TFVARS della workstation di amministrazione, imposta vm_template sulla versione che stai eseguendo. Il valore di vm_template ha il seguente aspetto, dove [VERSION] è la versione dell'OVA:
gke-on-prem-admin-appliance-vsphere-[VERSION]
Utilizzo di Terraform per eseguire l'upgrade della workstation di amministrazione
Per eseguire l'upgrade della workstation di amministrazione, esegui questo comando: Questo comando elimina la VM della workstation di amministrazione attuale e la sostituisce con una VM aggiornata:
terraform init && terraform apply -auto-approve -input=false
Connessione alla workstation di amministrazione
Accedi tramite SSH alla tua workstation di amministrazione:
ssh -i ~/.ssh/vsphere_workstation ubuntu@[IP_ADDRESS]
Se utilizzi un proxy, devi configurare Google Cloud CLI per il proxy, in modo da poter eseguire i comandi
gcloudegsutil. Per istruzioni, consulta la pagina sulla configurazione dell'interfaccia a riga di comando gcloud da utilizzare dietro un proxy/firewall.Accedi a Google Cloud utilizzando le credenziali del tuo account:
gcloud auth login
Registra
gcloudcome assistente credenziali di Docker. Scopri di più su questo comando:gcloud auth configure-docker
Crea una chiave privata per il tuo account di servizio incluso nella lista consentita.
Copia l'indirizzo email dell'account di servizio:
gcloud iam service-accounts list
Crea la chiave privata dell'account di servizio, dove [KEY_FILE] è un nome che scegli per il file. Questo comando salva il file nella directory di lavoro attuale:
gcloud iam service-accounts keys create key.json \ --project [PROJECT_ID] --iam-account [ALLOWLISTED_SERVICE_ACCOUNT_EMAIL]
dove:
- [PROJECT_ID] è l'ID progetto.
- [KEY_FILE] è un nome e un percorso per salvare la chiave privata dell'account di servizio, ad esempio
/home/ubuntu/key.json. - [ALLOWLISTED_SERVICE_ACCOUNT_EMAIL] è l'indirizzo email dell'account di servizio incluso nella lista consentita.
Per attivare l'account di servizio incluso nella lista consentita:
gcloud auth activate-service-account --project [PROJECT_ID] \ --key-file [KEY_FILE]
Copia la configurazione di cui hai eseguito il backup e i file kubeconfig
In precedenza, hai eseguito il backup del file di configurazione GKE on-prem e dei file kubeconfig dei cluster. Ora dovresti copiare i file nella tua workstation di amministrazione aggiornata.
Aggiornamento dei cluster
Dopo aver eseguito l'upgrade della workstation di amministrazione e aver effettuato la connessione, procedi nel seguente modo:
Verifica che siano disponibili indirizzi IP sufficienti
Prima di eseguire l'upgrade, assicurati di avere a disposizione un numero di indirizzi IP sufficiente 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 indirizzi IP sufficienti per questi nodi temporanei. Per ulteriori informazioni, consulta 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 per ciascuno dei tuoi cluster utente, verifica di aver prenotato un numero sufficiente di indirizzi IP. Per ogni cluster è necessario aver prenotato almeno un indirizzo IP in più rispetto al numero di nodi del cluster. Per saperne di più, consulta Configurazione degli 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 tuo 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 per i 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 del cluster per la modifica:
kubectl edit cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG]
In reservedAddresses, aggiungi un ulteriore blocco con gateway,
hostname, ip e netmask.
Segui la stessa procedura per ogni cluster utente.
Per determinare il numero di nodi in un cluster utente:
kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] get nodes
dove [USER_CLUSTER_KUBECONFIG] is the path of your user cluster's kubeconfig file.
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 tuo 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]
Modificare il file di configurazione
Sulla VM della workstation di amministrazione, modifica il file di configurazione. Imposta il valore di
bundlepath, dove [VERSION] è la versione on-prem di GKE
alla quale stai eseguendo l'upgrade dei cluster:
bundlepath: /var/lib/gke/bundles/gke-onprem-vsphere-[VERSION].tgz
Informazioni sulle funzionalità abilitate automaticamente
Una nuova versione di GKE On-Prem potrebbe includere nuove funzionalità o supporto per funzionalità VMware vSphere specifiche. Talvolta l'upgrade a una versione GKE On-Prem attiva automaticamente queste funzionalità. Scopri le nuove funzionalità delle note di rilascio di GKE On-Prem. A volte vengono visualizzate nuove funzionalità nel file di configurazione di GKE On-Prem.
Disattivazione di nuove funzionalità tramite il file di configurazione
Se devi disabilitare una nuova funzionalità abilitata automaticamente in una nuova versione di GKE On-Prem e basata sul file di configurazione, segui questi passaggi prima di eseguire l'upgrade del cluster:
Dalla workstation di amministrazione aggiornata, crea un nuovo file di configurazione con un nome diverso da quello utilizzato nel file di configurazione attuale:
gkectl create-config --config [CONFIG_NAME]
Apri il nuovo file di configurazione e il campo della funzionalità. Chiudi il file.
Apri il file di configurazione attuale e aggiungi il campo della nuova funzionalità nella specifica appropriata.
Specifica nel campo un valore di
falseo equivalente.Salva il file di configurazione. Procedi con l'upgrade dei cluster.
Dovresti sempre controllare le Note di rilascio prima di eseguire l'upgrade dei cluster. Non puoi modificare in modo dichiarativo la configurazione di un cluster esistente dopo averlo eseguito.
Esecuzione di gkectl prepare
Esegui questo comando:
gkectl prepare --config [CONFIG_FILE]
Il comando gkectl prepare esegue le attività seguenti:
Se necessario, copia una nuova immagine del sistema operativo del nodo nell'ambiente vSphere e contrassegna l'immagine del sistema operativo come modello.
Esegui il push delle immagini Docker aggiornate, specificate nel nuovo bundle, nel registro Docker privato, se ne hai configurato uno.
Upgrade del cluster di amministrazione
Esegui questo comando:
gkectl upgrade admin \ --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \ --config [CONFIG_FILE]
dove [ADMIN_CLUSTER_KUBECONFIG] è il file kubeconfig del cluster di amministrazione e [CONFIG_FILE] è il file di configurazione GKE On-Prem che stai utilizzando per eseguire l'upgrade.
Upgrade del cluster utente
Per eseguire l'upgrade di un cluster utente, devi eseguire l'upgrade del cluster di amministrazione alla versione desiderata o superiore prima di eseguire l'upgrade del cluster utente.
Gkectl
Dalla workstation di amministrazione, esegui il comando seguente:
gkectl upgrade cluster \ --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \ --config [CONFIG_FILE] \ --cluster-name [CLUSTER_NAME]
dove [ADMIN_CLUSTER_KUBECONFIG] è il file kubeconfig del cluster di amministrazione, [CLUSTER_NAME] è il nome del cluster utente che stai eseguendo l'upgrade e [CONFIG_FILE] è il file di configurazione on-prem di GKE che stai utilizzando per eseguire l'upgrade.
Console
Puoi scegliere di registrare i cluster utente con la console Google Cloud durante l'installazione o dopo averli creati. Puoi visualizzare e accedere ai cluster GKE on-prem registrati e ai cluster Google Kubernetes Engine dal menu GKE della console Google Cloud.
Quando diventa disponibile un upgrade per i cluster utente GKE On-Prem, viene visualizzata una notifica nella console Google Cloud. Se fai clic su questa notifica, viene visualizzato un elenco di versioni disponibili e un comando gkectl che puoi eseguire per eseguire l'upgrade del cluster:
Vai al menu GKE nella console Google Cloud.
Nella colonna Notifiche per il cluster utente, fai clic su Upgrade disponibile, se disponibile.
Copia il comando
gkectl upgrade cluster.Dalla workstation di amministrazione, esegui il comando
gkectl upgrade cluster, dove [ADMIN_CLUSTER_KUBECONFIG] è il file kubeconfig del cluster di amministrazione, [CLUSTER_NAME] è il nome del cluster utente che stai eseguendo l'upgrade e [CONFIG_FILE] è il file di configurazione on-prem di GKE che stai utilizzando per eseguire l'upgrade.
Ripresa dell'upgrade
Se l'upgrade di un cluster utente viene interrotto dopo l'upgrade corretto del cluster di amministrazione, puoi ripristinarlo eseguendo il medesimo comando di upgrade con il flag --skip-validation-all:
gkectl upgrade cluster \ --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \ --config [CONFIG_FILE] \ --cluster-name [CLUSTER_NAME] \ --skip-validation-all
Informazioni sul ripristino di un upgrade del cluster di amministrazione
Non devi interrompere un upgrade del cluster di amministrazione. Al momento, gli upgrade dei cluster di amministrazione non sono sempre ripristinabili. Se per qualsiasi motivo un upgrade del cluster di amministrazione viene interrotto, contatta l'assistenza.
Problemi noti
I seguenti problemi noti incidono sull'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 preflight di GKE On-Prem restituiranno un errore se il campo è presente nel file di configurazione.
Per risolvere il 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 la risoluzione dei problemi dei cluster.
Dopo aver eseguito l'upgrade dei cluster a 1.2.0-gke.6, esegui il comando seguente rispetto ai 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 dei carichi di lavoro con PodDisruptionBudget
Attualmente, l'upgrade dei cluster può causare interruzioni o tempi di inattività per carichi di lavoro che utilizzano PodDisruptionBudget (PDB).
Versione 1.2.0-gke.6: Prometheus e Grafana disabilitati dopo l'upgrade
Nei cluster utente, Prometheus e Grafana vengono disattivati automaticamente durante l'upgrade. Tuttavia, i dati di configurazione e metriche non andranno persi. Nei cluster di amministrazione, Prometheus e Grafana rimangono abilitati.
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 datastore vSAN può essere eliminato
Se utilizzi un datastore vSAN, devi creare una cartella in cui salvare il VMDK. Un problema noto richiede l'invio a vcenter.datadisk del percorso dell'identificatore univoco universale (UUID) della cartella anziché del percorso del file. Questa mancata corrispondenza può causare un errore 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
Impossibile eseguire l'upgrade alla versione 1.1.0-gke.6 delle versioni 1.0.11, 1.0.1-gke.5 e 1.0.2-gke.3 in cui è configurato OpenID Connect (OIDC). 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 eseguire l'upgrade. Devi invece creare nuovi cluster.
Upgrade dalla 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 dalla console Google Cloud:
usercluster.oidc.kubectlredirecturlusercluster.oidc.clientsecretusercluster.oidc.usehttpproxy
Se vuoi utilizzare OIDC, il campo clientsecret è obbligatorio anche se non vuoi accedere a un cluster dalla console Google Cloud. Per utilizzare OIDC, potrebbe essere necessario fornire un valore segnaposto per clientsecret:
oidc: clientsecret: "secret"
Appendice
Informazioni sulle regole DRS 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 di anti-affinità VMware Distributed Resource Scheduler (DRS) per i nodi del cluster utente, determinandone la distribuzione su almeno tre host fisici nel data center. A partire dalla versione 1.1.0-gke.6, questa funzionalità viene attivata automaticamente per i nuovi cluster e per i cluster esistenti.
Prima di eseguire l'upgrade, assicurati che il tuo ambiente vSphere soddisfi le seguenti condizioni:
- DRS VMware è abilitato. VMware DRS richiede l'edizione della licenza vSphere Enterprise Plus. Per informazioni su come abilitare DRS in un cluster, consulta Abilitare DRS VMware in un cluster
- L'account utente vSphere fornito nel campo
vcenterdispone dell'autorizzazioneHost.Inventory.EditCluster. - Sono disponibili almeno tre host fisici.
Disabilita DRS VMware prima di eseguire l'upgrade a 1.1.0-gke.6
Se non vuoi abilitare questa funzionalità per i tuoi cluster utente, ad esempio se non disponi di host sufficienti per supportare la funzionalità, esegui i passaggi seguenti prima di eseguire l'upgrade dei tuoi cluster utente:
- Apri il file esistente per la configurazione di GKE On-Prem.
- Nella specifica
usercluster, aggiungi il campoantiaffinitygroups:usercluster: ... antiaffinitygroups: enabled: false - Salva il file.
- Utilizza il file di configurazione per eseguire l'upgrade. È stato eseguito l'upgrade dei cluster, ma la funzionalità non è abilitata.
Scenario di upgrade alternativo
Questo argomento descrive il modo più semplice per eseguire l'upgrade di GKE On-Prem: eseguire l'upgrade della workstation di amministrazione e quindi eseguire l'upgrade dei cluster esistenti.
La tabella seguente descrive uno scenario di upgrade alternativo. In questo scenario, verrà eseguito l'upgrade solo di gkectl e dei tuoi cluster, senza eseguire l'upgrade della workstation di amministrazione:
| Scenario | Procedura |
|---|---|
| La release non include aggiornamenti di sicurezza per la workstation di amministrazione. |
|
Risolvere i problemi
Per ulteriori informazioni, 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 viene utilizzata la modalità di bilanciamento del carico manuale.
- Cause possibili
La convalida di Ingress in-node potrebbe 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
Diagnosi dei problemi del cluster con gkectl
Utilizza i comandi gkectl diagnoseper identificare i problemi del cluster e condividere le informazioni sul cluster con Google. Consulta Diagnosticare i problemi del cluster.
Comportamento predefinito di logging
Per gkectl e gkeadm è sufficiente utilizzare le impostazioni di logging predefinite:
-
Per impostazione predefinita, le voci di log vengono salvate nel seguente modo:
-
Per
gkectl, il file di log predefinito è/home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).loge il file è collegato correttamente 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.
-
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(impostazione predefinita) 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 di log al team di assistenza quando hai bisogno di aiuto.
Specifica di 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à simbolizzato nella directory locale.
Per specificare una posizione non predefinita per il file di log gkeadm, utilizza il flag --log_file.
Individuare i log dell'API Cluster nel cluster di amministrazione
Se l'avvio di una VM non va a buon fine dopo l'avvio del piano di controllo amministratore, puoi provare il debug controllando i log dei controller API del cluster nel cluster di amministrazione:
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
Apri i log del pod, dove [POD_NAME] è il nome del pod. Se vuoi, puoi utilizzare
grepo uno strumento simile per cercare gli errori:kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system logs [POD_NAME] vsphere-controller-manager