Questa pagina è stata tradotta dall'API Cloud Translation.

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 GKE su Bare Metal offre funzionalità e correzioni aggiuntive al cluster. Inoltre, garantisce che il cluster rimanga supportato. Puoi eseguire l'upgrade di cluster di amministrazione, ibridi, autonomi o utente con il comando bmctl upgrade cluster oppure puoi utilizzare kubectl.

Per scoprire di più sul processo di upgrade, consulta Ciclo di vita e fasi degli upgrade del cluster.

Pianifica l'upgrade

Questa sezione contiene informazioni e link a informazioni che devi prendere in considerazione prima di eseguire l'upgrade di un cluster.

best practice

Per informazioni su come prepararti per un upgrade del cluster, consulta Best practice per gli upgrade dei cluster Anthos clusters on bare metal.

Esegui l'upgrade dei controlli preflight

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 Comprendere i controlli preflight.

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

Problemi noti

Per informazioni su potenziali problemi relativi agli upgrade dei cluster, consulta Problemi noti di Anthos clusters on bare metal e seleziona la categoria di problemi Upgrade e aggiornamenti.

Configura le opzioni di upgrade

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

Upgrade selettivi del 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 per eseguire contemporaneamente l'upgrade di gruppi di nodi o pool di nodi.

Queste opzioni possono ridurre il rischio di interruzioni di applicazioni e servizi critici e ridurre in modo significativo i tempi complessivi di upgrade. Queste opzioni sono particolarmente utili per cluster di grandi dimensioni con numerosi nodi e pool di nodi che eseguono carichi di lavoro importanti. Per ulteriori informazioni su cosa fanno queste opzioni e su come utilizzarle, consulta le sezioni seguenti.

Upgrade del pool di nodi worker selettivi

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 fastidioso e richiedere molto tempo, in quanto comporta lo svuotamento di ogni nodo e il riavvio/ripianificazione di tutti i pod associati. Questa sezione descrive come includere o escludere determinati pool di nodi worker per un upgrade del cluster, in modo da ridurre al minimo l'interruzione dei carichi di lavoro. 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 upgrade selettivi dei pool di nodi nelle seguenti situazioni:

Per applicare correzioni di sicurezza senza interrompere i carichi di lavoro: puoi eseguire l'upgrade solo dei nodi del piano di controllo (e dei nodi del bilanciatore del carico) per applicare correzioni di vulnerabilità Kubernetes senza interrompere i pool di nodi worker.
Per verificare il corretto funzionamento di un sottoinsieme aggiornato di nodi worker 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 aggiornato 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 ristretti e più prevedibili possono essere utili per la pianificazione.

Per le 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 del cluster.

Esegui l'upgrade del piano di controllo del cluster e dei pool di nodi 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 del pool di nodi:
- Imposta anthosBareMetalVersion nella specifica del pool di nodi sulla versione dell'upgrade della destinazione del cluster.
- Ometti il campo anthosBareMetalVersion dalla specifica del pool di nodi o impostalo sulla stringa vuota. Per impostazione predefinita, i pool di nodi worker sono inclusi negli upgrade dei cluster.
Per i pool di nodi worker che vuoi escludere dall'upgrade, imposta anthosBareMetalVersion sulla versione attuale (prima dell'upgrade) del cluster:
Continua con l'upgrade come descritto in Avviare l'upgrade del cluster.

L'operazione di upgrade del cluster esegue l'upgrade dei seguenti nodi:
- Nodi del piano di controllo 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 carichi di lavoro normali. Non puoi eseguire l'upgrade selettivo di un pool di nodi del bilanciatore del carico, poiché è sempre incluso nell'upgrade iniziale del cluster.
- Pool di nodi worker non esclusi dall'upgrade.

Ad esempio, supponiamo che il tuo cluster sia alla versione 1.15.0 e che abbia due pool di nodi worker: wpool01 e wpool02. Supponiamo inoltre di voler eseguire l'upgrade del piano di controllo e di wpool01 alla versione 1.16.8, ma di voler mantenere la versione 1.15.0 di wpool02.

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.16.8
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.16.8
  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.15.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 pool di nodi alla versione attuale del cluster

Se hai escluso pool di nodi 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 esclusi da un upgrade del cluster hanno il campo anthosBareMetalVersion nella specifica del pool di nodi impostata sulla versione precedente del cluster (pre-upgrade).

Per portare i pool di nodi worker alla versione attuale del cluster aggiornata:

Modifica le specifiche del pool di nodi nel file di configurazione del cluster per i pool di nodi worker che vuoi visualizzare nella versione attuale del cluster. Imposta anthosBareMetalVersion sulla versione attuale del cluster (dopo l'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 sottoposti a upgrade in parallelo, se presente. Se non vuoi eseguire contemporaneamente l'upgrade dei pool di nodi worker, seleziona un pool di nodi alla volta.
Continua con l'upgrade come descritto in Avviare l'upgrade del cluster.

L'operazione di upgrade del cluster esegue l'upgrade solo dei pool di nodi worker esclusi in precedenza per i quali hai impostato anthosBareMetalVersion sulla versione attuale del cluster con upgrade eseguito.

Ad esempio, supponiamo che tu abbia eseguito l'upgrade del cluster alla versione 1.16.8, ma che il pool di nodi wpool02 sia ancora alla versione precedente del cluster prima dell'upgrade 1.15.0. I carichi di lavoro vengono eseguiti correttamente sul pool di nodi di cui è stato eseguito l'upgrade, wpool01, quindi ora vuoi portare wpool02 anche alla versione attuale del cluster. Per eseguire l'upgrade di wpool02, puoi rimuovere il campo anthosBareMetalVersion o impostare 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.16.8
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.16.8
  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

Upgrade paralleli

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

Esistono due strategie di upgrade parallelo che puoi utilizzare per accelerare 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 del pool di nodi (spec.upgradeStrategy.parallelUpgrade) ed è possibile eseguire l'upgrade in parallelo solo dei nodi in un pool di nodi worker. È possibile eseguire l'upgrade dei nodi nel piano di controllo o nei pool di nodi del bilanciatore del carico solo uno alla volta. Per ulteriori informazioni, consulta la sezione 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. È possibile eseguire l'upgrade in parallelo solo dei pool di nodi worker. È possibile eseguire l'upgrade dei pool di nodi del piano di controllo e del bilanciatore del carico solo uno alla volta.

Strategia di upgrade dei nodi

Puoi configurare pool di nodi worker in modo che più nodi eseguano contemporaneamente l'upgrade (concurrentNodes). Puoi anche impostare una soglia minima per il numero di nodi in grado di eseguire carichi di lavoro durante il processo di upgrade (minimumAvailableNodes). Questa configurazione viene effettuata nella specifica del pool di nodi. Per ulteriori informazioni su questi campi, consulta la documentazione di riferimento sui campi di configurazione del cluster.

La strategia di upgrade dei nodi si applica solo ai pool di nodi worker. Non puoi specificare una strategia di upgrade dei nodi per i pool di nodi del piano di controllo o del bilanciatore del carico. Durante l'upgrade di un cluster, i nodi nel piano di controllo e nei pool di nodi del bilanciatore del carico vengono aggiornati 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).

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

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 delle due opzioni è inferiore. Ad esempio, se il tuo pool di nodi ha 20 nodi, non puoi specificare un valore superiore a 10. Se il tuo 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, il valore concurrentNodes non può essere superiore a 2. Allo stesso modo, se concurrentNodes è impostato su 10, il valore minimumAvailableNodes non può essere maggiore di 10.

L'esempio seguente mostra un pool di nodi worker np1 con 10 nodi. In un upgrade, i nodi eseguono l'upgrade di 5 nodi alla volta e devono rimanere disponibili almeno quattro nodi affinché l'upgrade prosegua:

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 pool di nodi

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

I pool di nodi del piano di controllo e del bilanciamento del carico non sono interessati da questa impostazione. Questi pool di nodi vengono sempre aggiornati 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 di pool di nodi worker e nodi in un pool di nodi worker:

Aggiungi una sezione upgradeStrategy alla specifica del pool di nodi.

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 5 nodi vengono aggiornati in parallelo. Il campo minimumAvailableNodes è impostato su 10, il che significa che devono rimanere disponibili almeno 10 nodi per i carichi di lavoro durante l'upgrade.

Nota: non puoi specificare una strategia di upgrade dei nodi per i pool di nodi del piano di controllo o 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.16.8
  ...
  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 del pool di nodi.
Esegui l'upgrade del cluster come descritto nella sezione precedente Esegui l'upgrade dei cluster amministrativi, autonomi, ibridi o utente precedente.

Valori predefiniti per l'upgrade parallelo

Gli upgrade paralleli sono disabilitati 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 disabilitare la funzionalità prima di un upgrade successivo.

Nella tabella seguente sono elencati 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 del pool di nodi)	`1`	Esegui l'upgrade dei nodi in sequenza, uno dopo l'altro.
`upgradeStrategy.parallelUpgrade.minimumAvailableNodes` (specifica del pool di nodi)	Il valore predefinito di `minimumAvailableNodes` dipende dal valore di `concurrentNodes`. Se non specifichi `concurrentNodes`, `minimumAvailableNodes` per impostazione predefinita corrisponde ai 2/3 della dimensione 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 supera `minimumAvailableNodes`.

Avvia l'upgrade del cluster

Questa sezione contiene le istruzioni per eseguire 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.

Scarica l'ultima versione di bmctl come descritto nella sezione Download di GKE sui download Bare Metal.
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 alla versione più recente:
```
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
spec:
  type: admin
  # Anthos cluster version.
  anthosBareMetalVersion: 1.16.8
```
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 Risolvere i problemi di installazione o upgrade del cluster.

Una volta completato 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à, continueranno a essere eseguiti fino al superamento. Una volta superati tutti i controlli di integrità, l'upgrade termina correttamente.

Per ulteriori informazioni sulla sequenza degli eventi per gli upgrade dei cluster, consulta Ciclo di vita e fasi degli upgrade del 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 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 ulteriori informazioni, consulta Risolvere i problemi di installazione o upgrade dei cluster.

Anche se non è necessaria la versione più recente di bmctl per eseguire l'upgrade dei cluter con kubectl, ti consigliamo di scaricare l'ultima versione di bmctl. È necessario bmctl per eseguire altre attività, come controlli di integrità e backup, per garantire che il cluster continui a funzionare.