Eseguire 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 per il tuo cluster. Inoltre, assicura che il cluster continui a essere 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ù sulla procedura di upgrade e sulle regole di versionamento, consulta Ciclo di vita e fasi degli upgrade dei cluster.

Questa pagina è rivolta ad amministratori, architetti e operatori che gestiscono il ciclo di vita dell'infrastruttura tecnica di base. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti di Google Cloud, consulta Ruoli e attività comuni degli utenti di GKE Enterprise.

Nota: quando esegui l'upgrade di Google Distributed Cloud da una versione con una patch di sicurezza alla release secondaria successiva, ti consigliamo di eseguire l'upgrade alla versione della patch più recente disponibile per assicurarti di disporre delle patch di sicurezza più recenti. Prima di eseguire l'upgrade, controlla sempre le note di rilascio per sapere cosa è cambiato, incluse le correzioni di sicurezza e i problemi noti. Il downgrade a una versione precedente del cluster non è supportato.

Pianificare l'upgrade

Questa sezione contiene informazioni e link a informazioni che dovresti esaminare prima di eseguire l'upgrade di un cluster. Per ulteriori informazioni sugli upgrade, incluse le regole di versionamento per i cluster e i pool di nodi, consulta Ciclo di vita e fasi degli upgrade dei cluster.

Best practice

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

Controlli preflight dell'upgrade

I controlli preflight vengono eseguiti nell'ambito dell'upgrade del cluster per convalidare lo stato del cluster e l'integrità dei nodi. L'upgrade del cluster non procede se i controlli preflight non superano. Per ulteriori informazioni sui controlli preflight, consulta Informazioni sui controlli preliminari.

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

Problemi noti

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

Configurare le opzioni di upgrade

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

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

Queste opzioni possono ridurre il rischio di interruzioni di servizi e applicazioni critici e ridurre notevolmente il tempo complessivo 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 usarle, consulta le sezioni seguenti.

Upgrade selettivi dei pool di nodi 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 interrotto e richiedere molto tempo, poiché comporta lo svuotamento di ogni nodo e il riavvio e la riprogrammazione di tutti i pod associati. Questa sezione descrive come includere o escludere alcuni pool di nodi worker per un upgrade del 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 pool di nodi di lavoro.

Potresti utilizzare gli upgrade selettivi dei pool di nodi nelle seguenti situazioni:

• Per applicare le correzioni di sicurezza senza interrompere i workload: puoi eseguire l'upgrade solo dei nodi del piano di controllo (e dei nodi del bilanciatore del carico) per applicare le correzioni delle vulnerabilità di Kubernetes senza interrompere i pool di nodi worker.

• Per verificare 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 funzionino 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. Il tempo necessario per l'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 le finestre di manutenzione più brevi e prevedibili possono aiutarti con la pianificazione.

Due versioni secondarie con disallineamento delle versioni pool di nodi

Per i cluster della versione 1.28 e successive, la versione di un pool di nodi worker può essere fino a due versioni secondarie precedenti alla versione del cluster (control plane). Con il supporto della differenza di 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 precedenti al cluster alla stessa versione secondaria del cluster.

Questo supporto del disallineamento delle versioni n-2 per i pool di nodi worker ti offre maggiore flessibilità per pianificare gli upgrade del tuo parco macchine.

Ad esempio, se hai un cluster della versione 1.30, puoi avere pool di nodi worker in versioni selezionate 1.30, 1.29 e 1.28.

Prima di poter eseguire l'upgrade di un cluster, tutti i pool di nodi worker devono essere in una versione compatibile sia con la versione corrente del cluster sia con la versione di destinazione del cluster.

Ad esempio, se hai un cluster con la versione 1.29 e pool di nodi worker con la versione 1.29, 1.28 e 1.16, devi eseguire l'upgrade dei pool di nodi 1.16 alla versione 1.28 o 1.29 prima di poter eseguire l'upgrade del cluster alla versione 1.30.

Per ulteriori informazioni, inclusi gli elenchi delle versioni dei pool di nodi worker supportate da una determinata versione del cluster (applicabile alla versione 1.29 e precedenti), consulta Regole di versionamento dei pool di nodi

1,30

Nella release 1.30, il supporto della versione con uno scostamento di n-2 per i pool di nodi worker è disponibile come versione GA per tutti i tipi di cluster. Questa funzionalità è abilitata per impostazione predefinita per i cluster dalla versione 1.30.

È possibile eseguire l'upgrade dei pool di nodi a qualsiasi versione patch delle versioni secondarie 1.28 e 1.29 a qualsiasi versione patch di 1.30, se la versione del pool di nodi è uguale o precedente alla versione del cluster.

1,29

Nella release 1.29, il supporto della versione con n-2 per i pool di nodi worker è disponibile come versione GA per tutti i tipi di cluster. Questa funzionalità è attivata per impostazione predefinita per i cluster dalla versione 1.29.

Durante la transizione di questa funzionalità da Anteprima pubblica a versione GA, i cluster ibride richiedono ancora l'annotazione di anteprima nella seguente situazione. Se hai un cluster ibrido della versione 1.28.x con un pool di nodi worker della versione 1.16.y, devi aggiungere l'annotazione preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable al cluster prima di eseguire 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

Anteprima

Questo prodotto o funzionalità è soggetto ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici del servizio. I prodotti e le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Il supporto del disallineamento delle versioni n-2 per i pool di node worker è disponibile per la versione Anteprima nella release 1.28. Per attivare 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 attivi questa funzionalità di anteprima, lo scostamento massimo della versione tra un pool di nodi worker e il cluster è una versione minore.

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

Esegui l'upgrade del control plane 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 allo spec NodePool:

   • Imposta anthosBareMetalVersion nella specifica del node pool sulla versione di upgrade del cluster di destinazione.
   • 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 corrente (pre-upgrade) del cluster:

3. Procedi con l'upgrade come descritto in Avvia l'upgrade del cluster.

   L'operazione di upgrade del cluster esegue l'upgrade dei seguenti nodi:

   • Nodi del control plane 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 regolari. 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 che non hai escluso dall'upgrade.

Ad esempio, supponiamo che il tuo cluster sia alla versione 1.29.0 e abbia due pool di nodi worker: wpool01 e wpool02. Supponiamo inoltre che tu voglia eseguire l'upgrade del piano di controllo e di wpool01 alla versione 1.30.300-gke.84, ma che tu voglia mantenere wpool02 alla versione 1.29.0.

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.30.300-gke.84
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.30.300-gke.84
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  ...
  - address:  10.200.0.8

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

Esegui l'upgrade dei node pool alla versione corrente del cluster

Se hai escluso i pool di nodi da un upgrade del cluster, puoi eseguire un upgrade del cluster che li aggiorna 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 precedente (pre-upgrade) del cluster.

Per aggiornare i pool di nodi worker alla versione corrente del cluster di cui è stato eseguito l'upgrade:

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

   Se sono 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 di cui viene eseguito l'upgrade in parallelo, se presenti. Se non vuoi eseguire l'upgrade dei pool di nodi worker contemporaneamente, seleziona un solo pool di nodi alla volta per l'upgrade.

2. Procedi con l'upgrade come descritto in Avvia 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 aggiornata del cluster corrente.

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

Eseguire il rollback di un upgrade del pool di nodi

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

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

1,30

Per i cluster della versione 1.30 (cluster con nodi del piano di controllo nella versione 1.30), la funzionalità di rollback del pool di nodi è disponibile in versione GA ed è abilitata per impostazione predefinita.

1,29

Anteprima

Questo prodotto o funzionalità è soggetto ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici del servizio. I prodotti e le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

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

preview.baremetal.cluster.gke.io/worker-node-pool-upgrade-rollback: enable

1,28

La funzionalità di rollback del pool di nodi non è disponibile per i cluster con versione minore 1.28 o precedente.

Per eseguire il rollback di un upgrade del pool di nodi:

bmctl

Quando utilizzi bmctl per eseguire il rollback di un upgrade del pool di nodi, modifichi il file di configurazione del cluster e applichi 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 precedente (pre-upgrade) del cluster.

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

   Se per il rollback sono selezionati più pool di nodi worker, il valore di spec.nodePoolUpgradeStrategy.concurrentNodePools nella spec del cluster determina il numero di pool di nodi di cui viene eseguito il rollback in parallelo. Se non vuoi eseguire il rollback dei pool di nodi worker contemporaneamente, seleziona un pool di nodi alla volta per il rollback o aggiorna le impostazioninodePoolUpgradeStrategy. Analogamente, il valore di spec.upgradeStrategy.parallelUpgrade.concurrentNodes nella specifica NodePool determina il numero di nodi di cui 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 actualizare.

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

   Il rollback inizia automaticamente. Il comando bmctl update cluster esce immediatamente, ma il rollback continua a progredire. Non eseguire altre operazioni sul cluster mentre è in corso il rollback.

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

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

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

Non utilizzare bmctl update e kubectl apply -f in modo intercambiabile quando modifichi il file di configurazione del cluster. Quando questi comandi vengono utilizzati in modo intercambiabile, i contenuti inseriti dall'intestazione della specifica del cluster potrebbero essere rimossi involontariamente. Ad esempio, puoi utilizzare bmctl update per aggiornare il file di configurazione del cluster per configurare un mirror del registry. Il cluster viene quindi compilato con spec.nodeConfig.registryMirrors dopo la riconciliazione.

Se poi tenti di apportare modifiche al cluster utilizzando la configurazione del cluster con il comando kubectl apply -f, il valore spec.nodeConfig.registryMirrors compilato dal riconciliatore sul cluster viene rimosso. Questo comportamento si verifica perché la configurazione non esiste nella specifica di configurazione del cluster, ma esiste nel cluster.

kubectl

Puoi eseguire il rollback di un upgrade del pool di nodi utilizzando kubectl per modificare 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 esegui il rollback.

   • CLUSTER_NAMESPACE: il nome dello spazio dei nomi in cui è disegnato il pool di nodi. Questo è lo spazio dei nomi del cluster.

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

2. Modifica il valore di spec.anthosBareMetalVersion impostandolo sulla versione precedente (pre-upgrade).

   ...
   ---
   apiVersion: baremetal.cluster.gke.io/v1
   kind: NodePool
   metadata:
     name: wpool01
     namespace: cluster-user001
   spec:
     clusterName: user001
     anthosBareMetalVersion: 1.29.800-gke.111
     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 inizia automaticamente. Non eseguire altre operazioni sul cluster mentre è in corso il rollback.

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

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

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

Upgrade paralleli

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

Attenzione: se utilizzi servizi di dati gestiti, come Portworx, per gestire i carichi di lavoro stateful sui tuoi cluster, ti consigliamo di non utilizzare gli upgrade paralleli.

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

• Upgrade dei nodi in contemporanea: puoi configurare i pool di nodi worker in modo che l'upgrade di più nodi avvenga in parallelo. Gli upgrade paralleli dei nodi vengono configurati nello spec NodePool (spec.upgradeStrategy.parallelUpgrade) e solo i nodi di un pool di nodi worker possono essere sottoposti ad upgrade in parallelo. È possibile eseguire l'upgrade di un solo nodo alla volta nei pool di nodi del piano di controllo o dei bilanciatori del carico. Per ulteriori informazioni, consulta la Strategia di upgrade dei nodi.

• Upgrade simultaneo dei pool di nodi:puoi configurare il cluster in modo che l'upgrade di più pool di nodi venga eseguito in parallelo. Solo i pool di nodi worker possono essere sottoposti a upgrade in parallelo. È 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 i pool di nodi worker in modo che l'upgrade di più nodi venga eseguito contemporaneamente (concurrentNodes). Puoi anche impostare una soglia minima per il numero di nodi in grado di eseguire i carichi di lavoro durante la procedura di upgrade (minimumAvailableNodes). Questa configurazione viene eseguita nella specifica NodePool. Per ulteriori informazioni su questi campi, consulta il riferimento ai campi di configurazione del cluster.

Importante: gli upgrade paralleli non rispettano il budget di interruzione dei pod (PDB). Se i tuoi carichi di lavoro sono sensibili alle interruzioni, ti consigliamo di utilizzare il minimumAvailableNodes campo. Puoi specificare la quantità minima di nodi che deve rimanere disponibile per l'esecuzione dei carichi di lavoro durante la procedura di upgrade.

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 bilanciatore del carico o del piano di controllo. Durante un upgrade del cluster, i nodi dei pool di nodi del piano di controllo e dei bilanciatori del carico vengono sottoposti ad upgrade in sequenza, uno alla volta. I pool di nodi del piano di controllo e i pool di nodi del bilanciatore del carico vengono specificati nella specifica del cluster (controlPlane.nodePoolSpec.nodes e loadBalancer.nodePoolSpec.nodes).

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

• Il valore di concurrentNodes non può superare il 50% del numero di nodi nel pool di nodi o il numero fisso 15, a seconda del valore più piccolo. Ad esempio, se il pool di nodi ha 20 nodi, non puoi specificare un valore superiore a 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ò superare 2. Analogamente, se concurrentNodes è impostato su 10, minimumAvailableNodes non può superare 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 4 nodi per poter 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 node pool

Puoi configurare un cluster in modo che l'upgrade di più pool di nodi worker avvenga in parallelo. Il campo booleano nodePoolUpgradeStrategy.concurrentNodePools nella spec 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 avviene in sequenza, uno dopo l'altro. Quando imposti concurrentNodePools su 0, ogni pool di nodi worker del cluster viene sottoposto ad upgrade in parallelo.

I pool di nodi del control plane e del bilanciamento del carico non sono interessati da questa impostazione. L'upgrade di questi pool di nodi avviene sempre 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 dei pool di nodi worker e dei nodi in un pool di nodi worker:

1. Aggiungi una sezione upgradeStrategy alle specifiche del node pool.

   Puoi applicare questo manifest separatamente o all'interno 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 l'upgrade di 5 nodi viene eseguito in parallelo. Il campo minimumAvailableNodes è impostato su 10, il che significa che durante l'upgrade devono rimanere disponibili almeno 10 nodi per i carichi di lavoro.

   Nota: non puoi specificare una strategia di upgrade dei nodi per i pool di nodi del piano di controllo o del bilanciatore del carico.

2. Aggiungi una sezione nodePoolUpgradeStrategy allo spec 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.30.300-gke.84
     ...
     nodePoolUpgradeStrategy:
       concurrentNodePools: 0
     ...
   

   In questo esempio, il campo concurrentNodePools è impostato su 0, il che significa che tutti i pool di nodi worker vengono sottoposti ad upgrade contemporaneamente durante l'upgrade del cluster. La strategia di upgrade per i nodi nei pool di nodi è definita nelle specifiche di NodePool.

3. Esegui l'upgrade del cluster come descritto nella sezione precedente Eseguire l'upgrade di cluster di amministrazione, autonomi, ibridi o utente.

Valori predefiniti per l'upgrade parallelo

Gli upgrade paralleli sono disattivati per impostazione predefinita e i campi correlati agli upgrade paralleli sono mutabili. In qualsiasi momento, puoi rimuovere i campi o impostarli sui valori predefiniti per disattivare 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 (specifiche del cluster)	1	Esegui l'upgrade dei pool di nodi worker in sequenza, uno dopo l'altro.
upgradeStrategy.parallelUpgrade.concurrentNodes (specifica NodePool)	1	Esegui l'upgrade dei nodi in sequenza, uno dopo l'altro.
upgradeStrategy.parallelUpgrade.minimumAvailableNodes (specifica NodePool)	Il valore predefinito di minimumAvailableNodes dipende dal valore di concurrentNodes. Se non specifichi concurrentNodes, per impostazione predefinita minimumAvailableNodes corrisponde a 2/3 delle dimensioni del pool di nodi. Se specifichi concurrentNodes, per impostazione predefinita minimumAvailableNodes corrisponde alle dimensioni del pool di nodi meno concurrentNodes.	L'upgrade si blocca quando viene raggiunto minimumAvailableNodes e continua solo quando il numero di nodi disponibili è maggiore di minimumAvailableNodes.

Avvia l'upgrade del cluster

Questa sezione contiene istruzioni per l'upgrade dei cluster.

Nota: devi eseguire l'upgrade di un cluster di amministrazione prima di eseguire l'upgrade di eventuali cluster utente associati. Tuttavia, prima di eseguire l'upgrade del cluster di amministrazione a 1.30.300-gke.84, assicurati che i cluster utente associati siano alla versione 1.29.0 o superiore. bmctl emette un errore se rileva che un cluster utente è con una versione inferiore a 1.29.0.

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. Imposta le credenziali utente come Credenziali predefinite dell'applicazione (ADC):

   gcloud auth application-default login
   

   Segui le istruzioni per selezionare il tuo Account Google per l'ADC. Per ulteriori informazioni, consulta Configurare le credenziali predefinite dell'applicazione.

2. Scarica la versione più recente di bmctl come descritto in Download di Google Distributed Cloud.

3. 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 anthosBareMetalVersion campo aggiornato all'ultima versione:

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

4. 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.
   Nota: il comando bmctl upgrade aggiorna solo il valore anthosBareMetalVersion e le annotazioni di anteprima nella risorsa personalizzata Cluster. Se vuoi modificare altri campi della specifica del cluster, utilizza il comando bmctl update. Per ulteriori informazioni, consulta Aggiornare i cluster.

   L'operazione di upgrade del cluster esegue controlli preflight per convalidare lo stato del cluster e l'integrità dei nodi. L'upgrade del cluster non procede se i controlli preflight non superano. Per informazioni sulla risoluzione dei problemi, consulta Risolvere i problemi di installazione o upgrade del cluster.

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

   Per ulteriori informazioni sulla sequenza di 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, svolgi i seguenti passaggi:

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

2. Per avviare l'upgrade, esegui il seguente 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à dei nodi. Se i controlli preflight non superano, 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 maggiori informazioni, consulta Risolvere i problemi di installazione o upgrade del cluster.

Anche se non è necessaria la versione più recente di bmctl per eseguire l'upgrade dei cluster con kubectl, ti consigliamo di scaricare la versione più recente di bmctl. Per eseguire altre attività, come controlli di integrità e backup, è necessario bmctl per assicurarti che il tuo cluster rimanga in buone condizioni di funzionamento.

Mettere in pausa e riprendere gli upgrade

La funzionalità di messa in pausa e ripresa dell'upgrade ti consente di mettere in pausa un upgrade del cluster prima che sia completato. Quando un upgrade del 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 la versione secondaria 1.28 o successive. La funzionalità è disponibile in versione GA per i cluster con tutti i nodi del piano di controllo con versione secondaria 1.29 o successiva.

Potresti voler mettere in pausa un upgrade per i seguenti motivi:

• Hai rilevato un problema con i workload del cluster durante l'upgrade e vuoi mettere in pausa l'upgrade per esaminare il problema

• Hai finestre di manutenzione brevi, quindi vuoi mettere in pausa l'upgrade tra una finestra e l'altra

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

• Aggiunta o rimozione di nodi
• Aggiunta o rimozione di pool di nodi
• Aumento della copertura 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 su quel nodo finché l'upgrade non viene ripreso e completato.

Mentre l'upgrade del cluster è in pausa, le seguenti operazioni del cluster non sono supportate:

• Rotazione delle autorità di certificazione
• Eseguire il backup di un cluster

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

Attivare la messa in pausa e la ripresa dell'upgrade

Google Distributed Cloud 1.30

La funzionalità di sospensione e ripresa dell'upgrade è abilitata per impostazione predefinita per i cluster con tutti i nodi del piano di controllo nella versione secondaria 1.29 o successive.

Google Distributed Cloud 1.29

Anteprima

Questo prodotto o funzionalità è soggetto ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici del servizio. I prodotti e le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

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

Per attivare la sospensione e la ripresa dell'upgrade:

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 è mutabile. 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 del 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, devi aprire 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 prevedi una pausa prolungata, premi Ctrl+C per uscire da bmctl, altrimenti mantieni bmctl in esecuzione.

   La CLI bmctl non rileva le modifiche allo stato di pausa dell'upgrade, pertanto non esce automaticamente. Tuttavia, quando esci da bmctl, la registrazione dell'avanzamento dell'upgrade nel file log cluster-upgrade-TIMESTAMP nella cartella del cluster sulla workstation di amministrazione e in Cloud Logging viene interrotta. Pertanto, per brevi interruzioni, ti consigliamo di mantenere bmctl attivo. Se lasci bmctl in esecuzione per un periodo di tempo prolungato mentre l'upgrade è in pausa, il timeout si verifica.

Riprendere un upgrade in pausa

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

Per riprendere un upgrade del cluster in pausa:

1. Imposta nodePoolUpgradeStrategy.pause nel 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 da dove era stata interrotta.

3. Per controllare lo stato dell'upgrade, ottieni innanzitutto un elenco delle risorse che hanno anthosBareMetalVersion nel 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 le risorse personalizzate BareMetalMachine. Ogni BareMetalMachine corrisponde a un nodo del 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 controllare il valore status.anthosBareMetalVersion (versione corrente della risorsa), recupera i dettagli delle singole risorse:

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

   Il seguente esempio mostra i dettagli di 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 è in Google Distributed Cloud versione 1.16.2.