Questa pagina è stata tradotta dall'API Cloud Translation.

Eseguire l'upgrade dei cluster

Quando installi una nuova versione di bmctl, puoi eseguire l'upgrade dei cluster esistenti che sono stati 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, vedi 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, consulta Ruoli utente e attività comuni di GKE. Google Cloud

Pianificare l'upgrade

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

Best practice

Per informazioni che ti aiutino a prepararti per l'upgrade di un cluster, vedi Best practice per gli upgrade dei cluster Google Distributed Cloud.

Eseguire l'upgrade dei controlli preliminari

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 ulteriori informazioni sui controlli preliminari, vedi Informazioni sui controlli preliminari.

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

Problemi noti

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

Configurare le opzioni di upgrade

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

Upgrade selettivi dei pool di nodi worker: esegui l'upgrade di pool di nodi worker specifici separatamente dal resto del cluster.
Upgrade paralleli: configura il processo di upgrade in modo da eseguire l'upgrade di gruppi di nodi o node pool contemporaneamente.

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

Upgrade selettivi del 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. L'upgrade di un cluster può essere interruttivo e richiedere molto tempo, in quanto comporta lo svuotamento di ogni nodo e il riavvio e la riprogrammazione di tutti i pod associati. Questa sezione descrive come includere o escludere pool di nodi worker selezionati per un upgrade del cluster per 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.

Potresti utilizzare gli upgrade selettivi del pool di nodi nelle seguenti situazioni:

Per applicare le correzioni di sicurezza senza interrompere i workload:puoi eseguire l'upgrade solo dei nodi del piano di controllo (e dei nodi del bilanciatore del carico) per applicare le correzioni delle vulnerabilità di Kubernetes senza interrompere i pool di nodi worker.
Per verificare 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 carichi di lavoro vengano eseguiti correttamente in 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. Ridurre il numero di nodi di cui viene eseguito l'upgrade escludendo i node pool riduce il tempo di upgrade. Esegui più upgrade, ma le finestre di manutenzione più piccole e prevedibili possono aiutarti con la pianificazione.

Disallineamento delle versioni pool di nodi di due versioni secondarie

Per i cluster versione 1.28 e successive, la versione di un pool di nodi worker può essere fino a due versioni secondarie precedenti alla versione del cluster (control plane). Con il supporto dell'inclinazione della versione n-2, puoi anche ignorare una versione 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 node pool dei nodi worker offre maggiore flessibilità per pianificare gli upgrade del parco macchine.

Ad esempio, se hai un cluster versione 1.32, puoi avere pool di nodi worker nelle versioni 1.32, 1.31 e 1.30 selezionate.

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

Ad esempio, se hai un cluster alla versione 1.29 e pool di nodi worker alle versioni 1.29, 1.28 e 1.16, devi eseguire l'upgrade dei pool di nodi 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 del worker pool di nodi supportate da una determinata versione del cluster (valido per la versione 1.29 e precedenti), consulta Regole di controllo delle versioni del node pool.

1,30

Nella versione 1.30, il supporto dell'inclinazione della versione n-2 per i pool di nodi worker è GA per tutti i tipi di cluster. Questa funzionalità è abilitata per impostazione predefinita per i cluster alla versione 1.30.

I node pool in qualsiasi versione patch delle versioni secondarie 1.28 e 1.29 possono essere aggiornati a qualsiasi versione patch della 1.30, se la versionepool di nodil è uguale o inferiore a quella del cluster.

1,29

Nella release 1.29, il supporto dell'inclinazione della versione n-2 per i pool di nodi worker è GA per tutti i tipi di cluster. Questa funzionalità è abilitata per impostazione predefinita per i cluster alla versione 1.29.

Durante la transizione di questa funzionalità da Anteprima pubblica a GA, i cluster ibridi richiedono ancora l'annotazione di anteprima nella seguente situazione. 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 per lo sfasamento di versione n-2 per i pool di nodi di lavoro è disponibile per l'anteprima nella release 1.28. Per attivare questa funzionalità di 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 abiliti questa funzionalità di anteprima, la differenza massima tra le versioni tra un pool di nodi worker e il cluster è di una versione secondaria.

Per ulteriori informazioni sulle regole di controllo delle versioni per l'upgrade selettivo dei worker node pool, consulta Regole di controllo delle versioni dei node pool in Ciclo di vita e fasi degli upgrade del 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:

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 di destinazione del cluster.
- Ometti il campo anthosBareMetalVersion dalla specifica NodePool o impostalo sulla stringa vuota. Per impostazione predefinita, i pool di nodi worker sono inclusi negli upgrade del cluster.
Per i pool di nodi worker che vuoi escludere dall'upgrade, imposta anthosBareMetalVersion sulla versione attuale (pre-upgrade) del cluster:
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.
- Node 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.31.0 e abbia due pool di nodi worker: wpool01 e wpool02. Supponiamo inoltre di voler eseguire l'upgrade del control plane e di wpool01 alla versione 1.32.200-gke.104, ma di voler mantenere wpool02 alla versione 1.31.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.32.200-gke.104
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.32.200-gke.104
  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.31.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 precedente (pre-upgrade) del cluster.

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

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

Se vengono selezionati più pool di nodi worker per l'upgrade, il valore dispec.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.
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 corrente del cluster di cui è stato eseguito l'upgrade.

Ad esempio, supponiamo di aver eseguito l'upgrade del cluster alla versione 1.32.200-gke.104, mapool di nodil wpool02 è ancora alla versione precedente del cluster 1.31.0. I carichi di lavoro vengono eseguiti correttamente sul pool di nodil 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 sulla 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.32.200-gke.104
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.32.200-gke.104
  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 dell'upgrade di un pool di nodi

Esistono molte dipendenze, come la compatibilità con kubelet o i plug-in, che possono influire sulle prestazioni dei tuoi carichi di lavoro. 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 si trova nella stessa fase di lancio per tutte le versioni del cluster supportate:

1,30

Per i cluster versione 1.30 (cluster con nodi del control plane alla versione 1.30), la funzionalità di rollbackpool di nodil è GA ed è abilitata per impostazione predefinita.

1,29

La funzionalità di rollback del pool di nodi è disponibile in anteprima per i cluster versione 1.29 (cluster con nodi del control plane alla 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 dell'upgrade di un pool di nodi:

`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:

Modifica le specifiche NodePool nel file di configurazione del cluster per i pool di nodi worker a cui vuoi eseguire il rollback alla versione precedente. Imposta anthosBareMetalVersion sulla versione precedente (pre-upgrade) del cluster.
```
...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.31.700-gke.72
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  ...
```
Se vengono selezionati più pool di nodi di lavoro 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. Allo stesso modo, il valore di spec.upgradeStrategy.parallelUpgrade.concurrentNodes nella specifica NodePool determina il numero di nodi di cui viene eseguito il rollback in parallelo.
Utilizza bmctl update per applicare le modifiche alle specifiche 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 (amministrativo, ibrido o autonomo).
Il rollback inizia automaticamente. Il comando bmctl update cluster termina immediatamente, ma il rollback continua. Non eseguire altre operazioni sul cluster mentre è in corso il rollback.
Durante il rollback, Google Distributed Cloud esegue le seguenti attività per ogni nodo:
- Attiva la modalità di manutenzione del nodo.
- Esegui un job di ripristino sul nodo per riportarlo a uno stato pulito.
- Esegui i controlli preflight della macchina sul nodo.
- Esegui un job di inizializzazione della macchina sul nodo per reinstallarlo nella versione di rollback (pre-upgrade) di destinazione.
- 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.

Non utilizzare bmctl update e kubectl apply -f in modo intercambiabile durante la modifica del file di configurazione del cluster. Quando questi comandi vengono utilizzati in modo intercambiabile, i contenuti compilati dall'intestazione della specifica del cluster potrebbero essere rimossi involontariamente. Ad esempio, puoi utilizzare bmctl update per aggiornare il file di configurazione del cluster in modo da configurare un mirror del registro. Il cluster avrà quindi spec.nodeConfig.registryMirrors popolato dopo la riconciliazione.

Se poi tenti di apportare modifiche al cluster utilizzando la configurazione del cluster con il comando kubectl apply -f, viene rimosso spec.nodeConfig.registryMirrors compilato dal riconciliatore sul cluster. Questo comportamento si verifica perché la configurazione non esiste nella specifica di configurazione del cluster, ma esiste nel cluster.

`kubectl`

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

Per eseguire il rollback di un pool di nodi worker, apri la risorsa NodePool per la modifica:
```
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 viene 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 (amministrativo, ibrido o autonomo).

Modifica il valore di spec.anthosBareMetalVersion con la versione precedente (pre-upgrade).

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

Salva e chiudi la risorsa NodePool nell'editor.

Il rollback inizia automaticamente. Non eseguire altre operazioni sul cluster mentre è in corso il rollback.
Durante il rollback, Google Distributed Cloud esegue le seguenti attività per ogni nodo:
- Attiva la modalità di manutenzione del nodo.
- Esegui un job di ripristino sul nodo per riportarlo a uno stato pulito.
- Esegui i controlli preflight della macchina sul nodo.
- Esegui un job di inizializzazione della macchina sul nodo per reinstallarlo nella versione di rollback (pre-upgrade) di destinazione.
- 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 upgrade del cluster predefinito tipico, ogni nodo del cluster viene aggiornato in sequenza, uno dopo l'altro. Questa sezione mostra come configurare i pool di nodi worker e cluster in modo che più nodi vengano aggiornati in parallelo quando aggiorni il cluster. L'upgrade parallelo dei nodi accelera notevolmente gli upgrade dei cluster, soprattutto per i cluster con centinaia di nodi.

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

Upgrade simultaneo dei nodi: puoi configurare i pool di nodi worker in modo che più nodi vengano aggiornati 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. È possibile eseguire l'upgrade dei nodi nei pool di nodi del control plane o del bilanciatore del carico solo uno alla volta. Per maggiori informazioni, consulta la pagina Strategia di upgrade dei nodi.
Upgrade simultaneo del pool di nodi: puoi configurare il cluster in modo che più pool di nodi vengano aggiornati in parallelo. Solo i pool di nodi worker possono essere aggiornati in parallelo. È possibile eseguire l'upgrade dei pool di nodi del control plane e del bilanciatore del carico 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 i workload durante il processo di upgrade (minimumAvailableNodes). Questa configurazione viene eseguita nella specifica NodePool. Per maggiori informazioni su questi campi, consulta il riferimento ai campi di configurazione del cluster.

La strategia di upgrade dei nodi si applica solo ai node pool worker. Non puoi specificare una strategia di upgrade dei nodi per i pool di nodi del control plane o del bilanciatore del carico. Durante l'upgrade di un 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 inferiore. 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. Allo stesso modo, 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 per procedere con l'upgrade:

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 vengano aggiornati in parallelo. Il campo booleano nodePoolUpgradeStrategy.concurrentNodePools nella specifica del cluster indica se eseguire o meno l'upgrade di tutti i pool di nodi worker per un cluster contemporaneamente. Per impostazione predefinita (1), i node pool vengono aggiornati in sequenza, uno dopo l'altro. Quando imposti concurrentNodePools su 0, viene eseguito l'upgrade di ogni pool di nodi worker nel cluster 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 piano di controllo 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:

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 carichi di lavoro durante l'upgrade.

Nota: non puoi specificare una strategia di upgrade dei nodi per il piano di controllo o i pool di nodi del bilanciatore del carico.

Aggiungi una sezione nodePoolUpgradeStrategy alla specifica del 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.32.200-gke.104
  ...
  nodePoolUpgradeStrategy:
    concurrentNodePools: 0
  ...

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

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

Valori predefiniti dell'upgrade parallelo

Gli upgrade paralleli sono disattivati per impostazione predefinita e i campi correlati 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` (specifiche 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`, il valore predefinito di `minimumAvailableNodes` è 2/3 delle dimensioni del pool di nodi. Se specifichi `concurrentNodes`, `minimumAvailableNodes` per impostazione predefinita è la dimensione 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.

Imposta le 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 Configurare le credenziali predefinite dell'applicazione.
Scarica l'ultima versione di bmctl come descritto in Download di Google Distributed Cloud.
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. Lo snippet del file di configurazione del cluster seguente 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.32.200-gke.104
```
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.
Nota: il comando bmctl upgrade aggiorna solo il valore anthosBareMetalVersion e le annotazioni di anteprima nella risorsa personalizzata Cluster. Se vuoi modificare altri campi della specifica del cluster, utilizza il comando bmctl update. Per ulteriori informazioni, vedi Aggiornare i cluster.

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, vedi Risolvere 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 controlli di integrità del cluster. Questo 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 ulteriori informazioni 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:

Modifica il file di configurazione del cluster per impostare anthosBareMetalVersion sulla versione di destinazione dell'upgrade.
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 la procedura 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 vengono superati, 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 Risolvere i problemi di installazione o upgrade del cluster.

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

Mettere in pausa e riprendere gli upgrade

La funzionalità di pausa e ripresa dell'upgrade consente di mettere in pausa l'upgrade di un cluster prima che venga completato. Quando un upgrade del cluster viene messo 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 alla versione secondaria 1.28 o successive. La funzionalità è GA per i cluster con tutti i nodi del piano di controllo alla versione secondaria 1.29 o successive.

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 sospendere l'upgrade per esaminare il problema
Hai periodi di manutenzione 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 finché l'upgrade non viene ripreso e completato.

Mentre l'upgrade del cluster è in pausa, le seguenti operazioni del cluster non sono supportate:

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

Abilitare la pausa e la ripresa dell'upgrade

Google Distributed Cloud 1.32

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

Google Distributed Cloud 1.31

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

Per attivare la pausa e la ripresa dell'upgrade:

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

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

Mettere in pausa un upgrade

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

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

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.

Per applicare la modifica, aggiorna il cluster:
```
bmctl update CLUSTER_NAME
```
L'operazione di upgrade è in pausa. Non vengono attivati nuovi upgrade dei nodi.
Se hai utilizzato bmctl per avviare l'upgrade e prevedi una pausa prolungata, premi Control+C per uscire da bmctl, altrimenti mantieni bmctl in esecuzione.

La CLI bmctl non rileva le modifiche allo stato di pausa dell'upgrade, pertanto non viene chiusa automaticamente. Tuttavia, quando esci da bmctl, la registrazione dell'avanzamento dell'upgrade nel file di log cluster-upgrade-TIMESTAMP nella cartella del cluster sulla workstation di amministrazione e in Cloud Logging viene interrotta. Pertanto, per le pause brevi, ti consigliamo di mantenere bmctl in esecuzione. Se lasci bmctl in esecuzione per un periodo di tempo prolungato mentre l'upgrade è in pausa, alla fine si verifica un timeout.

Riprendere un upgrade in pausa

Per riprendere l'upgrade di un cluster in pausa, imposta nodePoolUpgradeStrategy.pause su false nella specifica del cluster o rimuovi nodePoolUpgradeStrategy.pause dalla specifica.

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

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.

Per applicare la modifica, aggiorna il cluster:
```
bmctl update CLUSTER_NAME
```
L'operazione di upgrade riprende da dove era stata interrotta.

Per controllare lo stato dell'upgrade, recupera innanzitutto un elenco delle risorse che hanno anthosBareMetalVersion nel 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.

Il seguente esempio 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

Per controllare status.anthosBareMetalVersion (la versione attuale della risorsa), recupera i dettagli delle singole risorse:

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

Il seguente esempio 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.

Eseguire l'upgrade dei cluster Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Pianificare l'upgrade

Best practice

Eseguire l'upgrade dei controlli preliminari

Problemi noti

Configurare le opzioni di upgrade

Upgrade selettivi del pool di nodi worker

Disallineamento delle versioni pool di nodi di due versioni secondarie

1,30

1,29

1,28

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

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

Esegui il rollback dell'upgrade di un pool di nodi

1,30

1,29

1,28

bmctl

kubectl

Upgrade paralleli

Strategia di upgrade dei nodi

Strategia di upgrade del node pool

Come eseguire un upgrade parallelo

Valori predefiniti dell'upgrade parallelo

Avvia l'upgrade del cluster

bmctl

kubectl

Mettere in pausa e riprendere gli upgrade

Abilitare la pausa e la ripresa dell'upgrade

Google Distributed Cloud 1.32

Google Distributed Cloud 1.31

Mettere in pausa un upgrade

Riprendere un upgrade in pausa

Eseguire l'upgrade dei cluster

`bmctl`

`kubectl`

`bmctl`

`kubectl`