Esegui l'upgrade dei cluster

Quando installi una nuova versione di bmctl, puoi eseguire l'upgrade dei cluster esistenti creati con una versione precedente. L'upgrade di un cluster alla versione più recente di GKE su Bare Metal offre funzionalità e correzioni aggiuntive al cluster. Inoltre, garantisce che il cluster rimanga supportato. Puoi eseguire l'upgrade di cluster di amministrazione, ibridi, autonomi o utente con il comando bmctl upgrade cluster oppure puoi utilizzare kubectl.

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

Pianifica l'upgrade

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

best practice

Per informazioni che ti aiuteranno a prepararti per l'upgrade di un cluster, consulta Best practice per gli upgrade di cluster GKE su Bare Metal.

Esegui l'upgrade dei controlli preflight

I controlli preflight vengono eseguiti nell'ambito dell'upgrade del cluster per convalidare lo stato del cluster e l'integrità del nodo. L'upgrade del cluster non procede se i controlli preflight non vanno a buon fine. Per saperne di più sui controlli preflight, consulta Comprendere i controlli preflight.

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

Problemi noti

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

Configura le opzioni di upgrade

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

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

Con GKE su Bare Metal release secondaria 1.28, la versione del pool di nodi worker può essere fino a due versioni secondarie dietro la versione del cluster (piano di controllo). Questo disallineamento delle versioni n-2 è disponibile come funzionalità (anteprima).

  • 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à di anteprima, il disallineamento massimo della versione tra un pool di nodi worker e il cluster è di una versione secondaria.

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.16.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.28.400-gke.77, ma di voler mantenere la versione 1.16.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.28.400-gke.77
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.28.400-gke.77
  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.16.0
  nodes:
  - address:  10.200.1.1
  - address:  10.200.1.2
  - address:  10.200.1.3
  ...
  - address:  10.200.1.12

Esegui l'upgrade dei pool di nodi alla versione attuale del cluster

Se hai escluso pool di nodi da un upgrade del cluster, puoi eseguire un upgrade del cluster che li porti alla versione del cluster di destinazione. I pool di nodi worker esclusi da un upgrade del cluster hanno il campo anthosBareMetalVersion nella specifica del pool di nodi impostata sulla versione precedente del cluster (pre-upgrade).

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

  1. Modifica le specifiche del pool di nodi nel file di configurazione del cluster per i pool di nodi worker che vuoi visualizzare nella versione attuale del cluster. Imposta anthosBareMetalVersion sulla versione attuale del cluster (dopo l'upgrade).

    Se vengono selezionati più pool di nodi worker per l'upgrade, il valore di spec.nodePoolUpgradeStrategy.concurrentNodePools nella specifica del cluster determina il numero di pool di nodi sottoposti a upgrade in parallelo, se presente. Se non vuoi eseguire contemporaneamente l'upgrade dei pool di nodi worker, seleziona un pool di nodi alla volta.

  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.28.400-gke.77, ma il pool di nodi wpool02 è ancora alla versione precedente del cluster prima dell'upgrade 1.16.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.28.400-gke.77
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.28.400-gke.77
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  ...
  - address:  10.200.0.8

apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool02
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: ""
  nodes:
  - address:  10.200.1.1
  - address:  10.200.1.2
  - address:  10.200.1.3
  ...
  - address:  10.200.1.12

Upgrade paralleli

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

Esistono due strategie di upgrade parallelo che puoi utilizzare per accelerare l'upgrade del cluster:

  • Upgrade simultaneo dei nodi: puoi configurare i pool di nodi worker in modo che più nodi vengano aggiornati in parallelo. Gli upgrade paralleli dei nodi sono configurati nella specifica del pool di nodi (spec.upgradeStrategy.parallelUpgrade) ed è possibile eseguire l'upgrade in parallelo solo dei nodi in un pool di nodi worker. È possibile eseguire l'upgrade dei nodi nel piano di controllo o nei pool di nodi del bilanciatore del carico solo uno alla volta. Per ulteriori informazioni, consulta la sezione Strategia di upgrade dei nodi.

  • Upgrade simultaneo del pool di nodi: puoi configurare il cluster in modo che più pool di nodi vengano aggiornati in parallelo. È possibile eseguire l'upgrade in parallelo solo dei pool di nodi worker. È possibile eseguire l'upgrade dei pool di nodi del piano di controllo e del bilanciatore del carico solo uno alla volta.

Strategia di upgrade dei nodi

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

La strategia di upgrade dei nodi si applica solo ai pool di nodi worker. Non puoi specificare una strategia di upgrade dei nodi per i pool di nodi del piano di controllo o del bilanciatore del carico. Durante l'upgrade di un cluster, i nodi nel piano di controllo e nei pool di nodi del bilanciatore del carico vengono aggiornati in sequenza, uno alla volta. I pool di nodi del piano di controllo e i pool di nodi del bilanciatore del carico sono specificati nella specifica del cluster (controlPlane.nodePoolSpec.nodes e loadBalancer.nodePoolSpec.nodes).

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

  • Il valore di concurrentNodes non può superare il 50% del numero di nodi nel pool di nodi o il numero fisso 15, a seconda di quale delle due opzioni è inferiore. Ad esempio, se il tuo pool di nodi ha 20 nodi, non puoi specificare un valore superiore a 10. Se il tuo pool di nodi ha 100 nodi, 15 è il valore massimo che puoi specificare.

  • Quando utilizzi concurrentNodes insieme a minimumAvailableNodes, i valori combinati non possono superare il numero totale di nodi nel pool di nodi. Ad esempio, se il pool di nodi ha 20 nodi e minimumAvailableNodes è impostato su 18, il valore concurrentNodes non può essere superiore a 2. Allo stesso modo, se concurrentNodes è impostato su 10, il valore minimumAvailableNodes non può essere maggiore di 10.

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

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

Strategia di upgrade del pool di nodi

Puoi configurare un cluster in modo che più pool di nodi worker vengano aggiornati in parallelo. Il campo booleano nodePoolUpgradeStrategy.concurrentNodePools nella specifica del cluster specifica se eseguire o meno l'upgrade di tutti i pool di nodi worker contemporaneamente per un cluster. Per impostazione predefinita (1), i pool di nodi vengono aggiornati in sequenza, uno dopo l'altro. Quando imposti concurrentNodePools su 0, ogni pool di nodi worker nel cluster viene eseguito in parallelo.

I pool di nodi del piano di controllo e del bilanciamento del carico non sono interessati da questa impostazione. Questi pool di nodi vengono sempre aggiornati in sequenza, uno alla volta. I pool di nodi del piano di controllo e i pool di nodi del bilanciatore del carico sono specificati nella specifica del cluster (controlPlane.nodePoolSpec.nodes e loadBalancer.nodePoolSpec.nodes).

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
spec:
  ...
  nodePoolUpgradeStrategy:
    concurrentNodePools: 0
  ...

Come eseguire un upgrade parallelo

Questa sezione descrive come configurare un cluster e un pool di nodi worker per gli upgrade paralleli.

Per eseguire un upgrade parallelo di pool di nodi worker e nodi in un pool di nodi worker:

  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.28.400-gke.77
  ...
  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:

Campo Valore predefinito Significato
nodePoolUpgradeStrategy.concurrentNodePools (specifica del cluster) 1 Esegui l'upgrade dei pool di nodi worker in sequenza, uno dopo l'altro.
upgradeStrategy.parallelUpgrade.concurrentNodes (specifica del pool di nodi) 1 Esegui l'upgrade dei nodi in sequenza, uno dopo l'altro.
upgradeStrategy.parallelUpgrade.minimumAvailableNodes (specifica del pool di nodi) Il valore predefinito di minimumAvailableNodes dipende dal valore di concurrentNodes.
  • Se non specifichi concurrentNodes, minimumAvailableNodes per impostazione predefinita corrisponde ai 2/3 della dimensione del pool di nodi.
  • Se specifichi concurrentNodes, minimumAvailableNodes per impostazione predefinita è la dimensione del pool di nodi meno concurrentNodes.
 L'upgrade si blocca una volta raggiunto minimumAvailableNodes e continua solo quando il numero di nodi disponibili supera minimumAvailableNodes.

Avvia l'upgrade del cluster

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

bmctl

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

  1. Scarica l'ultima versione di bmctl come descritto nella sezione Download di GKE sui download Bare Metal.

  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 alla versione più recente:

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

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

    Una volta completato l'upgrade di tutti i componenti del cluster, l'operazione di upgrade del cluster esegue i controlli di integrità del cluster. Quest'ultimo passaggio verifica che il cluster sia in buone condizioni operative. Se il cluster non supera tutti i controlli di integrità, continueranno a essere eseguiti fino al superamento. Una volta superati tutti i controlli di integrità, l'upgrade termina correttamente.

    Per ulteriori informazioni sulla sequenza degli eventi per gli upgrade dei cluster, consulta Ciclo di vita e fasi degli upgrade del cluster.

kubectl

Per eseguire l'upgrade di un cluster con kubectl, segui questi passaggi:

  1. Modifica il file di configurazione del cluster per impostare anthosBareMetalVersion sulla 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 log correlati, poiché non viene creato alcun cluster di bootstrap. Per ulteriori informazioni, consulta Risolvere i problemi di installazione o upgrade dei cluster.

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

Mettere in pausa e riprendere gli upgrade

Con GKE su Bare Metal release secondaria 1.28, puoi mettere in pausa e riprendere un upgrade del cluster. Quando un upgrade del cluster è in pausa, non vengono attivati nuovi upgrade dei nodi fino a quando non viene ripreso. Questa funzionalità è disponibile solo per i cluster con tutti i nodi del piano di controllo nella versione secondaria 1.28 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:

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:

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

Abilita pausa e riprendi l'upgrade

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

Per attivare la sospensione e la ripresa dell'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.

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
  annotations:
        preview.baremetal.cluster.gke.io/upgrade-pause-and-resume
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
  annotations:
        preview.baremetal.cluster.gke.io/upgrade-pause-and-resume
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 1.16.2 di GKE su Bare Metal.