Informazioni sugli upgrade dei cluster con sequenza di implementazione

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 avere familiarità con gli upgrade dei cluster, i canali di rilascio e la gestione del parco risorse.

Per iniziare, consulta Sequenziare l'implementazione degli upgrade dei cluster.

Terminologia

Questo documento utilizza il termine gruppo per fare riferimento sia agli ambiti di flotta che a quelli di team, perché puoi creare una sequenza di implementazione organizzata con uno dei due metodi di raggruppamento.

Qualificare gli upgrade tra gli ambienti

Per eseguire l'upgrade automatico dei cluster con sequenza di implementazione, utilizza i parchi risorse o gli ambiti del team in cui hai raggruppato i cluster con lo stesso canale di rilascio e la stessa versione secondaria in fasi di deployment. Scegli la sequenza di parchi risorse o di ambiti del team e imposta la durata del test di stress che vuoi tra ogni gruppo di cluster. Poi, quando GKE seleziona una nuova versione per gli upgrade automatici nel canale di rilascio, i tuoi gruppi di cluster vengono sottoposti a upgrade nella sequenza che hai definito e puoi verificare che i workload 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 come GKE esegue automaticamente l'upgrade dei 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 sul parco risorse, quando GKE rende disponibile un nuovo target di upgrade nel canale di rilascio in cui sono registrati tutti i cluster di questa sequenza, GKE esegue l'upgrade di questi parchi risorse di cluster in questa sequenza, 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. Upstream, in una sequenza di implementazione, si riferisce al gruppo precedente, mentre downstream si riferisce 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 aggiornati.

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 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 abilitare una serie di funzionalità basate sul team, tra cui il controllo dell'accesso e l'osservabilità con ambito del team, nonché il sequenziamento del rollout.

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, ognuna 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 parco risorse a parco risorse. Ciò è particolarmente utile per gli operatori delle applicazioni che vogliono gestire gli upgrade all'interno dei cluster del proprio team.

Come GKE esegue l'upgrade dei cluster in una sequenza di implementazione

Quando GKE esegue l'upgrade di un cluster, prima viene eseguito l'upgrade del control plane, poi dei nodi. In una sequenza di implementazione, i cluster vengono comunque sottoposti a upgrade utilizzando questa procedura, ma controlli anche l'ordine in cui vengono sottoposti a upgrade i gruppi (parchi risorse o ambiti) di cluster e specifichi un tempo di attesa per scegliere per quanto tempo GKE si interrompe prima che gli upgrade procedano da un gruppo al successivo.

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 su una versione secondaria in un canale di rilascio specifico, con le note di rilascio che menzionano qualcosa di simile al seguente messaggio: "I control plane e i nodi con l'upgrade automatico abilitato nel canale regolare verranno sottoposti all'upgrade dalla versione 1.21 alla versione 1.22.15-gke.1000 con questa release".
  2. GKE inizia l'upgrade dei control plane dei cluster alla nuova versione nel primo gruppo di cluster. Dopo che GKE esegue l'upgrade del control plane di un cluster, inizia l'upgrade dei nodi del cluster. GKE rispetta la disponibilità della manutenzione quando esegue l'upgrade dei cluster in una sequenza di implementazione.
  3. GKE esegue i seguenti passaggi successivi per gli upgrade del control plane:
    1. GKE inizia il periodo di sospensione per gli upgrade del control plane dopo che tutti gli upgrade del control plane del cluster nel primo gruppo sono terminati o sono trascorsi 30 giorni dall'inizio degli upgrade del control plane.
    2. Al termine del periodo di sospensione per gli upgrade del control plane del cluster nel primo gruppo, GKE inizia gli upgrade del control plane nel secondo gruppo.
  4. Parallelamente agli upgrade del control plane, GKE esegue i seguenti passaggi successivi per gli upgrade dei nodi:
    1. GKE inizia il periodo di sospensione per gli upgrade dei nodi dopo che tutti gli upgrade dei nodi del cluster nel primo gruppo sono terminati o sono trascorsi 30 giorni dall'inizio degli upgrade dei nodi.
    2. GKE inizia gli upgrade dei nodi nel secondo gruppo per i cluster in cui è già stato eseguito l'upgrade del control plane al termine del periodo di sospensione per gli upgrade dei nodi nel primo gruppo.
  5. GKE ripete questi passaggi dal secondo gruppo al terzo gruppo, finché i cluster di tutti i gruppi nella sequenza di rollout non sono stati sottoposti all'upgrade al nuovo target di upgrade.

Man mano che i cluster vengono aggiornati in ogni gruppo, verifica durante il tempo di sospensione che i tuoi 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 la sezione 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 che hai definito e vengono sottoposti a soak test in ogni gruppo per il periodo di tempo che hai scelto. Durante l'avanzamento degli upgrade, puoi controllare lo stato di una sequenza di implementazione e gestire la sequenza di implementazione in base alle esigenze. Puoi anche controllare la procedura nei seguenti modi:

Per scoprire di più, consulta la sezione Come funziona il sequenziamento del lancio con altre funzionalità di upgrade.

Esempio: la banca della comunità implementa gradualmente le modifiche da Test a Produzione

Ad esempio, l'amministratore della piattaforma di una banca comunitaria gestisce tre ambienti di implementazione principali, ognuno dei quali è un gruppo di cluster organizzati in un parco risorse: test, gestione temporanea e produzione. Come richiesto per il sequenziamento del rollout, l'amministratore ha registrato ogni cluster in tutti e tre i parchi risorse nello stesso canale di rilascio, ovvero il canale Regular, 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 offre all'amministratore l'opportunità di verificare che i workload vengano eseguiti come previsto con i cluster su una nuova versione di GKE prima che l'ambiente di produzione venga sottoposto all'upgrade alla nuova versione. Questa sequenza è illustrata dal diagramma della sequenza di implementazione basata sul parco risorse.

L'amministratore utilizza il tempo di sospensione tra l'upgrade di questi fleet per verificare che i carichi di lavoro vengano eseguiti come previsto con i cluster nella 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 Staging, hanno impostato il tempo di rodaggio su 7 giorni perché non hanno bisogno di tempo aggiuntivo dopo che i carichi di lavoro sono già stati eseguiti in Testing.

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 termina la qualifica della versione prima del completamento 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 qualificare la nuova versione prima che gli upgrade procedano alla flotta successiva, poiché ha notato un problema con alcuni dei suoi carichi di lavoro, quindi ha impostato il tempo di assorbimento sul massimo di 30 giorni.

L'amministratore utilizza periodi di manutenzione ed esclusioni per garantire che GKE esegua l'upgrade dei cluster quando l'interruzione è minima per la banca. GKE rispetta la disponibilità della manutenzione per i cluster di cui è stato eseguito l'upgrade in una sequenza di implementazione.

  • L'amministratore ha configurato le finestre di manutenzione per i cluster per assicurarsi 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 rileva problemi con i carichi di lavoro del cluster.

L'amministratore utilizza un mix di upgrade di picco e blue-green per i suoi nodi, bilanciando velocità e tolleranza al rischio a seconda dei 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 parco veicoli per applicazione e di dare agli amministratori del team di applicazioni un maggiore controllo sugli upgrade dei cluster, può utilizzare gli ambiti del team. Con gli ambiti del team, gli amministratori del team dell'applicazione possono creare sequenze di implementazione indipendenti con i gruppi di cluster assegnati ai loro team, che potrebbero essere eseguiti su canali di rilascio diversi o con tempi di assorbimento diversi.

Ad esempio, se il team del database vuole che i suoi cluster utilizzino il canale stabile e tempi di test più lunghi, mentre i cluster del team del sito web frontend utilizzano il canale rapido e tempi di test 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 dalle sequenze di implementazione basate sul parco risorse a quelle basate sul team e viceversa.

Tieni presente che l'utilizzo di questa funzionalità richiede cluster single-tenant: in altre parole, ogni singolo cluster è associato a un solo team. I cluster condivisi (supportati nella gestione generale dei team della flotta) non sono supportati per il sequenziamento del rollout. Per saperne di più sulla gestione dei cluster per i team, consulta Gestione dei team della flotta.

Idoneità all'implementazione

Affinché i cluster vengano aggiornati 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, poiché le destinazioni di upgrade sono impostate 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 che esegue più versioni secondarie.

Puoi controllare lo stato dell'implementazione della versione in una sequenza per ottenere maggiori informazioni sullo stato e se i problemi di idoneità della versione impediscono l'avanzamento degli upgrade. A seconda delle discrepanze tra le versioni, potresti dover intraprendere azioni come l'upgrade manuale di un cluster o la sua rimozione da un gruppo per procedere con gli upgrade del cluster. Se un cluster in una sequenza di implementazione non ha una destinazione di upgrade idonea, GKE non eseguirà l'upgrade automatico del cluster finché la versione secondaria esistente del cluster non raggiungerà la fine del supporto.

Per risolvere i problemi relativi all'idoneità al lancio, consulta la sezione Risolvere i problemi relativi all'idoneità al lancio.

Esempio di release di GKE

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 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 secondarie specifiche:

  • È stato eseguito l'upgrade dei cluster sulle versioni 1.20 e 1.21 alla versione 1.21.14-gke.4300.
  • È stato eseguito l'upgrade dei cluster sulla versione 1.22 alla versione 1.23.8-gke.1900.
  • È stato eseguito l'upgrade dei cluster 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 eseguivano la versione 1.20, questi cluster potevano essere aggiornati alla versione 1.21.14-gke.4300 e i cluster che eseguivano la versione 1.24 potevano essere aggiornati alla versione 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 un gruppo upstream per qualificare una nuova versione.

Un gruppo upstream deve qualificare una sola versione

In tutti i gruppi downstream, la possibilità di eseguire lGKE;upgrade dei cluster dipende dal fatto che il gruppo upstream abbia qualificato un target di upgrade per il quale tutti i cluster di questo gruppo sono idonei. In genere, ciò significa che tutti i cluster iniziano con la stessa versione secondaria. Tuttavia, dall'esempio di rilascio, i cluster su 1.20 e 1.21 avevano lo stesso target di upgrade, quindi i cluster che eseguono entrambe le versioni potevano, nello stesso gruppo, qualificare 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ò qualificare un target 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 alcuni cluster sono stati aggiornati alla versione 1.21.14-gke.4300 e altri alla versione 1.23.8-gke.1900, i cluster del secondo gruppo non possono essere aggiornati automaticamente perché il gruppo non ha ricevuto una versione qualificata. Per far avanzare gli upgrade in questa situazione, vedi 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 cui i cluster del gruppo successivo erano idonei, GKE non può eseguire automaticamente l'upgrade dei cluster in nessun gruppo downstream.

Ad esempio, se tutti i cluster del primo gruppo sono stati aggiornati alla versione 1.21.14-gke.4300, ma i cluster del secondo gruppo eseguono la versione 1.22 (dove la versione di destinazione dell'upgrade è 1.23.8-gke.1900), i cluster del secondo gruppo non verranno aggiornati automaticamente. Il primo gruppo ha qualificato la versione 1.21.14-gke.4300, ma i cluster del secondo gruppo (attualmente sulla versione 1.22) sono idonei solo per la versione di destinazione dell'upgrade 1.23.8-gke.1900, quindi GKE non può eseguire automaticamente l'upgrade di questi cluster. Per far avanzare gli upgrade in questa situazione, consulta Correggere l'idoneità tra i gruppi.

Come funziona la sequenza di implementazione con altre funzionalità di upgrade

Il sequenziamento del rollout è una funzionalità di una raccolta di funzionalità che ti consentono di controllare l'aspetto dell'upgrade del ciclo di vita del cluster. Questa sezione spiega come questa funzionalità funziona con alcune delle altre funzionalità disponibili relative agli upgrade dei cluster.

Come funziona il sequenziamento del lancio con periodi di manutenzione ed esclusioni

GKE rispetta i periodi di manutenzione e le esclusioni dalla manutenzione quando esegue l'upgrade dei cluster con sequenza di implementazione. GKE avvia l'upgrade di un cluster solo all'interno del periodo di manutenzione del cluster. Puoi utilizzare un'esclusione della manutenzione per impedire temporaneamente l'upgrade di un cluster. Se GKE non riesce ad aggiornare un cluster a causa di un periodo di manutenzione o di un'esclusione, ciò può impedire il completamento degli upgrade del cluster in un gruppo. Se l'upgrade di un cluster non può essere completato entro 30 giorni a causa di finestre di manutenzione o esclusioni, il gruppo entrerà nella fase di test indipendentemente dal fatto che tutti i cluster abbiano terminato l'upgrade.

Puoi utilizzare le esclusioni dalla manutenzione come misura temporanea per impedire a una sequenza di completare l'implementazione in un gruppo e passare al gruppo successivo. Per saperne 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à deprecate. Gli upgrade automatici vengono messi in pausa anche per i cluster di un gruppo in una sequenza di implementazione. Per saperne di più, consulta la pagina Come funzionano le deprecazioni 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 durante l'upgrade in una sequenza di implementazione. Come per gli upgrade dei cluster senza sequenza di implementazione, GKE utilizza gli upgrade inattivi per i nodi Autopilot. Per saperne di più, consulta Upgrade automatici dei nodi.

Se gli upgrade dei nodi non possono essere completati entro 30 giorni, il gruppo entrerà nella fase di soak indipendentemente dal fatto che tutti i cluster abbiano terminato l'upgrade. 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, soprattutto se si tratta di upool di nodiol di grandi dimensioni. Può anche essere esacerbato da finestre di manutenzione non abbastanza grandi da completare un upgrade del nodo. Per saperne di più, consulta Aspetti da considerare durante 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 di una sequenza di implementazione devono trovarsi nello stesso canale di rilascio.

Ricezione di più upgrade in una sequenza

Se una nuova versione diventa un target di upgrade sul canale di rilascio mentre gli upgrade del 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 sta implementando 1.24.2-gke.100, il primo gruppo della sequenza può implementare contemporaneamente 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 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 nella stessa versione secondaria nello stesso ambiente di produzione.
  • Devi automatizzare gli upgrade che non possono essere mappati a sole cinque fasi di deployment, in quanto 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 sul parco risorse possono includere fino a cinque parchi risorse, mentre quelle basate sul team possono includere fino a tre ambiti del team.
  • Non puoi utilizzare la gestione flotte.
  • Esegui spesso upgrade manuali che fanno sì che i cluster di un gruppo abbiano versioni di destinazione dell'upgrade automatico diverse.

Per creare sequenze di implementazione 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 sequenza di implementazione, devi rispettare le seguenti limitazioni:

  • Assicurati che tutti i cluster in una sequenza di implementazione siano registrati nello stesso canale di rilascio ed eseguano la stessa versione secondaria.
  • Se utilizzi la sequenza di implementazione basata sul team, registra un cluster in un solo ambito del team. Se un cluster è registrato in più ambiti del team, 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 sul 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 suo 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 flotta e di team nella stessa sequenza.
  • Crea una sequenza di implementazione tra cluster nella stessa organizzazione. Non puoi creare sequenze con cluster in più organizzazioni.

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. Questo si verifica più probabilmente nel primo gruppo di cluster e dovrebbe risolversi entro una settimana.
  • Se in una sequenza di implementazione è presente un gruppo vuoto, il modo in cui ciò influisce sulla qualifica della versione dipende dalle seguenti condizioni:
    • Se il gruppo vuoto non ha un gruppo upstream, gli upgrade del cluster non vengono eseguiti nel 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 entrano nello stato COMPLETE e vengono propagati al gruppo downstream.
  • A causa del modo in cui GKE monitora gli upgrade delle patch e secondari, potresti visualizzare due upgrade dello stesso tipo e della stessa versione, ma con stati diversi quando controlli lo stato dell'ambito.

Passaggi successivi