Nella versione 1.29 e successive, Google Distributed Cloud consente al piano di controllo di un cluster utente di essere fino a due versioni secondarie superiore ai pool di nodi del cluster. Ad esempio, se il control plane di un cluster utente è alla versione 1.29, i pool di nodi nel cluster possono essere alla versione 1.16, 1.28 o 1.29. Inoltre, Google Distributed Cloud consente di saltare una versione secondaria durante l'upgrade dei pool di nodi. Utilizzando l'esempio precedente, puoi eseguire l'upgrade dei pool di nodi che utilizzano la versione 1.16 direttamente alla versione 1.29 e saltare l'upgrade alla versione 1.28. Il salto di una versione secondaria durante l'upgrade dei node pool è definito upgrade con salto di versione.
Gli upgrade che ignorano le versioni sono supportati per i pool di nodi Ubuntu e COS, ma non per i pool di nodi Windows. Inoltre, questa funzionalità non è disponibile se hai abilitato i cluster avanzati.
A causa dei vincoli di Kubernetes, è necessario eseguire l'upgrade del piano di controllo di un cluster utente una versione secondaria alla volta. Tieni presente, tuttavia, che l'upgrade solo del piano di controllo richiede molto meno tempo ed è meno rischioso rispetto all'upgrade dei pool di nodi in cui vengono eseguiti i carichi di lavoro.
Questa pagina illustra alcuni dei vantaggi di un upgrade con salto di versione e fornisce i passaggi per eseguire un upgrade con salto di versione apportando modifiche al file di configurazione ed eseguendo gkectl upgrade cluster.
Questa pagina è rivolta agli amministratori IT e agli operatori che gestiscono il ciclo di vita dell'infrastruttura tecnologica di base. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti di Google Cloud , consulta Ruoli e attività comuni per gli utenti di GKE Enterprise. Questa pagina presuppone che tu abbia una certa familiarità con la pianificazione ed esecuzione degli upgrade di Google Distributed Cloud come descritto di seguito:
Vantaggi degli upgrade con salto di versione
Questa sezione descrive alcuni vantaggi dell'utilizzo degli upgrade con salto di versione.
È più facile mantenere i cluster in una versione supportata
Ogni quattro mesi viene rilasciata una nuova versione secondaria di Google Distributed Cloud e ogni versione secondaria ha un periodo di supporto di un anno. Affinché i tuoi cluster rimangano all'interno della finestra supportata, devi eseguire un upgrade di una versione secondaria ogni circa quattro mesi, come mostrato di seguito:
dic |
gen |
feb |
mar |
apr |
Maggio |
giu |
lug |
ago |
set |
ott |
nov |
dic |
gen |
feb |
mar |
apr |
Maggio |
giu |
lug |
ago |
set |
ott |
nov |
dic |
gen |
feb |
mar |
| 1,14 | Esegui l'upgrade | ||||||||||||||||||||||||||
| 1,15 | Esegui l'upgrade | ||||||||||||||||||||||||||
| 1.16 | Esegui l'upgrade | ||||||||||||||||||||||||||
| 1,28 | Esegui l'upgrade | ||||||||||||||||||||||||||
| 1,29 | Esegui l'upgrade |
Questo requisito comporta delle difficoltà quando è necessaria una finestra di convalida lunga per verificare una nuova versione secondaria e una periodo di manutenzione breve per eseguire l'upgrade dei cluster alla nuova versione secondaria. Per superare queste sfide, puoi utilizzare un upgrade con salto di versione, che consente ai tuoi cluster di rimanere nel periodo supportato eseguendo l'upgrade di un cluster ogni otto mesi anziché ogni quattro mesi. La tabella seguente mostra che se salti l'upgrade alla versione 1.15, l'upgrade verrà eseguito solo dopo otto mesi anziché quattro.
dic |
gen |
feb |
mar |
apr |
Maggio |
giu |
lug |
ago |
set |
ott |
nov |
dic |
gen |
feb |
mar |
apr |
Maggio |
giu |
lug |
ago |
set |
ott |
nov |
dic |
gen |
feb |
mar |
| 1,14 | Esegui l'upgrade | ||||||||||||||||||||||||||
| 1,15 | |||||||||||||||||||||||||||
| 1.16 | Esegui l'upgrade | ||||||||||||||||||||||||||
| 1,28 | |||||||||||||||||||||||||||
| 1,29 |
Se salti una versione secondaria durante l'upgrade dei node pool, il numero di upgrade necessari per continuare a utilizzare una versione supportata si riduce. Inoltre, non è necessario qualificare la versione secondaria saltata perché viene utilizzata temporaneamente solo dal piano di controllo.
Periodo di manutenzione più breve
Con un upgrade con salto di versione, non è necessario allargare la periodo di manutenzione. Saltare una versione minore durante l'upgrade dei pool di nodi richiede lo stesso tempo dell'upgrade dei pool di nodi alla versione minore successiva perché ogni nodo in un pool di nodi viene svuotato e ricreato una volta. Pertanto, un upgrade con salto di versione consente di risparmiare tempo in generale e di ridurre l'interruzione del carico di lavoro.
Riepilogo
In sintesi, un upgrade con salto di versione offre i seguenti vantaggi:
Eseguire l'upgrade dei cluster a una versione supportata: Google Distributed Cloud supporta le tre versioni secondarie più recenti. Se i tuoi cluster utilizzano una versione non supportata, a seconda della versione del cluster, saltare una versione secondaria durante l'upgrade delle pool di nodi potrebbe consentire di eseguire l'upgrade dei cluster a una versione supportata con meno upgrade.
Risparmia tempo: saltare una versione secondaria durante l'upgrade dei pool di nodi richiede la stessa quantità di tempo dell'upgrade dei pool di nodi alla versione secondaria successiva. Pertanto, un upgrade con salto di versione richiede circa la metà del tempo necessario per eseguire l'upgrade dei pool di nodi due volte. Analogamente, con un upgrade con salto di versione hai solo una finestra di convalida, rispetto a due con gli upgrade regolari.
Riduci le interruzioni: intervalli più lunghi tra gli upgrade e meno tempo impiegato per l'upgrade e la convalida significano che i carichi di lavoro vengono eseguiti più a lungo con meno interruzioni.
Controllo delle versioni del piano di controllo e del pool di nodi durante un upgrade
Nel file di configurazione del cluster utente, il campo
nodePools[i].gkeOnPremVersion
consente a un pool di nodi specifico di utilizzare una versione diversa da quella del campo
gkeOnPremVersion
di primo livello. Modificando il valore del campo nodePools[i].gkeOnPremVersion, puoi controllare quando viene eseguito l'upgrade di un pool di nodi quando esegui gkectl upgrade cluster.
Se non includi nodePools[i].gkeOnPremVersion nel file di configurazione o se imposti il campo su una stringa vuota, viene eseguito l'upgrade dei pool di nodi alla stessa versione di destinazione specificata in gkeOnPremVersion.
Regole Verson
Le regole per gli upgrade dipendono dalla versione secondaria del cluster.
Per le versioni 1.30 e precedenti, la versione secondaria del cluster utente deve essere maggiore o uguale alla versione secondaria del cluster di amministrazione. La versione del patch non è importante. Ad esempio, se un cluster utente è alla versione 1.30.1, è possibile eseguire l'upgrade del cluster di amministrazione a una versione patch successiva, ad esempio 1.30.3.
Per le versioni 1.31 e successive, la versione del cluster di amministrazione, inclusa la versione della patch, deve essere maggiore o uguale alla versione del cluster utente. Ad esempio, se un cluster di amministrazione è alla versione 1.31.1, la versione massima a cui è possibile eseguire l'upgrade del cluster utente è 1.31.1.
Quando vuoi eseguire l'upgrade dei cluster alla versione 1.31, devi prima eseguire l'upgrade di tutti i cluster alla versione 1.30. Dopo che tutti i cluster sono alla versione 1.30, esegui l'upgrade del cluster di amministrazione alla versione 1.31. Dopodiché, puoi eseguire l'upgrade dei cluster utente alla stessa versione della patch 1.31 del cluster di amministrazione.
Sequenza di upgrade con salto di versione
La sequenza in cui esegui l'upgrade dei cluster di amministrazione e utente dipende dalla versione del cluster a cui esegui l'upgrade, indicata come versione di destinazione:
1,31
Utilizza questa sequenza speciale se il cluster utente è alla versione 1.29, il che significa che la versione di destinazione è 1.31. Quando un cluster utente è alla versione 1.29, un cluster di amministrazione che gestisce il cluster utente potrebbe essere alla versione 1.27, 1.28 o 1.29.
- Se il cluster di amministrazione è alla versione 1.27, esegui l'upgrade alla versione 1.28.
- Se il tuo cluster di amministrazione è alla versione 1.28, esegui l'upgrade alla versione 1.29.
- Esegui l'upgrade solo del piano di controllo del cluster utente dalla versione di origine 1.29 a una versione intermedia 1.30. Lascia i node pool nella versione di origine. La versione intermedia 1.30 è necessaria perché è necessario eseguire l'upgrade del piano di controllo una versione secondaria alla volta.
- Esegui l'upgrade del cluster di amministrazione dalla versione 1.29 alla versione intermedia 1.30.
- Esegui l'upgrade del cluster di amministrazione alla versione target 1.31.
- Esegui l'upgrade del piano di controllo e dei pool di nodi del cluster utente alla versione di destinazione 1.31.
1,30 o meno
Utilizza questa sequenza se la versione di destinazione è 1.30 o precedente.
Supponiamo che il control plane del cluster utente e tutti i pool di nodi siano alla versione secondaria 1.N. A livello generale, l'upgrade del cluster da
1.N a 1.N+2 utilizzando un upgrade che salta la versione funziona
come segue:
- Esegui l'upgrade solo del control plane dalla versione di origine
1.Na una versione intermedia1.N+1. Lascia i node pool nella versione di origine. La versione intermedia è necessaria perché l'upgrade del piano di controllo deve essere eseguito una versione secondaria alla volta. - Esegui l'upgrade del control plane e dei pool di nodi alla versione di destinazione
1.N+2.
Eseguire un upgrade con salto di versione
Questa sezione illustra i passaggi per eseguire un upgrade con salto di versione.
Prima di iniziare
Assicurati che la versione corrente (la versione di origine) del cluster sia almeno 1.16. Assicurati di controllare la versione del control plane (
gkeOnPremVersion) e di tutti i node pool (nodePools[i].gkeOnPremVersion).Nella versione 1.29 e successive, i controlli preflight lato server sono attivati per impostazione predefinita. Assicurati di esaminare le regole del firewall per apportare le modifiche necessarie.
Per eseguire l'upgrade alla versione 1.28 e successive, devi attivare
kubernetesmetadata.googleapis.come concedere il ruolo IAMkubernetesmetadata.publisherall'account di servizio logging-monitoring. Per maggiori dettagli, consulta Requisiti dell'API Google e di IAM.
Esegui l'upgrade
1,31
Utilizza questa sequenza speciale se il cluster utente è alla versione 1.29, il che significa che la versione di destinazione è 1.31. Questa sequenza è necessaria perché le regole di versione sono cambiate nella versione 1.31.
Quando un cluster utente è alla versione 1.29, un cluster di amministrazione che gestisce il cluster utente potrebbe essere alla versione 1.27, 1.28 o 1.29.
Se il tuo cluster di amministrazione è alla versione 1.27, segui i passaggi per eseguire l'upgrade della workstation di amministrazione e del cluster di amministrazione alla versione 1.28.
Se il tuo cluster di amministrazione è alla versione 1.28, segui i passaggi per eseguire l'upgrade della workstation di amministrazione e del cluster di amministrazione alla versione 1.29.
Per risparmiare spazio sulla workstation di amministrazione, rimuovi i bundle scaricati:
rm /var/lib/gke/bundles/gke-onprem-vsphere-*.tgz
Quando il cluster di amministrazione e tutti i cluster utente sono alla versione 1.29, puoi avviare l'upgrade che salta la versione.
Definisci la versione di origine (1.29), una versione intermedia (1.30) e la versione di destinazione (1.31) nelle seguenti variabili segnaposto. Tutte le versioni devono essere il numero di versione completo nel formato
x.y.z-gke.N, ad esempio1.29.700-gke.110.Versione Ottieni la versione 1.29 del cluster utente corrente. Questa è la versione di origine. SOURCE_VERSIONScegli una versione intermedia 1.30. INTERMEDIATE_VERSIONScegli la versione di destinazione 1.31. Seleziona la patch consigliata dalla versione minore 1.31. TARGET_VERSIONEsegui l'upgrade della workstation di amministrazione alla versione intermedia 1.30,
INTERMEDIATE_VERSION. Attendi un messaggio che ti indichi che l'upgrade è stato eseguito correttamente.Installa il bundle corrispondente:
gkectl prepare \ --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-INTERMEDIATE_VERSION.tgz \ --kubeconfig ADMIN_CLUSTER_KUBECONFIGEsegui di nuovo l'upgrade della workstation di amministrazione, ma questa volta alla versione di destinazione 1.31,
TARGET_VERSION. Attendi un messaggio che ti indichi che l'upgrade è stato eseguito correttamente.Installa il bundle corrispondente:
gkectl prepare \ --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \ --kubeconfig ADMIN_CLUSTER_KUBECONFIGEsegui l'upgrade solo del piano di controllo del cluster utente alla versione intermedia come segue:
Apporta le seguenti modifiche al file di configurazione del cluster utente:
Imposta il campo
gkeOnPremVersionsulla versione intermedia,INTERMEDIATE_VERSION.Imposta tutte le versioni del pool di nodi in
nodePools[i].gkeOnPremVersionsulla versione di origine,SOURCE_VERSION.
Dopo aver aggiornato il file di configurazione, dovrebbe avere il seguente aspetto:
gkeOnPremVersion: INTERMEDIATE_VERSION ... nodePools: - name: pool-1 gkeOnPremVersion: SOURCE_VERSION ... - name: pool-2 gkeOnPremVersion: SOURCE_VERSION ...
Esegui l'upgrade del control plane:
gkectl upgrade cluster \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config USER_CLUSTER_CONFIG_FILESostituisci
USER_CLUSTER_CONFIGcon il percorso del file di configurazione del cluster utente.
Imposta il campo
bundlePathnel file di configurazione del cluster di amministrazione sulla versione intermedia 1.30 del bundle:bundlePath="/var/lib/gke/bundles/gke-onprem-vsphere-INTERMEDIATE_VERSION.tgz"
Esegui l'upgrade del cluster di amministrazione alla versione intermedia 1.30:
gkectl upgrade admin \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config ADMIN_CLUSTER_CONFIG_FILEImposta il campo
bundlePathnel file di configurazione del cluster di amministrazione sulla versione di destinazione 1.31 del bundle:bundlePath="/var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz"
Upgrade the admin cluster to the target 1.31 version:
gkectl upgrade admin \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config ADMIN_CLUSTER_CONFIG_FILEEsegui l'upgrade del control plane e dei pool di nodi alla versione di destinazione come segue:
Apporta le seguenti modifiche al file di configurazione del cluster utente:
Imposta il campo
gkeOnPremVersionsulla versione di destinazione,TARGET_VERSION.Imposta tutti i valori
nodePools[i].gkeOnPremVersionsu una stringa vuota.
Dopo aver aggiornato il file di configurazione, dovrebbe avere il seguente aspetto:
gkeOnPremVersion: TARGET_VERSION ... nodePools: - name: pool-1 gkeOnPremVersion: "" ... - name: pool-2 gkeOnPremVersion: "" ...
Esegui l'upgrade del control plane e dei pool di nodi:
gkectl upgrade cluster \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config USER_CLUSTER_CONFIG_FILE
1,30 o meno
Utilizza questa sequenza se la versione di destinazione è 1.30 o precedente.
Definisci la versione di origine (
1.N), la versione intermedia (1.N+1) e la versione di destinazione (1.N+2) nelle seguenti variabili segnaposto. Tutte le versioni devono essere il numero di versione completo nel formatox.y.z-gke.N, ad esempio1.16.11-gke.25.Versione Ottieni la versione corrente del cluster. Questa è la versione di origine ( 1.N).SOURCE_VERSIONScegli una versione intermedia ( 1.N+1).INTERMEDIATE_VERSIONScegli la versione di destinazione ( 1.N+2). Seleziona la patch consigliata dalla versione secondaria di destinazione.TARGET_VERSIONEsegui l'upgrade della workstation di amministrazione alla versione intermedia,
INTERMEDIATE_VERSION. Attendi un messaggio che ti indichi che l'upgrade è stato eseguito correttamente.Installa il bundle corrispondente:
gkectl prepare \ --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-INTERMEDIATE_VERSION.tgz \ --kubeconfig ADMIN_CLUSTER_KUBECONFIGSostituisci
ADMIN_CLUSTER_KUBECONFIGcon il percorso del filekubeconfigdel cluster amministrativo.Esegui di nuovo l'upgrade della workstation di amministrazione, ma questa volta alla versione di destinazione,
TARGET_VERSION. Attendi un messaggio che ti indichi che l'upgrade è stato eseguito correttamente.Installa il bundle corrispondente:
gkectl prepare \ --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \ --kubeconfig ADMIN_CLUSTER_KUBECONFIGEsegui l'upgrade solo del control plane alla versione intermedia come segue:
Apporta le seguenti modifiche al file di configurazione del cluster utente:
Imposta il campo
gkeOnPremVersionsulla versione intermedia,INTERMEDIATE_VERSION.Imposta tutte le versioni del pool di nodi in
nodePools[i].gkeOnPremVersionsulla versione di origine,SOURCE_VERSION.
Dopo aver aggiornato il file di configurazione, dovrebbe avere il seguente aspetto:
gkeOnPremVersion: INTERMEDIATE_VERSION ... nodePools: - name: pool-1 gkeOnPremVersion: SOURCE_VERSION ... - name: pool-2 gkeOnPremVersion: SOURCE_VERSION ...
Esegui l'upgrade del control plane:
gkectl upgrade cluster \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config USER_CLUSTER_CONFIG_FILESostituisci
USER_CLUSTER_CONFIGcon il percorso del file di configurazione del cluster utente.
Esegui l'upgrade del control plane e dei pool di nodi alla versione di destinazione come segue:
Apporta le seguenti modifiche al file di configurazione del cluster utente:
Imposta il campo
gkeOnPremVersionsulla versione di destinazione,TARGET_VERSION.Imposta tutti i valori
nodePools[i].gkeOnPremVersionsu una stringa vuota.
Dopo aver aggiornato il file di configurazione, dovrebbe avere il seguente aspetto:
gkeOnPremVersion: TARGET_VERSION ... nodePools: - name: pool-1 gkeOnPremVersion: "" ... - name: pool-2 gkeOnPremVersion: "" ...
Esegui l'upgrade del control plane e dei pool di nodi:
gkectl upgrade cluster \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config USER_CLUSTER_CONFIG_FILE
Se non hai altri cluster utente di cui eseguire l'upgrade, rimuovi i bundle dalla workstation di amministrazione per risparmiare spazio:
rm /var/lib/gke/bundles/gke-onprem-vsphere-*.tgz