Ciclo di vita e fasi degli upgrade dei cluster

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

Panoramica

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

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

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

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

Un'operazione di upgrade riuscita riconcilia status.anthosBareMetalVersion con 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 le versioni tra un cluster di gestione (ibrido o amministratore) e i relativi cluster utente gestiti. Quando aggiungi o esegui l'upgrade di un cluster utente, vengono applicate le seguenti regole di versione:

1,29

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

  • Le versioni del cluster utente non possono essere successive alla versione del cluster di gestione (amministrativa o ibrida).

  • (1.29 Anteprima) I cluster utente possono essere 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 n-2 è disponibile come funzionalità di anteprima per gestire i cluster alla versione 1.29.

  • (1.29 Anteprima) Per un determinato cluster di gestione, non è necessario che i cluster utente abbiano la stessa versione secondaria l'uno dell'altro. Ad esempio, un cluster di amministrazione della versione 1.29 può gestire i cluster utente delle versioni 1.29, 1.28 e 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 con inclinazione multipla Anteprima offre una maggiore flessibilità per pianificare gli upgrade del parco risorse. Ad esempio, non è necessario eseguire l'upgrade di tutti i cluster utente dalla versione 1.16 alla versione 1.28 prima di poter eseguire l'upgrade del cluster di amministrazione alla versione 1.29.

1.28 e precedenti

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

  • Le versioni del cluster utente non possono essere successive alla versione del cluster di gestione (amministrativa o ibrida).

  • I cluster utente possono essere fino a una versione secondaria inferiore rispetto alla versione del cluster di gestione. Ad esempio, un cluster di amministrazione della versione 1.28 non può gestire un cluster utente con la 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 amministratore, ibrido, autonomo 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.200-gke.243 di bmctl, puoi eseguire l'upgrade di un cluster solo alla versione 1.29.200-gke.243.

Upgrade delle versioni patch

Per una determinata versione secondaria, puoi eseguire l'upgrade a qualsiasi versione di patch superiore. 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 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 nei cluster siano applicate le correzioni di sicurezza più recenti.

Upgrade delle versioni minori

Puoi eseguire l'upgrade dei cluster da una versione secondaria all'altra, 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 cluster e N+1 è la successiva 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.700-gke.150 a 1.29.200-gke.243.

Non puoi saltare le versioni secondarie durante l'upgrade dei cluster. Se tenti di eseguire l'upgrade a una versione secondaria superiore di due o più versioni secondarie alla versione del cluster, bmctl emette 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 utilizzano la stessa versione secondaria o una precedente. I cluster utente gestiti non possono avere una versione secondaria inferiore di più di una versione 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 maggiore 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 avere una versione rilasciata cronologicamente più avanti rispetto alla versione del cluster. La release precedente non include i dettagli completi per quella successiva, 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. Allo stesso modo, 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 maggiore 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 è di due versioni secondarie quando la funzionalità Anteprima è abilitata per il disallineamento n-2 delle versioni. Se non abiliti questa funzionalità, il disallineamento massimo delle versioni tra un pool di nodi worker e il cluster è una versione secondaria.

  • I pool di nodi worker non possono avere una versione rilasciata cronologicamente più avanti rispetto alla versione del cluster. La release precedente non include i dettagli completi per quella successiva, 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. Allo stesso modo, 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 maggiore o uguale alla versione del pool di nodi worker.

  • 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 avere una versione rilasciata cronologicamente più avanti rispetto alla versione del cluster. La release precedente non include i dettagli completi per quella successiva, 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. Allo stesso modo, 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 del cluster (piano di controllo) Versioni del pool di nodi worker supportate
1.29.200-gke.243
  • 1.29.200-gke.243
  • 1.29.100-gke.251
  • 1.29.0-gke.1449
  • 1.28.500-gke.120
  • 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.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.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 del cluster (piano di controllo) Versioni del pool di nodi worker supportate
1.28.700-gke.150
  • 1.28.700-gke.150
  • 1.28.600-gke.163
  • 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.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.28.600-gke.163
  • 1.28.600-gke.163
  • 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.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.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 del cluster (piano di controllo) Versioni del pool di nodi worker supportate
1.16.10
  • 1.16.10
  • 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.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 sia a livello di nodo che di cluster. A livello di cluster, viene eseguito l'upgrade dei seguenti componenti:

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

I nodi in un cluster vengono eseguiti con uno dei seguenti ruoli, con l'upgrade dei vari componenti in base al ruolo del nodo:

Ruolo del nodo Funzione Componenti di cui eseguire l'upgrade
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 Keepafound che gestiscono il traffico a kube-apiserver ed eseguono speaker MetalLB per rivendicare indirizzi IP virtuali Pod statici del bilanciatore del carico del piano di controllo (HAProxy, Keepafound)

Speaker MetalLB

Aspettative relative al tempo di riposo

La tabella seguente descrive in dettaglio il tempo di inattività previsto e l'impatto potenziale dell'upgrade dei cluster. Questa tabella presuppone che tu disponga 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à, sono previsti tempi di inattività aggiuntivi. Se non indicato, questo tempo di inattività si applica agli upgrade dei cluster di amministrazione e dei cluster utente:

Componenti Aspettative relative al tempo di riposo Quando si verifica un tempo di inattività
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 Operatore svuotato e aggiornato. 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.
Container Network Interface (CNI) Nessun tempo di inattività per le route di rete esistenti.

Deployment di DaemonSet 2 a due senza tempi di inattività.

È stato eseguito lo svuotamento e l'upgrade dell'operatore. Tempo di riposo inferiore a 5 minuti.		 Al termine dell'upgrade dei nodi del piano di controllo.
MetalLB (solo cluster utente) Operatore svuotato e aggiornato. 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 gestore della scalabilità automatica DNS (solo cluster utente) CoreDNS ha più repliche con il gestore della scalabilità automatica. Di solito nessun tempo di inattività. Al termine dell'upgrade dei nodi del piano di controllo.
Provisioner volume locale Nessun tempo di inattività per i volumi permanenti di cui è stato eseguito il provisioning (PV) esistenti.

L'operatore potrebbe avere un tempo di inattività di 5 minuti.		 Al termine dell'upgrade dei nodi del piano di controllo.
Istio / in entrata È stato eseguito lo svuotamento e l'upgrade dell'operatore Istio. Circa 5 minuti di inattività.

Il traffico in entrata configurato esistente continuerà a funzionare.		 Al termine dell'upgrade dei nodi del piano di controllo.
Altri operatori di sistema Tempo di inattività di 5 minuti dopo lo svuotamento e l'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 comprenderne il potenziale impatto.		 Quando viene eseguito l'upgrade dei nodi worker.

Dettagli dell'upgrade del cluster utente

Questa sezione descrive 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 ulteriori controlli di integrità sul cluster prima dell'inizio del processo di upgrade.

Il diagramma precedente descrive i passaggi che vengono eseguiti durante un upgrade:

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

Se i controlli preflight hanno esito positivo e non sono presenti problemi di blocco, 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 e del pool di nodi del piano di controllo, quindi dell'upgrade e poi di GKE Connect, dei componenti aggiuntivi del cluster, del pool di nodi del bilanciatore del carico e dei pool di nodi worker.

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

  1. L'upgrade inizia aggiornando il campo spec.anthosBareMetalVersion.
  2. Viene eseguito l'upgrade dei bilanciatori del carico del piano di controllo.
  3. È stato eseguito l'upgrade del pool di nodi del piano di controllo.
  4. In parallelo, viene eseguito l'upgrade di GKE Connect, dei componenti aggiuntivi dei cluster e del pool di nodi del bilanciatore del carico.
    1. Al termine dell'upgrade del pool di nodi del bilanciatore del carico, verrà eseguito l'upgrade dei pool di nodi worker.

  5. Al termine dell'upgrade di tutti i componenti, vengono eseguiti i controlli di integrità del cluster.

    I controlli di integrità continuano a essere eseguiti fino al superamento di tutti i controlli.

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

Ogni componente ha il 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 i 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 in Cluster.Spec non è specificato alcun bilanciatore del carico del piano di controllo separato.
3 status.anthosBareMetalVersions Una mappa aggregata delle versioni in base ai numeri di nodo.
4 status.anthosBareMetalVersion Stato finale della versione aggiornata.

Dettagli sull'upgrade di cluster amministratore, ibrido e autonomo

A partire da bmctl versione 1.15.0, il comportamento predefinito dell'upgrade per i cluster autogestiti (amministrativi, ibridi o autonomi) è un upgrade in loco. In altre parole, 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, il che rende gli upgrade dei cluster più affidabili e scalabili.

Anche se non è consigliato utilizzare un cluster di bootstrap per l'upgrade, l'opzione è comunque disponibile. Per utilizzare un cluster di bootstrap durante 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 di upgrade in loco predefinito per i cluster autogestiti è simile a quello del cluster utente. Tuttavia, quando utilizzi il processo di upgrade in loco, viene eseguito il deployment di una nuova versione dell'preflightcheck-operator prima dell'esecuzione del controllo preflight e dei controlli di integrità del cluster:

Viene eseguito il deployment di una nuova versione dell'operatore preflightcheck 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. Prima di aggiornare i componenti, vengono eseguiti due passaggi aggiuntivi, come illustrato nel seguente diagramma: lifecycle-controller-manager esegue automaticamente l'upgrade alla versione di destinazione, quindi esegue il deployment della versione di destinazione di anthos-cluster-operator. anthos-cluster-operator esegue i passaggi rimanenti del processo di upgrade:

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

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

Esegui l'upgrade con un cluster di bootstrap

Il processo per eseguire l'upgrade di un cluster di amministrazione, ibrido o autonomo è simile a 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, di amministrazione 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 monitorare ed eseguire il debug del processo di upgrade. È possibile accedere al cluster di bootstrap tramite bmctl-workspace/.kindkubeconfig.

Per trasferire nuovamente la proprietà della gestione del cluster al termine dell'upgrade, il cluster esegue il pivot delle risorse dal cluster di bootstrap al cluster con upgrade eseguito. Non devi eseguire manualmente alcun passaggio per eseguire il pivot del cluster durante il processo di upgrade. Il cluster di bootstrap viene eliminato una volta completato l'upgrade del cluster.

Svuotamento dei nodi

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

I deployment possono essere utilizzati per tollerare queste interruzioni. Un deployment può specificare che devono essere eseguite più repliche di un'applicazione o di 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 con l'API Eviction, che rispetta PodDisruptionBudgets (PDB). I PDB possono essere utilizzati 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 di un carico di lavoro quando è necessario ripianificare i pod. Lo svuotamento dei nodi basato su eliminazione è disponibile come GA per la release 1.29.

Nelle release 1.28 e precedenti, Google Distributed Cloud non rispetta i PDB quando i nodi vengono scaricati durante un upgrade. Il processo di svuotamento dei nodi rappresenta invece il miglior tentativo. 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