Esegui l'upgrade dei cluster

Quando installi una nuova versione di bmctl, puoi eseguire l'upgrade dei cluster esistenti creati con una versione precedente. L'upgrade di un cluster alla versione più recente di Google Distributed Cloud offre funzionalità e correzioni aggiuntive per il tuo cluster. Inoltre, assicura che il cluster continui a essere supportato. Puoi eseguire l'upgrade dei cluster di amministrazione, ibridi, autonomi o utente con il comando bmctl upgrade cluster oppure puoi utilizzare kubectl.

Per scoprire di più sulla procedura di upgrade e sulle regole di controllo delle versioni, consulta Ciclo di vita e fasi degli upgrade dei cluster.

Questa pagina è rivolta ad amministratori, architetti e 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 di Google Cloud , consulta Ruoli e attività comuni degli utenti GKE.

Pianifica l'upgrade

Questa sezione contiene informazioni e link a informazioni che dovresti considerare prima di eseguire l'upgrade di un cluster. Per ulteriori informazioni sugli upgrade, incluse le regole di controllo delle versioni per cluster e node pool, consulta Ciclo di vita e fasi degli upgrade dei cluster.

Best practice

Per informazioni che ti aiutino a prepararti per un upgrade del cluster, consulta Best practice per gli upgrade dei cluster Google Distributed Cloud.

Controlli preflight per l'upgrade

I controlli preflight vengono eseguiti nell'ambito dell'upgrade del cluster per convalidare lo stato del cluster e l'integrità del nodo. L'upgrade del cluster non procede se i controlli preflight non vanno a buon fine. Per saperne di più sui controlli preflight, consulta Informazioni sui controlli preflight.

Puoi verificare se i cluster sono pronti per un upgrade eseguendo il controllo preflight prima di eseguire l'upgrade. Per saperne di più, consulta Controlli preflight per gli upgrade.

Problemi noti

Per informazioni sui potenziali problemi relativi agli upgrade dei cluster, consulta Problemi noti di Google Distributed Cloud per bare metal e seleziona la categoria di problemi Upgrade e aggiornamenti.

Configura le opzioni di upgrade

Prima di avviare l'upgrade di un cluster, puoi configurare le seguenti opzioni di upgrade che controllano il funzionamento del processo di upgrade:

Queste opzioni possono ridurre il rischio di interruzioni di applicazioni e servizi critici e ridurre in modo significativo il tempo complessivo di upgrade. Queste opzioni sono particolarmente utili per i cluster di grandi dimensioni con numerosi nodi e pool di nodi che eseguono workload importanti. Per saperne di più su cosa fanno queste opzioni e su come utilizzarle, consulta le sezioni seguenti.

Salta gli upgrade

A partire dalla versione 1.33, Google Distributed Cloud supporta gli upgrade con salto per tutti i tipi di cluster, consentendoti di eseguire l'upgrade di un cluster a una versione di destinazione (1.33 o successiva) che è di due versioni secondarie successive rispetto alla versione attuale in un'unica operazione. Ad esempio, puoi eseguire l'upgrade dalla versione 1.N.X direttamente alla versione 1.N+2.Z con un'unica operazione.

Il seguente elenco mostra la fase di lancio di questa funzionalità per versione, dove la versione è la versione target dell'upgrade:

  • 1.34 e versioni successive: GA
  • 1.33: Anteprima
  • 1.32 e versioni precedenti: non disponibile

Gli upgrade con salto ti consentono di accedere alle funzionalità e alle correzioni più recenti più rapidamente rispetto agli upgrade incrementali. I salti degli upgrade possono anche estendere il tempo tra le operazioni di upgrade richieste, riducendo le potenziali interruzioni. Puoi utilizzare gli upgrade con salto insieme ad altre opzioni di upgrade, come gli upgrade selettivi dei pool di nodi worker e gli upgrade paralleli.

Durante un upgrade con salto, il sistema esegue l'upgrade del cluster a una versione secondaria intermedia e poi immediatamente alla versione di destinazione. Questa versione intermedia ha implicazioni se utilizzi un mirror del registry. Per saperne di più, consulta Requisito aggiuntivo per i mirror del registry.

La funzionalità per saltare gli upgrade per i cluster è in anteprima per la versione 1.33. Ti consigliamo di non eseguire upgrade con salto dalla versione 1.31 alla 1.33 con i cluster di produzione.

Salta i prerequisiti per l'upgrade

La procedura per eseguire un upgrade con salto non è diversa da quella per eseguire un upgrade sequenziale, ma esistono alcuni prerequisiti aggiuntivi:

  1. Verifica che il cluster si trovi in uno stato in cui un upgrade con salto non viola le regole relative alle versioni del cluster e dei node pool:

    • Prima di avviare un upgrade con salto per un cluster di amministrazione o ibrido, assicurati che tutti i cluster utente gestiti abbiano la stessa versione secondaria del cluster di gestione.

    • Prima di avviare un upgrade con salto per un cluster utente, assicurati che i tuoi cluster soddisfino i seguenti criteri:

      • Il cluster di amministrazione o ibrido di gestione associato è di due versioni secondarie superiore rispetto al cluster utente.

      • Tutti i pool di nodi worker per il cluster utente hanno la stessa versione secondaria del cluster utente.

  2. Aggiungi l'annotazione preview.baremetal.cluster.gke.io/skip-minor-version-cluster-upgrade al file di configurazione del cluster:

    apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: baremetal-demo
  namespace: cluster-baremetal-demo
  annotations:
    preview.baremetal.cluster.gke.io/skip-minor-version-cluster-upgrade: "enable"
spec:
  type: user
  profile: default
  anthosBareMetalVersion:   1.36.200-gke.118
  ...

  3. Aggiorna anthosBareMetalVersion nel file di configurazione del cluster alla versione di destinazione dell'upgrade che vuoi saltare.

Come per gli upgrade sequenziali, puoi avviare l'upgrade con salto con bmctl upgrade cluster o kubectl apply.

Requisito aggiuntivo per i mirror del registry

Se esegui il pull delle immagini container da un mirror del registry per eseguire l'upgrade del cluster, il mirror del registry deve contenere le immagini sia per la versione di destinazione sia per la versione intermedia dell'upgrade con salto.

Per preparare il mirror del registry per un upgrade con salto, segui questi passaggi:

  1. Utilizzando la versione di bmctl corrispondente alla versione di destinazione dell'upgrade con salto, scopri qual è la versione intermedia per l'upgrade con salto:

    bmctl upgrade intermediate-version

    La risposta al comando è costituita dalla versione specifica della patch di Google Distributed Cloud utilizzata dal sistema come versione intermedia durante l'upgrade con salto. Ad esempio, per la versione 1.33.0-gke.799 di bmctl, la risposta è simile alla seguente:

    1.32.200-gke.104

  2. Scarica i pacchetti di immagini sia per la versione di destinazione sia per la versione intermedia.

    Per ulteriori informazioni, vedi Scarica il pacchetto di immagini.

  3. Esegui il push dei pacchetti di immagini sia per la versione di destinazione sia per la versione intermedia nel mirror del registry prima di avviare l'upgrade con salto.

    L'hosting delle immagini container per le versioni di destinazione e intermedie richiede spazio su disco aggiuntivo per il mirror del registry.

Come per gli upgrade sequenziali, puoi avviare l'upgrade con salto con bmctl upgrade cluster o kubectl apply.

Upgrade selettivi dei pool di nodi worker

Per impostazione predefinita, l'operazione di upgrade del cluster esegue l'upgrade di ogni nodo e pool di nodi nel cluster. Un upgrade del cluster può essere invasivo e richiedere molto tempo, in quanto comporta lo svuotamento di ogni nodo e il riavvio e la ripianificazione di tutti i pod associati. Questa sezione descrive come includere o escludere pool di nodi worker selezionati per un upgrade del cluster al fine di ridurre al minimo l'interruzione del workload. Questa funzionalità si applica solo ai cluster utente, ibridi e autonomi, poiché i cluster di amministrazione non consentono i pool di nodi worker.

Puoi utilizzare gli upgrade selettivi dei pool di nodi nelle seguenti situazioni:

  • Per applicare le correzioni di sicurezza senza interrompere i workload: puoi eseguire l'upgrade solo dei nodi del control plane (e dei nodi del bilanciatore del carico) per applicare le correzioni delle vulnerabilità di Kubernetes senza interrompere i pool di nodi worker.

  • Per confermare il corretto funzionamento di un sottoinsieme di nodi worker di cui è stato eseguito l'upgrade prima di eseguire l'upgrade di tutti i nodi worker: puoi eseguire l'upgrade dei pool di nodi worker in modo selettivo per assicurarti che i workload vengano eseguiti correttamente su un pool di nodi di cui è stato eseguito l'upgrade prima di eseguire l'upgrade di un altro pool di nodi.

  • Per ridurre il periodo di manutenzione: l'upgrade di un cluster di grandi dimensioni può richiedere molto tempo ed è difficile prevedere con precisione quando verrà completato. Il tempo di upgrade del cluster è proporzionale al numero di nodi di cui viene eseguito l'upgrade. La riduzione del numero di nodi di cui viene eseguito l'upgrade escludendo i pool di nodi riduce il tempo di upgrade. Esegui l'upgrade più volte, ma i periodi di manutenzione più brevi e prevedibili possono aiutarti con la pianificazione.

Disallineamento delle versioni pool di nodi di due versioni secondarie

Per i cluster della versione 1.28 e successive, la versione di un pool di nodi worker può essere precedente di un massimo di due versioni secondarie rispetto alla versione del cluster (control plane). Con il supporto della deviazione della versione n-2, puoi anche saltare una versione di release secondaria quando esegui l'upgrade di un pool di nodi worker da due versioni secondarie precedenti al cluster alla stessa versione secondaria del cluster.

Questo supporto per il disallineamento delle versioni n-2 per i pool di nodi worker offre una maggiore flessibilità per pianificare gli upgrade del parco risorse.

Ad esempio, se hai un cluster della versione 1.36, puoi avere node pool worker con versioni selezionate 1.36, 1.35 e 1.34.

Prima di poter eseguire l'upgrade di un cluster, tutti i pool di nodi worker devono essere in una versione compatibile sia con la versione attuale del cluster sia con la versione del cluster di destinazione.

Ad esempio, se hai un cluster alla versione 1.29 e pool di nodi worker alla versione 1.29, alla versione 1.28 e alla versione 1.16, devi eseguire l'upgrade dei pool di nodi alla versione 1.16 alla versione 1.28 o 1.29 prima di poter eseguire l'upgrade del cluster alla versione 1.30.

Per ulteriori informazioni, inclusi gli elenchi delle versioni dei pool di nodi worker supportate da una determinata versione del cluster (applicabile alla versione 1.29 e precedenti), consulta Regole di controllo delle versioni dei pool di nodi

1.30 e successive

Nella versione 1.30, il supporto della deviazione della versione n-2 per i node pool dei nodi worker è in disponibilità generale per tutti i tipi di cluster. Questa funzionalità è abilitata per impostazione predefinita per i cluster con versione 1.30.

I node pool con qualsiasi versione patch delle versioni secondarie 1.28 e 1.29 possono essere aggiornati a qualsiasi versione patch della 1.30, se la versione pool di nodi è uguale o precedente alla versione del cluster.

1,29

Nella versione 1.29, il supporto della deviazione della versione n-2 per i node pool dei nodi worker è in disponibilità generale per tutti i tipi di cluster. Questa funzionalità è abilitata per impostazione predefinita per i cluster con versione 1.29.

Durante la transizione di questa funzionalità da Anteprima pubblica a GA, i cluster ibridi richiedono comunque l'annotazione di anteprima nella situazione seguente. Se hai un cluster ibrido versione 1.28.x con un pool di nodi worker versione 1.16.y, devi aggiungere l'annotazione preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable al cluster prima di eseguire l'upgrade alla versione 1.29.z:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: baremetal-demo
  namespace: cluster-baremetal-demo
  annotations:
    preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable
spec:
  type: hybrid
  profile: default
  anthosBareMetalVersion: 1.28.400-gke.77
  ...

1,28

Il supporto del disallineamento delle versioni n-2 per i pool di nodi worker è disponibile in anteprima nella versione 1.28. Per attivare questa funzionalità in anteprima, aggiungi l'annotazione preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable al file di configurazione del cluster:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: baremetal-demo
  namespace: cluster-baremetal-demo
  annotations:
    preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable
spec:
...

Se non attivi questa funzionalità in anteprima, la deviazione massima della versione tra un pool di nodi worker e il cluster è di una versione secondaria.

Per saperne di più sulle regole di controllo delle versioni per l'upgrade selettivo dei pool di nodi worker, consulta Regole di controllo delle versioni dei pool di nodi in Ciclo di vita e fasi degli upgrade dei cluster.

Esegui l'upgrade del control plane del cluster e dei node pool selezionati

Per eseguire l'upgrade selettivo dei pool di nodi worker nell'upgrade iniziale del cluster:

  1. Per i pool di nodi worker che vuoi includere nell'upgrade del cluster, apporta una delle seguenti modifiche alla specifica NodePool:

    • Imposta anthosBareMetalVersion nella specifica NodePool sulla versione di upgrade target del cluster.
    • Ometti il campo anthosBareMetalVersion dalla specifica NodePool o impostalo su una stringa vuota. Per impostazione predefinita, i pool di nodi worker sono inclusi negli upgrade dei cluster.

  2. Per i node pool dei nodi worker che vuoi escludere dall'upgrade, imposta anthosBareMetalVersion sulla versione attuale (pre-upgrade) del cluster:

  3. Continua con l'upgrade come descritto in Avvia l'upgrade del cluster.

    L'operazione di upgrade del cluster esegue l'upgrade dei seguenti nodi:

    • Nodi del control plane del cluster.
    • Pool di nodi del bilanciatore del carico, se il cluster ne utilizza uno (spec.loadBalancer.nodePoolSpec). Per impostazione predefinita, i nodi del bilanciatore del carico possono eseguire workload regolari. Non puoi eseguire l'upgrade selettivo di un pool di nodi del bilanciatore del carico, che è sempre incluso nell'upgrade iniziale del cluster.
    • Pool di nodi worker che non hai escluso dall'upgrade.

Ad esempio, supponiamo che il cluster sia alla versione 1.35.0 e abbia due pool di nodi worker: wpool01 e wpool02. Supponiamo inoltre che tu voglia eseguire l'upgrade del control plane e di wpool01 alla versione 1.36.200-gke.118, ma che tu voglia che wpool02 rimanga alla versione 1.35.0.

Il seguente estratto del file di configurazione del cluster mostra come modificare la configurazione del cluster per supportare questo upgrade parziale:

...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user001
  namespace: cluster-user001
spec:
  type: user
  profile: default
  anthosBareMetalVersion: 1.36.200-gke.118
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.36.200-gke.118
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  ...
  - address:  10.200.0.8

apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool02
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.35.0
  nodes:
  - address:  10.200.1.1
  - address:  10.200.1.2
  - address:  10.200.1.3
  ...
  - address:  10.200.1.12

Esegui l'upgrade dei node pool alla versione attuale del cluster

Se hai escluso i node pool da un upgrade del cluster, puoi eseguire un upgrade del cluster che li porti alla versione del cluster di destinazione. I pool di nodi worker che sono stati esclusi da un upgrade del cluster hanno il campo anthosBareMetalVersion nella specifica NodePool impostato sulla versione del cluster precedente (pre-upgrade).

Per aggiornare i pool di nodi worker alla versione attuale del cluster di cui è stato eseguito l'upgrade:

  1. Modifica le specifiche NodePool nel file di configurazione del cluster per i pool di nodi worker che vuoi aggiornare alla versione attuale del cluster. Imposta anthosBareMetalVersion sulla versione attuale del cluster (post-upgrade).

    Se vengono selezionati più pool di nodi worker per l'upgrade, il valore di spec.nodePoolUpgradeStrategy.concurrentNodePools nella specifica del cluster determina il numero di pool di nodi di cui viene eseguito l'upgrade in parallelo, se presenti. Se non vuoi eseguire l'upgrade dei pool di nodi worker contemporaneamente, seleziona un pool di nodi alla volta per l'upgrade.

  2. Continua con l'upgrade come descritto in Avvia l'upgrade del cluster.

    L'operazione di upgrade del cluster esegue l'upgrade solo dei pool di nodi worker precedentemente esclusi per i quali hai impostato anthosBareMetalVersion sulla versione attuale del cluster di cui è stato eseguito l'upgrade.

Ad esempio, supponiamo che tu abbia eseguito l'upgrade del cluster alla versione 1.36.200-gke.118, ma che pool di nodi wpool02 sia ancora alla versione del cluster precedente all'upgrade, ovvero 1.35.0. I workload vengono eseguiti correttamente sul pool di nodi di cui è stato eseguito l'upgrade, wpool01, quindi ora vuoi portare anche wpool02 alla versione attuale del cluster. Per eseguire l'upgrade di wpool02, puoi rimuovere il campo anthosBareMetalVersion o impostarne il valore su una stringa vuota.

Il seguente estratto del file di configurazione del cluster mostra come modificare la configurazione del cluster per supportare questo upgrade parziale:

...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user001
  namespace: cluster-user001
spec:
  type: user
  profile: default
  anthosBareMetalVersion: 1.36.200-gke.118
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.36.200-gke.118
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  ...
  - address:  10.200.0.8

apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool02
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: ""
  nodes:
  - address:  10.200.1.1
  - address:  10.200.1.2
  - address:  10.200.1.3
  ...
  - address:  10.200.1.12

Esegui il rollback di un upgrade del pool di nodi

Esistono molte dipendenze, come la compatibilità con kubelet o i plug-in, che possono influire sulle prestazioni dei workload. Se riscontri un problema dopo l'upgrade di un pool di nodi worker, puoi eseguire il rollback del pool di nodi alla versione precedente.

Questa funzionalità non è nella stessa fase di lancio per tutte le versioni dei cluster supportate:

1.30 e successive

Per i cluster della versione 1.30 (cluster con nodi del control plane nella versione 1.30), la funzionalità di rollback dei pool di nodi è in disponibilità generale e abilitata per impostazione predefinita.

1,29

La funzionalità di rollback dei pool di nodi è disponibile in Anteprima per i cluster della versione 1.29 (cluster con nodi del control plane della versione 1.29). Mentre questa funzionalità è in anteprima, devi aggiungere la seguente annotazione alla risorsa Cluster per abilitarla:

preview.baremetal.cluster.gke.io/worker-node-pool-upgrade-rollback: enable

1,28

La funzionalità di rollback del pool di nodi non è disponibile per i cluster con versione secondaria 1.28 o precedente.

Per eseguire il rollback di un upgrade del pool di nodi, segui questi passaggi:

bmctl

Quando utilizzi bmctl per eseguire il rollback di un upgrade del pool di nodi, modifichi il file di configurazione del cluster e applichi le modifiche con il comando bmctl update:

  1. Modifica le specifiche NodePool nel file di configurazione del cluster per i pool di nodi worker di cui vuoi eseguire il rollback alla versione precedente. Imposta anthosBareMetalVersion sulla versione del cluster precedente (pre-upgrade).

    ...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.35.600-gke.141
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  ...

    Se vengono selezionati più pool di nodi worker per il rollback, il valore di spec.nodePoolUpgradeStrategy.concurrentNodePools nella specifica del cluster determina il numero di pool di nodi di cui viene eseguito il rollback in parallelo. Se non vuoi eseguire il rollback dei pool di nodi worker contemporaneamente, seleziona un pool di nodi alla volta per il rollback o aggiorna le impostazioni di nodePoolUpgradeStrategy. Analogamente, il valore di spec.upgradeStrategy.parallelUpgrade.concurrentNodes nella specifica NodePool determina il numero di nodi di cui viene eseguito il rollback in parallelo.

  2. Utilizza bmctl update per applicare le modifiche alla specifica NodePool:

    bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG

    Sostituisci quanto segue:

    • CLUSTER_NAME: il nome del cluster che vuoi aggiornare.

    • ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di gestione (amministratore, ibrido o autonomo).

    Il rollback inizia automaticamente. Il comando bmctl update cluster esce immediatamente, ma il rollback continua. Non eseguire altre operazioni sul cluster mentre è in corso il rollback.

  3. Durante l'esecuzione del rollback, Google Distributed Cloud esegue le seguenti attività per ogni nodo:

    • Attiva la modalità di manutenzione del nodo.
    • Esegui un job di reset sul nodo per riportarlo a uno stato pulito.
    • Esegui i controlli preflight della macchina sul nodo.
    • Esegui un job machine-init sul nodo per reinstallarlo nella versione di rollback di destinazione (pre-upgrade).
    • Rimuovi il nodo dalla modalità di manutenzione.

    Al termine di un rollback riuscito, il valore di nodePool.status.anthosBareMetalVersion nella risorsa NodePool viene impostato sulla versione di rollback di destinazione.

kubectl

Puoi eseguire il rollback di un upgrade del pool di nodi utilizzando kubectl per modificare direttamente la risorsa NodePool:

  1. Per eseguire il rollback di un pool di nodi worker, apri la risorsa NodePool per modificarla:

    kubectl edit nodepool NODE_POOL_NAME \
    --namespace CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG

    Sostituisci quanto segue:

    • NODE_POOL_NAME: il nome del pool di nodi di cui stai eseguendo il rollback.

    • CLUSTER_NAMESPACE: il nome dello spazio dei nomi in cui è stato eseguito il deployment del pool di nodi. Questo è lo spazio dei nomi del cluster.

    • ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di gestione (amministratore, ibrido o autonomo).

  2. Modifica il valore di spec.anthosBareMetalVersion impostandolo sulla versione precedente (pre-upgrade).

    ...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.35.600-gke.141
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  ...

  3. Salva e chiudi la risorsa NodePool nell'editor.

    Il rollback inizia automaticamente. Non eseguire altre operazioni sul cluster mentre è in corso il rollback.

  4. Durante l'esecuzione del rollback, Google Distributed Cloud esegue le seguenti attività per ogni nodo:

    • Attiva la modalità di manutenzione del nodo.
    • Esegui un job di reset sul nodo per riportarlo a uno stato pulito.
    • Esegui i controlli preflight della macchina sul nodo.
    • Esegui un job machine-init sul nodo per reinstallarlo nella versione di rollback di destinazione (pre-upgrade).
    • Rimuovi il nodo dalla modalità di manutenzione.

    Al termine di un rollback riuscito, il valore di nodePool.status.anthosBareMetalVersion nella risorsa NodePool viene impostato sulla versione di rollback di destinazione.

Upgrade paralleli

In un tipico upgrade predefinito del cluster, ogni nodo del cluster viene aggiornato in sequenza, uno dopo l'altro. Questa sezione mostra come configurare i pool di nodi del cluster e dei worker in modo che più nodi vengano aggiornati in parallelo quando esegui l'upgrade del cluster. L'upgrade dei nodi in parallelo accelera notevolmente gli upgrade dei cluster, soprattutto per i cluster con centinaia di nodi.

Esistono due strategie di upgrade parallelo che puoi utilizzare per velocizzare l'upgrade del cluster:

  • Upgrade dei nodi in parallelo: puoi configurare i pool di nodi worker in modo che l'upgrade di più nodi venga eseguito in parallelo. Gli upgrade paralleli dei nodi sono configurati nella specifica NodePool (spec.upgradeStrategy.parallelUpgrade) e solo i nodi in un pool di nodi worker possono essere aggiornati in parallelo. I nodi nei pool di nodi del control plane o del bilanciatore del carico possono essere aggiornati solo uno alla volta. Per saperne di più, consulta Strategia di upgrade dei nodi.

  • Upgrade simultaneo dei pool di nodi: puoi configurare il cluster in modo che l'upgrade di più node pool venga eseguito in parallelo. Solo i pool di nodi worker possono essere aggiornati in parallelo. L'upgrade dei pool di nodi del control plane e del bilanciatore del carico può essere eseguito solo uno alla volta.

Strategia di upgrade dei nodi

Puoi configurare i pool di nodi worker in modo che più nodi vengano aggiornati contemporaneamente (concurrentNodes). Puoi anche impostare una soglia minima per il numero di nodi in grado di eseguire workload durante il processo di upgrade (minimumAvailableNodes). Questa configurazione viene eseguita nella specifica NodePool. Per ulteriori informazioni su questi campi, consulta il Riferimento dei campi di configurazione del cluster.

La strategia di upgrade dei pool di nodi si applica solo ai pool di nodi worker. Non puoi specificare una strategia di upgrade dei nodi per i pool di nodi del control plane o del bilanciatore del carico. Durante un upgrade del cluster, i nodi nei pool di nodi del control plane e del bilanciatore del carico vengono aggiornati in sequenza, uno alla volta. I pool di nodi del control plane e i pool di nodi del bilanciatore del carico sono specificati nella specifica del cluster (controlPlane.nodePoolSpec.nodes e loadBalancer.nodePoolSpec.nodes).

Quando configuri gli upgrade paralleli per i nodi, tieni presente le seguenti limitazioni:

  • Il valore di concurrentNodes non può superare il 50% del numero di nodi nel pool di nodi o il numero fisso 15, a seconda di quale sia il valore più piccolo. Ad esempio, se il tuo pool di nodi ha 20 nodi, non puoi specificare un valore maggiore di 10. Se il pool di nodi ha 100 nodi, 15 è il valore massimo che puoi specificare.

  • Quando utilizzi concurrentNodes insieme a minimumAvailableNodes, i valori combinati non possono superare il numero totale di nodi nel pool di nodi. Ad esempio, se il pool di nodi ha 20 nodi e minimumAvailableNodes è impostato su 18, concurrentNodes non può superare 2. Analogamente, se concurrentNodes è impostato su 10, minimumAvailableNodes non può superare 10.

L'esempio seguente mostra un pool di nodi worker np1 con 10 nodi. In un upgrade, i nodi vengono aggiornati 5 alla volta e almeno 4 nodi devono rimanere disponibili affinché l'upgrade possa procedere:

apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: np1
  namespace: cluster-cluster1
spec:
  clusterName: cluster1
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  - address:  10.200.0.4
  - address:  10.200.0.5
  - address:  10.200.0.6
  - address:  10.200.0.7
  - address:  10.200.0.8
  - address:  10.200.0.9
  - address:  10.200.0.10 
  upgradeStrategy:
    parallelUpgrade:
      concurrentNodes: 5
      minimumAvailableNodes: 4

Strategia di upgrade del node pool

Puoi configurare un cluster in modo che più pool di nodi worker eseguano l'upgrade in parallelo. Il campo booleano nodePoolUpgradeStrategy.concurrentNodePools nella specifica del cluster indica se eseguire o meno l'upgrade contemporaneo di tutti i pool di nodi worker per un cluster. Per impostazione predefinita (1), l'upgrade dei node pool viene eseguito in sequenza, uno dopo l'altro. Quando imposti concurrentNodePools su 0, l'upgrade di ogni pool di nodi worker nel cluster viene eseguito in parallelo.

I pool di nodi del control plane e del bilanciamento del carico non sono interessati da questa impostazione. L'upgrade di questi pool di nodi viene sempre eseguito in sequenza, uno alla volta. I pool di nodi del control plane e i pool di nodi del bilanciatore del carico sono specificati nella specifica del cluster (controlPlane.nodePoolSpec.nodes e loadBalancer.nodePoolSpec.nodes).

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
spec:
  ...
  nodePoolUpgradeStrategy:
    concurrentNodePools: 0
  ...

Come eseguire un upgrade parallelo

Questa sezione descrive come configurare un cluster e un pool di nodi worker per gli upgrade paralleli.

Per eseguire un upgrade parallelo dei pool di nodi worker e dei nodi in un pool di nodi worker, segui questi passaggi:

  1. Aggiungi una sezione upgradeStrategy alla specifica NodePool.

    Puoi applicare questo manifest separatamente o come parte del file di configurazione del cluster quando esegui un aggiornamento del cluster.

    Ecco un esempio:

    ---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: np1
  namespace: cluster-ci-bf8b9aa43c16c47
spec:
  clusterName: ci-bf8b9aa43c16c47
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  ...
  - address:  10.200.0.30
  upgradeStrategy:
    parallelUpgrade:
      concurrentNodes: 5
      minimumAvailableNodes: 10

    In questo esempio, il valore del campo concurrentNodes è 5, il che significa che l'upgrade di 5 nodi viene eseguito in parallelo. Il campo minimumAvailableNodes è impostato su 10, il che significa che almeno 10 nodi devono rimanere disponibili per i workload durante l'upgrade.

  2. Aggiungi una sezione nodePoolUpgradeStrategy alla specifica Cluster nel file di configurazione del cluster.

    ---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-user001
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user001
  namespace: cluster-user001
spec:
  type: user
  profile: default
  anthosBareMetalVersion: 1.36.200-gke.118
  ...
  nodePoolUpgradeStrategy:
    concurrentNodePools: 0
  ...

    In questo esempio, il campo concurrentNodePools è impostato su 0, il che significa che l'upgrade di tutti i pool di nodi worker viene eseguito contemporaneamente durante l'upgrade del cluster. La strategia di upgrade per i nodi nei node pool è definita nelle specifiche NodePool.

  3. Esegui l'upgrade del cluster come descritto nella sezione precedente Esegui l'upgrade dei cluster di amministrazione, autonomi, ibridi o utente.

Valori predefiniti per l'upgrade parallelo

Gli upgrade paralleli sono disattivati per impostazione predefinita e i campi relativi agli upgrade paralleli sono modificabili. In qualsiasi momento, puoi rimuovere i campi o impostarli sui valori predefiniti per disattivare la funzionalità prima di un upgrade successivo.

La tabella seguente elenca i campi di upgrade parallelo e i relativi valori predefiniti:

Campo Valore predefinito Significato
nodePoolUpgradeStrategy.concurrentNodePools (specifica del cluster) 1 Esegui l'upgrade dei pool di nodi worker in sequenza, uno dopo l'altro.
upgradeStrategy.parallelUpgrade.concurrentNodes (specifica NodePool) 1 Esegui l'upgrade dei nodi in sequenza, uno dopo l'altro.
upgradeStrategy.parallelUpgrade.minimumAvailableNodes (specifica NodePool) Il valore predefinito di minimumAvailableNodes dipende dal valore di concurrentNodes.
  • Se non specifichi concurrentNodes, minimumAvailableNodes per impostazione predefinita è pari a 2/3 delle dimensioni del pool di nodi.
  • Se specifichi concurrentNodes, per impostazione predefinita minimumAvailableNodes corrisponde alle dimensioni del pool di nodi meno concurrentNodes.
 L'upgrade si blocca una volta raggiunto minimumAvailableNodes e continua solo quando il numero di nodi disponibili è maggiore di minimumAvailableNodes.

Avvia l'upgrade del cluster

Questa sezione contiene le istruzioni per l'upgrade dei cluster.

bmctl

Quando scarichi e installi una nuova versione di bmctl, puoi eseguire l'upgrade dei cluster di amministrazione, ibridi, autonomi e utente creati con una versione precedente. Per una determinata versione di bmctl, è possibile eseguire l'upgrade di un cluster solo alla stessa versione.

  1. Imposta le tue credenziali utente come Credenziali predefinite dell'applicazione (ADC):

    gcloud auth application-default login

    Segui le istruzioni per selezionare il tuo Account Google per ADC. Per saperne di più, consulta Configura le credenziali predefinite dell'applicazione.

  2. Scarica l'ultima versione di bmctl come descritto in Download di Google Distributed Cloud.

  3. Aggiorna anthosBareMetalVersion nel file di configurazione del cluster alla versione di destinazione dell'upgrade.

    La versione di destinazione dell'upgrade deve corrispondere alla versione del file bmctl scaricato. Il seguente snippet del file di configurazione del cluster mostra il campo anthosBareMetalVersion aggiornato all'ultima versione:

    ---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
spec:
  type: admin
  # Anthos cluster version.
  anthosBareMetalVersion: 1.36.200-gke.118

  4. Utilizza il comando bmctl upgrade cluster per completare l'upgrade:

    bmctl upgrade cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG

    Sostituisci quanto segue:

    • CLUSTER_NAME: il nome del cluster di cui eseguire l'upgrade.
    • ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.

    L'operazione di upgrade del cluster esegue controlli preflight per convalidare lo stato del cluster e l'integrità del nodo. L'upgrade del cluster non procede se i controlli preflight non vanno a buon fine. Per informazioni sulla risoluzione dei problemi, consulta Risolvi i problemi di installazione o upgrade del cluster.

    Una volta eseguito l'upgrade di tutti i componenti del cluster, l'operazione di upgrade del cluster esegue i controlli di integrità del cluster. Quest'ultimo passaggio verifica che il cluster sia in buone condizioni operative. Se il cluster non supera tutti i controlli di integrità, questi continuano a essere eseguiti finché non vengono superati. Quando tutti i controlli di integrità vengono superati, l'upgrade viene completato correttamente.

    Per saperne di più sulla sequenza di eventi per gli upgrade dei cluster, consulta Ciclo di vita e fasi degli upgrade dei cluster.

kubectl

Per eseguire l'upgrade di un cluster con kubectl, segui questi passaggi:

  1. Modifica il file di configurazione del cluster per impostare anthosBareMetalVersion sulla versione di destinazione dell'upgrade.

  2. Per avviare l'upgrade, esegui questo comando:

    kubectl apply -f CLUSTER_CONFIG_PATH

    Sostituisci CLUSTER_CONFIG_PATH con il percorso del file di configurazione del cluster modificato.

    Come per il processo di upgrade con bmctl, i controlli preflight vengono eseguiti nell'ambito dell'upgrade del cluster per convalidare lo stato del cluster e l'integrità del nodo. Se i controlli preflight non vanno a buon fine, l'upgrade del cluster viene interrotto. Per risolvere eventuali errori, esamina il cluster e i log correlati, poiché non viene creato alcun cluster di bootstrap. Per saperne di più, consulta Risolvi i problemi di installazione o upgrade del cluster.

Sebbene non sia necessaria l'ultima versione di bmctl per eseguire l'upgrade dei cluster con kubectl, ti consigliamo di scaricare l'ultima versione di bmctl. Hai bisogno di bmctl per eseguire altre attività, come controlli di integrità e backup, per assicurarti che il tuo cluster rimanga in buone condizioni di funzionamento.

Metti in pausa e riprendi gli upgrade

La funzionalità di pausa e ripresa dell'upgrade ti consente di mettere in pausa l'upgrade di un cluster prima che venga completato. Quando l'upgrade di un cluster è in pausa, non vengono attivati nuovi upgrade dei nodi worker finché l'upgrade non viene ripreso.

Questa funzionalità è disponibile in (Anteprima) per i cluster con tutti i nodi del control plane con versione secondaria 1.28 o successiva. La funzionalità è in disponibilità generale per i cluster con tutti i nodi del control plane con versione secondaria 1.29 o successiva.

Potresti voler mettere in pausa un upgrade per i seguenti motivi:

  • Hai rilevato un problema con i workload del cluster durante l'upgrade e vuoi mettere in pausa l'upgrade per esaminare il problema

  • I periodi di manutenzione sono brevi, quindi vuoi mettere in pausa l'upgrade tra un periodo e l'altro

Mentre l'upgrade di un cluster è in pausa, sono supportate le seguenti operazioni:

Quando viene aggiunto un nuovo nodo mentre un upgrade è in pausa, i job di controllo della macchina non vengono eseguiti sul nodo finché l'upgrade non viene ripreso e completato.

Durante la pausa dell'upgrade del cluster, le seguenti operazioni del cluster non sono supportate:

Non puoi avviare un nuovo upgrade del cluster mentre un upgrade del cluster attivo è in pausa.

Abilita la messa in pausa e la ripresa dell'upgrade

Google Distributed Cloud 1.36

La funzionalità di pausa e ripresa dell'upgrade è abilitata per impostazione predefinita per i cluster con tutti i nodi del control plane con versione secondaria 1.29 o successiva.

Google Distributed Cloud 1.35

Mentre la funzionalità di pausa e ripresa dell'upgrade è in anteprima, puoi attivarla con un'annotazione nella risorsa Cluster.

Per attivare la pausa e il ripristino dell'upgrade, segui questi passaggi:

  1. Aggiungi l'annotazione preview.baremetal.cluster.gke.io/upgrade-pause-and-resume al file di configurazione del cluster:

    apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: baremetal-demo
  namespace: cluster-baremetal-demo
  annotations:
    preview.baremetal.cluster.gke.io/upgrade-pause-and-resume: enable
spec:
...

  2. Per applicare la modifica, aggiorna il cluster:

    bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG

    Sostituisci quanto segue:

    • CLUSTER_NAME: il nome del cluster che vuoi aggiornare.
    • ADMIN_KUBECONFIG: per i cluster di amministrazione, ibridi o autonomi, inserisci il percorso del file kubeconfig del cluster. Per un cluster utente, inserisci il percorso del file kubeconfig del cluster admin.

    Il campo nodePoolUpgradeStrategy.pause è modificabile. Puoi aggiungerlo e aggiornarlo in qualsiasi momento.

Metti in pausa un upgrade

Per mettere in pausa l'upgrade di un cluster, imposta nodePoolUpgradeStrategy.pause su true nella specifica del cluster.

Per mettere in pausa un upgrade del cluster attivo, segui questi passaggi:

  1. Aggiungi nodePoolUpgradeStrategy.pause al file di configurazione del cluster e impostalo su true:

    apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: baremetal-demo
  namespace: cluster-baremetal-demo
  ...
spec:
  ...
  nodePoolUpgradeStrategy:
    pause: true
  ...

    Se hai utilizzato bmctl per avviare l'upgrade, devi aprire una nuova finestra del terminale per eseguire il passaggio successivo.

  2. Per applicare la modifica, aggiorna il cluster:

    bmctl update CLUSTER_NAME

    L'operazione di upgrade è in pausa. Non vengono attivati nuovi upgrade dei nodi.

  3. Se hai utilizzato bmctl per avviare l'upgrade e prevedi una pausa di lunga durata, premi Ctrl+C per uscire da bmctl, altrimenti mantieni bmctl in esecuzione.

    L'interfaccia a riga di comando bmctl non rileva le modifiche allo stato di pausa dell'upgrade, quindi non esce automaticamente. Tuttavia, quando esci da bmctl, l'avanzamento dell'upgrade non viene più registrato nel file di log cluster-upgrade-TIMESTAMP nella cartella del cluster sulla tua workstation di amministrazione e in Cloud Logging. Pertanto, per brevi pause, ti consigliamo di mantenere bmctl in esecuzione. Se lasci bmctl in esecuzione per un periodo prolungato mentre l'upgrade è in pausa, alla fine si verifica un timeout.

Riprendi un upgrade in pausa

Puoi riprendere un upgrade del cluster in pausa impostando nodePoolUpgradeStrategy.pause su false nella specifica del cluster o rimuovendo nodePoolUpgradeStrategy.pause dalla specifica.

Per riprendere un upgrade del cluster che è stato messo in pausa, segui questi passaggi:

  1. Imposta nodePoolUpgradeStrategy.pause sul file di configurazione del cluster e impostalo su false:

    apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: baremetal-demo
  namespace: cluster-baremetal-demo
  ...
spec:
  ...
  nodePoolUpgradeStrategy:
    pause: false
  ...

    In alternativa, puoi rimuovere il campo pause, perché il valore predefinito è false.

  2. Per applicare la modifica, aggiorna il cluster:

    bmctl update CLUSTER_NAME

    L'operazione di upgrade riprende da dove era stata interrotta.

  3. Per controllare lo stato dell'upgrade, recupera innanzitutto un elenco delle risorse che contengono anthosBareMetalVersion in status:

    kubectl get RESOURCE --kubeconfig ADMIN_KUBECONFIG --all_namespaces

    Sostituisci quanto segue:

    • RESOURCE: il nome della risorsa che vuoi recuperare. Le risorse Cluster, NodePool e BareMetalMachine contengono tutte informazioni sullo stato anthosBareMetalVersion.

    • ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.

    L'esempio seguente mostra il formato della risposta per le risorse personalizzate BareMetalMachine. Ogni BareMetalMachine corrisponde a un nodo del cluster.

    NAMESPACE              NAME         CLUSTER        READY   INSTANCEID               MACHINE      ABM VERSION   DESIRED ABM VERSION
cluster-nuc-admin001   192.0.2.52   nuc-admin001   true    baremetal://192.0.2.52   192.0.2.52   1.28.0        1.28.0
cluster-nuc-user001    192.0.2.53   nuc-user001    true    baremetal://192.0.2.53   192.0.2.53   1.16.2        1.16.2
cluster-nuc-user001    192.0.2.54   nuc-user001    true    baremetal://192.0.2.54   192.0.2.54   1.16.2        1.16.2

  4. Per controllare l'status.anthosBareMetalVersion (versione corrente della risorsa), recupera i dettagli delle singole risorse:

    kubectl describe RESOURCE RESOURCE_NAME \
    --kubeconfig ADMIN_KUBECONFIG \
    --namespace CLUSTER_NAMESPACE

    L'esempio seguente mostra i dettagli di BareMetalMachine per il nodo del cluster con indirizzo IP 192.0.2.53:

    Name:         192.0.2.53
Namespace:    cluster-nuc-user001
...
API Version:  infrastructure.baremetal.cluster.gke.io/v1
Kind:         BareMetalMachine
Metadata:
  Creation Timestamp:  2023-09-22T17:52:09Z
  ...
Spec:
  Address:                    192.0.2.53
  Anthos Bare Metal Version:  1.16.2
  ...
Status:
  Anthos Bare Metal Version:  1.16.2

    In questo esempio, il nodo è alla versione 1.16.2 di Google Distributed Cloud.