Quando esegui l'upgrade di Google Distributed Cloud, la procedura di upgrade prevede più 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 in dettaglio i componenti e le fasi di un upgrade del cluster.
Panoramica
La procedura di upgrade sposta il cluster Google Distributed Cloud dalla versione corrente a una versione successiva.
Queste informazioni sulla versione vengono memorizzate nelle seguenti posizioni 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 quando inizia l'esecuzione della procedura di upgrade.
Un'operazione di upgrade riuscita riconcilia status.anthosBareMetalVersion con spec.anthosBareMetalVersion in modo che entrambe mostrino la versione di destinazione.
Disallineamento delle versioni del cluster
Lo skew della versione del cluster è la differenza di versioni tra un cluster di gestione (ibrido o amministrativo) e i relativi cluster utente gestiti. Quando aggiungi o esegui l'upgrade di un cluster utente, si applicano le seguenti regole di versione:
1,30
Le seguenti regole si applicano ai cluster di utenti gestiti da un cluster amministrativo o da un cluster ibrido della versione 1.30:
Le versioni dei cluster utente non possono essere superiori a quella del cluster di gestione (di amministrazione o ibrido).
(1.30 GA) I cluster utente possono essere fino a due versioni secondarie precedenti alla versione del cluster di gestione. Ad esempio, un cluster di amministrazione della versione 1.30 può gestire un cluster utente della versione 1.28. Questa funzionalità di gestione dello scostamento delle versioni n-2 è disponibile in versione GA per la gestione dei cluster a partire dalla versione 1.30.
(1.30 GA) Per un determinato cluster di gestione alla versione 1.30, i cluster utente non devono avere necessariamente la stessa versione secondaria. Ad esempio, un cluster di amministrazione della versione 1.30 può gestire i cluster utente della versione 1.30, 1.29 e 1.28.
La funzionalità di gestione multi-deviazione ti 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.28 alla versione 1.29 prima di poter eseguire l'upgrade del cluster di amministrazione alla versione 1.30.
1,29
Le seguenti regole si applicano ai cluster di utenti gestiti da un cluster amministrativo o un cluster ibrido della versione 1.29:
Le versioni dei cluster utente non possono essere superiori a quella del cluster di gestione (di amministrazione o ibrido).
(Anteprima 1.29) I cluster utente possono essere fino a due versioni secondarie precedenti rispetto alla versione del cluster di gestione. Ad esempio, un cluster di amministrazione della versione 1.29 può gestire un cluster utente 1.16. Questa gestione degli scostamenti delle versioni n-2 è disponibile come funzionalità Anteprima per la gestione dei cluster nella versione 1.29.
(Anteprima 1.29) Per un determinato cluster di gestione, i cluster utente non devono avere necessariamente la stessa versione secondaria. Ad esempio, un cluster amministrativo della versione 1.29 può gestire i cluster di utenti della versione 1.29, 1.28 e 1.16. Questa gestione dell'asimmetria delle versioni è disponibile come funzionalità in anteprima per la gestione dei cluster nella versione 1.29.
La funzionalità di gestione di più schemi di Anteprima ti offre maggiore flessibilità per pianificare gli upgrade del tuo 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 o un cluster ibrido della versione 1.28 o precedente:
Le versioni dei cluster utente non possono essere superiori a quella del cluster di gestione (di amministrazione o ibrido).
I cluster utente possono essere fino a una versione secondaria inferiore alla versione del cluster di gestione. Ad esempio, un cluster di amministrazione della versione 1.28 non può gestire un cluster utente della 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 versionamento dei pool di nodi.
Regole delle 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 in uso. In altre parole, se utilizzi la versione 1.30.300-gke.84 di bmctl, puoi eseguire l'upgrade di un cluster solo alla versione 1.30.300-gke.84.
Upgrade delle versioni patch
Per una determinata versione secondaria, puoi eseguire l'upgrade a qualsiasi versione della patch successiva. In altre parole,
puoi eseguire l'upgrade di un cluster con versione 1.30.X
alla versione
1.30.Y purché
Y sia maggiore di
X. Ad esempio, puoi eseguire l'upgrade da
1.29.0 a 1.29.100 e da
1.29.100 a 1.29.300. Ti consigliamo di eseguire l'upgrade alla versione più recente della patch, se possibile, per assicurarti che i tuoi cluster dispongano delle correzioni di sicurezza più recenti.
Upgrade delle versioni secondarie
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 successiva
versione minore disponibile. In questo caso, le versioni patch X e
Y non influiscono sulla logica di upgrade. Ad esempio, puoi eseguire l'upgrade da 1.29.800-gke.111 a
1.30.300-gke.84.
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 rispetto alla versione del cluster corrente, bmctl emette un errore. Ad esempio, non puoi eseguire l'upgrade di un cluster della versione 1.28.0 alla versione 1.30.0 in un unico passaggio.
Come descritto in precedenza, un cluster di amministrazione può gestire i cluster utente che utilizzano la stessa versione o una versione precedente. La differenza di versioni tra i cluster di utenti e il cluster di gestione (a volte indicato come "spostamento della versione") varia in base alla versione del cluster. Prima di eseguire l'upgrade di un cluster di gestione a una nuova versione secondaria, assicurati che le versioni dei cluster utente gestiti rimangano conformi alle regole di sfasamento delle versioni dei cluster per la versione di upgrade di destinazione.
Regole di versionamento dei node pool
Quando esegui l'upgrade dei node pool in modo selettivo, si applicano le seguenti regole di versione:
1,30
La versione del cluster deve essere maggiore o uguale alla versione del pool di nodi worker.
Lo scarto massimo tra le versioni di un pool di nodi worker e quelle del cluster è di due versioni minori.
I pool di nodi worker possono essere in qualsiasi versione patch di una versione secondaria compatibile.
1,29
La versione del cluster deve essere maggiore o uguale alla versione del pool di nodi worker.
(1.29 GA) Lo scarto massimo della versione tra un pool di nodi worker e il cluster è di due versioni minori.
I pool di nodi worker non possono essere in una versione rilasciata in un momento successivo rispetto alla versione del cluster. La release precedente non contiene dettagli completi per la release successiva, che è un requisito per la compatibilità.
Ad esempio, la versione 1.16.6 è stata rilasciata dopo la 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 nella 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 maggiore o uguale alla versione del pool di nodi worker.
(1.28 Preview) Lo scostamento massimo della versione tra un pool di nodi worker e il cluster è di due versioni minori quando è abilitata la funzionalità di anteprima dello scostamento della versione n-2. Se non attivi questa funzionalità, lo scarto massimo della versione tra un pool di nodi worker e il cluster è una versione minore.
I pool di nodi worker non possono essere in una versione rilasciata in un momento successivo rispetto alla versione del cluster. La release precedente non contiene dettagli completi per la release successiva, che è un requisito per la compatibilità.
Ad esempio, la versione 1.16.6 è stata rilasciata dopo la 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 nella 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 maggiore o uguale alla versione del pool di nodi worker.
Lo scarto massimo della versione tra un pool di nodi worker e il cluster è una versione minore.
I pool di nodi worker non possono essere in una versione rilasciata in un momento successivo rispetto alla versione del cluster. La release precedente non contiene dettagli completi per la release successiva, che è un requisito per la compatibilità.
Ad esempio, la versione 1.16.6 è stata rilasciata dopo la 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 nella 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 tabella seguente elenca le versioni dei pool di nodi supportate consentite per una versione specifica del cluster:
1,30
Per i pool di nodi con una versione secondaria compatibile, 1.29 o 1.28, tutte le versioni patch sono compatibili con i cluster con qualsiasi versione patch della versione secondaria 1.30.
1,29
| Versione del cluster (piano di controllo) | Versioni del pool di nodi worker supportate (versioni aggiunte in grassetto) | |||
|---|---|---|---|---|
| 1.29.800-gke.111 |
|
|
|
|
| 1.29.700-gke.113 |
|
|
|
|
| 1.29.600-gke.105 |
|
|
|
|
| 1.29.500-gke.162 |
|
|
|
|
| 1.29.400-gke.86 |
|
|
|
|
| 1.29.300-gke.185 |
|
|
|
|
| 1.29.200-gke.243 |
|
|
|
|
| 1.29.100-gke.251 |
|
|
|
|
| 1.29.0-gke.1449 |
|
|
|
|
1,28
| Versione del cluster (piano di controllo) | Versioni del pool di nodi worker supportate (versioni aggiunte in grassetto) | |||
|---|---|---|---|---|
| 1.28.1200-gke.83 |
|
|
|
|
| 1.28.1100-gke.94 |
|
|
|
|
| 1.28.1000-gke.60 |
|
|
|
|
| 1.28.900-gke.112 |
|
|
|
|
| 1.28.800-gke.111 |
|
|
|
|
| 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
| Versione del cluster (piano di controllo) | Versioni del pool di nodi worker supportate (versioni aggiunte in grassetto) | |||
|---|---|---|---|---|
| 1.16.12 |
|
|
|
|
| 1.16.11 |
|
|
|
|
| 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 |
|
|
||
Componenti di upgrade
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 di un cluster vengono eseguiti come uno dei seguenti ruoli, con l'upgrade di componenti diversi a seconda del ruolo del nodo:
| Ruolo del nodo | Funzione | Componenti di cui eseguire l'upgrade |
|---|---|---|
| Worker | Esegue i carichi di lavoro degli utenti | Kubelet, runtime del container (Docker o containerd) |
| Piano di controllo | Esegue il piano di controllo Kubernetes, i controller del ciclo di vita del cluster e i componenti aggiuntivi della piattaforma Google Kubernetes Engine (GKE) Enterprise | Pod statici del piano di controllo di Kubernetes (kubeapi-server,
kube-scheduler, kube-controller-manager, etcd)
Controllori del ciclo di vita come lifecycle-controllers-manager e
anthos-cluster-operatorComponenti aggiuntivi della piattaforma Google Kubernetes Engine (GKE) Enterprise come stackdriver-log-aggregator e
gke-connect-agent |
| Bilanciatore del carico del control plane | Esegue HAProxy e Keepalived che inviano traffico a
kube-apiserver ed esegue speaker MetalLB per rivendicare indirizzi IP virtuali
|
Pod statici del bilanciatore del carico del piano di controllo (HAProxy, Keepalived)
Speaker MetalLB |
Tempo di riposo previsto
La tabella seguente illustra il tempo di riposo previsto e il potenziale impatto durante l'upgrade dei cluster. Questa tabella presuppone che tu abbia più nodi del cluster e un piano di controllo ad alta disponibilità. Se utilizzi un cluster autonomo o non disponi di un control plane di HA, prevedi tempi di inattività aggiuntivi. Salvo diversa indicazione, questo tempo di riposo si applica sia agli upgrade dei cluster di amministrazione sia a quelli dei cluster utente:
| Componenti | Tempo di riposo previsto | Quando si verifica il tempo di riposo |
|---|---|---|
Server API del piano di controllo Kubernetes (kube-apiserver),
etcd e scheduler |
Zero tempi di inattività | N/D |
Controllori del ciclo di vita e job ansible-runner (solo
cluster di amministrazione) |
Zero tempi di inattività | N/D |
Piano di controllo Kubernetes loadbalancer-haproxy e
keepalived |
Tempo di inattività transitorio (meno di 1-2 minuti) quando il bilanciatore del carico reindirizza il traffico. | Avvio della procedura di upgrade. |
Osservabilità pipeline-stackdriver e
metrics-server |
L'operatore ha eseguito il backup e l'upgrade. Il tempo di riposo deve essere inferiore a 5 minuti.
I DaemonSet continuano a funzionare senza tempi di riposo. |
Al termine dell'upgrade dei nodi del piano di controllo. |
| Interfaccia di rete del contenitore (CNI) | Nessun tempo di riposo per le route di rete esistenti. Il DaemonSet è stato disegnato a due a due senza tempi di inattività. L'operatore viene svuotato e sottoposto ad upgrade. Tempo di inattività inferiore a 5 minuti. |
Al termine dell'upgrade dei nodi del piano di controllo. |
| MetalLB (solo cluster utente) | L'operatore ha eseguito il backup e l'upgrade. Il tempo di inattività è 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 Autoscaler (solo cluster utente) | CoreDNS ha più repliche con il gestore della scalabilità automatica. Di solito non c'è alcun tempo di riposo. | Al termine dell'upgrade dei nodi del piano di controllo. |
| Provisioner del volume locale | Nessun tempo di riposo per i volumi permanenti (PV) di cui è stato eseguito il provisioning esistenti.
L'operatore potrebbe avere un tempo di inattività di 5 minuti. |
Al termine dell'upgrade dei nodi del piano di controllo. |
| Istio / ingress | L'operatore Istio viene svuotato e sottoposto ad upgrade. Circa 5 minuti di
interruzione del servizio. Le importazioni configurate esistenti continueranno a funzionare. |
Al termine dell'upgrade dei nodi del piano di controllo. |
| Altri operatori di sistema | 5 minuti di tempo di riposo dopo lo svuotamento e l'upgrade. | Al termine dell'upgrade dei nodi del piano di controllo. |
| Workload utente | Dipende dalla configurazione, ad esempio se è ad alta disponibilità. Esamina i tuoi implementazioni dei 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 un upgrade del cluster utente. La sezione seguente descrive le deviazioni da questo flusso per gli upgrade di cluster amministrativi, ibridi o autonomi.
Il seguente diagramma mostra la procedura di controllo preflight per un upgrade del cluster utente:
Il diagramma precedente illustra i passaggi che si verificano durante un upgrade:
- Il comando
bmctl upgrade clustercrea una risorsa personalizzataPreflightCheck. - Questo controllo preflight esegue controlli aggiuntivi come controlli di upgrade del cluster, controlli di integrità della rete e controlli di integrità dei nodi.
- I risultati di questi controlli aggiuntivi si combinano per indicare la possibilità per il cluster di eseguire l'upgrade alla versione di destinazione.
Se i controlli preliminari vanno a buon fine e non ci sono problemi di blocco, viene eseguito l'upgrade dei componenti del cluster in un ordine specificato, come mostrato nel seguente diagramma:
Nel diagramma precedente, l'upgrade dei componenti viene eseguito nell'ordine seguente:
- L'upgrade inizia aggiornando il campo
spec.anthosBareMetalVersion. - Viene eseguito l'upgrade dei bilanciatori del carico del piano di controllo.
- Viene eseguito l'upgrade del pool di nodi del control plane.
- In parallelo, viene eseguito l'upgrade di GKE Connect, degli componenti aggiuntivi del cluster e del
pool di nodi del bilanciatore del carico.
- Dopo l'upgrade del pool di nodi del bilanciatore del carico, viene eseguito l'upgrade dei pool di nodi worker.
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.
Quando tutti i controlli di integrità vengono superati, 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 non viene specificato un bilanciatore del carico del piano di controllo distinto in Cluster.Spec. |
| 3 | status.anthosBareMetalVersions |
Una mappa delle versioni aggregate che associa le versioni ai numeri di nodo. |
| 4 | status.anthosBareMetalVersion |
Stato finale della versione di cui è stato eseguito l'upgrade. |
Dettagli sull'upgrade dei cluster di amministrazione, ibridi e autonomi
A partire dalla versione 1.15.0 di bmctl, il comportamento predefinito dell'upgrade per i cluster autogestiti (di amministrazione, ibridi o autonomi) è un upgrade in place.
In altre parole, quando esegui l'upgrade di un cluster alla versione 1.15.0 o successiva, l'upgrade
utilizza i controller del ciclo di vita anziché un cluster di bootstrap per gestire l'intero
processo di upgrade. Questa modifica semplifica la procedura e riduce i requisiti di risorse, il che rende gli upgrade dei cluster più affidabili e scalabili.
Sebbene l'utilizzo di un cluster di bootstrap per l'upgrade non sia consigliato, l'opzione è ancora 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
La procedura di upgrade in situ predefinita per i cluster autogestiti è simile alla procedura di upgrade dei cluster utente. Tuttavia, quando utilizzi la procedura di upgrade in situ, viene eseguita la distribuzione di una nuova versione di preflightcheck-operator prima dell'esecuzione del controllo preflight e dei controlli di integrità del cluster:
Come per l'upgrade del cluster utente, la procedura di upgrade inizia aggiornando il campo Cluster.spec.anthosBareMetalVersion alla versione di destinazione. Prima di aggiornare i componenti, vengono eseguiti altri due passaggi, come mostrato nel seguente diagramma: lifecycle-controller-manager esegue l'upgrade alla versione di destinazione e poi esegue il deployment della versione di destinazione di anthos-cluster-operator. Questo
anthos-cluster-operator esegue i passaggi rimanenti della procedura di upgrade:
In caso di esito positivo, anthos-cluster-operator riconcilia la versione target da
spec.anthosBareMetalVersion a status.anthosBareMetalVersion.
Eseguire l'upgrade con un cluster di bootstrap
La procedura per eseguire l'upgrade di un cluster di amministrazione, ibrido o autonomo è simile a quella per un cluster utente descritto 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 di trasferimento della proprietà di 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 viene visualizzato solo nelle risorse del cluster di bootstrap.
Se necessario, puoi accedere al cluster di bootstrap per monitorare e eseguire il debug della procedura di upgrade. È possibile accedere al cluster di bootstrap tramite
bmctl-workspace/.kindkubeconfig.
Per trasferire nuovamente la proprietà di gestione del cluster al termine dell'upgrade, il cluster esegue il pivot delle risorse dal cluster di bootstrap al cluster di cui è stato eseguito l'upgrade. Non sono previsti passaggi manuali per eseguire il pivot del cluster durante il processo di upgrade. Il cluster di bootstrap viene eliminato al termine dell'upgrade del cluster.
Svuotamento dei nodi
Gli upgrade dei cluster Google Distributed Cloud potrebbero causare interruzioni dell'applicazione man mano che i nodi vengono svuotati. Questo processo di svuotamento fa sì che tutti i pod in esecuzione su un nodo si arrestino e riavviino sui nodi rimanenti del 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 in 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 normale funzionamento.
I PDB ti consentono di limitare l'interruzione di un carico di lavoro quando i relativi pod devono essere riprogrammati. Lo svuotamento dei nodi basato sull'espulsione è disponibile come versione GA per la release 1.29.
Nelle release 1.28 e precedenti, Google Distributed Cloud non rispetta i PDB quando i nodi si svuotano durante un upgrade. Il processo di svuotamento dei nodi è invece il best effort. Alcuni
pod potrebbero rimanere bloccati in uno stato Terminating e rifiutarsi di liberare il nodo. L'upgrade procede, anche con i pod bloccati, quando il processo di svuotamento su un nodo richiede più di 20 minuti.
Per saperne di più, consulta Mettere i nodi in modalità di manutenzione.
Passaggi successivi
- Consulta le best practice per gli upgrade di Google Distributed Cloud
- Eseguire l'upgrade di Google Distributed Cloud
- Risolvere i problemi di upgrade del cluster