Se installi una nuova versione di bmctl
, puoi eseguire l'upgrade delle app esistenti
creati con una versione precedente. L'upgrade di un cluster
l'ultima versione di Google Distributed Cloud introduce funzionalità e correzioni aggiuntive per
in un cluster Kubernetes. Garantisce inoltre che il cluster resti
supportato.
Puoi eseguire l'upgrade di cluster di amministrazione, ibridi, autonomi o utente con
bmctl upgrade cluster
oppure puoi usare kubectl
.
Per saperne di più sul processo di upgrade e sulle regole di controllo delle versioni, consulta Ciclo di vita e fasi degli upgrade dei cluster.
Questa pagina è rivolta agli amministratori, agli architetti e agli operatori che gestiscono ciclo di vita dell'infrastruttura tecnica sottostante. Per scoprire di più sui modelli ruoli e attività di esempio a cui facciamo riferimento nei contenuti di Google Cloud, vedi Ruoli e attività utente comuni di GKE Enterprise.
Pianifica l'upgrade
Questa sezione contiene informazioni e link a informazioni che dovresti prendere in considerazione prima di eseguire l'upgrade di un cluster.
Best practice
Per informazioni che ti aiutano 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 il cluster e l'integrità del nodo. L'upgrade del cluster non procede se il preflight controlli non andati a buon fine. Per ulteriori informazioni sui controlli preflight, vedi Informazioni sui controlli preflight.
Puoi verificare se i cluster sono pronti per un upgrade eseguendo il preflight controllare prima di eseguire l'upgrade. Per ulteriori informazioni, vedi Controlli preflight per gli upgrade.
Problemi noti
Per informazioni sui potenziali problemi relativi agli upgrade dei cluster, consulta Google Distributed Cloud per problemi noti 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 il seguente upgrade opzioni che controllano il funzionamento del processo di upgrade:
Upgrade selettivi del pool di nodi worker: upgrade specifico pool di nodi worker separatamente dal resto del cluster.
Upgrade paralleli: configura il processo di upgrade a eseguire l'upgrade di gruppi di nodi o pool di nodi contemporaneamente.
Queste opzioni possono ridurre il rischio di interruzioni delle applicazioni critiche e ridurre significativamente i tempi complessivi di upgrade. Queste opzioni sono particolarmente utile per cluster di grandi dimensioni con numerosi nodi e pool di nodi in esecuzione carichi di lavoro più importanti. Per ulteriori informazioni su cosa fanno queste opzioni e su come 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, comporta lo svuotamento di ciascun nodo e lo svuotamento di tutti i pod associati è stato riavviato e riprogrammato. Questa sezione descrive come includere o escludere seleziona pool di nodi worker per l'upgrade di un cluster al fine di ridurre al minimo l'interruzione del carico di lavoro. Questa funzionalità si applica solo a cluster utente, ibridi e autonomi, poiché l'amministratore i cluster 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 i nodi del piano di controllo (e i nodi del bilanciatore del carico) per applicare correzioni di vulnerabilità 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 Upgrade di tutti i nodi worker: puoi eseguire l'upgrade dei pool di nodi worker in modo selettivo per garantire che i carichi di lavoro vengano eseguiti correttamente pool di nodi 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 tempo ed è difficile prevedere con precisione quando un upgrade completato. Il tempo di upgrade del cluster è proporzionale al numero di nodi con upgrade eseguito. Riduzione del numero di nodi di cui è in corso l'upgrade escludendo nodi riduce i tempi di upgrade. Esegui l'upgrade più volte, ma periodi di manutenzione più prevedibili possono aiutarti nella pianificazione.
Disallineamento delle versioni del pool di nodi con due versioni secondarie
Per i cluster della versione 1.28 e successive, la versione di un pool di nodi worker può essere fino a due versioni secondarie dietro la versione del cluster (piano di controllo). Con n-2 per il disallineamento delle versioni, puoi anche saltare una versione secondaria eseguire l'upgrade di un pool di nodi worker da due versioni secondarie dietro il cluster la 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 in versione 1.28, puoi avere pool di nodi worker con determinate 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 pre-upgrade. Non è necessario eseguire l'upgrade della versione pool di nodi worker dalla versione 1.16 alla versione 1.28 prima di eseguire l'upgrade del cluster Versione 1.29. Una volta eseguito l'upgrade del cluster alla versione 1.29, quando 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 maggiori informazioni, inclusi gli elenchi di versioni dei pool di nodi worker supportate supportato 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 è in GA per tutti i tipi di cluster. Questa funzionalità è abilitata per impostazione predefinita per i cluster in Versione 1.29.
Durante la transizione di questa funzionalità da Anteprima pubblica a GA, i cluster ibridi
sarà comunque necessaria l'annotazione di anteprima nella seguente situazione. Se disponi
per un cluster ibrido versione 1.28.x con un pool di nodi worker versione 1.16.y,
devi aggiungere preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable
per il 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
Anteprima nella release 1.28. Per attivare questa funzionalità
Anteprima, aggiungi
preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable
nel 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 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 del worker per i pool di nodi, consulta Controllo delle versioni dei pool di nodi in Ciclo di vita di 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:
Per i pool di nodi worker che vuoi includere nel cluster eseguire l'upgrade, apporta una delle seguenti modifiche alla specifica del pool di nodi:
- Imposta
anthosBareMetalVersion
nella specifica del pool di nodi sulla destinazione del cluster di upgrade. - Ometti il campo
anthosBareMetalVersion
dalla specifica NodePool. o imposta alla stringa vuota. Per impostazione predefinita, i pool di nodi worker sono inclusi degli upgrade dei cluster.
- Imposta
Per i pool di nodi worker che vuoi escludere dall'upgrade, imposta
anthosBareMetalVersion
alla versione attuale (prima dell'upgrade) dell' cluster:Continuare l'upgrade come descritto in Avvia 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 dei bilanciatori del carico per eseguire carichi di lavoro regolari. Non puoi eseguire selettivamente l'upgrade di un nodo 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 cluster sia 1.28.0
ha due pool di nodi worker: wpool01
e wpool02
. Inoltre, supponiamo che tu voglia
di eseguire l'upgrade del piano di controllo e di wpool01
a 1.29.400-gke.86, ma vuoi
wpool02
per rimanere alla versione 1.28.0.
Il seguente estratto del file di configurazione del cluster mostra come modificare 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.400-gke.86
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
name: wpool01
namespace: cluster-user001
spec:
clusterName: user001
anthosBareMetalVersion: 1.29.400-gke.86
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 cluster
per passare alla versione del cluster di destinazione. Pool di nodi worker
escluse da un upgrade del cluster hanno anthosBareMetalVersion
nella specifica NodePool
impostata sulla versione precedente del cluster (prima dell'upgrade).
Per portare i pool di nodi worker alla versione attuale del cluster con upgrade eseguito:
Modifica le specifiche
NodePool
nel file di configurazione del cluster per il worker pool di nodi che vuoi visualizzare alla versione attuale del cluster. ImpostaanthosBareMetalVersion
alla versione attuale del cluster (dopo l'upgrade).Se sono selezionati più pool di nodi worker per l'upgrade, il valore di
spec.nodePoolUpgradeStrategy.concurrentNodePools
nel determina il numero di pool di nodi di cui viene eseguito l'upgrade in parallelo, se qualsiasi. Se non vuoi eseguire contemporaneamente l'upgrade dei pool di nodi worker, selezionane uno un pool di nodi alla volta per l'upgrade.Continuare l'upgrade come descritto in Avvia l'upgrade del cluster.
L'operazione di upgrade del cluster esegue l'upgrade solo del worker escluso in precedenza pool di nodi per i quali hai impostato il valore attuale di
anthosBareMetalVersion
, alla versione aggiornata del cluster.
Ad esempio, supponiamo che tu abbia eseguito l'upgrade del cluster alla versione
1.29.400-gke.86, ma il pool di nodi wpool02
è ancora al vecchio livello prima dell'upgrade
del cluster versione 1.28.0. I carichi di lavoro vengono eseguiti correttamente
di cui è stato eseguito l'upgrade del pool di nodi, wpool01
. Ora vuoi che wpool02
con la versione attuale del cluster. Per eseguire l'upgrade di wpool02
, puoi rimuovere il componente
anthosBareMetalVersion
o imposta il valore sulla stringa vuota.
Il seguente estratto del file di configurazione del cluster mostra come modificare 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.400-gke.86
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
name: wpool01
namespace: cluster-user001
spec:
clusterName: user001
anthosBareMetalVersion: 1.29.400-gke.86
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, come la compatibilità con kubelet o plug-in, che possono influire sulle prestazioni dei carichi di lavoro. Nel caso in cui rilevi un dopo aver eseguito l'upgrade di un pool di nodi worker, puoi eseguirne la versione precedente.
La funzionalità di rollback del pool di nodi è disponibile
Anteprima per i cluster della versione 1.29 (cluster
con i nodi del piano di controllo alla versione 1.29). Mentre questa funzionalità è in anteprima,
devi aggiungere
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, modifichi il cluster
di configurazione del deployment e applica le modifiche con il comando bmctl update
:
Modifica le specifiche
NodePool
nel file di configurazione del cluster per pool di nodi worker di cui vuoi eseguire il rollback alla versione precedente. ImpostaanthosBareMetalVersion
sul cluster precedente (pre-upgrade) completamente gestita.... --- apiVersion: baremetal.cluster.gke.io/v1 kind: NodePool metadata: name: wpool01 namespace: cluster-user001 spec: clusterName: user001 anthosBareMetalVersion: 1.28.800-gke.111 nodes: - address: 10.200.0.1 - address: 10.200.0.2 - address: 10.200.0.3 ...
Se sono selezionati più pool di nodi worker per il rollback, il valore
spec.nodePoolUpgradeStrategy.concurrentNodePools
pollici la specifica del cluster determina per quanti pool di nodi viene eseguito il rollback 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 Impostazioni dinodePoolUpgradeStrategy
. Analogamente, il valorespec.upgradeStrategy.parallelUpgrade.concurrentNodes
inNodePool
determina per quanti nodi viene eseguito il rollback in parallelo.Utilizza
bmctl update
per applicare le modifiche alle specificheNodePool
:bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG
Sostituisci quanto segue:
CLUSTER_NAME
: il nome del cluster che ti interessa da aggiornare.ADMIN_KUBECONFIG
: il percorso di kubeconfig del cluster di gestione (amministratore, ibrido o autonomo).
Il rollback si avvia automaticamente.
Durante l'esecuzione del rollback, Google Distributed Cloud esegue quanto segue per ogni nodo:
- Imposta il nodo in modalità di manutenzione.
- Esegui un job di ripristino sul nodo per riportarlo a uno stato pulito.
- Esegui preflight della macchina controlla nodo.
- Esegui un job machine-init sul nodo per reinstallarlo nella destinazione di rollback (prima dell'upgrade).
- Rimuovi il nodo dalla modalità di manutenzione.
Al termine di un rollback corretto, il valore
nodePool.status.anthosBareMetalVersion
nella risorsaNodePool
impostata alla versione di rollback di destinazione.
kubectl
Puoi eseguire il rollback di un upgrade del pool di nodi utilizzando kubectl
per modificare
NodePool
risorsa direttamente:
Per eseguire il rollback di un pool di nodi worker, apri la risorsa
NodePool
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 esegui il rollback.CLUSTER_NAMESPACE
: il nome dello spazio dei nomi in di cui viene eseguito il deployment del pool di nodi. Questo è lo spazio dei nomi del cluster.ADMIN_KUBECONFIG
: il percorso di kubeconfig del cluster di gestione (amministratore, ibrido o autonomo).
Sostituisci il valore di
spec.anthosBareMetalVersion
con il valore precedente (prima dell'upgrade).... --- apiVersion: baremetal.cluster.gke.io/v1 kind: NodePool metadata: name: wpool01 namespace: cluster-user001 spec: clusterName: user001 anthosBareMetalVersion: 1.28.800-gke.111 nodes: - address: 10.200.0.1 - address: 10.200.0.2 - address: 10.200.0.3 ...
Salva e chiudi la risorsa
NodePool
nell'editor.Il rollback si avvia automaticamente.
Durante l'esecuzione del rollback, Google Distributed Cloud esegue quanto segue per ogni nodo:
- Imposta il nodo in modalità di manutenzione.
- Esegui un job di ripristino sul nodo per riportarlo a uno stato pulito.
- Esegui preflight della macchina controlla nodo.
- Esegui un job machine-init sul nodo per reinstallarlo nella destinazione di rollback (prima dell'upgrade).
- Rimuovi il nodo dalla modalità di manutenzione.
Al termine di un rollback corretto, il valore
nodePool.status.anthosBareMetalVersion
nella risorsaNodePool
impostata alla versione di rollback di destinazione.
Upgrade paralleli
In un tipico upgrade predefinito del cluster, viene eseguito l'upgrade di ogni nodo del cluster in sequenza, uno dopo l'altro. Questa sezione mostra come configurare cluster e pool di nodi worker in modo che più nodi eseguano l'upgrade in parallelo eseguire l'upgrade del cluster. L'upgrade dei nodi in parallelo velocizza gli upgrade dei cluster in modo significativo, soprattutto per i cluster con centinaia di nodi.
Esistono due strategie di upgrade parallele che puoi utilizzare per velocizzare upgrade del cluster:
Upgrade simultaneo dei nodi: puoi configurare i pool di nodi worker in modo che per eseguire l'upgrade di più nodi in parallelo. Gli upgrade paralleli dei nodi configurato nella specifica del pool di nodi (
spec.upgradeStrategy.parallelUpgrade
) e è possibile eseguire l'upgrade in parallelo solo dei nodi di un pool di nodi worker. Nodi in dei pool di nodi del piano di controllo o del bilanciatore del carico può essere eseguito solo uno alla volta nel tempo. Per ulteriori informazioni, consulta Strategia di upgrade dei nodi.Upgrade simultaneo del pool di nodi: puoi configurare il cluster in modo che di più pool di nodi in parallelo. Solo i pool di nodi worker possono essere in parallelo. I pool di nodi del piano di controllo e del bilanciatore del carico possono essere ne viene eseguito uno alla volta.
Strategia di upgrade dei nodi
Puoi configurare pool di nodi worker in modo che più nodi eseguano l'upgrade contemporaneamente
(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 creata nelle specifiche del pool di nodi. Per
ulteriori informazioni su questi campi, consulta
Riferimento per il 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 un cluster
upgrade dei nodi nel piano di controllo e nel bilanciatore del carico, upgrade dei pool di nodi
in sequenza, uno alla volta. Pool di nodi del piano di controllo e nodo del bilanciatore del carico
sono specificati nelle specifiche 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 né il 50% del numero di nodi nel pool di nodi o il numero fisso 15, a seconda di quale sia il numero minore. 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 aminimumAvailableNodes
, il valore i valori combinati non possono superare il numero totale di nodi nel pool di nodi. Per Ad esempio, se il pool di nodi ha 20 nodi e il valoreminimumAvailableNodes
è impostato su 18, il valoreconcurrentNodes
non può essere maggiore di 2. Allo stesso modo, seconcurrentNodes
è impostato su 10, il valoreminimumAvailableNodes
non può essere superiore a 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 almeno 4 nodi
disponibili per procedere con l'upgrade:
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 avvenga in
parallelo. Il campo booleano nodePoolUpgradeStrategy.concurrentNodePools
nella sezione
specifica se eseguire l'upgrade di tutti i pool di nodi worker per un
in un cluster contemporaneamente. Per impostazione predefinita (1
), l'upgrade dei pool di nodi
in sequenza, uno dopo l'altro. Se imposti concurrentNodePools
a 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. Nodo del piano di controllo
i pool di nodi e i pool di nodi del bilanciatore del carico sono specificati nella
(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 upgrade paralleli.
Eseguire un upgrade parallelo dei pool di nodi worker e dei nodi in un nodo worker. pool, segui questi passaggi:
Aggiungi una sezione
upgradeStrategy
alla specifica del pool di nodi.Puoi applicare questo manifest separatamente o come parte del cluster di configurazione 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
, che significa che 5 nodi vengono aggiornati in parallelo. Il campominimumAvailableNodes
è impostato su10
, il che significa che devono rimanere disponibili almeno 10 nodi per tutta la durata dell'upgrade.Aggiungi una sezione
nodePoolUpgradeStrategy
alla specifica del cluster nel 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.400-gke.86 ... nodePoolUpgradeStrategy: concurrentNodePools: 0 ...
In questo esempio, il campo
concurrentNodePools
è impostato su0
, il che significa eseguire contemporaneamente l'upgrade di tutti i pool di nodi worker durante l'upgrade del cluster. La strategia di upgrade per i nodi nei pool di nodi è definita nella specifiche del pool di nodi.Esegui l'upgrade del cluster come descritto nella precedente Esegui l'upgrade di cluster amministrativi, autonomi, ibridi o utente .
Valori predefiniti per upgrade parallelo
Gli upgrade paralleli sono disattivati per impostazione predefinita e i campi relativi al monitoraggio sono mutabili. In qualsiasi momento puoi rimuovere i campi o impostarli ai valori predefiniti per disattivare 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 .
|
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
Se scarichi e installi una nuova versione di bmctl
, puoi eseguire l'upgrade del tuo
di amministrazione, ibridi, autonomi e utenti creati con una versione precedente.
Per una determinata versione di bmctl
, è possibile eseguire l'upgrade di un cluster alla stessa versione
.
Imposta le tue credenziali utente come Credenziali predefinite dell'applicazione (ADC):
gcloud auth application-default login
Segui le istruzioni per selezionare il tuo Account Google per ADC. Per ulteriori informazioni informazioni, consulta Configurare le impostazioni predefinite dell'applicazione Credenziali.
Scarica l'ultima versione di
bmctl
come descritto in Download di Google Distributed Cloud.Aggiorna
anthosBareMetalVersion
nel file di configurazione del cluster con eseguire l'upgrade della versione di destinazione.La versione di destinazione dell'upgrade deve corrispondere alla versione del download
bmctl
. Il seguente snippet del file di configurazione del cluster mostra CampoanthosBareMetalVersion
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.400-gke.86
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 cluster di amministrazione kubeconfig.
L'operazione di upgrade del cluster esegue controlli preflight per convalidare il cluster e l'integrità del nodo. L'upgrade del cluster non continua se controlli preflight non riusciti. Per informazioni sulla risoluzione dei problemi, vedi Risolvi i problemi di installazione o upgrade del cluster.
Una volta eseguito l'upgrade di tutti i componenti del cluster, di upgrade del cluster esegue 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à, continuano a essere eseguiti fino a quando non vengono superati. Quando tutti i controlli di integrità sono stati superati, l'upgrade viene completato correttamente.
Per saperne di più 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:
Modifica il file di configurazione del cluster impostando
anthosBareMetalVersion
sul eseguire l'upgrade della versione di destinazione.Per avviare l'upgrade, esegui questo comando:
kubectl apply -f CLUSTER_CONFIG_PATH
Sostituisci
CLUSTER_CONFIG_PATH
con il percorso del di configurazione del cluster modificato.Come nel caso del processo di upgrade con
bmctl
, i controlli preflight vengono eseguiti nell'ambito di l'upgrade del cluster per convalidarne lo stato e l'integrità del nodo. Se l'istanza preflight non vanno a buon fine, l'upgrade del cluster viene interrotto. Per risolvere eventuali errori, esaminare il cluster e i relativi log, poiché non viene creato alcun cluster di bootstrap. Per ulteriori informazioni, vedi Risolvi i problemi di installazione o upgrade del cluster.
Anche se non hai bisogno dell'ultima versione di bmctl
per eseguire l'upgrade con
kubectl
, ti consigliamo
scarica l'ultima versione di bmctl
. È necessario bmctl
per
eseguire altre attività, come i controlli di integrità e i backup, per garantire che
rimane in buono stato 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 l'upgrade di un cluster prima che avvenga finiture in cui sono finite. Quando l'upgrade di un cluster è in pausa, non vengono eseguiti nuovi upgrade dei nodi worker finché l'upgrade non viene ripreso.
Questa funzionalità è disponibile in (Anteprima) per cluster con tutti i nodi del piano di controllo con versione secondaria 1.28 o successiva. La è GA per i cluster con tutti i nodi del piano di controllo nella versione secondaria 1.29 in alto.
Ti consigliamo di mettere in pausa un upgrade per i seguenti motivi:
Hai rilevato qualcosa di sbagliato nei carichi di lavoro del cluster durante l'upgrade e vuoi mettere in pausa l'upgrade per analizzare il problema
Hai periodi di manutenzione brevi, quindi vuoi mettere in pausa l'upgrade tra tra le finestre
Mentre l'upgrade di un cluster è in pausa, sono supportate le seguenti operazioni:
- Aggiungere o rimuovere nodi
- Aggiunta o rimozione di pool di nodi
- Aumento dell'intervallo della rete di servizi
- Ripristinare un cluster da un backup
Quando un nuovo nodo viene aggiunto mentre un upgrade è in pausa, i job di controllo delle macchine non finché l'upgrade non viene ripreso e completato.
Mentre l'upgrade del cluster è in pausa, le seguenti operazioni del cluster non vengono supportati:
Non puoi avviare un upgrade di un nuovo cluster mentre è in corso 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 abilitarlo con un'annotazione nella risorsa Cluster.
Per mettere in pausa e riprendere l'upgrade, segui questi passaggi:
Aggiungi
preview.baremetal.cluster.gke.io/upgrade-pause-and-resume
nel 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: ...
Per applicare la modifica, aggiorna il cluster:
bmctl update CLUSTER_NAME
La
nodePoolUpgradeStrategy.pause
è modificabile. Puoi aggiungerlo e aggiornarlo in qualsiasi momento.
Metti in pausa un upgrade
Metti in pausa l'upgrade di un cluster impostando nodePoolUpgradeStrategy.pause
su true
nella specifica del cluster.
Per mettere in pausa l'upgrade di un cluster attivo:
Aggiungi
nodePoolUpgradeStrategy.pause
al file di configurazione del cluster e impostalo sutrue
: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 servirà una nuova finestra del terminale per eseguire il passaggio successivo.Per applicare la modifica, aggiorna il cluster:
bmctl update CLUSTER_NAME
L'operazione di upgrade è in pausa. Non vengono attivati nuovi upgrade dei nodi.
Se hai utilizzato
bmctl
per avviare l'upgrade e stai pianificando una di una pausa di lunga durata, premi Ctrl+C per uscire dabmctl
, altrimenti mantienibmctl
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 dabmctl
, la registrazione viene interrotta avanzamento dell'upgrade al log dicluster-upgrade-TIMESTAMP
nella cartella del cluster sulla workstation di amministrazione in Cloud Logging. Di conseguenza, per le pause brevi, ti consigliamo di mantenerebmctl
in esecuzione. Se lasci in esecuzionebmctl
per un periodo prolungato mentre è in pausa, alla fine si verifica un timeout.
Riprendi un upgrade in pausa
Puoi riprendere l'upgrade di un cluster in pausa tramite una delle due impostazioni
Da nodePoolUpgradeStrategy.pause
a false
nella specifica del cluster o rimozione
nodePoolUpgradeStrategy.pause
secondo le specifiche.
Per riprendere l'upgrade di un cluster che è stato messo in pausa, segui questi passaggi:
Imposta
nodePoolUpgradeStrategy.pause
sul file di configurazione del cluster e impostalo sufalse
: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 predefinitafalse
.Per applicare la modifica, aggiorna il cluster:
bmctl update CLUSTER_NAME
L'operazione di upgrade riprende da dove era stata interrotta.
Per controllare lo stato dell'upgrade, devi prima ottenere un elenco delle risorse che hanno
anthosBareMetalVersion
nel lorostatus
:kubectl get RESOURCE --kubeconfig ADMIN_KUBECONFIG --all_namespaces
Sostituisci quanto segue:
RESOURCE
: il nome della risorsa che vuoi ottenere. Le risorseCluster
,NodePool
eBareMetalMachine
contengono tutte Informazioni sullo stato dianthosBareMetalVersion
.ADMIN_KUBECONFIG
: il percorso del cluster di amministrazione kubeconfig.
L'esempio seguente mostra il formato della risposta per
BareMetalMachine
risorse personalizzate. OgniBareMetalMachine
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
Per controllare
status.anthosBareMetalVersion
(versione attuale risorsa), recupera i dettagli delle singole risorse:kubectl describe RESOURCE RESOURCE_NAME \ --kubeconfig ADMIN_KUBECONFIG \ --namespace CLUSTER_NAMESPACE
L'esempio seguente mostra i dettagli di
BareMetalMachine
per il cluster nodo con indirizzo IP192.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.