Ciclo di vita e fasi degli upgrade dei cluster

Quando esegui l'upgrade di Google Distributed Cloud, il processo di upgrade prevede più passaggi e componenti. Per monitorare lo stato dell'upgrade o diagnosticare e risolvere i problemi, è utile sapere che cosa succede quando esegui il comando bmctl upgrade cluster. Questo documento descrive in dettaglio i componenti e le fasi dell'upgrade di un cluster.

Panoramica

Il processo di upgrade sposta il tuo cluster Google Distributed Cloud dalla versione attuale a una versione superiore.

Queste informazioni sulla versione sono archiviate nelle seguenti località come parte della risorsa personalizzata del cluster nel cluster di amministrazione:

  • status.anthosBareMetalVersion: definisce la versione corrente del cluster.

  • spec.anthosBareMetalVersion: definisce la versione di destinazione e viene impostato all'inizio dell'esecuzione del processo di upgrade.

Un'operazione di upgrade riuscita esegue la riconciliazione tra status.anthosBareMetalVersion e spec.anthosBareMetalVersion in modo che entrambi mostrino la versione di destinazione.

Disallineamento delle versioni del cluster

Il disallineamento delle versioni del cluster è la differenza tra un cluster in gestione (ibrido o amministratore) e i relativi cluster utente gestiti. Quando aggiungi o esegui l'upgrade di un cluster utente, si applicano le seguenti regole della versione:

1,29

Le seguenti regole si applicano ai cluster utente gestiti da un cluster di amministrazione o da un cluster ibrido versione 1.29:

  • Le versioni del cluster utente non possono essere successive a quella del cluster di gestione (amministratore o ibrido).

  • (1.29 Anteprima) I cluster utente possono avere fino a due versioni secondarie sotto la versione del cluster di gestione. Ad esempio, un cluster di amministrazione della versione 1.29 può gestire un cluster utente 1.16. Questa gestione del disallineamento delle versioni n-2 è disponibile come funzionalità di anteprima per gestire i cluster con la versione 1.29.

  • (1.29 Anteprima) Per un determinato cluster di gestione, i cluster utente non devono avere la stessa versione secondaria degli altri. Ad esempio, un cluster di amministrazione della versione 1.29 può gestire i cluster utente della versione 1.29, della versione 1.28 e della versione 1.16. Questa gestione del disallineamento delle versioni mista è disponibile come funzionalità di anteprima per la gestione dei cluster nella versione 1.29.

    La funzionalità di gestione di più disallineamento Anteprima offre maggiore flessibilità per pianificare gli upgrade del parco risorse. Ad esempio, non è necessario eseguire l'upgrade di tutti i cluster utente della versione 1.16 alla versione 1.28 prima di poter eseguire l'upgrade del cluster di amministrazione alla versione 1.29.

1,28 e versioni precedenti

Le seguenti regole si applicano ai cluster utente gestiti da un cluster di amministrazione versione 1.28 o precedente o da un cluster ibrido:

  • Le versioni del cluster utente non possono essere successive a quella del cluster di gestione (amministratore o ibrido).

  • I cluster utente possono essere fino a una versione secondaria inferiore a quella del cluster di gestione. Ad esempio, un cluster di amministrazione della versione 1.28 non può gestire un cluster utente nella versione 1.15.

  • Per un determinato cluster di gestione, tutti i cluster utente gestiti devono avere la stessa versione secondaria.

Per informazioni sulle regole di disallineamento delle versioni per i pool di nodi, consulta Regole di controllo delle versioni dei pool di nodi.

Regole per le versioni

Quando scarichi e installi una nuova versione di bmctl, puoi eseguire l'upgrade dei cluster di amministrazione, ibridi, autonomi e utente creati o di cui è stato eseguito l'upgrade con una versione precedente di bmctl. Non è possibile eseguire il downgrade dei cluster a una versione precedente.

Puoi eseguire l'upgrade di un cluster solo a una versione corrispondente alla versione di bmctl che stai utilizzando. Ciò significa che se utilizzi la versione 1.29.100-gke.251 di bmctl, puoi eseguire l'upgrade di un cluster solo alla versione 1.29.100-gke.251.

Upgrade della versione delle patch

Per una determinata versione secondaria, puoi eseguire l'upgrade a qualsiasi versione patch successiva. In altre parole, puoi eseguire l'upgrade di un cluster di versione 1.29.X alla versione 1.29.Y, purché Y sia superiore a X. Ad esempio, puoi eseguire l'upgrade da 1.28.0 a 1.28.100 e puoi eseguire l'upgrade da 1.28.100 a 1.28.300. Ti consigliamo di eseguire l'upgrade alla versione più recente della patch quando possibile per assicurarti che i tuoi cluster dispongano delle correzioni di sicurezza più recenti.

Upgrade della versione secondaria

Puoi eseguire l'upgrade dei cluster da una versione secondaria alla successiva, indipendentemente dalla versione della patch. In altre parole, puoi eseguire l'upgrade da 1.N.X a 1.N+1.Y, dove 1.N.X è la versione del tuo cluster e N+1 è la prossima versione secondaria disponibile. In questo caso, le versioni della patch, X e Y, non influiscono sulla logica di upgrade. Ad esempio, puoi eseguire l'upgrade da 1.28.500-gke.120 a 1.29.100-gke.251.

Non puoi saltare le versioni secondarie durante l'upgrade dei cluster. Se tenti di eseguire l'upgrade a una versione secondaria superiore a quella del cluster di due o più versioni secondarie, bmctl genera un errore. Ad esempio, non puoi eseguire l'upgrade di un cluster di versione 1.16.0 alla versione 1.29.0.

Un cluster di amministrazione può gestire i cluster utente che si trovano nella versione secondaria uguale o precedente. I cluster utente gestiti non possono essere inferiori di più di una versione secondaria rispetto al cluster di amministrazione. Di conseguenza, prima di eseguire l'upgrade di un cluster di amministrazione a una nuova versione secondaria, assicurati che tutti i cluster utente gestiti abbiano la stessa versione secondaria del cluster di amministrazione.

Regole di controllo delle versioni dei pool di nodi

Quando esegui l'upgrade dei pool di nodi in modo selettivo, si applicano le seguenti regole di versione:

1,29

  • La versione del cluster deve essere superiore o uguale alla versione del pool di nodi worker.

  • (1.29 GA) Il disallineamento massimo delle versioni tra un pool di nodi worker e il cluster è costituito da due versioni secondarie.

  • I pool di nodi worker non possono essere a una versione rilasciata cronologicamente successivamente alla versione del cluster. La release precedente non include i dettagli completi per la release successiva, il che è un requisito di compatibilità.

    Ad esempio, la versione 1.16.6 rilasciata dopo il rilascio della versione 1.28.100-gke.146, pertanto non puoi eseguire l'upgrade del cluster dalla versione 1.16.6 alla versione 1.28.100-gke.146 e lasciare un pool di nodi worker alla versione 1.16.6. Analogamente, se esegui l'upgrade del cluster alla versione 1.28.100-gke.146, ma hai scelto di lasciare un pool di nodi worker alla versione 1.16.5, non puoi eseguire l'upgrade del pool di nodi worker alla versione 1.16.6 mentre il cluster è alla versione 1.28.100-gke.146.

1,28

  • La versione del cluster deve essere superiore o uguale alla versione del pool di nodi worker.

  • (1.28 Anteprima) Il disallineamento massimo delle versioni tra un pool di nodi worker e il cluster è costituito da due versioni secondarie quando è abilitata la funzionalità n-2 disallineamento delle versioni Anteprima. Se non abiliti questa funzionalità, il disallineamento massimo delle versioni tra un pool di nodi worker e il cluster è di una versione secondaria.

  • I pool di nodi worker non possono essere a una versione rilasciata cronologicamente successivamente alla versione del cluster. La release precedente non include i dettagli completi per la release successiva, il che è un requisito di compatibilità.

    Ad esempio, la versione 1.16.6 rilasciata dopo il rilascio della versione 1.28.100-gke.146, pertanto non puoi eseguire l'upgrade del cluster dalla versione 1.16.6 alla versione 1.28.100-gke.146 e lasciare un pool di nodi worker alla versione 1.16.6. Analogamente, se esegui l'upgrade del cluster alla versione 1.28.100-gke.146, ma hai scelto di lasciare un pool di nodi worker alla versione 1.16.5, non puoi eseguire l'upgrade del pool di nodi worker alla versione 1.16.6 mentre il cluster è alla versione 1.28.100-gke.146.

1,16

  • La versione del cluster deve essere superiore o uguale alla versione del pool di nodi worker.

  • Il disallineamento massimo delle versioni tra un pool di nodi worker e il cluster è una versione secondaria.

  • I pool di nodi worker non possono essere a una versione rilasciata cronologicamente successivamente alla versione del cluster. La release precedente non include i dettagli completi per la release successiva, il che è un requisito di compatibilità.

    Ad esempio, la versione 1.16.6 rilasciata dopo il rilascio della versione 1.28.100-gke.146, pertanto non puoi eseguire l'upgrade del cluster dalla versione 1.16.6 alla versione 1.28.100-gke.146 e lasciare un pool di nodi worker alla versione 1.16.6. Analogamente, se esegui l'upgrade del cluster alla versione 1.28.100-gke.146, ma hai scelto di lasciare un pool di nodi worker alla versione 1.16.5, non puoi eseguire l'upgrade del pool di nodi worker alla versione 1.16.6 mentre il cluster è alla versione 1.28.100-gke.146.

La seguente tabella elenca le versioni del pool di nodi supportate consentite per una versione specifica del cluster:

1,29

Versione cluster (piano di controllo) Versioni di pool di nodi worker supportate
1.29.100-gke.251
  • 1.29.100-gke.251
  • 1.29.0-gke.1449
  • 1.28.400-gke.77
  • 1.28.300-gke.136
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.435
  • 1.16.8
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
1.29.0-gke.1449
  • 1.29.0-gke.1449
  • 1.28.300-gke.136
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.435
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0

1,28

Versione cluster (piano di controllo) Versioni di pool di nodi worker supportate
1.28.500-gke.120
  • 1.28.500-gke.120
  • 1.28.400-gke.77
  • 1.28.300-gke.131
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.400-gke.77
  • 1.28.400-gke.77
  • 1.28.300-gke.131
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.300-gke.131
  • 1.28.300-gke.131
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.200-gke.118
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.100-gke.146
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.0-gke.425
  • 1.28.0-gke.425
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0

     

     

     

1,16

Versione cluster (piano di controllo) Versioni di pool di nodi worker supportate
1.16.9
  • 1.16.9
  • 1.16.8
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.8
  • 1.16.8
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.7
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.6
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.5
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.4
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.3
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.2
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.1
  • 1.16.1
  • 1.16.0
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.0
  • 1.16.0
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0

Esegui l'upgrade dei componenti

L'upgrade dei componenti viene eseguito a livello di nodo e di cluster. A livello di cluster, viene eseguito l'upgrade dei seguenti componenti:

  • Componenti del cluster per networking, osservabilità e archiviazione.
  • Per cluster amministrativi, ibridi e autonomi, i controller del ciclo di vita.
  • L'elemento gke-connect-agent.

I nodi in un cluster vengono eseguiti come uno dei seguenti ruoli, con upgrade di componenti diversi in base al ruolo del nodo:

Ruolo del nodo Funzione Componenti da aggiornare
Worker Esegue carichi di lavoro utente Kubelet, runtime del container (Docker o containerd)
Piano di controllo Esegue il piano di controllo Kubernetes, i controller del ciclo di vita dei cluster e i componenti aggiuntivi della piattaforma Google Kubernetes Engine (GKE) Enterprise Pod statici del piano di controllo Kubernetes (kubeapi-server, kube-scheduler, kube-controller-manager e così via)

Controller del ciclo di vita come lifecycle-controllers-manager e anthos-cluster-operator

Componenti aggiuntivi della piattaforma Google Kubernetes Engine (GKE) Enterprise come stackdriver-log-aggregator e gke-connect-agent
Bilanciatore del carico del piano di controllo Esegue HAProxy e KeepaDuration che gestiscono il traffico a kube-apiserver ed eseguono speaker MetalLB per rivendicare gli indirizzi IP virtuali Pod statici del bilanciatore del carico del piano di controllo (HAProxy, KeepaDuration)

Speaker MetalLB

Aspettativa di tempo di riposo

La seguente tabella descrive i tempi di inattività previsti e il potenziale impatto quando esegui l'upgrade dei cluster. Questa tabella presuppone la presenza di più nodi cluster e di un piano di controllo ad alta disponibilità. Se esegui un cluster autonomo o non hai un piano di controllo ad alta disponibilità, è previsto tempi di inattività aggiuntivi. Se non diversamente specificato, questo tempo di inattività si applica agli upgrade dei cluster di amministrazione e utente:

Componenti Aspettative relative al tempo di riposo Quando si verifica il tempo di riposo
Server API del piano di controllo Kubernetes (kube-apiserver), etcd e scheduler Zero tempi di inattività N/A
Controller del ciclo di vita e job ansible-runner (solo cluster di amministrazione) Zero tempi di inattività N/A
Piano di controllo Kubernetes loadbalancer-haproxy e keepalived Tempo di inattività temporaneo (meno di 1-2 minuti) quando il bilanciatore del carico reindirizza il traffico. Inizio del processo di upgrade.
Osservabilità pipeline-stackdriver e metrics-server Utente svuotato ed eseguito l'upgrade. Il tempo di riposo dovrebbe essere inferiore a 5 minuti.

I DaemonSet continuano a funzionare senza tempi di inattività.		 Al termine dell'upgrade dei nodi del piano di controllo.
Interfaccia di rete del container (CNI) Nessun tempo di inattività per le route di networking esistenti.

Deployment di DaemonSet 2:2 senza tempi di inattività.

Svuotamento dell'operatore ed è stato eseguito l'upgrade. Tempo di riposo inferiore a 5 minuti.		 Al termine dell'upgrade dei nodi del piano di controllo.
MetalLB (solo cluster utente) Utente svuotato ed eseguito l'upgrade. Il tempo di riposo è inferiore a 5 minuti.

Nessun tempo di inattività per il servizio esistente		 Al termine dell'upgrade dei nodi del piano di controllo.
CoreDNS e DNS gestore della scalabilità automatica (solo cluster utente) CoreDNS ha più repliche con il gestore della scalabilità automatica. Solitamente senza tempi di inattività. Al termine dell'upgrade dei nodi del piano di controllo.
Provisioning del volume locale Nessun tempo di inattività per i volumi permanenti (PV) di cui è stato eseguito il provisioning esistente.

L'operatore potrebbe avere un tempo di inattività di 5 minuti.		 Al termine dell'upgrade dei nodi del piano di controllo.
Istio / Ingress Viene svuotato ed eseguito l'upgrade dell'operatore Istio. Tempo di inattività di circa 5 minuti.

Il traffico in entrata configurato esistente continua a funzionare.		 Al termine dell'upgrade dei nodi del piano di controllo.
Altri operatori di sistema 5 minuti di tempo di inattività in caso di svuotamento e upgrade. Al termine dell'upgrade dei nodi del piano di controllo.
Carichi di lavoro utente Dipende dalla configurazione, ad esempio dalla disponibilità elevata.

Esamina i deployment dei tuoi carichi di lavoro per comprendere il potenziale impatto.		 Quando viene eseguito l'upgrade dei nodi worker.

Dettagli dell'upgrade del cluster utente

Questa sezione descrive in dettaglio l'ordine degli upgrade dei componenti e le informazioni sullo stato per l'upgrade di un cluster utente. La sezione seguente descrive le deviazioni da questo flusso per gli upgrade di cluster amministrativi, ibridi o autonomi.

Il seguente diagramma mostra il processo di controllo preflight per l'upgrade di un cluster utente:

Il controllo preflight del cluster esegue controlli di integrità aggiuntivi sul cluster prima dell'avvio del processo di upgrade.

Il diagramma precedente descrive in dettaglio i passaggi che si verificano durante un upgrade:

  • Il comando bmctl upgrade cluster crea una risorsa personalizzata PreflightCheck.
  • Questo controllo preflight esegue controlli aggiuntivi come quelli di upgrade del cluster, di integrità della rete e dei nodi.
  • I risultati di questi controlli aggiuntivi vengono combinati per segnalare la capacità del cluster di eseguire correttamente l'upgrade alla versione di destinazione.

Se i controlli preflight hanno esito positivo e non sono presenti problemi che bloccano la migrazione, l'upgrade dei componenti nel cluster viene eseguito in un ordine specificato, come mostrato nel diagramma seguente:

Viene eseguito l'upgrade dei bilanciatori del carico del piano di controllo, del pool di nodi del piano di controllo e dell'upgrade, quindi di GKE Connect, dei componenti aggiuntivi del cluster, del pool di nodi e dei pool di nodi worker del bilanciatore del carico.

Nel diagramma precedente, l'upgrade dei componenti viene eseguito nel seguente modo:

  1. L'upgrade inizia aggiornando il campo spec.anthosBareMetalVersion.
  2. È stato eseguito l'upgrade dei bilanciatori del carico del piano di controllo.
  3. Viene eseguito l'upgrade del pool di nodi del piano di controllo.
  4. Parallelamente, viene eseguito l'upgrade di GKE Connect, dei componenti aggiuntivi del cluster e del pool di nodi del bilanciatore del carico.
    1. Una volta completato l'upgrade del pool di nodi del bilanciatore del carico, viene eseguito l'upgrade dei pool di nodi worker.

  5. Una volta eseguito l'upgrade di tutti i componenti, vengono eseguiti i controlli di integrità del cluster.

    I controlli di integrità continuano a essere eseguiti finché non vengono superati tutti i controlli.

  6. Una volta superati tutti i controlli di integrità, l'upgrade è terminato.

Ogni componente ha un proprio campo di stato all'interno della risorsa personalizzata Cluster. Puoi controllare lo stato in questi campi per comprendere l'avanzamento dell'upgrade:

Sequenza Nome campo Significato
1 status.controlPlaneNodepoolStatus Lo stato viene copiato dallo stato del pool di nodi del piano di controllo. Il campo include le versioni dei nodi dei pool di nodi del piano di controllo
2 status.anthosBareMetalLifecycleControllersManifestsVersion Versione di lifecycles-controllers-manager applicata al cluster. Questo campo è disponibile solo per cluster di amministrazione, autonomi o ibridi.
2 status.anthosBareMetalManifestsVersion Versione del cluster dall'ultimo manifest applicato.
2 status.controlPlaneLoadBalancerNodepoolStatus Lo stato viene copiato dallo stato del pool di nodi del bilanciatore del carico del piano di controllo. Questo campo è vuoto se non viene specificato alcun bilanciatore del carico del piano di controllo separato in Cluster.Spec.
3 status.anthosBareMetalVersions Una mappa aggregata della versione della versione ai numeri di nodi.
4 status.anthosBareMetalVersion Stato finale della versione aggiornata.

Dettagli dell'upgrade dei cluster amministrativi, ibridi e autonomi

A partire dalla versione 1.15.0 di bmctl, il comportamento predefinito per l'upgrade dei cluster autogestiti (amministratori, ibridi o autonomi) è un upgrade in loco. Ciò significa che quando esegui l'upgrade di un cluster alla versione 1.15.0 o successiva, l'upgrade utilizza 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.

Sebbene non sia consigliato utilizzare un cluster di bootstrap per l'upgrade, l'opzione è ancora disponibile. Per utilizzare un cluster di bootstrap quando esegui l'upgrade, esegui il comando bmctl upgrade con il flag --use-bootstrap=true. Le fasi dell'upgrade sono diverse a seconda del metodo utilizzato.

Upgrade in loco

Il processo predefinito di upgrade in loco per i cluster autogestiti è simile al processo di upgrade dei cluster utente. Tuttavia, quando utilizzi il processo di upgrade in loco, viene eseguito il deployment di una nuova versione di preflightcheck-operator prima dell'esecuzione del controllo preflight del cluster e dei controlli di integrità:

Viene eseguito il deployment di una nuova versione dell'operatore preflightcheck-operator prima che il controllo preflight del cluster esegua ulteriori controlli di integrità sul cluster.

Come per l'upgrade del cluster utente, il processo di upgrade inizia aggiornando il campo Cluster.spec.anthosBareMetalVersion alla versione di destinazione. Vengono eseguiti due passaggi aggiuntivi prima che i componenti vengano aggiornati, come mostrato nel seguente schema: lifecycle-controller-manager esegue automaticamente l'upgrade alla versione di destinazione, quindi esegue il deployment della versione di destinazione di anthos-cluster-operator. Questa azione anthos-cluster-operator esegue i restanti passaggi del processo di upgrade:

Il deployment di ciclo-controller-manager e anthos-cluster-operator viene eseguito prima dell'upgrade del resto del cluster nello stesso ordine dei componenti nel cluster utente.

Se l'operazione riesce, l'anthos-cluster-operator riconcilia la versione di destinazione da spec.anthosBareMetalVersion a status.anthosBareMetalVersion.

Esegui l'upgrade con un cluster di bootstrap

Il processo di upgrade di un cluster amministratore, ibrido o autonomo è simile a quello di un cluster utente discusso nella sezione precedente.

La differenza principale è che il comando bmctl upgrade cluster avvia un processo per creare un cluster di bootstrap. Questo cluster di bootstrap è un cluster temporaneo che gestisce il cluster ibrido, amministratore o autonomo durante un upgrade.

Il processo per trasferire la proprietà della gestione del cluster al cluster di bootstrap è chiamato pivot. Il resto dell'upgrade segue la stessa procedura dell'upgrade del cluster utente.

Durante il processo di upgrade, le risorse nel cluster di destinazione rimangono inattive. L'avanzamento dell'upgrade si riflette solo nelle risorse del cluster di bootstrap.

Se necessario, puoi accedere al cluster di bootstrap per facilitare il monitoraggio e il debug del processo di upgrade. È possibile accedere al cluster di bootstrap tramite bmctl-workspace/.kindkubeconfig.

Per trasferire di nuovo la proprietà gestita del cluster dopo il completamento dell'upgrade, il cluster esegue il pivot delle risorse dal cluster di bootstrap al cluster di cui è stato eseguito l'upgrade. Non devi eseguire passaggi manuali per eseguire il pivot del cluster durante il processo di upgrade. Il cluster di bootstrap viene eliminato dopo il completamento dell'upgrade del cluster.

Svuotamento dei nodi

Gli upgrade dei cluster Google Distributed Cloud potrebbero causare l'interruzione delle applicazioni durante lo svuotamento dei nodi. Questo processo di svuotamento provoca l'arresto e il riavvio di tutti i pod in esecuzione su un nodo sui nodi rimanenti nel cluster.

Gli oggetti Deployment possono essere usati per tollerare questo tipo di interruzione. Un oggetto Deployment può specificare più repliche per l'esecuzione di un'applicazione o un servizio. Un'applicazione con più repliche dovrebbe subire interruzioni minime o nulle durante gli upgrade.

PodDisruptionBudgets (PDB)

Quando esegui l'upgrade di un cluster, Google Distributed Cloud utilizza il flusso della modalità di manutenzione per svuotare i nodi.

A partire dalla release 1.29, i nodi vengono svuotati mediante l'API Eviction, che rispetta i PodDisruptionBudgets (PDB). Puoi utilizzare i PDB per garantire che un numero definito di repliche venga sempre eseguito nel cluster in condizioni di esecuzione normali. I PDB consentono di limitare l'interruzione a un carico di lavoro quando è necessario ripianificare i relativi pod. Lo svuotamento dei nodi basato sulla rimozione è disponibile in disponibilità generale per la release 1.29.

Nelle release 1.28 e precedenti, Google Distributed Cloud non rispetta i PDB quando i nodi si scaricano durante un upgrade. Invece, il processo di svuotamento dei nodi è il modo migliore. Alcuni pod potrebbero rimanere bloccati in uno stato Terminating e rifiutarsi di liberare il nodo. L'upgrade continua, anche con i pod bloccati, quando il processo di svuotamento su un nodo richiede più di 20 minuti.

Per ulteriori informazioni, consulta Mettere i nodi in modalità di manutenzione.

Passaggi successivi