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
problemi, è utile sapere cosa succede quando esegui il comando bmctl upgrade
cluster. Questo documento descrive in dettaglio i componenti e le fasi di un cluster
upgrade.
Panoramica
Il processo di upgrade sposta il tuo cluster Google Distributed Cloud dall'attuale a una versione successiva.
Le informazioni sulla versione vengono archiviate nelle seguenti posizioni nell'ambito di risorsa personalizzata nel cluster di amministrazione:
status.anthosBareMetalVersion: definisce la versione corrente del cluster.spec.anthosBareMetalVersion: definisce la versione di destinazione e viene impostato quando viene avviata l'esecuzione del processo di upgrade.
Le riconciliazioni di un'operazione di upgrade riuscita
Da status.anthosBareMetalVersion a
spec.anthosBareMetalVersion in modo che vengano visualizzati entrambi
la versione di destinazione.
Disallineamento delle versioni del cluster
Il disallineamento delle versioni del cluster è la differenza nelle versioni (ibrido o amministratore) e i relativi cluster utente gestiti. Quando aggiungi o esegui l'upgrade per un cluster utente, vengono applicate le seguenti regole di versione:
1,30
Le seguenti regole si applicano ai cluster utente gestiti da un amministratore della versione 1.30 in un cluster o in un cluster ibrido:
Le versioni del cluster utente non possono essere successive a quelle del cluster di gestione (amministratore o ibrida).
(1.30 GA) I cluster utente possono essere fino a due versioni secondarie sotto e gestire la versione del cluster. Ad esempio, un cluster di amministrazione della versione 1.30 può gestire un cluster utente 1.28. Gestione del disallineamento delle versioni n-2 è in disponibilità generale per la gestione dei cluster alla versione 1.30.
(1.30 GA) Per un determinato cluster di gestione con versione 1.30, i cluster utente non è necessario avere la stessa versione secondaria l'una dell'altra. Ad esempio, un il cluster di amministrazione di versione 1.30 può gestire la versione 1.30, versione 1.29 e cluster utente della versione 1.28.
La funzionalità di gestione con multi-inclinazione offre una maggiore flessibilità di pianificazione gli upgrade della tua flotta. Ad esempio, non è necessario eseguire l'upgrade dalla versione 1.28 alla versione 1.29 prima di eseguire l'upgrade del tuo alla versione 1.30.
1,29
Le regole seguenti si applicano ai cluster utente gestiti da un amministratore della versione 1.29 in un cluster o in un cluster ibrido:
Le versioni del cluster utente non possono essere successive a quelle del cluster di gestione (ammin. o ibrida).
(1.29 Anteprima) I cluster utente possono essere fino a due versioni secondarie sotto la versione del cluster di gestione. Per 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 la gestione alla versione 1.29.
(1.29 Anteprima) Per un determinato gestore non è necessario che i cluster utente abbiano la stessa versione secondaria e l'altro. Ad esempio, un amministratore della versione 1.29 il cluster può gestire le versioni 1.29, 1.28 e 1.16 cluster. La gestione del disallineamento delle versioni mista è disponibile Funzionalità Anteprima per nella gestione dei cluster alla versione 1.29.
La gestione dell'inclinazione multipla in Anteprima offre una maggiore flessibilità per pianificare gli upgrade del parco dispositivi. Per Ad esempio, non è necessario eseguire l'upgrade di tutti i cluster utente della versione 1.16. alla versione 1.28 prima di eseguire l'upgrade del cluster di amministrazione alla versione 1,29.
1.28 e precedenti
Le regole seguenti si applicano ai cluster utente gestiti da una versione 1.28 o cluster di amministrazione o cluster ibrido precedente:
Le versioni del cluster utente non possono essere successive a quelle del cluster di gestione (ammin. o ibrida).
I cluster utente possono essere fino a una versione secondaria al di sotto del livello di gestione alla versione del cluster esistente. Ad esempio, un cluster di amministrazione della versione 1.28 non può gestire per un cluster utente alla versione 1.15.
Per un determinato cluster di gestione, tutti i cluster utente gestiti devono trovarsi la stessa versione secondaria.
Per informazioni sulle regole di disallineamento delle versioni per i pool di nodi, consulta Regole di controllo delle versioni del pool di nodi.
Regole per le versioni
Se scarichi e installi una nuova versione di bmctl, puoi eseguire l'upgrade del tuo
di amministrazione, ibridi, autonomi e utenti creati o sottoposti a upgrade con una versione
versione di bmctl. Non è possibile eseguire il downgrade dei cluster a una versione precedente.
Puoi eseguire l'upgrade di un cluster solo a una versione che corrisponde
versione di bmctl in uso. Vale a dire che se utilizzi la versione
1.30.0-gke.1930 di bmctl, puoi eseguire l'upgrade di un cluster alla versione
Solo 1.30.0-gke.1930.
Upgrade delle versioni delle patch
Per una determinata versione secondaria, puoi eseguire l'upgrade a qualsiasi versione di patch superiore. Vale a dire che
puoi eseguire l'upgrade di un 1.30.X
dal cluster alla versione
1.30.Y a lungo
Y è maggiore di
X. Ad esempio, puoi eseguire l'upgrade
Da 1.29.0 a 1.29.100 e puoi eseguire l'upgrade da
1.29.100 a 1.29.300. Ti consigliamo di eseguire l'upgrade
all'ultima versione della patch quando possibile per assicurarti che i cluster abbiano
correzioni di sicurezza più recenti.
Upgrade delle versioni minori
Puoi eseguire l'upgrade dei cluster da una versione secondaria all'altra, indipendentemente
versione patch. Vale a dire che 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 è il successivo
una versione secondaria. Le versioni patch, X e
Y, in questo caso non influiscono sulla logica di upgrade. Per
Ad esempio, puoi eseguire l'upgrade da 1.29.400-gke.86 a
1.30.0-gke.1930.
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 al cluster
dell'app, bmctl emette un errore. Ad esempio, non puoi eseguire l'upgrade di una versione
1.28.0 cluster alla versione 1.30.0.
Un cluster di amministrazione può gestire i cluster utente che si trovano sullo stesso elemento o su una precedente completamente gestita. I cluster utente gestiti non possono avere una versione secondaria inferiore di più di una versione del cluster di amministrazione, quindi 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 eseguire l'upgrade dei pool di nodi in modo selettivo, si applicano le seguenti regole di versione:
1,30
La versione del cluster deve essere maggiore o uguale al pool di nodi worker completamente gestita.
Il disallineamento massimo delle versioni tra un pool di nodi worker e il cluster è due versioni secondarie.
I pool di nodi worker possono trovarsi in qualsiasi versione di patch di un minore compatibile completamente gestita.
1,29
La versione del cluster deve essere maggiore o uguale al pool di nodi worker completamente gestita.
(1.29 GA) Disallineamento massimo delle versioni tra un pool di nodi worker e il è costituito da due versioni secondarie.
I pool di nodi worker non possono avere una versione rilasciata cronologicamente successiva alla versione del cluster. La release precedente non include dettagli completi per la release successiva, che è un requisito per la compatibilità.
Ad esempio, la versione 1.16.6 rilasciata dopo la versione È stato rilasciato il file 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 lasciano un nodo worker nella versione 1.16.6. Analogamente, se esegui l'upgrade del cluster versione 1.28.100-gke.146, ma ha scelto di lasciare un pool di nodi worker in 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 al pool di nodi worker completamente gestita.
(1.28 Anteprima) Versione massima il disallineamento tra un pool di nodi worker e il cluster è costituito da due versioni secondarie quando le versioni n-2 disallineano La funzionalità Anteprima è attivata. Se non abilitare questa funzionalità, il disallineamento massimo della versione tra di pool di nodi e il cluster è una versione secondaria.
I pool di nodi worker non possono avere una versione rilasciata cronologicamente successiva alla versione del cluster. La release precedente non include dettagli completi per la release successiva, che è un requisito per la compatibilità.
Ad esempio, la versione 1.16.6 rilasciata dopo la versione È stato rilasciato il file 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 lasciano un nodo worker nella versione 1.16.6. Analogamente, se esegui l'upgrade del cluster versione 1.28.100-gke.146, ma ha scelto di lasciare un pool di nodi worker in 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 al pool di nodi worker completamente gestita.
Il disallineamento massimo delle versioni tra un pool di nodi worker e il cluster è uno una versione secondaria.
I pool di nodi worker non possono avere una versione rilasciata cronologicamente successiva alla versione del cluster. La release precedente non include dettagli completi per la release successiva, che è un requisito per la compatibilità.
Ad esempio, la versione 1.16.6 rilasciata dopo la versione È stato rilasciato il file 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 lasciano un nodo worker nella versione 1.16.6. Analogamente, se esegui l'upgrade del cluster versione 1.28.100-gke.146, ma ha scelto di lasciare un pool di nodi worker in 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 specifica versione del cluster:
1,30
Per i pool di nodi con una versione secondaria compatibile, versione 1.29 o versione 1.28, tutte le versioni di patch sono compatibili con i cluster in qualsiasi versione di patch 1.30 versione minore.
1,29
| Versione del cluster (piano di controllo) | Versioni del pool di nodi worker supportate (versioni aggiunte in grassetto) | |||
|---|---|---|---|---|
| 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.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 |
|
|
||
Esegui l'upgrade dei componenti
L'upgrade dei componenti viene eseguito sia a livello di nodo che di cluster. Al 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 componenti diversi upgrade eseguito 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 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-operatorComponenti 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 KeepaLifetime che gestiscono il traffico
kube-apiserver ed esegui speaker MetalLB per richiedere una proprietà IP virtuale
addresses |
Pod statici del bilanciatore del carico del piano di controllo (HAProxy, KeepaLive)
Altoparlanti MetalLB |
Aspettative relative al tempo di riposo
La tabella seguente descrive in dettaglio il tempo di inattività previsto e l'impatto potenziale quando eseguire l'upgrade dei cluster. Questa tabella presuppone che tu abbia più nodi cluster e un'alta disponibilità dal piano di controllo. Se esegui un cluster autonomo o non hai un controllo ad alta disponibilità il piano tariffario, sono previsti tempi di inattività aggiuntivi. Se non indicato, il tempo di inattività si applica a entrambi upgrade dei cluster di amministrazione e degli utenti:
| 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/D |
Controller del ciclo di vita e job ansible-runner (amministratore
) |
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 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 no o un 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 riposo 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
o un tempo 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 di un cluster utente. La seguente sezione 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 diagramma precedente descrive i passaggi che vengono eseguiti durante un upgrade:
- Il comando
bmctl upgrade clustercrea un filePreflightCheckpersonalizzato risorsa. - Questo controllo preflight esegue controlli aggiuntivi, come i controlli di upgrade del cluster, di integrità di rete e di integrità dei nodi.
- I risultati di questi controlli aggiuntivi si combinano per indicare la capacità di del cluster per eseguire correttamente l'upgrade alla versione di destinazione.
Se i controlli preflight hanno esito positivo e non ci sono problemi di blocco, di componenti del cluster vengono aggiornati in un ordine specificato, come mostrato nell' diagramma seguente:
Nel diagramma precedente, l'upgrade dei componenti viene eseguito nel seguente modo:
- L'upgrade inizia aggiornando
spec.anthosBareMetalVersion. - Viene eseguito l'upgrade dei bilanciatori del carico del piano di controllo.
- È stato eseguito l'upgrade del pool di nodi del piano di controllo.
- In parallelo, viene eseguito l'upgrade di GKE Connect, dei componenti aggiuntivi dei cluster e
viene eseguito l'upgrade del pool di nodi
del bilanciatore del carico.
- Una volta eseguito l'upgrade del pool di nodi del bilanciatore del carico, il worker viene eseguito l'upgrade dei pool di nodi.
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.
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. Tu 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 a
in un cluster Kubernetes. Questo campo è disponibile solo per amministratori, utenti autonomi o ibridi
cluster. |
| 2 | status.anthosBareMetalManifestsVersion |
Versione del cluster dall'ultimo manifest applicato. |
| 2 | status.controlPlaneLoadBalancerNodepoolStatus |
Lo stato viene copiato dal pool di nodi del bilanciatore del carico del piano di controllo
. Questo campo è vuoto se non è presente alcun bilanciatore del carico del piano di controllo separato
specificato in Cluster.Spec. |
| 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 (amministratori, ibridi o autonomi) sono un upgrade in loco.
Questo significa che quando esegui l'upgrade di un cluster alla versione 1.15.0 o successiva,
utilizza controller del ciclo di vita, invece di un cluster di bootstrap, per gestire l'intero
processo di upgrade. Questa modifica semplifica il processo e riduce
rendendo più affidabili e scalabili gli upgrade dei cluster.
Anche se l'utilizzo di un cluster di bootstrap per l'upgrade non è consigliato, l'opzione
è ancora disponibile. Per utilizzare un cluster di bootstrap durante l'upgrade, esegui
Comando bmctl upgrade con il flag --use-bootstrap=true.
Le fasi dell'upgrade sono diverse a seconda del metodo scelto
per gli utilizzi odierni.
Upgrade in loco
Il processo di upgrade in loco predefinito per i cluster autogestiti è simile a
il processo di upgrade del cluster utente. Tuttavia, quando utilizzi l'upgrade in loco
viene eseguito il deployment di una nuova versione di preflightcheck-operator prima
vengono eseguiti controlli preflight e controlli di integrità del cluster:
Come per l'upgrade del cluster utente, il processo di upgrade inizia aggiornando
Cluster.spec.anthosBareMetalVersion alla versione di destinazione. Due.
ulteriori passaggi eseguiti prima di aggiornare i componenti, come illustrato di seguito
diagramma: lifecycle-controller-manager si aggiorna 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 del processo di upgrade:
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 di cui abbiamo parlato 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 bootstrap cluster è chiamato pivot. Il resto dell'upgrade segue la stessa procedura eseguire l'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 bootstrap in un cluster Kubernetes.
Se necessario, puoi accedere al cluster di bootstrap per monitorare ed eseguire il debug del
processo di upgrade. È possibile accedere al cluster di bootstrap
bmctl-workspace/.kindkubeconfig.
Per trasferire nuovamente la proprietà della gestione del cluster dopo l'upgrade, completato, il cluster esegue il pivot delle risorse dal cluster di bootstrap con upgrade eseguito. Non devi eseguire alcun passaggio manuale per eseguire il pivot del cluster durante il processo di upgrade. Il cluster di bootstrap viene eliminato dopo il cluster upgrade eseguito correttamente.
Svuotamento dei nodi
Gli upgrade dei cluster Google Distributed Cloud potrebbero causare interruzioni delle applicazioni i nodi vengono svuotati. Questo processo di svuotamento fa sì che tutti i pod in esecuzione su un nodo arresta e riavvia sui nodi rimanenti nel cluster.
I deployment possono essere utilizzati per tollerare queste interruzioni. Un deployment può specificare è necessario eseguire più repliche di un'applicazione o di un servizio. Un'applicazione con più repliche dovrebbero subire interruzioni minime o nulle durante gli upgrade.
PodDisruptionBudgets (PDB)
Quando esegui l'upgrade di un cluster, Google Distributed Cloud utilizza la modalità di manutenzione per lo svuotamento dei nodi.
A partire dalla release 1.29, i nodi vengono svuotati con l'API Eviction, che
onora PodDisruptionBudgets (PDB). I PDB possono essere usati per garantire che un
di repliche eseguite nel cluster in condizioni di esecuzione normali.
I PDB consentono di limitare l'interruzione di un carico di lavoro quando è necessario
riprogrammato. 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
lo svuotamento durante un upgrade. Il processo di svuotamento dei nodi rappresenta invece il miglior tentativo. Alcune
I pod potrebbero rimanere bloccati in uno stato Terminating e rifiutarsi di liberare il nodo. La
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 Eseguire la manutenzione dei nodi .
Passaggi successivi
- Esamina il best practice per gli upgrade di Google Distributed Cloud
- Esegui l'upgrade di Google Distributed Cloud
- Risolvere i problemi di upgrade del cluster