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 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 in 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 solo per i pool di nodi Ubuntu e COS. 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 degli 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 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 aumentare 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.

Sequenza di upgrade con salto di versione

Supponiamo che il piano di controllo del cluster e tutti i pool di nodi siano alla versione secondaria1.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:

  1. 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 piano di controllo una versione secondaria alla volta.
  2. 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

  1. 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).

  2. 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.

  3. Per eseguire l'upgrade alla versione 1.28 e successive, devi attivare kubernetesmetadata.googleapis.com e concedere il ruolo IAM kubernetesmetadata.publisher all'account di servizio logging-monitoring. Per maggiori dettagli, consulta Requisiti dell'API Google e di IAM.

Esegui l'upgrade

  1. 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 corrente 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

  2. Esegui l'upgrade della workstation di amministrazione alla versione intermedia,INTERMEDIATE_VERSION. Attendi un messaggio che ti indichi che l'upgrade è stato eseguito correttamente.

  3. 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 amministrativo.

  4. 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.

  5. Installa il bundle corrispondente:

    gkectl prepare \
    --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

  6. Esegui l'upgrade solo del control plane 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 del pool di nodi in nodePools[i].gkeOnPremVersion sulla 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
  ...

    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.

  7. 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 valori nodePools[i].gkeOnPremVersion su 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: ""
  ...

    2. Esegui l'upgrade del control plane e dei pool di nodi:

      gkectl upgrade cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE

Passaggi successivi