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 attuale a una versione successiva.
Queste informazioni sulla versione vengono archiviate 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 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
La differenza di versione del cluster è la differenza tra le versioni di un cluster di gestione (ibrido o di amministrazione) 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 e versioni successive
Ai cluster utente gestiti da un cluster di amministrazione o ibrido versione 1.30 o successiva si applicano le seguenti regole:
Le versioni dei cluster utente non possono essere superiori a quella del cluster di gestione (amministrazione o ibrido).
I cluster utente possono essere fino a due versioni secondarie precedenti alla versione del cluster di gestione. Ad esempio, un cluster di amministrazione versione 1.30 può gestire un cluster utente versione 1.28. Questa funzionalità di gestione dell'inclinazione della versione n-2 è disponibile a livello GA per la gestione dei cluster alla versione 1.30.
Per un determinato cluster di gestione alla versione 1.30 o successive, i cluster utente non devono avere la stessa versione secondaria. Ad esempio, un cluster di amministrazione versione 1.30 può gestire cluster utente versione 1.30, 1.29 e 1.28.
La funzionalità di gestione di più SKU offre maggiore flessibilità per pianificare gli upgrade della flotta. 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
Ai cluster utente gestiti da un cluster di amministrazione o ibrido versione 1.29 si applicano le seguenti regole:
Le versioni del cluster utente non possono essere superiori a quella del cluster di gestione (amministrazione o ibrido).
(1.29 Anteprima) I cluster utente possono essere fino a due versioni secondarie precedenti alla versione del cluster di gestione. Ad esempio, un cluster di amministrazione versione 1.29 può gestire un cluster utente 1.16. Questa gestione dell'inclinazione della versione n-2 è disponibile come funzionalità di anteprima per la gestione dei cluster alla versione 1.29.
(1.29 Anteprima) Per un determinato cluster di gestione, i cluster utente non devono avere la stessa versione secondaria. Ad esempio, un cluster di amministrazione versione 1.29 può gestire i cluster utente versione 1.29, 1.28 e 1.16. Questa gestione dell'inclinazione della versione mista è disponibile come funzionalità di anteprima per la gestione dei cluster alla versione 1.29.
La funzionalità di gestione multi-skew 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 precedenti
Ai cluster utente gestiti da un cluster di amministrazione o ibrido versione 1.28 o precedente si applicano le seguenti regole:
Le versioni del cluster utente non possono essere superiori a quella del cluster di gestione (amministrazione o ibrido).
I cluster utente possono avere una versione secondaria inferiore a quella del cluster di gestione. Ad esempio, un cluster di amministrazione versione 1.28 non può gestire un cluster utente 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 node pool, vedi Regole di controllo delle versioni dei node pool.
Regole di versione
Quando scarichi e installi una nuova versione di bmctl, puoi eseguire l'upgrade dei cluster di amministrazione, ibridi, autonomi e utente creati o aggiornati 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 a quella di bmctl che stai utilizzando. ovvero, se utilizzi la versione
1.32.100-gke.106 di bmctl, puoi eseguire l'upgrade di un cluster solo alla versione
1.32.100-gke.106.
Upgrade della versione patch
Per una determinata versione secondaria, puoi eseguire l'upgrade a qualsiasi versione patch successiva. ovvero puoi eseguire l'upgrade di un cluster di versione 1.32.X alla versione 1.32.Y, a condizione che Y sia maggiore di X. Ad esempio, puoi eseguire l'upgrade da
1.31.0 a 1.31.100 e da
1.31.100 a 1.31.300. Ti consigliamo di eseguire l'upgrade
all'ultima versione 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 patch. ovvero 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 versione secondaria
successiva disponibile. Le versioni patch X e
Y non influiscono sulla logica di upgrade in questo caso. Ad esempio, puoi eseguire l'upgrade da 1.31.600-gke.85 a 1.32.100-gke.106.
Non puoi saltare le versioni secondarie durante l'upgrade dei cluster. Se provi a eseguire l'upgrade
a una versione secondaria che è due o più versioni secondarie superiore alla versione corrente
del cluster, bmctl genera un errore. Ad esempio, non puoi eseguire l'upgrade di un cluster
versione 1.30.0 alla versione 1.32.0 in un
unico passaggio.
Come descritto in precedenza, un cluster di amministrazione può gestire cluster utente con la stessa versione o una versione precedente. La differenza tra le versioni dei cluster utente e del cluster di gestione (a volte indicata come distorsione 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 differenza di versione del cluster per la versione di upgrade di destinazione.
Regole di controllo delle versioni del node pool
Quando esegui l'upgrade dei node pool in modo selettivo, si applicano le seguenti regole di versione:
1.30 e versioni successive
La versione del cluster deve essere maggiore o uguale alla versione del pool di nodi worker.
La differenza massima tra le versioni di un pool di nodi worker e del cluster è di due versioni secondarie.
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) La differenza massima tra la versione di un pool di nodi worker e quella del cluster è di due versioni secondarie.
I pool di nodi worker non possono avere una versione rilasciata cronologicamente successiva a quella del cluster. La release precedente non contiene i dettagli completi della release successiva, 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 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 maggiore o uguale alla versione del pool di nodi worker.
(1.28 Anteprima) La differenza massima tra le versioni di un pool di nodi worker e del cluster è di due versioni secondarie quando è abilitata la funzionalità n-2 di differenza tra le versioni Anteprima. Se non attivi questa funzionalità, la differenza massima tra le versioni di un pool di nodi worker e del cluster è di una versione secondaria.
I pool di nodi worker non possono avere una versione rilasciata cronologicamente successiva a quella del cluster. La release precedente non contiene i dettagli completi della release successiva, 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 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 maggiore o uguale alla versione del pool di nodi worker.
La differenza massima tra la versione di un pool di nodi worker e quella del cluster è di una versione secondaria.
I pool di nodi worker non possono avere una versione rilasciata cronologicamente successiva a quella del cluster. La release precedente non contiene i dettagli completi della release successiva, 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 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 tabella seguente elenca le versioni del pool di nodi supportate consentite per una versione specifica del cluster:
1.30 e versioni successive
Per i cluster versione 1.30 e successive, le versioni pool di nodi possono essere inferiori fino a due versioni secondarie. Sono compatibili tutte le versioni patch del pool di nodi all'interno delle versioni secondarie compatibili.
1,29
| Versione del cluster (piano di controllo) | Versioni del pool di nodi worker supportate (le versioni aggiunte sono in grassetto) | |||
|---|---|---|---|---|
| 1.29.1200-gke.98 |
|
|
|
|
| 1.29.1100-gke.84 |
|
|
|
|
| 1.29.1000-gke.93 |
|
|
|
|
| 1.29.900-gke.180 |
|
|
|
|
| 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 (le versioni aggiunte sono in grassetto) | |||
|---|---|---|---|---|
| 1.28.1400-gke.79 |
|
|
|
|
| 1.28.1300-gke.59 |
|
|
|
|
| 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 (le versioni aggiunte sono 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 |
|
|
||
Eseguire l'upgrade dei componenti
I componenti vengono aggiornati sia a livello di nodo che di cluster. A livello di cluster, vengono aggiornati i seguenti componenti:
- Componenti del cluster per networking, osservabilità e spazio di archiviazione.
- Per i cluster di amministrazione, ibridi e autonomi, i controller del ciclo di vita.
- Il
gke-connect-agent.
I nodi di un cluster vengono eseguiti con uno dei seguenti ruoli, con diversi componenti aggiornati a seconda del ruolo del nodo:
| Ruolo del nodo | Funzione | Componenti da aggiornare |
|---|---|---|
| Worker | Esegue i carichi di lavoro degli utenti | Kubelet, runtime 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 control plane di Kubernetes (kubeapi-server,
kube-scheduler, kube-controller-manager, etcd)
Controller del ciclo di vita come lifecycle-controllers-manager e
anthos-cluster-operatorComponenti aggiuntivi della piattaforma Google Kubernetes Engine (GKE) Enterprise edition come stackdriver-log-aggregator e
gke-connect-agent |
| Bilanciatore del carico del control plane | Esegue HAProxy e Keepalived che gestiscono il traffico verso
kube-apiserver ed esegue speaker MetalLB per rivendicare indirizzi IP virtuali |
Pod statici del bilanciatore del carico del control plane (HAProxy, Keepalived)
Speaker MetalLB |
Aspettativa di tempo di inattività
La seguente tabella descrive in dettaglio i tempi di inattività previsti e il potenziale impatto quando esegui l'upgrade dei cluster. Questa tabella presuppone che tu disponga di più nodi cluster e di un piano di controllo HA. Se esegui un cluster autonomo o non disponi di un control plane HA, prevedi tempi di inattività aggiuntivi. Se non diversamente indicato, questo tempo di inattività si applica sia agli upgrade del cluster di amministrazione sia a quelli del cluster utente:
| Componenti | Aspettative per i tempi di inattività | Quando si verifica il tempo di riposo |
|---|---|---|
Server API del control plane Kubernetes (kube-apiserver),
etcd e scheduler |
Zero tempi di inattività | N/D |
Controller 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à temporaneo (meno di 1-2 minuti) quando il bilanciatore del carico reindirizza il traffico. | Inizio della procedura di upgrade. |
Osservabilità pipeline-stackdriver e
metrics-server |
Operatore svuotato e aggiornato. Il tempo di inattività deve essere inferiore a 5 minuti.
I DaemonSet continuano a funzionare senza tempi di inattività. |
Al termine dell'upgrade dei nodi del control plane. |
| Interfaccia di rete del container (CNI) | Nessun downtime per le route di rete esistenti. DaemonSet di cui è stato eseguito il deployment due alla volta senza tempi di inattività. L'operatore viene svuotato e potenziato. Tempo di inattività inferiore a 5 minuti. |
Al termine dell'upgrade dei nodi del control plane. |
| MetalLB (solo cluster utente) | Operatore svuotato e aggiornato. Il tempo di inattività è inferiore a 5 minuti.
Nessun tempo di inattività per il servizio esistente |
Al termine dell'upgrade dei nodi del control plane. |
| CoreDNS e gestore della scalabilità automatica DNS (solo cluster utente) | CoreDNS ha più repliche con scalabilità automatica. Solitamente nessun tempo di inattività. | Al termine dell'upgrade dei nodi del control plane. |
| Provisioner del volume locale | Nessun tempo di inattività per i volumi permanenti (PV) di cui è stato eseguito il provisioning esistenti.
L'operatore potrebbe avere 5 minuti di inattività. |
Al termine dell'upgrade dei nodi del control plane. |
| Istio / ingress | L'operatore Istio viene svuotato e sottoposto a upgrade. Circa 5 minuti di
inattività. L'ingresso configurato esistente continua a funzionare. |
Al termine dell'upgrade dei nodi del control plane. |
| Altri operatori di sistema | 5 minuti di inattività quando è scarico e viene aggiornato. | Al termine dell'upgrade dei nodi del control plane. |
| Workload utente | Dipende dalla configurazione, ad esempio se è ad alta disponibilità. Esamina le tue 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 in dettaglio le deviazioni da questo flusso per gli upgrade dei cluster amministratore, ibridi o autonomi.
Il seguente diagramma mostra la procedura di controllo preflight per un upgrade del cluster utente:
Il diagramma precedente descrive in dettaglio i passaggi che vengono eseguiti 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 segnalare la capacità del cluster di eseguire l'upgrade alla versione di destinazione.
Se i controlli preliminari vanno a buon fine e non ci sono problemi bloccanti, i componenti del cluster vengono aggiornati in un ordine specifico, come mostrato nel seguente diagramma:
Nel diagramma precedente, i componenti vengono aggiornati nel seguente ordine:
- L'upgrade inizia con l'aggiornamento del campo
spec.anthosBareMetalVersion. - È stato eseguito l'upgrade dei bilanciatori del carico del control plane.
- Il pool di nodi del control plane viene sottoposto all'upgrade.
- Parallelamente, viene eseguito l'upgrade di GKE Connect, dei componenti aggiuntivi del cluster e del
pool di nodil 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 controlli di integrità del cluster.
I controlli di integrità continuano a essere eseguiti finché non vengono superati tutti.
Quando tutti i controlli di integrità vengono superati, l'upgrade è terminato.
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 control plane. Il campo include le versioni dei nodi dei pool di nodi del control plane |
| 2 | status.anthosBareMetalLifecycleControllersManifestsVersion
|
Versione di lifecycles-controllers-manager applicata al
cluster. Questo campo è disponibile solo per i cluster amministrativi, autonomi o ibridi. |
| 2 | status.anthosBareMetalManifestsVersion |
Versione del cluster dell'ultimo manifest applicato. |
| 2 | status.controlPlaneLoadBalancerNodepoolStatus |
Lo stato viene copiato dallo stato del pool di nodi del bilanciatore del carico del control plane. 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 delle versioni dei numeri di versione e dei nodi. |
| 4 | status.anthosBareMetalVersion |
Stato finale della versione di cui è stato eseguito l'upgrade. |
Dettagli dell'upgrade del cluster di amministrazione, ibrido e autonomo
A partire dalla versione 1.15.0 di bmctl, il comportamento di upgrade predefinito per i cluster autogestiti (di amministrazione, ibridi o autonomi) è un upgrade in loco.
Ciò significa che quando esegui l'upgrade di un cluster alla versione 1.15.0 o successive, 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
delle risorse, il che rende gli upgrade del 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 loco predefinita per i cluster autogestiti è simile a quella per l'upgrade del cluster utente. Tuttavia, quando utilizzi la procedura di upgrade in loco, viene eseguito il deployment 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, il processo di upgrade inizia aggiornando il campo Cluster.spec.anthosBareMetalVersion alla versione di destinazione. Prima dell'aggiornamento dei componenti vengono eseguiti due
passaggi aggiuntivi, come mostrato nel seguente
diagramma: lifecycle-controller-manager esegue l'upgrade alla versione
di destinazione, quindi 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 di destinazione da
spec.anthosBareMetalVersion a status.anthosBareMetalVersion.
Esegui l'upgrade con un cluster di bootstrap
La procedura di upgrade di un cluster di amministrazione, ibrido o autonomo è simile a quella di un cluster utente descritta 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.
La procedura per trasferire la proprietà di gestione del cluster al cluster di bootstrap è chiamata pivot. Il resto dell'upgrade segue lo stesso processo dell'upgrade del cluster utente.
Durante il processo di upgrade, le risorse nel cluster di destinazione rimangono obsolete. L'avanzamento dell'upgrade viene visualizzato solo nelle risorse del cluster bootstrap.
Se necessario, puoi accedere al cluster di bootstrap per monitorare ed 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 sposta le risorse dal cluster di bootstrap al cluster aggiornato. Non sono previsti passaggi manuali per eseguire il pivot del cluster durante il processo di upgrade. Il cluster di bootstrap viene eliminato dopo l'aggiornamento del cluster.
Svuotamento dei nodi
Gli upgrade dei cluster Google Distributed Cloud potrebbero causare interruzioni dell'applicazione durante lo svuotamento dei nodi. Questo processo di svuotamento causa l'arresto e il riavvio di tutti i pod in esecuzione su un nodo sui nodi rimanenti del cluster.
I deployment possono essere utilizzati per tollerare queste interruzioni. Un deployment può specificare più repliche di un'applicazione o di un servizio da eseguire. 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 versione 1.29, i nodi vengono svuotati con l'API Eviction, che
rispetta i PodDisruptionBudgets (PDB). I PDB possono essere utilizzati per garantire che un numero definito di repliche sia sempre in esecuzione nel cluster in condizioni di funzionamento normali.
I PDB ti consentono di limitare l'interruzione di un carico di lavoro quando i relativi pod devono essere
ripianificati. Lo svuotamento dei nodi basato sull'espulsione è disponibile come GA per la release 1.29.
Nelle versioni 1.28 e precedenti, Google Distributed Cloud non rispetta i PDB quando i nodi
vengono svuotati durante un upgrade. Il processo di svuotamento dei nodi viene eseguito al meglio delle possibilità. Alcuni
pod potrebbero bloccarsi nello stato Terminating e rifiutarsi di lasciare il nodo. L'upgrade procede, anche con i pod bloccati, quando il processo di svuotamento di un nodo richiede più di 20 minuti.
Per saperne di più, consulta Attivazione della modalità di manutenzione dei nodi.
Passaggi successivi
- Consulta le best practice per gli upgrade di Google Distributed Cloud
- Esegui l'upgrade di Google Distributed Cloud
- Risolvere i problemi di upgrade del cluster