Esegui l'upgrade dei cluster

Version 1.15 

• Versione 1.28 (più recente)
• Versione 1.16
• Versione 1.15
• Versioni precedenti (non supportate)

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.

A partire da GKE su Bare Metal versione 1.15.0, il comportamento di upgrade predefinito per i cluster autogestiti (amministratori, ibridi o autonomi) è un upgrade in loco. Gli upgrade in loco utilizzano controller del ciclo di vita, anziché un cluster di bootstrap, per gestire l'intero processo di upgrade. Questa modifica semplifica il processo e riduce i requisiti di risorse, rendendo gli upgrade dei cluster più affidabili e scalabili.

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

Nota: quando esegui l'upgrade di GKE su Bare Metal da una versione con una patch di sicurezza alla release secondaria successiva, ti consigliamo di eseguire l'upgrade alla versione patch più recente disponibile per assicurarti di avere le patch di sicurezza più recenti. Controlla sempre le note di rilascio prima di eseguire l'upgrade in modo da essere a conoscenza delle modifiche, incluse le correzioni di sicurezza e i problemi noti. L'upgrade a una versione patch precedente non è supportato.

Considerazioni sull'upgrade

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

best practice

Per informazioni su come prepararti per un upgrade del cluster, consulta Best practice per gli upgrade dei cluster Anthos clusters on 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.

Esegui l'upgrade di cluster amministrativi, autonomi, ibridi o utente

Questa sezione contiene le istruzioni per eseguire 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.15.11, assicurati che i cluster utente associati siano alla versione 1.14.0 o successiva. bmctl emette un errore se rileva che un cluster utente è inferiore a 1.14.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. 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.15.11
   

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.

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.

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

Nota: per GKE su Bare Metal versioni da 1.14.0 a 1.14.4, il campo della specifica del pool di nodi spec.upgradeStrategy.parallelUpgrade.concurrentNodes è immutabile. In queste versioni, puoi aggiungere il campo solo a un nuovo pool di nodi. Una volta aggiunto, questo campo non può essere aggiornato o rimosso. Ti consigliamo di eseguire l'upgrade a una versione più recente della 1.14.4 prima di eseguire gli upgrade paralleli.

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. Per l'Anteprima pubblica è possibile eseguire contemporaneamente l'upgrade di più pool di nodi. Per saperne di più, consulta Strategia di upgrade dei pool di nodi.

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.

Importante: gli upgrade paralleli non rispettano il budget di interruzione dei pod (PDB). Se i tuoi carichi di lavoro sono sensibili a interruzioni, ti consigliamo di utilizzare il campo minimumAvailableNodes. Puoi specificare la quantità minima di nodi che devono rimanere disponibili per eseguire carichi di lavoro durante il processo 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 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 20% del numero di nodi nel pool di nodi o 10, a seconda di quale delle due opzioni è inferiore. Ad esempio, se il tuo pool di nodi ha 40 nodi, non puoi specificare un valore superiore a 8. Se il tuo pool di nodi ha 100 nodi, 10 è 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, vengono eseguiti due nodi alla volta e, affinché l'upgrade prosegua, devono rimanere disponibili almeno cinque nodi:

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: 2
      minimumAvailableNodes: 5 

Strategia di upgrade del pool di nodi

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.

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

La possibilità di eseguire contemporaneamente l'upgrade di tutti i pool di nodi worker è disponibile solo per l'anteprima. Non utilizzare questa funzionalità sui cluster di produzione.

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

Attenzione: per GKE su Bare Metal versioni da 1.14.0 a 1.14.4, il campo upgradeStrategy è immutabile. In queste versioni, puoi aggiungere il campo solo a un nuovo pool di nodi. Una volta aggiunto, questo campo non può essere aggiornato o rimosso.

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.

   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 alla specifica del cluster nel file di configurazione del cluster.

   Attenzione: la possibilità di eseguire l'upgrade di tutti i pool di nodi worker contemporaneamente è disponibile solo per l'anteprima. Non utilizzare questa funzionalità sui tuoi cluster di produzione.

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

Come disabilitare gli upgrade paralleli dei nodi

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)	0	Non è necessario garantire la disponibilità di nodi durante un upgrade.