Puoi gestire l'ordine degli upgrade automatici dei cluster Google Kubernetes Engine (GKE) in più ambienti utilizzando la sequenza di implementazione. Ad esempio, puoi qualificare una nuova versione nei cluster di pre-produzione prima di eseguire l'upgrade dei cluster di produzione. Per utilizzare questa funzionalità, devi conoscere gli upgrade dei cluster, i canali di release e la gestione del parco risorse.
Per iniziare, consulta Eseguire la sequenza dell'implementazione degli upgrade dei cluster.
Terminologia
In questo documento il termine gruppo si riferisce sia agli scopi dei fleet sia a quelli dei team, perché puoi creare una sequenza di implementazione organizzata con entrambi i metodi di raggruppamento.
Verificare la qualità degli upgrade in più ambienti
Per eseguire l'upgrade automatico dei cluster con la sequenza di implementazione, utilizza parchi risorse o ambiti di team in cui hai raggruppato i cluster con lo stesso canale di rilascio e la stessa versione minore nelle fasi di implementazione. Scegli la sequenza di parchi risorse o la sequenza di ambiti di team e imposta il tempo di test di satura che vuoi tra ogni gruppo di cluster. Poi, quando GKE seleziona una nuova versione per gli upgrade automatici nel canale di rilascio, viene eseguito l'upgrade dei gruppi di cluster nella sequenza che hai definito e puoi verificare che i workload funzionino come previsto con una nuova versione prima dell'inizio degli upgrade dei cluster di produzione.
Sequenza di implementazione basata sul parco risorse
Il seguente diagramma illustra come GKE esegue automaticamente gli upgrade dei cluster in una sequenza di implementazione organizzata in base ai parchi risorse:
Con una sequenza basata su parchi risorse, quando GKE rende disponibile un nuovo target di upgrade nel canale di rilascio in cui sono registrati tutti i cluster di questa sequenza, esegue l'upgrade di questi parchi risorse di cluster, con i cluster del parco risorse upstream che qualificano la nuova versione per i cluster del parco risorse downstream, per un massimo di cinque parchi risorse. In una sequenza di implementazione, il termine upstream fa riferimento al gruppo precedente e downstream al gruppo successivo.
Durante il tempo di sospensione configurato tra i parchi risorse, dopo il completamento degli upgrade nel parco risorse upstream e prima che inizino nel parco risorse downstream, puoi verificare che i workload vengano eseguiti come previsto sui cluster di cui è stato eseguito l'upgrade.
Sequenza di implementazione basata sul team
Se hai suddiviso ulteriormente i cluster in un parco risorse per team o applicazione, puoi creare una sequenza di implementazione tra gli ambiti del team. Gli ambiti del team sono un costrutto a livello di parco risorse aziendale per associare sottoinsiemi di cluster del parco risorse a team di applicazioni specifici e possono essere utilizzati per attivare una serie di funzionalità basate sul team, tra cui il controllo dell'accesso e l'osservabilità basata sul team, nonché la sequenziazione dell'implementazione.
Con gli ambiti del team, puoi creare più sequenze di implementazione in un parco risorse, ciascuna con i propri canali di rilascio, target di upgrade e tempi di attesa indipendenti. Una sequenza di implementazione basata sul team funziona in modo identico a una sequenza di implementazione basata sul parco risorse, tranne per il fatto che gli upgrade sono qualificati tra i cluster di un team specifico in ogni parco risorse, anziché da un parco risorse all'altro. Questo è particolarmente utile per gli operatori delle applicazioni che vogliono gestire gli upgrade all'interno dei cluster del proprio team.
La sequenziazione dell'implementazione basata su team è in anteprima, mentre la sequenziazione dell'implementazione basata sul parco è in disponibilità generale (GA).
In che modo GKE esegue l'upgrade dei cluster in una sequenza di implementazione
Quando GKE esegue l'upgrade di un cluster, viene eseguito prima l'upgrade del piano di controllo, poi dei nodi. In una sequenza di implementazione, l'upgrade dei cluster viene comunque eseguito utilizzando questa procedura, ma puoi anche controllare l'ordine in cui viene eseguito l'upgrade dei gruppi (parchi risorse o ambiti) di cluster e specificare un tempo di attesa per scegliere per quanto tempo GKE deve essere in pausa prima di passare dall'upgrade di un gruppo all'altro.
Gli upgrade dei cluster in una sequenza di implementazione procedono con i seguenti passaggi:
- GKE imposta un nuovo target di upgrade automatico per i cluster su una versione secondaria in un canale di rilascio specifico, con la nota di rilascio che menziona qualcosa di simile al seguente messaggio: "Con questa release verrà eseguito l'upgrade dei control plane e dei nodi con l'upgrade automatico abilitato nel canale regolare dalla versione 1.21 alla versione 1.22.15-gke.1000".
- GKE inizia l'upgrade dei piani di controllo dei cluster alla nuova versione nel primo gruppo di cluster. Dopo che GKE ha eseguito l'upgrade del piano di controllo di un cluster, inizia l'upgrade dei nodi del cluster. GKE rispetta la disponibilità per la manutenzione durante l'upgrade dei cluster in una sequenza di implementazione.
- GKE esegue i seguenti passaggi successivi per gli upgrade del piano di controllo:
- GKE inizia il periodo di attesa per gli upgrade del piano di controllo dopo il completamento di tutti gli upgrade del piano di controllo del cluster nel primo gruppo o se sono trascorsi 30 giorni dall'inizio degli upgrade del piano di controllo.
- Al termine del periodo di attesa per gli upgrade del piano di controllo del cluster nel primo gruppo, GKE avvia gli upgrade del piano di controllo nel secondo gruppo.
- Parallelamente agli upgrade del piano di controllo, GKE esegue i seguenti passaggi successivi per gli upgrade dei nodi:
- GKE inizia il periodo di attesa per gli upgrade dei nodi dopo il completamento di tutti gli upgrade dei nodi del cluster nel primo gruppo o dopo 30 giorni dall'inizio degli upgrade dei nodi.
- GKE inizia gli upgrade dei nodi nel secondo gruppo per i cluster di cui è già stato eseguito l'upgrade del piano di controllo al termine del periodo di attesa per gli upgrade dei nodi nel primo gruppo.
- GKE ripete questi passaggi dal secondo gruppo al terzo finché non è stato eseguito l'upgrade dei cluster di tutti i gruppi nella sequenza di implementazione al nuovo target dell'upgrade.
Durante l'upgrade dei cluster in ogni gruppo, verifica che i workload vengano eseguiti come previsto con i cluster che eseguono la nuova versione di GKE.
L'upgrade dei cluster potrebbe anche essere impedito a causa di finestre di manutenzione o esclusioni, utilizzo di API ritirate o altri motivi. Per scoprire di più, consulta Come funziona la sequenziazione dell'implementazione con altre funzionalità di upgrade.
Come controllare gli upgrade in una sequenza di implementazione
Con gli upgrade dei cluster in una sequenza di implementazione, i gruppi di cluster vengono sottoposti ad upgrade nell'ordine che hai definito e vengono sottoposti a stress test in ogni gruppo per il periodo di tempo che hai scelto. Durante l'esecuzione degli upgrade, puoi controllare lo stato di una sequenza di implementazione e gestire la sequenza di implementazione in base alle esigenze. Puoi anche controllare il processo nei seguenti modi:
- Per un gruppo in una sequenza di implementazione, puoi sostituire il tempo di attesa predefinito se hai bisogno di più o meno tempo di attesa per una versione specifica.
- Per gli upgrade dei singoli cluster, puoi continuare a utilizzare i seguenti strumenti:
- Controllare manualmente gli upgrade adottando azioni come annullamento, ripristino, ripristino dei dati precedenti o completamento degli upgrade dei pool di nodi.
- Utilizza periodi di manutenzione ed esclusioni per decidere quando è possibile eseguire l'upgrade di un cluster e quando no.
- Configura le strategie di upgrade dei nodi per trovare il giusto equilibrio tra velocità e tolleranza al rischio, a seconda dei carichi di lavoro in esecuzione su questi nodi.
Per scoprire di più, consulta come funziona la sequenza di implementazione con altre funzionalità di upgrade.
Esempio: una banca di quartiere implementa gradualmente le modifiche dal test alla produzione
Ad esempio, l'amministratore della piattaforma di una banca di quartiere gestisce tre ambienti di implementazione principali, ciascuno un gruppo di cluster organizzati in un parco risorse: test, gestione temporanea e produzione. Come richiesto per il sequenziamento dell'implementazione, l'amministratore ha registrato ogni cluster in tutti e tre i parchi risorse nello stesso canale di rilascio, in questo caso il canale regolare, con tutti i cluster che eseguono la stessa versione secondaria.
L'amministratore utilizza la sequenza di implementazione per definire l'ordine in cui GKE esegue l'upgrade dei cluster in questi ambienti. L'ordinamento dell'implementazione consente all'amministratore di verificare che i workload vengano eseguiti come previsto con i cluster su una nuova versione di GKE prima di eseguire l'upgrade dell'ambiente di produzione alla nuova versione. Questa sequenza è illustrata dal diagramma della sequenza di implementazione basata su parchi risorse.
L'amministratore utilizza il tempo di sospensione tra l'upgrade di questi parchi per verificare che i relativi carichi di lavoro vengano eseguiti come previsto con i cluster della nuova versione di GKE. Per il parco macchine di test, l'amministratore imposta il tempo di attesa su 14 giorni in modo da avere due settimane intere per testare l'esecuzione dei carichi di lavoro. Per l'implementazione, impostano il tempo di attesa su 7 giorni perché non hanno bisogno di molto tempo aggiuntivo dopo che i carichi di lavoro sono già stati eseguiti in Test.
L'amministratore può anche sostituire il tempo di attesa predefinito per gli upgrade a versioni specifiche, cosa che potrebbe voler fare in una delle seguenti situazioni:
- L'amministratore completa la convalida della versione prima del termine del tempo di soak e vuole che gli upgrade procedano al parco risorse successivo, quindi imposta il tempo di soak su zero.
- L'amministratore ha bisogno di più tempo per convalidare la nuova versione prima che gli upgrade procedano al parco risorse successivo, poiché ha notato un problema con alcuni dei suoi carichi di lavoro, quindi imposta il tempo di attesa massimo su 30 giorni.
L'amministratore utilizza i periodi di manutenzione ed esclusioni per assicurarsi che gli upgrade dei cluster GKE vengano eseguiti quando l'impatto sulla banca è minimo. GKE rispetta la disponibilità per la manutenzione dei cluster di cui è stato eseguito l'upgrade in una sequenza di implementazione.
- L'amministratore ha configurato finestre di manutenzione per i propri cluster per assicurarsi che GKE eseguisse l'upgrade dei cluster solo dopo l'orario di apertura.
- L'amministratore utilizza inoltre le esclusioni di manutenzione per impedire temporaneamente l'upgrade dei cluster se vengono rilevati problemi con i relativi carichi di lavoro.
L'amministratore utilizza una combinazione di upgrade di picco e blue-green per i propri nodi, trovando il giusto equilibrio tra velocità e tolleranza al rischio in base ai carichi di lavoro in esecuzione su questi nodi.
L'amministratore passa alle sequenze di implementazione basate sul team
Se l'amministratore decide di raggruppare ulteriormente i cluster all'interno di un fleet per applicazione e di concedere agli amministratori del team delle applicazioni un maggiore controllo sugli upgrade dei cluster, può utilizzare gli ambiti di gruppo. Con gli ambiti di team, gli amministratori dei team di applicazioni possono creare sequenze di implementazione indipendenti con i gruppi di cluster assegnati ai loro team, potenzialmente in esecuzione su diversi canali di rilascio o con tempi di attesa diversi.
Ad esempio, se il team del database vuole che i propri cluster utilizzino il canale Stabile e tempi di attesa più lunghi, mentre i cluster del team del sito web frontend utilizzano il canale Rapido e tempi di attesa più brevi, può utilizzare gli ambiti del team per creare sequenze di implementazione separate. Questo tipo di sequenza è illustrato dal diagramma della sequenza di implementazione basata su team. Per farlo nel tuo ambiente, segui le istruzioni per passare da una sequenza di implementazione basata sul parco risorse a una basata sul team e viceversa.
Tieni presente che l'utilizzo di questa funzionalità richiede cluster single-tenancy: in altre parole, ogni singolo cluster è associato a un solo team. I cluster condivisi (supportati nella gestione del team del parco risorse in generale) non sono supportati per il sequenziamento dell'implementazione. Per scoprire di più sulla gestione dei cluster per i team, consulta Gestione del team del parco risorse.
Idoneità all'implementazione
Affinché gli upgrade dei cluster vengano eseguiti automaticamente con la sequenza di implementazione, tutti i cluster in tutti i gruppi (parchi risorse o ambiti) di una sequenza di implementazione devono ricevere lo stesso target di upgrade. I cluster devono essere registrati nello stesso canale di rilascio e consigliamo di eseguire la stessa versione secondaria, in quanto i target di upgrade sono impostati per versione secondaria. Tuttavia, per alcune release, come quella nell'esempio seguente, i cluster di più versioni secondarie hanno ricevuto lo stesso target, il che significa che è stato possibile eseguire l'upgrade dei cluster nella sequenza di implementazione con più versioni secondarie.
Puoi controllare lo stato dell'implementazione della versione in una sequenza per avere ulteriori informazioni sullo stato e se i problemi di idoneità della versione impediscono il proseguimento degli upgrade. A seconda delle discrepanze tra le versioni, potrebbe essere necessario eseguire azioni come l'upgrade manuale di un cluster o la sua rimozione da un gruppo per poter procedere con gli upgrade dei cluster. Se un cluster in una sequenza di implementazione non ha un target di upgrade idoneo, GKE non eseguirà l'upgrade automatico del cluster finché la versione secondaria esistente del cluster non raggiunge la fine del ciclo di vita.
Per risolvere i problemi di idoneità al rollout, consulta la sezione Risolvere i problemi di idoneità al rollout.
Release GKE di esempio
Ad esempio, la release 2022-R25 ha impostato un target di upgrade per più versioni secondarie nei cluster registrati nel canale normale. Un target di upgrade può essere una nuova versione secondaria (da 1.20 a 1.21) o semplicemente una nuova versione della patch (da 1.21.x-gke.x a 1.21.14-gke.4300). In questa release, nel canale Regolare, sono state rese disponibili le seguenti nuove versioni per i cluster su versioni minori specifiche:
- È stato eseguito l'upgrade dei cluster su 1.20 e 1.21 alla versione 1.21.14-gke.4300.
- È stato eseguito l'upgrade dei cluster su 1.22 alla versione 1.23.8-gke.1900.
- È stato eseguito l'upgrade dei cluster su 1.24 alla versione 1.24.5-gke.600.
Il gruppo più a monte riceve tutti i target di upgrade
Per i cluster del primo gruppo di una sequenza, che non ha un gruppo upstream per qualificare le nuove versioni, GKE esegue l'upgrade di tutti i cluster con target di upgrade idonei, indipendentemente dal fatto che questi target di upgrade siano diversi tra loro. Ad esempio, nel primo gruppo di una sequenza, se alcuni cluster erano in esecuzione su 1.20, è possibile eseguire l'upgrade a 1.21.14-gke.4300 e ai cluster in esecuzione su 1.24 è possibile eseguire l'upgrade a 1.24.5-gke.600. Questo perché, per il primo gruppo di una sequenza, GKE considera idonei tutti i target di upgrade per questi cluster in quanto non esiste un gruppo upstream per qualificare una nuova versione.
Un gruppo upstream deve qualificare una sola versione
In qualsiasi gruppo downstream, la possibilità per GKE di eseguire l'upgrade dei cluster dipende dal fatto che il gruppo upstream abbia definito un target di upgrade per cui tutti i cluster di questo gruppo sono idonei. In genere, ciò significa che tutti i cluster vengono avviati con la stessa versione secondaria. Tuttavia, dalla release di esempio, i cluster su 1.20 e 1.21 avevano lo stesso target di upgrade, quindi i cluster che eseguivano entrambe le versioni potevano, nello stesso gruppo, soddisfare i requisiti di idoneità per l'upgrade a 1.21.14-gke.4300.
Se tutti i cluster di un gruppo non hanno lo stesso target di upgrade, questo gruppo non può soddisfare i requisiti di un target di upgrade per il gruppo successivo. In questa situazione, GKE non può eseguire automaticamente l'upgrade dei cluster nei gruppi a valle. Ad esempio, se nel primo gruppo è stato eseguito l'upgrade di alcuni cluster a 1.21.14-gke.4300 e di altri a 1.23.8-gke.1900, non è possibile eseguire l'upgrade automatico dei cluster del secondo gruppo perché il gruppo non ha ricevuto una versione qualificata. Per procedere con gli upgrade in questa situazione, consulta Correggere l'idoneità in un gruppo.
Un gruppo upstream deve qualificare una versione corrispondente ai cluster del gruppo successivo
Se i cluster di un gruppo upstream hanno qualificato una versione diversa da quella per la quale erano idonei i cluster del gruppo successivo, GKE non può nemmeno eseguire l'upgrade automatico dei cluster in nessun gruppo downstream.
Ad esempio, se è stato eseguito l'upgrade a 1.21.14-gke.4300 su tutti i cluster del primo gruppo, ma i cluster del secondo gruppo eseguono 1.22 (dove il target di upgrade è 1.23.8-gke.1900), non verrà eseguito automaticamente l'upgrade dei cluster del secondo gruppo. Il primo gruppo ha ottenuto la qualificazione per la versione 1.21.14-gke.4300, ma i cluster del secondo gruppo (attualmente in 1.22) sono idonei solo per la versione di destinazione dell'upgrade 1.23.8-gke.1900, pertanto GKE non può eseguire automaticamente l'upgrade di questi cluster. Per eseguire gli upgrade in questa situazione, consulta Correggere l'idoneità tra i gruppi.
Come funziona la sequenza di implementazione con altre funzionalità di upgrade
La sequenziazione dell'implementazione è una funzionalità di una raccolta di funzionalità che ti consente di controllare l'aspetto dell'upgrade del ciclo di vita del cluster. Questa sezione spiega come funziona questa funzionalità con alcune delle altre funzionalità disponibili relative agli upgrade dei cluster.
Come funziona la sequenziazione dell'implementazione con periodi di manutenzione ed esclusioni
GKE rispetta i periodi di manutenzione e le esclusioni dalla manutenzione durante l'upgrade dei cluster con la sequenza di implementazione. GKE avvia un upgrade del cluster solo durante il periodo di manutenzione del cluster. Puoi utilizzare un'esclusione per la manutenzione per impedire temporaneamente l'upgrade di un cluster. Se GKE non può eseguire l'upgrade di un cluster a causa di un periodo di manutenzione o di un'esclusione, ciò può impedire il completamento degli upgrade dei cluster in un gruppo. Se un upgrade del cluster non può essere completato entro 30 giorni a causa di finestre di manutenzione o esclusioni, il gruppo entrerà nella fase di assorbimento indipendentemente dal fatto che l'upgrade di tutti i cluster sia stato completato.
Puoi utilizzare le esclusioni per la manutenzione come misura temporanea per impedire a una sequenza di completare l'implementazione in un gruppo e passare al gruppo successivo. Per scoprire di più, consulta Ritardare il completamento dell'implementazione della versione del gruppo.
Come funziona la sequenza di implementazione con il rilevamento dell'utilizzo del ritiro
GKE mette in pausa gli upgrade dei cluster quando rileva l'utilizzo di determinate API e funzionalità ritirate. Gli upgrade automatici vengono messi in pausa anche per i cluster di un gruppo in una sequenza di implementazione. Per scoprire di più, consulta Come funzionano le ritirazioni di Kubernetes con GKE.
Come funziona la sequenza di implementazione con le strategie di upgrade dei nodi
Gli upgrade dei nodi utilizzeranno la strategia di upgrade dei nodi configurata quando viene eseguito l'upgrade in una sequenza di implementazione. Come per gli upgrade dei cluster senza sequenza di implementazione, GKE utilizza gli upgrade di picco per i nodi Autopilot. Per ulteriori informazioni, consulta Upgrade automatici dei nodi.
Se gli upgrade dei nodi non possono essere completati entro 30 giorni, il gruppo entrerà nella fase di assorbimento indipendentemente dal fatto che l'upgrade di tutti i cluster sia stato completato. Ciò può accadere se la strategia di upgrade dei nodi fa sì che l'upgrade dei nodi di un cluster standard richieda più tempo per essere completato, in particolare se si tratta di un pool di nodi di grandi dimensioni. Inoltre, può essere aggravato da finestre di manutenzione non sufficientemente lunghe per completare un upgrade del nodo. Per scoprire di più, consulta Aspetti da considerare quando si configura un periodo di manutenzione.
Come funziona la sequenza di implementazione con i canali di rilascio
I canali di rilascio sono obbligatori per utilizzare la sequenza di implementazione. Tutti i cluster di tutti i gruppi in una sequenza di implementazione devono trovarsi nello stesso canale di rilascio.
Ricevere più upgrade in una sequenza
Se una nuova versione diventa un target di upgrade nel canale di release mentre gli upgrade dei cluster a un target di upgrade precedente sono ancora in corso nella sequenza di implementazione, un gruppo upstream può iniziare l'implementazione di una nuova versione mentre un gruppo downstream sta ancora ricevendo l'upgrade precedente. Ad esempio, se il terzo gruppo di una sequenza implementa la versione 1.24.2-gke.100, il primo gruppo della sequenza può implementare contemporaneamente la versione 1.24.3-gke.500.
Considerazioni per la scelta della sequenza di implementazione
Valuta la possibilità di utilizzare la sequenza di implementazione se vuoi gestire gli upgrade dei cluster qualificando le nuove versioni in un ambiente prima di implementarle in un altro.
Tuttavia, questa potrebbe non essere la scelta giusta per il tuo ambiente se una delle seguenti affermazioni è vera:
- I cluster non sono nello stesso canale di rilascio o nella stessa versione secondaria nello stesso ambiente di produzione.
- Devi automatizzare gli upgrade che non possono essere mappati a soli cinque passaggi di deployment, poiché puoi creare una sequenza di implementazione con un massimo di cinque gruppi di cluster. Non puoi collegare gruppi in più sequenze di implementazione per creare una sequenza di implementazione con più di cinque gruppi. Le sequenze basate su parchi risorse possono includere fino a cinque parchi risorse, mentre le sequenze basate su team possono includere fino a tre ambiti di team.
- Non puoi utilizzare la gestione delle flotte.
- Esegui spesso upgrade manuali che causano versioni di destinazione dell'upgrade automatico diverse per i cluster di un gruppo.
Per creare sequenze di implementazione basate su team, devi anche essere in grado di abilitare GKE Enterprise nei progetti ospitanti del parco risorse.
Limitazioni
Per eseguire correttamente l'upgrade dei cluster con sequenza di implementazione, devi rispettare le seguenti limitazioni:
- Se utilizzi la sequenza di implementazione basata sui team, registra un cluster in un solo ambito di team. Se un cluster è registrato in più ambiti di gruppo, GKE non può eseguire automaticamente l'upgrade del cluster in una sequenza di implementazione basata sul team.
- La creazione di una sequenza di implementazione basata su team con più ambiti del team all'interno della stessa flotta non è supportata.
- Crea una sequenza di implementazione lineare senza cicli (un gruppo ha un gruppo downstream come gruppo upstream) o rami (un gruppo ha più di un gruppo downstream).
- Crea sequenze di implementazione tra gli ambiti di un team o tra i parchi risorse. Non puoi creare sequenze miste con ambiti di parchi e team nella stessa sequenza.
- Assicurati che tutti i cluster in una sequenza di implementazione siano registrati nello stesso canale di rilascio ed eseguino la stessa versione secondaria.
Problemi noti
- Se un gruppo contiene cluster di località diverse, l'upgrade di un cluster potrebbe essere temporaneamente disponibile solo per alcuni dei cluster a causa dell'implementazione graduale della nuova versione. Questo problema si verifica più spesso nel primo gruppo di cluster e dovrebbe risolversi entro una settimana.
- Se in una sequenza di implementazione è presente un gruppo vuoto, l'impatto sulla qualifica della versione dipende dalle seguenti condizioni:
- Se il gruppo vuoto non ha un gruppo upstream, gli upgrade del cluster non procedono al gruppo downstream perché il gruppo vuoto non può qualificare le versioni.
- Se il gruppo vuoto ha un gruppo upstream, tutti gli upgrade dei cluster in attesa assumono lo stato
COMPLETEe vengono propagati al gruppo downstream.
- A causa del modo in cui GKE monitora gli upgrade delle patch e secondari, potresti vedere due upgrade dello stesso tipo e della stessa versione, ma con stati diversi quando controlli lo stato dell'ambito.