Informazioni sugli upgrade dei cluster con sequenza di implementazione

Puoi gestire l'ordine degli upgrade automatici dei cluster in Google Kubernetes Engine (GKE) in più ambienti utilizzando la sequenziazione del rollout. Ad esempio, puoi convalidare 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 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.

Qualificazione degli upgrade in più ambienti

Per eseguire l'upgrade automatico dei cluster con la sequenza di implementazione, utilizza parchi risorse o ambito del team in cui hai raggruppato i cluster con lo stesso canale di rilascio e la stessa versione minore in fasi di implementazione. Scegli la sequenza dei parchi risorse o la sequenza degli ambiti dei team e imposta come il tempo necessario per i test di sospensione 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 nella sequenza che hai definito e puoi verificare che i carichi di lavoro vengano eseguiti 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 gli upgrade automatici di cluster in una sequenza di implementazione organizzata in base ai parchi risorse:

Sequenza di implementazione basata sul parco risorse. Puoi organizzare i cluster in parchi risorse o suddividerli ulteriormente in parchi risorse con ambiti.

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 tre 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, una volta completati gli upgrade, parco risorse upstream e prima che inizino sul parco risorse downstream, puoi confermare che i carichi di lavoro vengano eseguiti come previsto sui cluster di cui è stato eseguito l'upgrade.

Sequenza di implementazione basata sul team

Se hai suddiviso ulteriormente i cluster di un parco risorse per team o applicazione, puoi creare una sequenza di implementazione tra gli ambiti dei team. Ambiti dei team sono una struttura a livello di parco risorse aziendale per associare sottoinsiemi di cluster a team di applicazioni specifici e possono essere utilizzate per abilitare una gamma di funzionalità basate sui team, tra cui il controllo dell'accesso e l'osservabilità a livello di team, nonché la sequenza di implementazione.

Sequenze di implementazione basate sull'ambito. Puoi organizzare i cluster in parchi risorse o suddividerli ulteriormente in parchi risorse con ambiti.

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. R una sequenza di implementazione basata sul team funziona in modo identico a un'implementazione basata sul parco risorse sequenza temporale specifica, ad eccezione del fatto che gli upgrade sono qualificati tra i cluster di un team specifico in ogni parco risorse, dalla flotta alla flotta. Questo è particolarmente utile per gli operatori delle applicazioni che vogliono gestire gli upgrade all'interno dei cluster del proprio team.

La sequenza di implementazione basata sul team è in anteprima, mentre l'implementazione basata sul parco risorse la sequenza è in disponibilità generale (GA).

Come 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, viene eseguito l'upgrade 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 da un gruppo all'altro.

Gli upgrade dei cluster in una sequenza di implementazione procedono con i seguenti passaggi:

  1. GKE imposta un nuovo target di upgrade automatico per i cluster una versione secondaria in uno specifico canale di rilascio, con il nota in cui viene menzionato qualcosa di simile a il seguente messaggio: "Piani di controllo e nodi con upgrade automatico abilitato nel canale regolare verrà eseguito l'upgrade dalla versione 1.21 alla versione 1.22.15-gke.1000 con questa release".
  2. GKE inizia l'upgrade dei piani di controllo del cluster al nuovo nel primo gruppo di cluster. Dopo l'upgrade di un cluster GKE di controllo del cluster, GKE avvia l'upgrade nodi. GKE rispetta la disponibilità di manutenzione durante l'upgrade dei cluster in una sequenza di implementazione.
  3. GKE esegue i seguenti passaggi successivi per gli upgrade del piano di controllo:
    1. 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.
    2. Dopo il periodo di sospensione per gli upgrade del piano di controllo del cluster nel primo viene completato, GKE avvia gli upgrade del piano di controllo secondo gruppo.
  4. In parallelo agli upgrade del piano di controllo, GKE esegue queste operazioni: passaggi successivi per gli upgrade dei nodi:
    1. 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.
    2. GKE avvia gli upgrade dei nodi nel secondo gruppo per i quali è già stato eseguito l'upgrade del piano di controllo dopo di sospensione per gli upgrade dei nodi nel primo gruppo.
  5. GKE ripete questi passaggi dal secondo al terzo gruppo finché i cluster di tutti i gruppi nella sequenza di implementazione non sono stati aggiornato al nuovo target.

Durante l'upgrade dei cluster in ogni gruppo, verifica che i carichi di lavoro vengano eseguiti come previsto con i cluster che eseguono la nuova versione di GKE.

È possibile che l'upgrade dei cluster venga impedito anche a causa di periodi di manutenzione o esclusioni, utilizzo deprecato dell'API 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, viene eseguito l'upgrade di gruppi di cluster all'ordine che hai definito e che sono immersi in ogni gruppo per la quantità all'ora selezionata. Durante l'esecuzione degli upgrade, puoi controllare lo stato di una sequenza di implementazione e gestirli come necessario. Puoi anche controllare il processo nei seguenti modi:

Per scoprire di più, consulta come funziona la sequenza di implementazione con altre funzionalità di upgrade.

Esempio: la Community Bank implementa gradualmente le modifiche dal test alla produzione

Ad esempio, l’amministratore di piattaforma di una banca comunitaria gestisce tre principali ambienti di deployment, ciascuno a un gruppo di cluster organizzati in un parco risorse: test, staging 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 usa 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 carichi di lavoro 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 è illustrato dal diagramma della sequenza di implementazione basata sul parco risorse.

L'amministratore utilizza il tempo di sospensione tra l'upgrade di questi parchi per verificare che i 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 la gestione temporanea, impostano il tempo di sospensione su 7 giorni in quanto non hanno bisogno di molto. di tempo in più dopo che i carichi di lavoro sono già in esecuzione nel test.

L'amministratore può anche ignorare 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 attesa e vuole che gli upgrade procedano al parco risorse successivo, quindi imposta il tempo di attesa su zero.
  • L'amministratore ha bisogno di più tempo per convalidare la nuova versione prima che gli upgrade procedano al parco risorse successivo perché ha notato un problema con alcuni dei suoi carichi di lavoro, quindi imposta il tempo di attesa massimo su 30 giorni.

L'amministratore usa periodi di manutenzione ed esclusioni per garantire GKE esegue l'upgrade dei cluster quando è meno invasivo per la banca. GKE rispetta la disponibilità per la manutenzione dei cluster di cui è stato eseguito l'upgrade in una sequenza di implementazione.

  • L'amministratore ha configurato periodi di manutenzione per i propri cluster assicura che GKE esegua gli 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 dover raggruppare ulteriori cluster all'interno di un parco risorse per applicazione e offrono agli amministratori dei team delle applicazioni un maggiore controllo sugli upgrade dei cluster, possono utilizzare gli ambiti dei team. Con gli ambiti dei team, gli amministratori dei team delle applicazioni possono creare implementazioni indipendenti con i gruppi di cluster assegnati ai loro team, potenzialmente in esecuzione diversi canali di rilascio o con tempi di sospensione diversi.

Ad esempio, se il team del database vuole che i propri cluster utilizzino canale stabile e tempi di sospensione più lunghi mentre i cluster del team del sito web frontend usano il canale Rapido e tempi di sospensione più brevi, possono usare gli ambiti del team per creare sequenze di implementazione separate. Questo tipo di sequenza è illustrato dalla sequenza di implementazione basata sui team in questo diagramma. Per farlo per il tuo ambiente, segui istruzioni per passare dall'implementazione basata sul parco risorse a quella basata sul team e viceversa sequenze.

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. Puoi scoprire di più sulla gestione dei cluster per i team in Gestione dei 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 consiglia di impostare la stessa versione secondaria dei cluster delle destinazioni dell'upgrade alla 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 per sapere se problemi di idoneità della versione stanno impedendo l'avanzamento 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 nel cluster fino a quando la versione secondaria esistente del cluster non raggiunge la fine dell'IA.

Per risolvere i problemi relativi all'idoneità dell'implementazione, consulta Risolvere i problemi relativi all'implementazione. idoneità.

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 Regolare. 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 questo di Google, nel canale regolare sono state rese disponibili le nuove versioni riportate di seguito per i cluster su versioni secondarie 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 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 ha un upstream per qualificare le nuove versioni, GKE esegue l'upgrade di qualsiasi cluster target di upgrade idonei, indipendentemente dal fatto che siano diversi l'uno dall'altro. Ad esempio, nel primo gruppo di una sequenza, se alcuni cluster la versione 1.20, è stato possibile eseguire l'upgrade di questi cluster alla versione 1.21.14-gke.4300 e è possibile eseguire l'upgrade 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 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, se GKE può eseguire l'upgrade dei cluster dipende da se il gruppo upstream ha qualificato un target di upgrade per il quale 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 che corrisponde 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 di tutti i cluster nel primo gruppo a 1.21.14-gke.4300, ma i cluster del secondo gruppo erano in esecuzione 1.22 (dove il target dell'upgrade è 1.23.8-gke.1900), i cluster del secondo gruppo non viene eseguito automaticamente. Il primo gruppo ha superato la verifica 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 avanzare negli upgrade in questa situazione, vedi Risolvere l'idoneità tra i gruppi.

Come funziona il sequenziamento dell'implementazione con altre funzionalità di upgrade

La sequenza di implementazione è una delle funzionalità di una raccolta che ti offre un controllo completo sull'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 di manutenzione durante l'upgrade dei cluster con la sequenza di implementazione. GKE avvia solo di eseguire l'upgrade del cluster entro 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 oppure un'esclusione, questo può impedire la fine degli upgrade del cluster in un gruppo. Se l'upgrade del cluster non può essere completato entro 30 giorni a causa di periodi di manutenzione o esclusioni, il gruppo entrerà nella fase di sospensione indipendentemente dal fatto che tutti di cluster al termine dell'upgrade.

Puoi utilizzare le esclusioni dalla manutenzione come misura temporanea per evitare una sequenza dal completamento di un'implementazione in un gruppo al passaggio 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. Anche gli upgrade automatici sono in pausa per i cluster in 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 la sequenza di implementazione, GKE usa gli upgrade di sovraccarico 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 sospensione indipendentemente dal fatto che tutti i cluster abbiano terminato l'upgrade. Questo può si verificano se la strategia di upgrade del nodo causa un nodo del cluster Standard l'upgrade potrebbe richiedere più tempo, soprattutto se si tratta di un pool di nodi di grandi dimensioni. Inoltre, può essere aggravato da finestre di manutenzione non sufficientemente lunghe per completare l'upgrade di un nodo. Per saperne di più, vedi Considerazioni per la configurazione di una manutenzione finestra.

Come funziona la sequenza di implementazione con i canali di rilascio

I canali di rilascio sono necessaria per usare 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 prevede l'implementazione di 1.24.2-gke.100, il primo contemporaneamente può essere implementato 1.24.3-gke.500.

Considerazioni sulla scelta della sequenza di implementazione

Valuta la possibilità di utilizzare la sequenza di implementazione se vuoi gestire gli upgrade del 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 nel caso di uno dei le seguenti affermazioni sono vere:

  • 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 solo a tre fasi perché puoi creare una sequenza di implementazione con un massimo di tre gruppi dei 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 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 il sequenziamento dell'implementazione, devi rispettare le seguenti limitazioni:

  • Se utilizzi una sequenza di implementazione basata sul team, registra un cluster in un solo ambito del team. Se un cluster è registrato in più di team, GKE non può eseguire automaticamente l'upgrade del cluster sequenza di implementazione.
  • Creazione di una sequenza di implementazione basata sul team con più ambiti all'interno dello stesso Il parco risorse non è supportato.
  • Creare una sequenza di implementazione lineare senza cicli (un gruppo ha un come gruppo upstream) o rami (un gruppo ha più di un 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, viene l'upgrade potrebbe essere temporaneamente disponibile solo per alcuni cluster a causa un'implementazione graduale della nuova versione. Questo problema si verifica più spesso nel primo gruppo di cluster e dovrebbe essere risolto 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 procedi al gruppo downstream poiché il gruppo vuoto non può qualificare le versioni.
    • Se il gruppo vuoto ha un gruppo upstream, tutti gli upgrade del cluster in attesa vengono inseriti lo stato COMPLETE e propagarsi 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.

Passaggi successivi