Puoi gestire l'ordine degli upgrade automatici dei cluster nei 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 avere familiarità con gli upgrade dei cluster, i canali di rilascio e la gestione del parco risorse.
Per iniziare, consulta Sequenza dell'implementazione degli upgrade del cluster.
Terminologia
Questo documento utilizza il termine group per fare riferimento sia ai parchi risorse che agli ambiti dei team, perché puoi creare una sequenza di implementazione organizzata con entrambi i metodi di raggruppamento.
Qualifica gli upgrade tra gli ambienti
Per eseguire automaticamente l'upgrade dei cluster con la sequenza di implementazione, utilizza i parchi risorse o gli ambiti dei team in cui hai raggruppato i tuoi cluster con lo stesso canale di rilascio e la stessa versione secondaria in fasi di deployment. Scegli la sequenza di parchi risorse o la sequenza di ambiti dei team e imposta la quantità di tempo per i test di soak che vuoi tra ciascun 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 secondo la sequenza che hai definito e puoi convalidare che i carichi di lavoro vengano eseguiti come previsto con una nuova versione prima che gli upgrade inizino con i cluster di produzione.
Sequenza di implementazione basata sul parco risorse
Il seguente diagramma illustra in che modo GKE esegue automaticamente l'upgrade dei cluster in una sequenza di implementazione organizzata con i parchi risorse:
Con una sequenza basata sul parco risorse, quando GKE rende disponibile una nuova destinazione dell'upgrade nel canale di rilascio in cui sono registrati tutti i cluster in questa sequenza, GKE esegue l'upgrade di questi gruppi di cluster in questa sequenza, con i cluster del parco risorse upstream che qualifica la nuova versione per i cluster nel parco risorse downstream, per un massimo di tre parchi risorse. Upstream, in sequenza di implementazione, fa riferimento al gruppo precedente e downstream al gruppo successivo.
Durante il tempo di attesa configurato tra i parchi risorse, dopo il completamento degli upgrade nel parco risorse upstream e prima che inizino nel parco risorse downstream, puoi confermare che i carichi di lavoro vengano eseguiti come previsto nei 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 dei team. Gli ambiti dei team sono un costrutto a livello di parco risorse aziendale per associare sottoinsiemi di cluster del parco risorse a team delle applicazioni specifici e possono essere utilizzati per abilitare una serie di funzionalità basate sui team, tra cui il controllo dell'accesso dell'accesso e l'osservabilità a livello di team, nonché la sequenza delle implementazioni.
Con gli ambiti dei team, puoi creare più sequenze di implementazione in un parco risorse, ciascuna con i propri canali di rilascio, destinazioni 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, ad eccezione del fatto che gli upgrade sono qualificati tra i cluster di un team specifico in ogni parco risorse, anziché tra il parco risorse. Questo è particolarmente utile per gli operatori di applicazioni che vogliono gestire gli upgrade all'interno dei cluster del proprio team.
La sequenza di implementazioni basata sul parco risorse è in anteprima, mentre la sequenza di implementazioni basata sul parco risorse è 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 prima eseguito l'upgrade del piano di controllo, quindi dell'upgrade dei nodi. In una sequenza di implementazione, i cluster vengono comunque aggiornati utilizzando questo processo, ma puoi anche controllare l'ordine in cui viene eseguito l'upgrade dei gruppi (parchi risorse o ambiti) di cluster e specificare un periodo di soak time per la durata della pausa di GKE prima che gli upgrade passino da un gruppo al gruppo successivo.
Gli upgrade dei cluster in una sequenza di implementazione procedi nel seguente modo:
- GKE imposta un nuovo target per l'upgrade automatico per i cluster su una versione secondaria in uno specifico canale di rilascio, con la nota di rilascio che riporta qualcosa di simile al seguente messaggio: "Con questa release verrà eseguito l'upgrade dei piani di controllo e dei nodi con upgrade automatico nel canale regolare, che verrà eseguito dalla versione 1.21 alla versione 1.22.15-gke.1000".
- GKE inizia a eseguire l'upgrade dei piani di controllo del cluster alla nuova versione nel primo gruppo di cluster. Dopo che GKE ha eseguito l'upgrade del piano di controllo di un cluster, GKE inizia a eseguire l'upgrade dei nodi del cluster. GKE rispetta la disponibilità della manutenzione quando esegui l'upgrade dei cluster in una sequenza di implementazione.
- GKE esegue i seguenti passaggi per gli upgrade del piano di controllo:
- GKE inizia il periodo di attesa per gli upgrade del piano di controllo al termine di tutti gli upgrade del piano di controllo del cluster nel primo gruppo o dopo 30 giorni dall'inizio degli upgrade del piano di controllo.
- Una volta completato il 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 per gli upgrade dei nodi:
- GKE inizia il periodo di attesa per gli upgrade dei nodi al termine di tutti gli upgrade dei nodi del cluster nel primo gruppo o dopo 30 giorni dall'inizio degli upgrade dei nodi.
- GKE avvia gli upgrade dei nodi nel secondo gruppo per i cluster in cui è già stato eseguito l'upgrade del piano di controllo al termine del periodo di assorbimento degli upgrade dei nodi nel primo gruppo.
- GKE ripete questi passaggi dal secondo al terzo gruppo, finché non viene eseguito l'upgrade dei cluster in tutti i gruppi nella sequenza di implementazione alla nuova destinazione dell'upgrade.
Man mano che viene eseguito l'upgrade dei cluster in ogni gruppo, verifica durante il periodo di soak in cui i carichi di lavoro vengono eseguiti come previsto con i cluster che eseguono la nuova versione di GKE.
Potrebbe anche essere impedito l'upgrade dei cluster a causa di periodi di manutenzione o esclusioni, utilizzo di API deprecato o altri motivi. Per scoprire di più, consulta Come funziona la sequenza di 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 aggiornati nell'ordine da te definito e rimangono inseriti in ogni gruppo per il periodo di tempo che hai scelto. Mentre sono in corso gli upgrade, puoi controllare lo stato di una sequenza di implementazione e gestire la sequenza di implementazione in base alle tue esigenze. Puoi controllare la procedura anche nei seguenti modi:
- Per un gruppo in una sequenza di implementazione, puoi eseguire l'override del tempo di attesa predefinito se hai bisogno di più o meno ammollo per una versione specifica.
- Per gli upgrade di singoli cluster, puoi continuare a utilizzare i seguenti strumenti:
- controllare manualmente gli upgrade intraprendendo azioni come annullamento, ripresa, rollback o completamento degli upgrade del pool di nodi.
- Utilizza periodi di manutenzione ed esclusioni per decidere quando è possibile e quando è possibile eseguire l'upgrade di un cluster.
- Configura le strategie di upgrade dei nodi per bilanciare velocità e tolleranza di rischio in base ai carichi di lavoro in esecuzione sui nodi.
Per saperne di più, scopri come funziona la sequenza di implementazione con altre funzionalità di upgrade.
Esempio: la Community Bank implementa gradualmente le modifiche da Test a Produzione
Ad esempio, l'amministratore di piattaforma presso una banca della community gestisce tre ambienti di deployment principali, ciascuno un gruppo di cluster organizzati in un parco risorse: test, gestione temporanea e produzione. Come richiesto per la sequenza di implementazione, l'amministratore ha registrato ciascun cluster in tutti e tre i parchi risorse nello stesso canale di rilascio, in questi parchi risorse, 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'ordine dell'implementazione offre all'amministratore la possibilità di verificare che i carichi di lavoro vengano eseguiti come previsto con i cluster su una nuova versione di GKE prima che venga eseguito l'upgrade dell'ambiente di produzione alla nuova versione. Questa sequenza è illustrata dal diagramma della sequenza di implementazione basata sul parco risorse.
L'amministratore utilizza il tempo di attesa tra questi parchi risorse per l'upgrade per verificare che i carichi di lavoro vengano eseguiti come previsto con i cluster della nuova versione di GKE. Per il parco risorse di test, l'amministratore imposta il tempo di attesa su 14 giorni, in modo da avere due settimane complete per testare l'esecuzione dei carichi di lavoro. Per la gestione temporanea, impostano il tempo di attesa su 7 giorni, in quanto non hanno bisogno di molto tempo aggiuntivo dopo l'esecuzione dei carichi di lavoro in fase di test.
L'amministratore può anche eseguire l'override del tempo di attesa predefinito per gli upgrade a versioni specifiche, operazione che potrebbe essere opportuno eseguire in una delle seguenti situazioni:
- L'amministratore completa l'idoneità della versione prima del completamento del tempo di attesa e vuole che gli upgrade proseguano al parco risorse successivo, quindi imposta il tempo di inattività su zero.
- L'amministratore ha bisogno di più tempo per qualificare la nuova versione prima che gli upgrade procedono al parco risorse successivo, in quanto rileva un problema con alcuni carichi di lavoro, quindi ha impostato il tempo di soak su un massimo di 30 giorni.
L'amministratore utilizza periodi di manutenzione ed esclusioni per garantire che GKE esegua l'upgrade dei cluster quando sono meno fastidiosi per la banca. GKE rispetta la disponibilità di manutenzione per i cluster di cui è stato eseguito l'upgrade in una sequenza di implementazione.
- L'amministratore ha configurato periodi di manutenzione per i cluster in modo che GKE esegua l'upgrade dei cluster solo dopo l'orario di lavoro.
- L'amministratore utilizza anche le esclusioni di manutenzione per impedire temporaneamente l'upgrade dei cluster se vengono rilevati problemi con i carichi di lavoro del cluster.
L'amministratore utilizza una combinazione di upgrade di sovraccarico e blu-verde per i nodi, bilanciando velocità e tolleranza al rischio in base ai carichi di lavoro in esecuzione sui nodi.
L'amministratore passa alle sequenze di implementazioni basate sui team
Se l'amministratore decide di raggruppare ulteriormente i cluster all'interno di un parco risorse per applicazione e di offrire agli amministratori del team dell'applicazione un maggiore controllo sugli upgrade dei cluster, può utilizzare gli ambiti dei team. Con gli ambiti dei team, gli amministratori dei team delle applicazioni possono creare sequenze di implementazioni indipendenti con i gruppi di cluster assegnati ai propri team, potenzialmente in esecuzione su canali di rilascio diversi 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 soaking più lunghi, mentre i cluster del team del sito web di 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 sul team. Per farlo per il tuo ambiente, segui le istruzioni per passare tra le sequenze di implementazione basate sul parco risorse e quelle basate sui team.
Tieni presente che l'uso di questa funzionalità richiede cluster singolarmente: in altre parole, ogni singolo cluster è associato a un solo team. I cluster condivisi (supportati nella gestione generale dei team del parco risorse) non sono supportati per la sequenza di implementazioni. Puoi scoprire di più sulla gestione dei cluster per i team in Gestione dei team del parco risorse.
Idoneità all'implementazione
Affinché venga eseguito automaticamente l'upgrade dei cluster con la sequenza di implementazione, tutti i cluster in tutti i gruppi (parchi risorse o ambiti) in una sequenza di implementazione devono ricevere la stessa destinazione di upgrade. I cluster devono essere registrati nello stesso canale di rilascio e consigliamo che i cluster eseguano la stessa versione secondaria poiché le destinazioni di upgrade sono impostate come versione secondaria. Tuttavia, per alcune release, come quella nell'esempio seguente, i cluster di più versioni secondarie hanno ricevuto lo stesso target, quindi è stato possibile eseguire correttamente l'upgrade dei cluster nella sequenza di implementazione che esegue più versioni secondarie.
Puoi controllare lo stato dell'implementazione della versione in sequenza per avere ulteriori informazioni sullo stato e se i problemi di idoneità della versione impediscono il proseguimento degli upgrade. A seconda delle discrepanze di versione, potresti dover eseguire azioni come l'upgrade manuale di un cluster o la sua rimozione da un gruppo affinché gli upgrade del cluster proseguano. Se un cluster in una sequenza di implementazione non ha una destinazione di upgrade idonea, GKE non esegue 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à dell'implementazione, consulta Risolvere i problemi di idoneità dell'implementazione.
Release GKE di esempio
Ad esempio, la release 2022-R25 ha impostato una destinazione dell'upgrade per più versioni secondarie nei cluster registrati nel canale regolare. Una destinazione dell'upgrade può essere una nuova versione secondaria (da 1.20 a 1.21) o solo 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 specifiche versioni secondarie:
- I cluster in 1.20 e 1.21 sono stati aggiornati a 1.21.14-gke.4300.
- I cluster su 1.22 sono stati aggiornati a 1.23.8-gke.1900.
- I cluster su 1.24 sono stati aggiornati a 1.24.5-gke.600.
Il gruppo più a monte riceve tutti i target di upgrade
Per i cluster nel primo gruppo di una sequenza, che non hanno un gruppo upstream per qualificare le nuove versioni, GKE esegue l'upgrade di tutti i cluster con destinazioni di upgrade idonee, indipendentemente dal fatto che le destinazioni di upgrade siano diverse l'una dall'altra. Ad esempio, nel primo gruppo di una sequenza, se alcuni cluster eseguivano la versione 1.20, è possibile eseguire l'upgrade di questi cluster a 1.21.14-gke.4300 e dei cluster che eseguono la versione 1.24 a 1.24.5-gke.600. Questo perché, per il primo gruppo di una sequenza, GKE considera tutti i target di upgrade idonei per questi cluster, in quanto non esiste alcun gruppo upstream che possa qualificare una nuova versione.
Un gruppo upstream deve qualificare una sola versione
In tutti i gruppi downstream, la possibilità di GKE di eseguire l'upgrade dei cluster dipende dal fatto che il gruppo a monte abbia qualificato un target di upgrade per la quale tutti i cluster nel gruppo sono idonei. In genere, ciò significa che tutti i cluster iniziano sulla 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 eseguono entrambe le versioni potrebbero, nello stesso gruppo, qualificare l'upgrade a 1.21.14-gke.4300.
Se tutti i cluster in un gruppo non hanno la stessa destinazione di upgrade, questo gruppo non può qualificare una destinazione di upgrade per il gruppo successivo. In questa situazione, GKE non può eseguire automaticamente l'upgrade dei cluster nei gruppi downstream. 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 automaticamente l'upgrade dei cluster del secondo gruppo perché il gruppo non ha ricevuto una versione qualificata. Per far avanzare gli upgrade in questa situazione, consulta Correggere l'idoneità in un gruppo.
Un gruppo upstream deve qualificare una versione che corrisponde ai cluster del gruppo successivo
Se i cluster in un gruppo a monte qualificano una versione diversa da quella per cui erano idonei i cluster del gruppo successivo, GKE non può eseguire automaticamente l'upgrade dei cluster in nessun gruppo a valle.
Ad esempio, se è stato eseguito l'upgrade di tutti i cluster nel primo gruppo a 1.21.14-gke.4300, ma i cluster del secondo gruppo eseguivano la versione 1.22 (in cui la destinazione dell'upgrade è 1.23.8-gke.1900), per i cluster del secondo gruppo non verrà eseguito automaticamente l'upgrade. Il primo gruppo qualificava 1.21.14-gke.4300, ma i cluster del secondo gruppo (attualmente la versione 1.22) sono idonei solo per la destinazione dell'upgrade 1.23.8-gke.1900, pertanto GKE non può eseguire automaticamente l'upgrade di questi cluster. Per anticipare gli upgrade in questa situazione, consulta Correggere l'idoneità tra gruppi.
Come funziona la sequenza di implementazioni con altre funzionalità di upgrade
La sequenza di implementazione è una funzionalità di una raccolta di funzionalità che ti offre il controllo sull'aspetto dell'upgrade del ciclo di vita del cluster. Questa sezione spiega come funziona con alcune delle altre funzionalità disponibili relative agli upgrade dei cluster.
Come funziona la sequenza di implementazioni con i periodi di manutenzione e le esclusioni
GKE rispetta i periodi di manutenzione e le esclusioni di manutenzione quando esegui l'upgrade dei cluster con la sequenza di implementazioni. GKE avvia un upgrade del cluster solo entro il periodo di manutenzione. Puoi utilizzare un'esclusione di manutenzione per impedire temporaneamente l'upgrade di un cluster. Se GKE non riesce a eseguire l'upgrade di un cluster a causa di un periodo di manutenzione o di un'esclusione, questo può impedire il completamento degli upgrade del cluster in un gruppo. Se non è possibile completare un upgrade del cluster entro 30 giorni a causa di periodi di manutenzione o esclusioni, il gruppo entrerà nella fase di soak indipendentemente dal fatto che tutti i cluster abbiano terminato l'upgrade.
Puoi utilizzare le esclusioni dalla manutenzione come misura temporanea per impedire che una sequenza completi un'implementazione in un gruppo e passi al gruppo successivo. Per scoprire di più, vedi Ritardare il completamento dell'implementazione della versione del gruppo.
Come funziona la sequenza di implementazioni 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 in un gruppo in una sequenza di implementazione. Per saperne di più, consulta Come funzionano i ritiri di Kubernetes con GKE.
Come funziona la sequenza di implementazione con le strategie di upgrade dei nodi
Durante l'upgrade in una sequenza di implementazione, gli upgrade dei nodi utilizzeranno la strategia di upgrade dei nodi configurata. Come per gli upgrade dei cluster senza sequenziamento 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à in fase di soak indipendentemente dal fatto che tutti i cluster abbiano completato l'upgrade. Ciò può verificarsi se la strategia di upgrade dei nodi fa sì che l'upgrade dei nodi di un cluster Standard richieda più tempo per il completamento, soprattutto se si tratta di un pool di nodi di grandi dimensioni. Può anche essere esacerbato da periodi di manutenzione non abbastanza grandi per il completamento dell'upgrade di un nodo. Per scoprire di più, consulta Considerazioni per la configurazione di 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 sullo stesso canale di rilascio.
Ricezione di più upgrade in una sequenza
Se una nuova versione diventa la destinazione dell'upgrade nel canale di rilascio mentre gli upgrade del cluster a un target di upgrade precedente sono ancora in corso nella sequenza di implementazione, un gruppo a monte 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 1.24.2-gke.100, il primo gruppo nella sequenza può implementare contemporaneamente 1.24.3-gke.500.
Considerazioni sulla scelta della sequenza di implementazione
Prendi in considerazione l'utilizzo della 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:
- Hai cluster che non si trovano nello stesso canale di rilascio o in una versione secondaria nello stesso ambiente di produzione.
- Devi automatizzare gli upgrade che non possono essere mappati solo a tre fasi di deployment, dato che puoi creare una sequenza di implementazione solo con un massimo di tre gruppi di cluster. Non puoi collegare gruppi in più sequenze di implementazione per creare una sequenza di implementazione con più di tre gruppi.
- Non puoi utilizzare la gestione del parco risorse.
- Esegui spesso upgrade manuali che fanno sì che i cluster in un gruppo abbiano versioni di destinazione dell'upgrade automatico diverse.
Per creare sequenze di implementazioni basate sul team, devi anche essere in grado di abilitare GKE Enterprise nei progetti host del parco risorse.
Limitazioni
Per eseguire correttamente l'upgrade dei cluster con la sequenza di implementazione, devi rispettare le seguenti limitazioni:
- Se utilizzi una sequenza di implementazione basata sui team, registra un cluster in un solo ambito del team. Se un cluster è registrato in più ambiti, GKE non può eseguire automaticamente l'upgrade del cluster in una sequenza di implementazione basata sui team.
- La creazione di una sequenza di implementazione basata sul team con più ambiti all'interno dello stesso parco risorse non è supportata.
- Crea una sequenza di implementazione lineare senza cicli (un gruppo ha un gruppo a valle come gruppo a monte) o con rami (un gruppo ha più di un gruppo a valle).
- Crea sequenze di implementazione tra gli ambiti di un team o sequenze di implementazione tra parchi risorse. Non puoi creare sequenze miste con parchi risorse e ambiti dei team nella stessa sequenza.
- Assicurati che i cluster in una sequenza di implementazione siano tutti registrati nello stesso canale di rilascio e che stiano eseguendo 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 cluster a causa dell'implementazione graduale della nuova versione. È più probabile che si verifichi nel primo gruppo di cluster e dovrebbe risolversi entro una settimana.
- Se in una sequenza di implementazione è presente un gruppo vuoto, l'impatto sull'idoneità delle versioni dipende dalle condizioni seguenti:
- Se il gruppo vuoto non ha un gruppo upstream, gli upgrade del cluster non vengono trasferiti al gruppo downstream poiché il gruppo vuoto non può qualificare le versioni.
- Se il gruppo vuoto ha un gruppo a monte, tutti gli upgrade del cluster in attesa entrano nello stato
COMPLETEe si propagano al gruppo a valle.
- A causa del modo in cui GKE monitora gli upgrade di patch e di minore, potresti vedere due upgrade dello stesso tipo e della stessa versione, ma con stati diversi quando controlli lo stato dell'ambito.