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 introduce funzionalità e correzioni aggiuntive per il tuo 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 dei 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 che ti aiutino 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 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 preflight, vedi Comprendere i controlli preflight.

Puoi verificare se i cluster sono pronti per un upgrade eseguendo il controllo preflight prima dell'upgrade. Per ulteriori informazioni, consulta la pagina Controlli preflight per gli upgrade.

Problemi noti

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

Configura le opzioni di upgrade

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

Queste opzioni possono ridurre il rischio di interruzioni di applicazioni e servizi critici e ridurre notevolmente 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 come utilizzarle, 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, poiché determina lo svuotamento di ogni nodo e il riavvio e la ripianificazione di tutti i pod associati. Questa sezione descrive come includere o escludere pool di nodi worker selezionati per l'upgrade di un cluster al fine di ridurre al minimo l'interruzione del carico 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 del pool di nodi nelle seguenti situazioni:

  • Per applicare le 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 le correzioni di vulnerabilità Kubernetes senza interrompere i pool di nodi worker.

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

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

Disallineamento delle versioni del pool di nodi con due versioni secondarie

Per i cluster della versione 1.28 e successive, una versione del pool di nodi worker può essere fino a due versioni secondarie rispetto alla versione del cluster (piano di controllo). Con il supporto del disallineamento della versione n-2, puoi anche saltare una versione di release secondaria quando esegui l'upgrade di un pool di nodi worker da due versioni secondarie dietro il cluster alla 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 disponi di un cluster della versione 1.28, puoi avere pool di nodi worker selezionare le versioni 1.28, 1.16 e 1.15. Per eseguire l'upgrade del cluster alla versione 1.29, devi prima eseguire l'upgrade di qualsiasi pool di nodi worker 1.15 a una versione supportata per il cluster della versione 1.28 precedente all'upgrade. Non è necessario eseguire l'upgrade dei pool di nodi worker alla versione 1.16 alla versione 1.28 prima di poter eseguire l'upgrade del cluster alla versione 1.29. Una volta eseguito l'upgrade del cluster alla versione 1.29, se decidi di eseguire l'upgrade dei pool di nodi worker dalla versione 1.16 alla versione 1.29, puoi eseguire l'upgrade in un solo passaggio, saltando la versione 1.28.

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

1,29

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

Durante la transizione di questa funzionalità da Anteprima pubblica a GA, i cluster ibridi continuano a richiedere l'annotazione di anteprima nella situazione seguente. Se disponi di un cluster ibrido in 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 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 l'anteprima nella release 1.28. Per abilitare 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à in 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 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 selettivamente l'upgrade 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 di 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 del cluster.

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

  3. Continua 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 selettivamente l'upgrade di un pool di nodi 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 tuo cluster sia 1.28.0 e abbia due pool di nodi worker: wpool01 e wpool02. Inoltre, supponiamo di voler eseguire l'upgrade del piano di controllo e di wpool01 alla versione 1.29.100-gke.251, ma di voler mantenere wpool02 alla versione 1.28.0.

Il seguente estratto del file di configurazione del cluster mostra come puoi 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 i pool di nodi da un upgrade del cluster, puoi eseguire un upgrade del cluster per portarli alla versione del cluster di destinazione. I pool di nodi worker che sono stati esclusi da un upgrade del cluster hanno il campo anthosBareMetalVersion nella specifica NodePool impostato sulla versione del cluster precedente (pre-upgrade).

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

  1. Modifica le specifiche NodePool nel file di configurazione del cluster per i pool di nodi worker che vuoi visualizzare alla 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 nelle specifiche del cluster determina il numero di pool di nodi di cui viene eseguito l'upgrade in parallelo, se presenti. Se non vuoi eseguire contemporaneamente l'upgrade dei pool di nodi worker, seleziona un pool di nodi alla volta per l'upgrade.

  2. Continua 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 e aggiornata del cluster.

Ad esempio, supponiamo che tu abbia eseguito l'upgrade del cluster alla versione 1.29.100-gke.251, ma che il pool di nodi wpool02 sia ancora alla versione precedente del cluster 1.28.0 prima dell'upgrade. I carichi di lavoro vengono eseguiti correttamente sul pool di nodi sottoposto ad 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 suo valore sulla stringa vuota.

Il seguente estratto del file di configurazione del cluster mostra come puoi 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 del pool di nodi

Esistono molte dipendenze, ad esempio la compatibilità con kubelet o plug-in, che possono influire sulle prestazioni dei carichi di lavoro. Se riscontri un problema dopo l'upgrade di un pool di nodi worker, puoi eseguirne il rollback alla 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 abilitare la funzionalità.

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, puoi modificare il file di configurazione del cluster e applicare le modifiche con il comando bmctl update:

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

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

    Se vengono selezionati più pool di nodi worker per il rollback, il valore di spec.nodePoolUpgradeStrategy.concurrentNodePools nella specifica del cluster determina il numero di pool di nodi di cui viene eseguito il rollback in parallelo. Se non vuoi eseguire contemporaneamente il rollback dei pool di nodi worker, 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 per quanti nodi viene eseguito il rollback in parallelo.

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

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

    Il rollback si avvia automaticamente.

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

    • Imposta il nodo in modalità di manutenzione.
    • Esegui un job di ripristino sul nodo per riportarlo a uno stato pulito.
    • Esegui controlli preflight sulla macchina sul nodo.
    • Esegui un job di inizializzazione della macchina sul nodo per reinstallarlo nella versione del rollback di destinazione (pre-upgrade).
    • Rimuovi il nodo dalla modalità di manutenzione.

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

kubectl

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

  1. Per eseguire il rollback di un pool di nodi worker, apri la risorsa NodePool per 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 è stato eseguito il deployment del pool di nodi. Questo è lo spazio dei nomi del cluster.

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

  2. Modifica il valore di spec.anthosBareMetalVersion alla versione precedente (prima dell'upgrade).

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

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

    Il rollback si avvia automaticamente.

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

    • Imposta il nodo in modalità di manutenzione.
    • Esegui un job di ripristino sul nodo per riportarlo a uno stato pulito.
    • Esegui controlli preflight sulla macchina sul nodo.
    • Esegui un job di inizializzazione della macchina sul nodo per reinstallarlo nella versione del rollback di destinazione (pre-upgrade).
    • Rimuovi il nodo dalla modalità di manutenzione.

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

Upgrade paralleli

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

Per accelerare l'upgrade del cluster, puoi utilizzare due strategie di upgrade parallele:

  • Upgrade simultaneo dei nodi: puoi configurare i tuoi pool di nodi worker in modo che più nodi eseguano l'upgrade in parallelo. Gli upgrade paralleli dei nodi vengono configurati nella specifica del pool di nodi (spec.upgradeStrategy.parallelUpgrade) e solo i nodi in un pool di nodi worker possono essere aggiornati in parallelo. È 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 Strategia di upgrade dei nodi.

  • Upgrade simultaneo del pool di nodi: puoi configurare il cluster in modo da eseguire l'upgrade di più pool di nodi in parallelo. È possibile eseguire l'upgrade in parallelo solo dei pool di nodi worker. L'upgrade dei pool di nodi del piano di controllo e del bilanciatore del carico può essere eseguito solo uno alla volta.

Strategia di upgrade dei nodi

Puoi configurare i pool di nodi worker in modo da eseguire contemporaneamente l'upgrade di più nodi (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 definita nella specifica del pool di nodi. Per ulteriori informazioni su questi campi, consulta il riferimento sul 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 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 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ò essere superiore a 2. Allo stesso modo, se concurrentNodes è impostato su 10, 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 vengono aggiornati 5 alla volta e devono rimanere disponibili almeno quattro nodi affinché l'upgrade possa procedere:

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

Strategia di upgrade del pool di nodi

Puoi configurare un cluster in modo che l'upgrade di più pool di nodi worker sia eseguito in parallelo. Il campo booleano nodePoolUpgradeStrategy.concurrentNodePools nelle specifiche del cluster specifica se eseguire o meno l'upgrade di tutti i pool di nodi worker per un cluster contemporaneamente. Per impostazione predefinita (1), l'upgrade dei pool di nodi viene eseguito in sequenza, uno dopo l'altro. Se 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. L'upgrade di questi pool di nodi è sempre sequenziale, 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, segui questi passaggi:

  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 precedente sezione Eseguire l'upgrade di cluster di amministrazione, autonomi, ibridi o utente.

Valori predefiniti per upgrade parallelo

Gli upgrade paralleli sono disabilitati per impostazione predefinita e i campi relativi agli upgrade paralleli sono mutabili. In qualsiasi momento puoi rimuovere i campi o impostarli sui valori predefiniti per disabilitare 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

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

  1. Scarica l'ultima versione di bmctl come descritto nella sezione Download di Google Distributed Cloud.

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

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

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

  3. 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 dei cluster.

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

    Per ulteriori informazioni 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:

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

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

    kubectl apply -f CLUSTER_CONFIG_PATH

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

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

Anche se non è necessaria l'ultima versione di bmctl per eseguire l'upgrade con kubectl, ti consigliamo di scaricare l'ultima versione di bmctl. Hai bisogno di bmctl per eseguire altre attività, come i controlli di integrità e i backup, per garantire che il cluster funzioni sempre correttamente.

Mettere in pausa e riprendere gli upgrade

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

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

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

  • Durante l'upgrade hai rilevato un problema nei carichi di lavoro del cluster e vuoi metterlo in pausa

  • 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 un nuovo nodo viene aggiunto mentre un upgrade è in pausa, i job di controllo delle macchine non vengono eseguiti su di esso fino a quando 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 l'upgrade di un cluster attivo è in pausa.

Abilita la messa in pausa e la ripresa dell'upgrade

Google Distributed Cloud 1.29

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

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

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

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

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

  2. Per applicare la modifica, aggiorna il cluster:

    bmctl update CLUSTER_NAME

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

Metti in pausa un upgrade

Metti in pausa un upgrade del cluster impostando nodePoolUpgradeStrategy.pause su true nelle specifiche del cluster.

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

  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, ti serve una nuova finestra del terminale per eseguire il passaggio successivo.

  2. Per applicare la modifica, aggiorna il cluster:

    bmctl update CLUSTER_NAME

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

  3. Se hai utilizzato bmctl per avviare l'upgrade e stai pianificando 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 dell'avanzamento dell'upgrade al file di log cluster-upgrade-TIMESTAMP nella cartella del cluster sulla workstation di amministrazione e a Cloud Logging viene interrotta. Pertanto, per brevi pause, potresti voler mantenere bmctl in esecuzione. Se lasci in esecuzione bmctl per un periodo prolungato mentre l'upgrade è in pausa, alla fine si verifica il timeout.

Riprendi un upgrade in pausa

Riprende l'upgrade di un cluster in pausa impostando nodePoolUpgradeStrategy.pause su false nella specifica del cluster o rimuovendo nodePoolUpgradeStrategy.pause dalla specifica.

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

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

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

    In alternativa, puoi rimuovere il campo pause, perché per impostazione predefinita è false.

  2. Per applicare la modifica, aggiorna il cluster:

    bmctl update CLUSTER_NAME

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

  3. Per controllare lo stato dell'upgrade, devi prima ottenere un elenco delle risorse con anthosBareMetalVersion in status:

    kubectl get RESOURCE --kubeconfig ADMIN_KUBECONFIG --all_namespaces

    Sostituisci quanto segue:

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

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

    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

  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 1.16.2 di Google Distributed Cloud.