Anthos clusters on bare metal è ora Google Distributed Cloud (solo software) per bare metal. Per ulteriori informazioni, consulta la panoramica del prodotto.

Questa pagina è stata tradotta dall'API Cloud Translation.

Esegui l'upgrade dei cluster

Se installi una nuova versione di bmctl, puoi eseguire l'upgrade delle app esistenti creati con una versione precedente. L'upgrade di un cluster l'ultima versione di Google Distributed Cloud introduce funzionalità e correzioni aggiuntive per in un cluster Kubernetes. Garantisce inoltre che il cluster resti supportato. Puoi eseguire l'upgrade di cluster di amministrazione, ibridi, autonomi o utente con bmctl upgrade cluster oppure puoi usare kubectl.

Per saperne di più sul processo di upgrade e sulle regole di controllo delle versioni, consulta Ciclo di vita e fasi degli upgrade dei cluster.

Questa pagina è rivolta agli amministratori, agli architetti e agli operatori che gestiscono ciclo di vita dell'infrastruttura tecnica sottostante. Per scoprire di più sui modelli ruoli e attività di esempio a cui facciamo riferimento nei contenuti di Google Cloud, vedi Ruoli e attività utente comuni di GKE Enterprise.

Pianifica l'upgrade

Questa sezione contiene informazioni e link a informazioni che dovresti 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, Ciclo di vita e fasi degli upgrade dei cluster.

Best practice

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

Esegui l'upgrade dei controlli preflight

I controlli preflight vengono eseguiti nell'ambito dell'upgrade del cluster per convalidare il cluster e l'integrità del nodo. L'upgrade del cluster non procede se il preflight controlli non andati a buon fine. Per ulteriori informazioni sui controlli preflight, vedi Informazioni sui controlli preflight.

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

Problemi noti

Per informazioni sui potenziali problemi relativi agli upgrade dei cluster, consulta Google Distributed Cloud per problemi noti 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 il seguente upgrade opzioni che controllano il funzionamento del processo di upgrade:

Upgrade selettivi del pool di nodi worker: upgrade specifico pool di nodi worker separatamente dal resto del cluster.
Upgrade paralleli: configura il processo di upgrade a eseguire l'upgrade di gruppi di nodi o pool di nodi contemporaneamente.

Queste opzioni possono ridurre il rischio di interruzioni delle applicazioni critiche e ridurre significativamente i tempi complessivi di upgrade. Queste opzioni sono particolarmente utile per cluster di grandi dimensioni con numerosi nodi e pool di nodi in esecuzione carichi di lavoro più importanti. Per ulteriori informazioni su cosa fanno queste opzioni e su come consulta le sezioni seguenti.

Upgrade selettivi del pool di nodi di 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, comporta lo svuotamento di ciascun nodo e lo svuotamento di tutti i pod associati è stato riavviato e riprogrammato. Questa sezione descrive come includere o escludere seleziona pool di nodi worker per l'upgrade di un cluster al fine di ridurre al minimo l'interruzione del carico di lavoro. Questa funzionalità si applica solo a cluster utente, ibridi e autonomi, poiché l'amministratore i cluster non consentono i pool di nodi worker.

Puoi utilizzare upgrade selettivi del pool di nodi nelle seguenti situazioni:

Per applicare le correzioni di sicurezza senza interrompere i carichi di lavoro: puoi eseguire l'upgrade solo i nodi del piano di controllo (e i nodi del bilanciatore del carico) per applicare correzioni di vulnerabilità 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 Upgrade di tutti i nodi worker: puoi eseguire l'upgrade dei pool di nodi worker in modo selettivo per garantire che i carichi di lavoro vengano eseguiti correttamente pool di nodi 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 tempo ed è difficile prevedere con precisione quando un upgrade completato. Il tempo di upgrade del cluster è proporzionale al numero di nodi con upgrade eseguito. Riduzione del numero di nodi di cui è in corso l'upgrade escludendo nodi riduce i tempi di upgrade. Esegui l'upgrade più volte, ma periodi di manutenzione più prevedibili possono aiutarti nella pianificazione.

Disallineamento delle versioni del pool di nodi con due versioni secondarie

Per i cluster della versione 1.28 e successive, la versione di un pool di nodi worker può essere fino a due versioni secondarie dietro la versione del cluster (piano di controllo). Con n-2 per il disallineamento delle versioni, puoi anche saltare una versione secondaria eseguire l'upgrade di un pool di nodi worker da due versioni secondarie dietro il cluster la stessa versione secondaria del cluster.

Questo supporto per il disallineamento n-2 delle versioni 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.30, puoi avere pool di nodi worker selezionati 1,30, 1,29 e versioni 1.28.

Prima di poter eseguire l'upgrade di un cluster, tutti i pool di nodi worker devono trovarsi compatibile con la versione attuale del cluster e la destinazione alla versione del cluster esistente.

Ad esempio, se hai un cluster alla versione 1.29 e pool di nodi worker in versione 1.29, versione 1.28 e versione 1.16, è necessario eseguire l'upgrade della versione 1.16 dei pool di nodi alla versione 1.28 o 1.29 prima di eseguire l'upgrade del cluster alla versione 1,30.

Per maggiori informazioni, inclusi gli elenchi di versioni dei pool di nodi worker supportate supportato da una determinata versione del cluster (applicabile per la versione 1.29 e precedenti). Consulta Regole di controllo delle versioni del pool di nodi

1,30

Nella release 1.30, il supporto del disallineamento delle versioni n-2 per i pool di nodi worker è in GA per tutti i tipi di cluster. Questa funzionalità è abilitata per impostazione predefinita per i cluster in Versione 1.30.

I pool di nodi in qualsiasi versione di patch delle versioni secondarie 1.28 e 1.29 possono essere eseguito l'upgrade a qualsiasi versione di patch 1.30, se la versione del pool di nodi è la stessa rispetto alla versione del cluster.

1,29

Nella release 1.29, il supporto del disallineamento delle versioni n-2 per i pool di nodi worker è in GA per tutti i tipi di cluster. Questa funzionalità è abilitata per impostazione predefinita per i cluster in Versione 1.29.

Durante la transizione di questa funzionalità da Anteprima pubblica a GA, i cluster ibridi sarà comunque necessaria l'annotazione di anteprima nella seguente situazione. Se disponi per un cluster ibrido versione 1.28.x con un pool di nodi worker versione 1.16.y, devi aggiungere preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable per il cluster prima di eseguirne 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 n-2 per i pool di nodi worker è disponibile per Anteprima nella release 1.28. Per attivare questa funzionalità Anteprima, aggiungi preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable nel 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, il disallineamento massimo delle versioni tra un pool di nodi worker e il cluster è una versione secondaria.

Per ulteriori informazioni sulle regole di controllo delle versioni per l'upgrade selettivo del worker per i pool di nodi, consulta Controllo delle versioni dei pool di nodi in Ciclo di vita di upgrade dei cluster.

Esegui l'upgrade del piano di controllo del cluster e dei pool di nodi selezionati

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

Per i pool di nodi worker che vuoi includere nel cluster eseguire l'upgrade, apporta una delle seguenti modifiche alla specifica del pool di nodi:
- Imposta anthosBareMetalVersion nella specifica del pool di nodi sulla destinazione del cluster di upgrade.
- Ometti il campo anthosBareMetalVersion dalla specifica NodePool. o imposta alla stringa vuota. Per impostazione predefinita, i pool di nodi worker sono inclusi degli upgrade dei cluster.
Per i pool di nodi worker che vuoi escludere dall'upgrade, imposta anthosBareMetalVersion alla versione attuale (prima dell'upgrade) dell' cluster:
Continuare l'upgrade come descritto in Avvia 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 dei bilanciatori del carico per eseguire carichi di lavoro regolari. Non puoi eseguire selettivamente l'upgrade di un nodo del bilanciatore del carico poiché è sempre incluso nell'upgrade iniziale del cluster.
- Pool di nodi worker che non hai escluso dall'upgrade.

Ad esempio, supponiamo che la versione del cluster sia 1.29.0 ha due pool di nodi worker: wpool01 e wpool02. Inoltre, supponiamo che tu voglia di eseguire l'upgrade del piano di controllo e di wpool01 a 1.30.0-gke.1930, ma vuoi wpool02 per rimanere alla versione 1.29.0.

Il seguente estratto del file di configurazione del cluster mostra come modificare 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.30.0-gke.1930
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.30.0-gke.1930
  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.29.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 i pool di nodi da un upgrade del cluster, puoi eseguire un cluster per passare alla versione del cluster di destinazione. Pool di nodi worker escluse da un upgrade del cluster hanno anthosBareMetalVersion nella specifica NodePool impostata sulla versione precedente del cluster (prima dell'upgrade).

Per portare i pool di nodi worker alla versione attuale del cluster con upgrade eseguito:

Modifica le specifiche NodePool nel file di configurazione del cluster per il worker pool di nodi che vuoi visualizzare alla versione attuale del cluster. Imposta anthosBareMetalVersion alla versione attuale del cluster (dopo l'upgrade).

Se sono selezionati più pool di nodi worker per l'upgrade, il valore di spec.nodePoolUpgradeStrategy.concurrentNodePools nel determina il numero di pool di nodi di cui viene eseguito l'upgrade in parallelo, se qualsiasi. Se non vuoi eseguire contemporaneamente l'upgrade dei pool di nodi worker, selezionane uno un pool di nodi alla volta per l'upgrade.
Continuare l'upgrade come descritto in Avvia l'upgrade del cluster.

L'operazione di upgrade del cluster esegue l'upgrade solo del worker escluso in precedenza pool di nodi per i quali hai impostato il valore attuale di anthosBareMetalVersion, alla versione aggiornata del cluster.

Ad esempio, supponiamo che tu abbia eseguito l'upgrade del cluster alla versione 1.30.0-gke.1930, ma il pool di nodi wpool02 è ancora al livello precedente dell'upgrade del cluster versione 1.29.0. I carichi di lavoro vengono eseguiti correttamente di cui è stato eseguito l'upgrade del pool di nodi, wpool01. Ora vuoi che wpool02 con la versione attuale del cluster. Per eseguire l'upgrade di wpool02, puoi rimuovere il componente anthosBareMetalVersion o imposta il valore sulla stringa vuota.

Il seguente estratto del file di configurazione del cluster mostra come modificare 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.30.0-gke.1930
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.30.0-gke.1930
  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 plug-in, che possono influire sulle prestazioni dei carichi di lavoro. Nel caso in cui rilevi un dopo aver eseguito l'upgrade di un pool di nodi worker, puoi eseguirne la versione precedente.

Questa funzionalità non si trova nella stessa fase di lancio per tutte le versioni del cluster supportate:

1,30

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

1,29

La funzionalità di rollback del pool di nodi è disponibile Anteprima per i cluster della versione 1.29 (cluster con nodi del piano di controllo alla versione 1.29). Anche se questa funzionalità è in anteprima, devi aggiungere la seguente annotazione alla risorsa Cluster per attivare la funzionalità:

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 versione 1.28 o precedenti.

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 cluster di configurazione del deployment e applica le modifiche con il comando bmctl update:

Modifica le specifiche NodePool nel file di configurazione del cluster per pool di nodi worker di cui vuoi eseguire il rollback alla versione precedente. Imposta anthosBareMetalVersion sul cluster precedente (pre-upgrade) completamente gestita.
```
...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.29.400-gke.86
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  ...
```
Se sono selezionati più pool di nodi worker per il rollback, il valore spec.nodePoolUpgradeStrategy.concurrentNodePools pollici la specifica del cluster determina per quanti pool di nodi viene eseguito il rollback 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 Impostazioni di nodePoolUpgradeStrategy. Analogamente, il valore spec.upgradeStrategy.parallelUpgrade.concurrentNodes in NodePool determina per quanti nodi 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 ti interessa da aggiornare.
- ADMIN_KUBECONFIG: il percorso di kubeconfig del cluster di gestione (amministratore, ibrido o autonomo).
Il rollback si avvia automaticamente. Il comando bmctl update cluster si chiude immediatamente, ma il rollback continua ad avanzare. Non eseguire a qualsiasi altra operazione sul cluster mentre è in corso il rollback.
Durante l'esecuzione del rollback, Google Distributed Cloud esegue quanto segue per ogni nodo:
- Imposta il nodo in modalità di manutenzione.
- Esegui un job di ripristino sul nodo per riportarlo a uno stato pulito.
- Esegui preflight della macchina controlla nodo.
- Esegui un job machine-init sul nodo per reinstallarlo nella destinazione di rollback (prima dell'upgrade).
- Rimuovi il nodo dalla modalità di manutenzione.
Al termine di un rollback corretto, il valore nodePool.status.anthosBareMetalVersion nella risorsa NodePool impostata alla versione di rollback di destinazione.

di Gemini Advanced.

Non usare bmctl update e kubectl apply -f in modo intercambiabile quando modifichi il file di configurazione del cluster. Quando questi vengono usati in modo intercambiabile, ovvero i contenuti potrebbe essere rimossa involontariamente. Ad esempio, potresti utilizzare bmctl update per aggiornare il file di configurazione del cluster configurare un mirror del registro. Il cluster ha quindi completato spec.nodeConfig.registryMirrors dopo la riconciliazione.

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

`kubectl`

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

Per eseguire il rollback di un pool di nodi worker, apri la risorsa NodePool 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 esegui il rollback.
- CLUSTER_NAMESPACE: il nome dello spazio dei nomi in di cui viene eseguito il deployment del pool di nodi. Questo è lo spazio dei nomi del cluster.
- ADMIN_KUBECONFIG: il percorso di kubeconfig del cluster di gestione (amministratore, ibrido o autonomo).

Sostituisci il valore di spec.anthosBareMetalVersion con il valore precedente (prima dell'upgrade).

...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.29.400-gke.86
  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 si avvia automaticamente. Non eseguire altre operazioni su nel cluster mentre è in corso il rollback.
Durante l'esecuzione del rollback, Google Distributed Cloud esegue quanto segue per ogni nodo:
- Imposta il nodo in modalità di manutenzione.
- Esegui un job di ripristino sul nodo per riportarlo a uno stato pulito.
- Esegui preflight della macchina controlla nodo.
- Esegui un job machine-init sul nodo per reinstallarlo nella destinazione di rollback (prima dell'upgrade).
- Rimuovi il nodo dalla modalità di manutenzione.
Al termine di un rollback corretto, il valore nodePool.status.anthosBareMetalVersion nella risorsa NodePool impostata alla versione di rollback di destinazione.

Upgrade paralleli

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

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

Upgrade simultaneo dei nodi: puoi configurare i pool di nodi worker in modo che per eseguire l'upgrade di più nodi in parallelo. Gli upgrade paralleli dei nodi configurato nella specifica del pool di nodi (spec.upgradeStrategy.parallelUpgrade) e è possibile eseguire l'upgrade in parallelo solo dei nodi di un pool di nodi worker. Nodi in dei pool di nodi del piano di controllo o del bilanciatore del carico può essere eseguito solo uno alla volta nel tempo. Per ulteriori informazioni, consulta Strategia di upgrade dei nodi.
Upgrade simultaneo del pool di nodi: puoi configurare il cluster in modo che di più pool di nodi in parallelo. Solo i pool di nodi worker possono essere in parallelo. I pool di nodi del piano di controllo e del bilanciatore del carico possono essere ne viene eseguito uno alla volta.

Strategia di upgrade dei nodi

Puoi configurare pool di nodi worker in modo che più nodi eseguano l'upgrade contemporaneamente (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 creata nelle specifiche del pool di nodi. Per ulteriori informazioni su questi campi, consulta Riferimento per il campo 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 un cluster upgrade dei nodi nel piano di controllo e nel bilanciatore del carico, upgrade dei pool di nodi in sequenza, uno alla volta. Pool di nodi del piano di controllo e nodo del bilanciatore del carico sono specificati nelle specifiche 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 né il 50% del numero di nodi nel pool di nodi o il numero fisso 15, a seconda di quale sia il numero minore. Ad esempio, se il 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, il valore i valori combinati non possono superare il numero totale di nodi nel pool di nodi. Per Ad esempio, se il pool di nodi ha 20 nodi e il valore minimumAvailableNodes è impostato su 18, il valore concurrentNodes non può essere maggiore di 2. Allo stesso modo, se concurrentNodes è impostato su 10, il valore minimumAvailableNodes non può essere superiore a 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 devono rimanere almeno 4 nodi 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 pool di nodi

Puoi configurare un cluster in modo che l'upgrade di più pool di nodi worker avvenga in parallelo. Il campo booleano nodePoolUpgradeStrategy.concurrentNodePools nella sezione specifica se eseguire l'upgrade di tutti i pool di nodi worker per un in un cluster contemporaneamente. Per impostazione predefinita (1), l'upgrade dei pool di nodi in sequenza, uno dopo l'altro. Se imposti concurrentNodePools a 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. L'upgrade di questi pool di nodi è sempre sequenziale, uno alla volta. Nodo del piano di controllo i pool di nodi e i pool di nodi del bilanciatore del carico sono specificati nella (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 upgrade paralleli.

Eseguire un upgrade parallelo dei pool di nodi worker e dei nodi in un nodo worker. pool, segui questi passaggi:

Aggiungi una sezione upgradeStrategy alla specifica del pool di nodi.

Puoi applicare questo manifest separatamente o come parte del cluster di configurazione 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, 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 tutta la durata dell'upgrade.

Nota: non puoi specificare una strategia di upgrade dei nodi per il piano di controllo o il carico pool di nodi del bilanciatore.
Aggiungi una sezione nodePoolUpgradeStrategy alla specifica del cluster nel 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.30.0-gke.1930
  ...
  nodePoolUpgradeStrategy:
    concurrentNodePools: 0
  ...
```
In questo esempio, il campo concurrentNodePools è impostato su 0, il che significa eseguire contemporaneamente l'upgrade di tutti i pool di nodi worker durante l'upgrade del cluster. La strategia di upgrade per i nodi nei pool di nodi è definita nella specifiche del pool di nodi.
Esegui l'upgrade del cluster come descritto nella precedente Esegui l'upgrade di cluster amministrativi, autonomi, ibridi o utente .

Valori predefiniti per upgrade parallelo

Gli upgrade paralleli sono disattivati per impostazione predefinita e i campi relativi al monitoraggio sono mutabili. In qualsiasi momento puoi rimuovere i campi o impostarli ai valori predefiniti per disattivare la funzionalità prima di un successivo upgrade.

La seguente tabella 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` (specifiche di NodePool)	`1`	Esegui l'upgrade dei nodi in sequenza, uno dopo l'altro.
`upgradeStrategy.parallelUpgrade.minimumAvailableNodes` (specifiche di NodePool)	Il valore predefinito di `minimumAvailableNodes` dipende dal valore di `concurrentNodes`. Se non specifichi `concurrentNodes`, per impostazione predefinita il valore di `minimumAvailableNodes` è 2/3 della dimensione del pool di nodi. Se specifichi `concurrentNodes`, per impostazione predefinita viene utilizzata la dimensione del pool di nodi `minimumAvailableNodes` meno `concurrentNodes`.	L'upgrade si blocca una volta raggiunto `minimumAvailableNodes` e continua solo quando il numero di nodi disponibili è superiore a `minimumAvailableNodes`.

Avvia l'upgrade del cluster

Questa sezione contiene istruzioni per l'upgrade dei cluster.

`bmctl`

Se scarichi e installi una nuova versione di bmctl, puoi eseguire l'upgrade del tuo di amministrazione, ibridi, autonomi e utenti creati con una versione precedente. Per una determinata versione di bmctl, è possibile eseguire l'upgrade di un cluster alla stessa versione .

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 maggiori informazioni informazioni, consulta Configurare le impostazioni predefinite dell'applicazione Credenziali.
Scarica l'ultima versione di bmctl come descritto in Download di Google Distributed Cloud.
Aggiorna anthosBareMetalVersion nel file di configurazione del cluster con eseguire l'upgrade della versione di destinazione.

La versione di destinazione dell'upgrade deve corrispondere alla versione del download bmctl. Il seguente snippet del file di configurazione del cluster mostra 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.30.0-gke.1930
```
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 cluster di amministrazione kubeconfig.
L'operazione di upgrade del cluster esegue controlli preflight per convalidare il cluster e l'integrità del nodo. L'upgrade del cluster non continua se controlli preflight non riusciti. Per informazioni sulla risoluzione dei problemi, vedi Risolvi i problemi di installazione o upgrade del cluster.

Una volta eseguito l'upgrade di tutti i componenti del cluster, di upgrade del cluster esegue controlli di integrità del cluster. Questo ultimo passaggio verifica che il cluster sia in buone condizioni di funzionamento. Se il cluster non supera tutti i controlli di integrità, continuano a essere eseguiti fino a quando non vengono superati. Quando tutti i controlli di integrità sono stati superati, l'upgrade viene completato correttamente.

Per saperne di più sulla sequenza degli 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 impostando anthosBareMetalVersion sul eseguire l'upgrade della versione di destinazione.
Per avviare l'upgrade, esegui questo comando:
```
kubectl apply -f CLUSTER_CONFIG_PATH
```
Sostituisci CLUSTER_CONFIG_PATH con il percorso del di configurazione del cluster modificato.

Come nel caso del processo di upgrade con bmctl, i controlli preflight vengono eseguiti nell'ambito di l'upgrade del cluster per convalidarne lo stato e l'integrità del nodo. Se l'istanza preflight non vanno a buon fine, l'upgrade del cluster viene interrotto. Per risolvere eventuali errori, esaminare il cluster e i relativi log, poiché non viene creato alcun cluster di bootstrap. Per ulteriori informazioni, vedi Risolvi i problemi di installazione o upgrade del cluster.

Anche se non hai bisogno dell'ultima versione di bmctl per eseguire l'upgrade con kubectl, ti consigliamo scarica l'ultima versione di bmctl. È necessario bmctl per eseguire altre attività, come i controlli di integrità e i backup, per garantire che rimane in buono stato di funzionamento.

Mettere in pausa e riprendere gli upgrade

La funzionalità di messa in pausa e ripresa dell'upgrade ti consente di mettere in pausa l'upgrade di un cluster prima che avvenga finiture in cui sono finite. Quando l'upgrade di un cluster è in pausa, non vengono eseguiti nuovi upgrade dei nodi worker finché l'upgrade non viene ripreso.

Questa funzionalità è disponibile in (Anteprima) per cluster con tutti i nodi del piano di controllo con versione secondaria 1.28 o successiva. La è GA per i cluster con tutti i nodi del piano di controllo nella versione secondaria 1.29 in alto.

Ti consigliamo di mettere in pausa un upgrade per i seguenti motivi:

Hai rilevato qualcosa di sbagliato nei carichi di lavoro del cluster durante l'upgrade e vuoi mettere in pausa l'upgrade per analizzare il problema
Hai periodi di manutenzione brevi, quindi vuoi mettere in pausa l'upgrade tra tra le finestre

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

Quando un nuovo nodo viene aggiunto mentre un upgrade è in pausa, i job di controllo delle macchine non finché l'upgrade non viene ripreso e completato.

Mentre l'upgrade del cluster è in pausa, le seguenti operazioni del cluster non vengono supportati:

Non puoi avviare un upgrade di un nuovo cluster mentre è in corso l'upgrade di un cluster attivo in pausa.

Abilita la messa in pausa e la ripresa dell'upgrade

Google Distributed Cloud 1.30

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

Google Distributed Cloud 1.29

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

Per mettere in pausa e riprendere l'upgrade, segui questi passaggi:

Aggiungi preview.baremetal.cluster.gke.io/upgrade-pause-and-resume nel 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
spec:
...

Per applicare la modifica, aggiorna il cluster:
```
bmctl update CLUSTER_NAME
```
La nodePoolUpgradeStrategy.pause è modificabile. Puoi aggiungerlo e aggiornarlo in qualsiasi momento.

Metti in pausa un upgrade

Metti in pausa l'upgrade di un cluster impostando nodePoolUpgradeStrategy.pause su true nella specifica del cluster.

Per mettere in pausa l'upgrade di un cluster attivo:

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, ti servirà 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 stai pianificando una di 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 modifiche nello stato di pausa dell'upgrade, quindi non si chiude automaticamente. Tuttavia, quando esci da bmctl, la registrazione viene interrotta avanzamento dell'upgrade al log di cluster-upgrade-TIMESTAMP nella cartella del cluster sulla workstation di amministrazione in Cloud Logging. Di conseguenza, per le pause brevi, ti consigliamo di mantenere bmctl in esecuzione. Se lasci in esecuzione bmctl per un periodo prolungato mentre è in pausa, alla fine si verifica un timeout.

Riprendi un upgrade in pausa

Puoi riprendere l'upgrade di un cluster in pausa tramite una delle due impostazioni Da nodePoolUpgradeStrategy.pause a false nella specifica del cluster o rimozione nodePoolUpgradeStrategy.pause secondo le specifiche.

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é per impostazione predefinita 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, devi prima ottenere un elenco delle risorse che hanno anthosBareMetalVersion nel loro status:

kubectl get RESOURCE --kubeconfig ADMIN_KUBECONFIG --all_namespaces

Sostituisci quanto segue:

RESOURCE: il nome della risorsa che vuoi ottenere. Le risorse Cluster, NodePool e BareMetalMachine contengono tutte Informazioni sullo stato di anthosBareMetalVersion.
ADMIN_KUBECONFIG: il percorso del cluster di amministrazione kubeconfig.

L'esempio seguente mostra il formato della risposta per BareMetalMachine risorse personalizzate. Ogni BareMetalMachine corrisponde a un nodo 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 (versione attuale 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 cluster nodo 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 si trova alla versione 1.16.2 di Google Distributed Cloud.