Esegui l'upgrade dei cluster

Quando installi una nuova versione di bmctl, puoi eseguire l'upgrade dei cluster esistenti creati con una versione precedente. L'upgrade di un cluster alla versione più recente di Google Distributed Cloud offre funzionalità e correzioni aggiuntive 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 e sulle regole di controllo delle versioni, 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 le 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 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 Google Distributed Cloud per problemi noti di 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 e la 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.

Disallineamento delle versioni dei pool di nodi delle versioni secondarie

Per i cluster versione 1.28 e successive, la versione del pool di nodi worker può essere al massimo due versioni secondarie dietro la versione del cluster (piano di controllo). Il supporto del disallineamento della versione n-2 per i pool di nodi worker offre una maggiore flessibilità per pianificare gli upgrade del parco risorse. Ad esempio, non è necessario eseguire l'upgrade di tutti i pool di nodi worker della versione 1.16 alla versione 1.28 prima di poter eseguire l'upgrade del cluster alla versione 1.29.

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

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

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

Esegui l'upgrade del 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:

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

2. Per i pool di nodi worker che vuoi escludere dall'upgrade, imposta anthosBareMetalVersion sulla versione attuale (prima dell'upgrade) del cluster:

3. 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, supponi che il tuo cluster abbia la versione 1.28.0 e che abbia due pool di nodi worker: wpool01 e wpool02. Supponiamo anche di voler eseguire l'upgrade del piano di controllo e di wpool01 alla versione 1.29.100-gke.251, ma di voler mantenere la versione 1.28.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.29.100-gke.251
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.29.100-gke.251
  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.28.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 NodePool impostata sulla versione precedente del cluster (prima dell'upgrade).

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

1. Modifica le specifiche NodePool 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.

2. 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, supponi di aver eseguito l'upgrade del cluster alla versione 1.29.100-gke.251, ma il pool di nodi wpool02 è ancora alla versione precedente del cluster prima dell'upgrade 1.28.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.29.100-gke.251
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.29.100-gke.251
  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 di un pool di nodi

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

La funzionalità di rollback del pool di nodi è disponibile per l'anteprima per i cluster della versione 1.29 (cluster con nodi del piano di controllo alla versione 1.29). Mentre questa funzionalità è in anteprima, devi aggiungere l'annotazione preview.baremetal.cluster.gke.io/worker-node-pool-upgrade-rollback: enable alla risorsa Cluster per abilitarla.

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

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:

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

2. 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.29.100-gke.251
     ...
     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.

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

Avvia l'upgrade del cluster

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

Mettere in pausa e riprendere gli upgrade

La funzionalità di pausa e ripresa dell'upgrade ti consente di mettere in pausa l'upgrade di un cluster prima del suo completamento. Quando un upgrade del cluster è in pausa, non vengono attivati nuovi upgrade dei nodi worker fino a quando non viene ripreso.

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

Puoi mettere in pausa un upgrade per i seguenti motivi:

• Hai rilevato un problema con i carichi di lavoro del cluster durante l'upgrade e vuoi metterlo in pausa per esaminare il problema

• Poiché i periodi di manutenzione sono brevi, vuoi mettere in pausa l'upgrade tra un periodo e l'altro

Mentre un upgrade del cluster è in pausa, sono supportate le seguenti operazioni:

• Aggiunta o rimozione di nodi
• Aggiunta o rimozione di pool di nodi
• Aumento dell'intervallo della rete di servizi
• Ripristinare un cluster da un backup

Quando viene aggiunto un nuovo nodo mentre un upgrade è in pausa, i job di controllo delle macchine 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:

• Autorità di certificazione in rotazione
• Backup di un cluster

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

Abilita pausa e riprendi l'upgrade

Mettere in pausa un upgrade

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

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

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

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

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

2. Per applicare la modifica, aggiorna il cluster:

   bmctl update CLUSTER_NAME
   

   L'operazione di upgrade è in pausa. Non viene attivato alcun nuovo upgrade del nodo.

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

   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, si interrompe il logging dell'avanzamento dell'upgrade al file di log cluster-upgrade-TIMESTAMP nella cartella del cluster sulla workstation di amministrazione e in Cloud Logging. Pertanto, per brevi pause, ti consigliamo di mantenere bmctl in esecuzione. Se lasci bmctl in esecuzione per un periodo prolungato mentre l'upgrade è in pausa, si verifica il timeout.

Riprendere un upgrade in pausa

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

Per riprendere un upgrade del cluster che è stato messo in pausa:

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

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

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

2. Per applicare la modifica, aggiorna il cluster:

   bmctl update CLUSTER_NAME
   

   L'operazione di upgrade riprende dal punto in cui era stata interrotta.

3. Per controllare lo stato dell'upgrade, ottieni prima un elenco delle risorse che hanno anthosBareMetalVersion in 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 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 cluster.

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

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

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

   L'esempio seguente mostra i dettagli 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 si trova alla versione Google Distributed Cloud 1.16.2.