Questa pagina è stata tradotta dall'API Cloud Translation.

Saltare una versione durante l'upgrade dei pool di nodi

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 superiori rispetto ai pool di nodi nel 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 ti consente di saltare una versione secondaria durante l'upgrade dei pool di nodi. Utilizzando l'esempio precedente, puoi eseguire l'upgrade dei node pool alla versione 1.16 direttamente alla versione 1.29 e saltare l'upgrade alla versione 1.28. L'omissione di una versione secondaria durante l'upgrade dei node pool è definita upgrade con salto di versione.

Questa pagina illustra alcuni dei vantaggi di un upgrade con salto di versione e fornisce i passaggi su come 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 sottostante. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti, consulta Ruoli utente e attività comuni di GKE. Google Cloud Questa pagina presuppone che tu abbia una certa familiarità con la pianificazione e l'esecuzione degli upgrade di Google Distributed Cloud, come descritto di seguito:

Limitazioni

Gli upgrade con salto di versione presentano le seguenti limitazioni:

Gli upgrade con salto di versione sono supportati per i node pool Ubuntu e COS, ma non per i node pool Windows.
Versione 1.31: questa funzionalità non è disponibile sui cluster avanzati.
Versione 1.32 e successive: questa funzionalità è disponibile sui cluster avanzati.
A causa dei vincoli di Kubernetes, il control plane di un cluster utente deve essere sottoposto a upgrade di una versione secondaria alla volta. Tieni presente, tuttavia, che l'upgrade del solo control plane richiede molto meno tempo ed è meno rischioso rispetto all'upgrade dei node pool in cui vengono eseguiti i carichi di lavoro.

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. Per mantenere i cluster all'interno della finestra supportata, devi eseguire un upgrade della versione secondaria circa ogni quattro mesi, come mostrato di seguito:

dic

Gen

Feb

Mar

Apr

Mag

Giu

Lug

Ago

Set

Ott

Nov

Dic

Gen

Feb

Mar

Apr

Mag

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 pone delle sfide quando hai bisogno di una lunga finestra di convalida per verificare una nuova versione secondaria e di una breveperiodo di manutenzionee per eseguire l'upgrade dei cluster alla nuova versione secondaria. Per superare queste sfide, puoi utilizzare un aggiornamento con salto di versione, che consente ai cluster di rimanere all'interno della finestra supportata eseguendo l'upgrade di un cluster ogni otto mesi anziché ogni quattro mesi. La tabella seguente mostra come saltare l'upgrade alla versione 1.15 significa eseguire l'upgrade solo dopo otto mesi anziché quattro.

dic

Gen

Feb

Mar

Apr

Mag

Giu

Lug

Ago

Set

Ott

Nov

Dic

Gen

Feb

Mar

Apr

Mag

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, riduci il numero di upgrade necessari per continuare a utilizzare una versione supportata. Inoltre, non è necessario qualificare la versione secondaria ignorata perché viene utilizzata solo temporaneamente dal control plane.

Periodo di manutenzione più breve

Con un upgrade con salto di versione, non è necessario ampliare la periodo di manutenzione. L'omissione di una versione secondaria durante l'upgrade dei node pool richiede lo stesso tempo dell'upgrade dei node pool alla versione secondaria successiva, perché ogni nodo di un pool di nodi viene svuotato e ricreato una volta. Pertanto, un upgrade con salto di versione consente di risparmiare tempo complessivamente e riduce le interruzioni del workload.

Riepilogo

In sintesi, un upgrade con salto di versione offre i seguenti vantaggi:

Porta i 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 dei node pool potrebbe consentire di portare i cluster a una versione supportata con meno upgrade.
Risparmia tempo: saltare una versione secondaria durante l'upgrade dei node pool richiede lo stesso tempo necessario per eseguire l'upgrade dei node pool 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 una sola finestra di convalida, rispetto alle due degli upgrade regolari.
Riduzione delle interruzioni: intervalli più lunghi tra gli upgrade e meno tempo dedicato all'upgrade e alla convalida significano che i tuoi workload vengono eseguiti più a lungo con meno interruzioni.

Controllo delle versioni del control plane 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 dal campo gkeOnPremVersion di primo livello. Modificando il valore del campo nodePools[i].gkeOnPremVersion, controlli 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, i pool di nodi vengono sottoposti all'upgrade alla stessa versione di destinazione specificata in gkeOnPremVersion.

Regole di versione

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 a quella del cluster di amministrazione. La versione patch non è importante. Ad esempio, se un cluster utente ha la versione 1.30.1, il cluster di amministrazione può essere aggiornato a una versione patch superiore, 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 ha la versione 1.31.1, la versione più recente a cui è possibile eseguire l'upgrade del cluster utente è la 1.31.1.

Quando vuoi eseguire l'upgrade dei cluster alla versione 1.31, devi prima portare 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 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 di cui stai eseguendo l'upgrade, denominata versione di destinazione:

1.32 e successive

Utilizza questa sequenza se la versione di destinazione è 1.32 o successive. 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 con salto di versione funziona nel seguente modo:

Esegui l'upgrade del cluster di amministrazione dalla versione 1.N a una versione intermedia, 1.N+1.
Esegui l'upgrade del cluster di amministrazione dalla versione intermedia 1.N+1 alla versione di destinazione 1.N+2.
Esegui l'upgrade solo del control plane del cluster utente dalla versione di origine, 1.N, a una versione intermedia, 1.N+1. Lascia i node pool nella versione di origine. La versione intermedia è necessaria perché è necessario eseguire l'upgrade del control plane di una versione secondaria alla volta.
Esegui l'upgrade del control plane e dei pool di nodi alla versione di destinazione, 1.N+2.

1,31

Utilizza questa sequenza speciale se il cluster utente è alla versione 1.29, il che significa che la versione di destinazione è 1.31. Se 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 cluster di amministrazione è alla versione 1.28, esegui l'upgrade alla versione 1.29.
Esegui l'upgrade solo del control plane 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é il control plane deve essere aggiornato 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 di destinazione, 1.31.
Esegui l'upgrade del control plane del cluster utente e dei pool di nodi alla versione di destinazione 1.31.

1,30 e inferiore

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 si trovino alla versione secondaria 1.N. A livello generale, l'upgrade del cluster da 1.N a 1.N+2 utilizzando un upgrade con salto di versione funziona nel seguente modo:

Esegui l'upgrade solo del control plane dalla versione di origine, 1.N, a una versione intermedia 1.N+1. Lascia i node pool nella versione di origine. La versione intermedia è necessaria perché è necessario eseguire l'upgrade del control plane di una versione secondaria alla volta.
Esegui l'upgrade del control plane e dei pool di nodi alla versione di destinazione 1.N+2.

Esegui un upgrade con salto di versione

Questa sezione fornisce 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 la versione 1.16 o successive. 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 abilitati per impostazione predefinita. Assicurati di rivedere le regole firewall per apportare le modifiche necessarie.
Per eseguire l'upgrade alla versione 1.28 e successive, devi attivare kubernetesmetadata.googleapis.com e concedere il ruolo IAM kubernetesmetadata.publisher al service account logging-monitoring. Per maggiori dettagli, vedi Requisiti di Google API e 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.

Se un cluster utente è alla versione 1.29, un cluster di amministrazione che lo gestisce potrebbe essere alla versione 1.27, 1.28 o 1.29.

Se il cluster di amministrazione è alla versione 1.27, segui i passaggi per eseguire l'upgrade della workstation di amministrazione e l'upgrade del cluster di amministrazione alla versione 1.28.
Se il cluster di amministrazione è alla versione 1.28, segui i passaggi per eseguire l'upgrade della workstation di amministrazione e aggiornare il 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 con salto di 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 esempio 1.29.700-gke.110.

Versione
Ottieni la versione 1.29 del cluster utente corrente. Questa è la versione dell'origine.	`SOURCE_VERSION`
Scegli una versione intermedia 1.30.	`INTERMEDIATE_VERSION`
Scegli la versione di destinazione 1.31. Seleziona la patch consigliata dalla versione secondaria 1.31.	`TARGET_VERSION`

Esegui l'upgrade della workstation di amministrazione alla versione intermedia 1.30, INTERMEDIATE_VERSION. Attendi un messaggio che indica 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_KUBECONFIG

Esegui di nuovo l'upgrade della workstation di amministrazione, ma questa volta alla versione di destinazione 1.31, TARGET_VERSION. Attendi un messaggio che indica 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_KUBECONFIG

Esegui l'upgrade solo del control plane del cluster utente alla versione intermedia come segue:
1. Apporta le seguenti modifiche al file di configurazione del cluster utente:
  - Imposta il campo gkeOnPremVersion sulla versione intermedia, INTERMEDIATE_VERSION.
  - Imposta tutte le versioni pool di nodi in nodePools[i].gkeOnPremVersion sulla versione di origine, SOURCE_VERSION.
  Dopo l'aggiornamento, il file di configurazione dovrebbe essere simile al seguente:
```
gkeOnPremVersion: INTERMEDIATE_VERSION
...
nodePools:
- name: pool-1
  gkeOnPremVersion: SOURCE_VERSION
  ...
- name: pool-2
  gkeOnPremVersion: SOURCE_VERSION
  ...
```
2. Esegui l'upgrade del control plane:
```
gkectl upgrade cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE
```
  Sostituisci USER_CLUSTER_CONFIG con il percorso del file di configurazione del cluster utente.
Imposta il campo bundlePath nel 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_FILE

Imposta il campo bundlePath nel file di configurazione del cluster di amministrazione sulla versione 1.31 di destinazione 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_FILE

Esegui l'upgrade del control plane e dei pool di nodi alla versione di destinazione come segue:
1. Apporta le seguenti modifiche al file di configurazione del cluster utente:
  - Imposta il campo gkeOnPremVersion sulla versione di destinazione, TARGET_VERSION.
  - Imposta tutti i nodePools[i].gkeOnPremVersion su una stringa vuota.
  Dopo l'aggiornamento, il file di configurazione dovrebbe essere simile al seguente:
```
gkeOnPremVersion: TARGET_VERSION
...
nodePools:
- name: pool-1
  gkeOnPremVersion: ""
  ...
- name: pool-2
  gkeOnPremVersion: ""
  ...
```
2. Esegui l'upgrade del control plane e dei node pool:
```
gkectl upgrade cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE
```

1,30 e inferiore

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 formato x.y.z-gke.N, ad esempio 1.16.11-gke.25.

Versione
Ottieni la versione attuale del cluster. Questa è la versione di origine (`1.N`).	`SOURCE_VERSION`
Scegli una versione intermedia (`1.N+1`).	`INTERMEDIATE_VERSION`
Scegli la versione di destinazione (`1.N+2`). Seleziona la patch consigliata dalla versione secondaria di destinazione.	`TARGET_VERSION`

Esegui l'upgrade della workstation di amministrazione alla versione intermedia, INTERMEDIATE_VERSION. Attendi un messaggio che indica 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_KUBECONFIG

Sostituisci ADMIN_CLUSTER_KUBECONFIG con il percorso del file kubeconfig del cluster di amministrazione.

Esegui di nuovo l'upgrade della workstation di amministrazione, ma questa volta alla versione di destinazione, TARGET_VERSION. Attendi un messaggio che indica 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_KUBECONFIG

Esegui l'upgrade solo del control plane alla versione intermedia nel seguente modo:
1. Apporta le seguenti modifiche al file di configurazione del cluster utente:
  - Imposta il campo gkeOnPremVersion sulla versione intermedia, INTERMEDIATE_VERSION.
  - Imposta tutte le versioni pool di nodi in nodePools[i].gkeOnPremVersion sulla versione di origine, SOURCE_VERSION.
  Dopo l'aggiornamento, il file di configurazione dovrebbe essere simile al seguente:
```
gkeOnPremVersion: INTERMEDIATE_VERSION
...
nodePools:
- name: pool-1
  gkeOnPremVersion: SOURCE_VERSION
  ...
- name: pool-2
  gkeOnPremVersion: SOURCE_VERSION
  ...
```
2. Esegui l'upgrade del control plane:
```
gkectl upgrade cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE
```
  Sostituisci USER_CLUSTER_CONFIG con 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:
1. Apporta le seguenti modifiche al file di configurazione del cluster utente:
  - Imposta il campo gkeOnPremVersion sulla versione di destinazione, TARGET_VERSION.
  - Imposta tutti i nodePools[i].gkeOnPremVersion su una stringa vuota.
  Dopo l'aggiornamento, il file di configurazione dovrebbe essere simile al seguente:
```
gkeOnPremVersion: TARGET_VERSION
...
nodePools:
- name: pool-1
  gkeOnPremVersion: ""
  ...
- name: pool-2
  gkeOnPremVersion: ""
  ...
```
2. Esegui l'upgrade del control plane e dei node pool:
```
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

Saltare una versione durante l'upgrade dei pool di nodi Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Limitazioni

Vantaggi degli upgrade con salto di versione

Più facile mantenere i cluster in una versione supportata

Periodo di manutenzione più breve

Riepilogo

Controllo delle versioni del control plane e del pool di nodi durante un upgrade

Regole di versione

Sequenza di upgrade con salto di versione

1.32 e successive

1,31

1,30 e inferiore

Esegui un upgrade con salto di versione

Prima di iniziare

Esegui l'upgrade

1,31

1,30 e inferiore

Passaggi successivi

Saltare una versione durante l'upgrade dei pool di nodi