Aggiornamento dei cluster

Questa pagina spiega come eseguire l'upgrade dei cluster di amministrazione e utente da una versione patch GKE On-Prem alla versione successiva più recente. Per informazioni sulle versioni disponibili, consulta Versioni.

Vedi anche:

• Download
• Note di rilascio
• Upgrade della workstation di amministrazione

Panoramica

GKE On-Prem supporta l'upgrade sequenziale. Ad esempio, supponiamo che siano le uniche versioni esistenti:

• 1,0
• 1.0.X, dove X è arrivato dopo 0 .10
• 1.0.Y, dove Y è arrivato dopo la X

In questo caso, 1.0.Y è l'ultima versione. Per eseguire l'upgrade di un cluster dalla versione 1.0.10 alla versione 1.0.Y, segui questi passaggi:

1. Esegui l'upgrade del cluster da 1.0.10 a 1.0.X.
2. Quindi, esegui l'upgrade del cluster da 1.0.X a 1.0.Y.

Prima di iniziare

1. Accedi tramite SSH alla workstation di amministrazione:

   ssh -i ~/.ssh/vsphere_workstation ubuntu@[IP_ADDRESS]
   

2. Autorizza gcloud ad accedere a Google Cloud:

   gcloud auth login

3. Attiva il tuo account di servizio di accesso:

   gcloud auth activate-service-account --project [PROJECT_ID] \
   --key-file [ACCESS_KEY_FILE]
   

   dove:

   • [PROJECT_ID] è l'ID progetto.
   • [ACCESS_KEY_FILE] è il percorso del file della chiave JSON del tuo account di servizio di accesso, ad esempio /home/ubuntu/access.json.

Upgrade alla versione 1.0.2

Nella versione 1.0.2-gke.3 sono stati aggiunti i seguenti campi OIDC (usercluster.oidc). Questi campi consentono di accedere a un cluster da Cloud Console:

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

Se non vuoi accedere a un cluster da Cloud Console, ma vuoi utilizzare OIDC, puoi trasferire i valori segnaposto per i seguenti campi:

oidc:
  kubectlredirecturl: "redirect.invalid"
  clientsecret: "secret"
  usehttpproxy: "false"

Determinazione dello scenario di upgrade del cluster in corso...

Prima di eseguire l'upgrade del cluster, decidi quale di questi scenari è pertinente alla versione a cui stai eseguendo l'upgrade:

Scenario	Azione richiesta	Note
La versione non contiene aggiornamenti della sicurezza.	Scarica la versione più recente di gkectl. Scarica l'ultimo bundle. Segui le istruzioni riportate in questa pagina.
La versione ha aggiornamenti della sicurezza.	Scarica l'OVA della workstation di amministrazione più recente. Esegui l'upgrade della workstation di amministrazione. Segui le istruzioni riportate in questa pagina.	Devi eseguire l'upgrade della workstation di amministrazione solo se la nuova versione ha aggiornamenti di sicurezza. L'upgrade della workstation di amministrazione include l'ultimo gkectl e il pacchetto più recente.

Stabilire la versione della piattaforma

Per eseguire l'upgrade dei cluster, devi determinarne la versione della piattaforma:

Dalla documentazione

Vedi Versioni.

Da bundle

Esegui il comando seguente per estrarre il bundle in una directory temporanea:

tar -xvzf /var/lib/gke/bundles/gke-onprem-vsphere-[VERSION].tgz -C [TEMP_DIR]

Esamina i file YAML estratti per farti un'idea generale di cosa c'è nel pacchetto.

In particolare, apri gke-onprem-vsphere-[VERSION]-images.yaml. Esamina il campo osimages. Puoi vedere la versione della piattaforma GKE nel nome del file immagine del sistema operativo. Ad esempio, nella seguente immagine del sistema operativo, puoi vedere che la versione della piattaforma GKE è 1.12.7-gke.19.

osImages:
  admin: "gs://gke-on-prem-os-ubuntu-release/gke-on-prem-osimage-1.12.7-gke.19-20190516-905ef43658.ova"

Modificare il file di configurazione

Sulla VM della tua workstation di amministrazione, modifica il file di configurazione. Imposta i valori di gkeplatformversion e bundlepath. Ad esempio:

gkeplatformversion: 1.12.7-gke.19
bundlepath: /var/lib/gke/bundles/gke-onprem-vsphere-1.0.10.tgz

Preparazione di gkectl in corso

Esegui questo comando:

gkectl prepare --config [CONFIG_FILE]

Il comando gkectl prepare esegue le seguenti attività:

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

• Esegui il push delle immagini Docker aggiornate, specificate nel nuovo bundle, al tuo registro Docker, se ne hai configurato uno.

Upgrade dei cluster

Per eseguire l'upgrade di un cluster utente, il cluster di amministrazione deve avere una versione almeno pari a quella dell'upgrade del cluster utente. Se la tua versione del cluster di amministrazione non è così elevata, esegui l'upgrade del cluster prima di eseguire l'upgrade del cluster utente.

Cluster di amministrazione

Esegui questo comando:

gkectl upgrade admin \
--kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
--config [CONFIG_FILE]

dove [ADMIN_CLUSTER_KUBECONFIG] è il file di amministrazione del cluster di amministrazione e [CONFIG_FILE] è il file di configurazione di GKE On-Prem che stai utilizzando per eseguire l'upgrade.

Cluster utente

Esegui questo comando:

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

dove [ADMIN_CLUSTER_KUBECONFIG] è il file di kubeconfig del cluster di amministrazione, [CLUSTER_NAME] è il nome del cluster utente di cui stai eseguendo l'upgrade e [CONFIG_FILE] è il file di configurazione di GKE On-Prem che stai utilizzando per eseguire l'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à.

Problemi noti

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

Risolvere i problemi

Per ulteriori informazioni, consulta la sezione Risoluzione dei problemi.

Nuovi nodi creati ma non integri

Sintomi

I nuovi nodi non si registrano al piano di controllo del cluster utente quando utilizzi la modalità di bilanciamento del carico manuale.

Cause possibili

La convalida Ingress in nodo 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 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