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. GKE fornisce anche una versione della sequenza di implementazione che utilizza fasi personalizzate (anteprima) per offrirti un controllo più granulare sugli upgrade dei cluster.

Questo documento presuppone che tu conosca quanto segue:

Per configurare una sequenza di implementazione, vedi Sequenziare l'implementazione degli upgrade del cluster.

Panoramica

La sequenza di implementazione di GKE consente di definire una sequenza specifica e ordinata per gli upgrade dei cluster nei vari ambienti, ad esempio prima l'upgrade dei cluster nell'ambiente di sviluppo, poi nell'ambiente di test e infine in produzione. Questa strategia progressiva prevede un periodo di rodaggio integrato, che ti consente di scoprire e mitigare potenziali problemi prima che l'upgrade raggiunga i tuoi sistemi più critici.

La sequenza di implementazione si basa sul concetto di parco risorse, ovvero raggruppamenti logici di cluster GKE mappati a un ambiente (ad esempio, test). Per utilizzare questa funzionalità, definisci una sequenza composta da parchi risorse e imposta il tempo di rodaggio tra un gruppo e l'altro. Quando GKE seleziona una nuova versione, i cluster vengono sottoposti ad upgrade nell'ordine definito, consentendoti di convalidare i workload prima che la versione venga completamente implementata nell'ambiente di produzione.

I parchi risorse supportano appartenenze leggere, che consentono di raggruppare i cluster in modo logico per il sequenziamento dell'implementazione senza attivare tutte le configurazioni e le funzionalità a livello di parco risorse. L'appartenenza leggera è una buona scelta se vuoi utilizzare il sequenziamento del lancio senza alcune delle altre implicazioni della gestione completa del parco risorse, come l'identità dello spazio dei nomi a livello di parco risorse. Per saperne di più, consulta Abbonamenti leggeri.

Scegliere una strategia di sequenziamento dell'implementazione

GKE offre due versioni del sequenziamento dell'implementazione. Entrambe le versioni si basano sugli stessi principi fondamentali di aggiornamenti progressivi basati sulla flotta, ma offrono diversi livelli di flessibilità. Questa sezione ti aiuta a decidere quale versione è più adatta al tuo caso d'uso.

  • Sequenza di implementazione basata sul parco risorse (GA): questa versione è la strategia consigliata per la maggior parte dei casi d'uso di produzione. La sequenza di implementazione basata sul parco risorse fornisce un metodo stabile e supportato per implementare progressivamente gli upgrade in tutti gli ambienti (ad esempio test, gestione temporanea e produzione) e utilizza una sequenza lineare di parchi risorse.

  • Sequenza di implementazione con fasi personalizzate (anteprima): questa versione è un'evoluzione del modello basato sulla flotta, che offre un controllo e una flessibilità più granulari. Con le fasi personalizzate, puoi definire fasi specifiche all'interno di una flotta utilizzando le etichette, il che le rende una buona scelta per strategie di implementazione più complesse, come il deployment di una nuova versione su un piccolo sottoinsieme di cluster di produzione prima di un'implementazione più ampia. Scegli questa opzione se hai bisogno di maggiore flessibilità o vuoi visualizzare l'anteprima delle funzionalità di sequenziamento dell'implementazione più recenti.

Sequenza di implementazione basata sul parco risorse

Per eseguire l'upgrade automatico dei cluster con sequenza di implementazione, utilizza i parchi risorse in cui hai raggruppato i cluster con lo stesso canale di rilascio e la stessa versione secondaria in fasi di deployment. Definisci la sequenza dei parchi risorse e il tempo di sospensione che vuoi tra ogni gruppo di cluster. Poi, quando GKE seleziona una nuova versione per gli upgrade automatici nel canale di rilascio, i gruppi di cluster vengono sottoposti ad 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.

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 in cui raggruppi i cluster in parchi risorse.
Figura: una sequenza di implementazione basata sul parco risorse

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. In una sequenza di implementazione, upstream indica il gruppo precedente, mentre downstream indica il gruppo successivo.

Durante il tempo di sospensione configurato tra i parchi risorse, puoi verificare che i tuoi workload vengano eseguiti come previsto sui cluster aggiornati.

Sequenza di implementazione con fasi personalizzate

Quando utilizzi la sequenza di implementazione con fasi personalizzate, definisci l'ordine degli upgrade del parco risorse e imposti i tempi di attesa. Inoltre, puoi anche:

  • Definisci una sequenza con fasi granulari che possono scegliere come target sottoinsiemi specifici di cluster all'interno di un parco risorse utilizzando le etichette, il che la rende una buona scelta per strategie come implementazioni in fasi.
  • Ottieni maggiore controllo e osservabilità tramite i nuovi oggetti API RolloutSequence e Rollout.

Questo metodo offre la massima flessibilità e il massimo controllo granulare sugli upgrade del cluster. Per scegliere come target sottoinsiemi specifici di cluster all'interno di un parco risorse, utilizza un label-selector per scegliere come target solo i cluster con etichette Kubernetes specifiche.

Il seguente diagramma mostra come GKE esegue automaticamente l'upgrade dei cluster in una sequenza di implementazione che utilizza fasi personalizzate. Gli obiettivi dello stage raggruppano i cluster con un label-selector denominato canary nel parco risorse prod:

Sequenza di implementazione con fasi personalizzate in GKE.
Figura: una sequenza di implementazione con fasi personalizzate

Quando un nuovo target di upgrade diventa disponibile nel canale di rilascio in cui sono registrati tutti i cluster di questa sequenza, GKE esegue l'upgrade prima dei cluster nel parco risorse di test, seguiti dai cluster nel parco risorse di gestione temporanea. Poi, nel parco di produzione, GKE assegna la priorità ai cluster che corrispondono a label-selector. Poiché prod-cluster-1 è etichettato con canary: true, GKE esegue l'upgrade di questo cluster successivo. GKE esegue l'upgrade di tutti i cluster rimanenti nel parco risorse di produzione (nella fase principale) alla fine del processo perché questa fase non ha alcun selettore di etichette.

Durante il tempo di sospensione configurato tra le fasi, puoi verificare che i tuoi carichi di lavoro vengano eseguiti come previsto sui cluster aggiornati. L'esempio precedente mostra una fase personalizzata nella flotta di produzione, ma puoi aggiungere più fasi a qualsiasi flotta o utilizzare una sola flotta con più fasi.

Per ulteriori informazioni sul sequenziamento dell'implementazione con fasi personalizzate, vedi Informazioni sul sequenziamento dell'implementazione con fasi personalizzate.

Il resto di questo documento riguarda solo il sequenziamento del lancio basato sul parco auto.

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 eseguiti gli upgrade dei gruppi (parchi risorse) di cluster. Specifichi anche un tempo di soak che definisce per quanto tempo GKE si mette in pausa prima che gli upgrade procedano 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 su una versione secondaria in un canale di rilascio specifico, con una nota di rilascio 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.29 alla versione 1.30.14-gke.1150000".

  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 per gli upgrade del control plane:

    1. Al termine di tutti gli upgrade del control plane del cluster nel primo gruppo, GKE inizia il periodo di sospensione per gli upgrade del control plane. GKE inizia anche il periodo di sospensione se sono trascorsi più di 30 giorni dall'inizio degli upgrade del control plane.

    2. Al termine del periodo di sospensione per gli upgrade del control plane del cluster del primo gruppo, GKE inizia l'upgrade dei control plane del secondo gruppo alla nuova versione. Tuttavia, tieni presente le seguenti considerazioni:

      • In alcuni casi, GKE potrebbe eseguire l'upgrade dei control plane del cluster del primo gruppo più volte prima di eseguire l'upgrade dei control plane del cluster del secondo gruppo. In questa situazione, GKE sceglie la versione più recente che presenta anche i seguenti attributi:
        • La versione è qualificata dal primo gruppo.
        • La versione è al massimo una versione secondaria successiva alla versione del control plane dei cluster del secondo gruppo.
      • GKE non esegue l'upgrade del control plane dei cluster nel secondo gruppo che hanno una versione successiva a quella di destinazione dell'upgrade automatico qualificata dal primo gruppo.

  4. Parallelamente agli upgrade del control plane, GKE esegue i seguenti passaggi per gli upgrade dei nodi:

    1. Al termine degli upgrade dei nodi di tutti i cluster del primo gruppo, GKE inizia il periodo di sospensione per gli upgrade dei nodi. GKE inizia anche il periodo di sospensione se sono trascorsi più di 30 giorni dall'inizio degli upgrade dei nodi.
    2. Al termine del periodo di sospensione per gli upgrade dei nodi del primo gruppo, GKE inizia l'upgrade dei nodi del secondo gruppo alla nuova versione. Tuttavia, tieni presente le seguenti considerazioni:
      • In alcuni casi, GKE potrebbe eseguire l'upgrade dei nodi del cluster del primo gruppo più volte prima di eseguire l'upgrade dei nodi del cluster del secondo gruppo. Quando si verifica questa situazione, GKE sceglie la versione più recente che ha anche i seguenti attributi:
        • La versione è qualificata dal primo gruppo.
        • La versione non è successiva alla versione del control plane del cluster del secondo gruppo.
      • GKE non esegue l'upgrade dei nodi dei cluster nel secondo gruppo che hanno una versione successiva al target dell'upgrade automatico qualificato dal primo gruppo.

  5. GKE ripete questi passaggi dal secondo gruppo al terzo gruppo, finché i cluster in tutti i gruppi nella sequenza di rollout non sono stati aggiornati al nuovo target di upgrade.

Mentre i cluster vengono sottoposti all'upgrade in ogni gruppo, durante il periodo di attesa, verifica che i tuoi workload con i cluster che eseguono la nuova versione di GKE funzionino come previsto .

L'upgrade dei cluster potrebbe anche essere impedito a causa di finestre di manutenzione o esclusioni, utilizzo di API ritirate o altri motivi.

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 a upgrade nell'ordine che hai definito e vengono sottoposti a soaking in ogni gruppo per il periodo di tempo che hai scelto. Durante l'avanzamento degli upgrade, puoi controllare lo stato e gestire la sequenza di implementazione in base alle esigenze. Puoi anche controllare la procedura nei seguenti modi:

  • Per gli upgrade dei singoli cluster, puoi continuare a utilizzare i seguenti strumenti:
    • Controlla manualmente gli upgrade eseguendo azioni come l'annullamento, la ripresa, il rollback o il completamento degli upgrade del pool di nodi.
    • Utilizza periodi di manutenzione ed esclusioni per decidere quando è possibile eseguire l'upgrade di un cluster.
    • Configura le strategie di upgrade dei nodi per bilanciare velocità e tolleranza al rischio, a seconda dei carichi di lavoro in esecuzione su questi nodi.

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: test, gestione temporanea e produzione. Ogni ambiente ha un gruppo di cluster organizzati in un parco risorse. Come richiesto per la sequenza di implementazione, 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 nel diagramma della sequenza di implementazione basata sul parco risorse.

L'amministratore utilizza il tempo di sospensione tra i fleet per verificare che i carichi di lavoro vengano eseguiti come previsto 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 ulteriore tempo 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 rodaggio al massimo di 30 giorni.

L'amministratore utilizza periodi di manutenzione ed esclusioni per consentire a GKE di eseguire l'upgrade dei cluster quando l'impatto è minimo per la banca. GKE rispetta la disponibilità della manutenzione per i cluster sottoposti ad upgrade in una sequenza di implementazione.

  • L'amministratore ha configurato i periodi di manutenzione per i suoi cluster in modo che GKE esegua l'upgrade dei cluster solo dopo l'orario di lavoro.
  • L'amministratore utilizza anche le esclusioni dalla manutenzione per impedire temporaneamente l'upgrade dei cluster se rileva problemi con i carichi di lavoro del cluster.

L'amministratore utilizza un mix di aggiornamenti surge e blu/verde per i suoi nodi, bilanciando velocità e tolleranza al rischio a seconda dei carichi di lavoro in esecuzione su questi nodi.

Idoneità all'implementazione basata sul parco risorse

Affinché i cluster vengano aggiornati automaticamente con la sequenza di implementazione, tutti i cluster in tutti i parchi risorse 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 eseguendo 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 di idoneità al lancio, vedi Risolvere i problemi di idoneità al lancio.

Esempio di release di GKE

Ad esempio, il 2025-R45 ha impostato un target di upgrade per più versioni secondarie nei cluster registrati nel canale regolare. Una destinazione di upgrade può essere una nuova versione secondaria (da 1.30 a 1.31) o solo una nuova versione patch (da 1.31.x-gke.x a 1.31.13-gke.1023000). 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 alla versione 1.31.13-gke.1023000.
  • È stato eseguito l'upgrade dei cluster alla versione 1.32.9-gke.1108000.
  • I cluster sulla versione 1.32 sono stati sottoposti all'upgrade alla versione 1.33.5-gke.1162000.

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.30, questi cluster potevano essere aggiornati alla versione 1.31.13-gke.1023000 e i cluster che eseguivano la versione 1.32 potevano essere aggiornati alla versione 1.33.5-gke.1162000. 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

Affinché l'upgrade dei cluster in qualsiasi gruppo downstream possa iniziare, il gruppo upstream deve aver qualificato correttamente un unico target di upgrade comune per il quale tutti i cluster del gruppo downstream sono idonei. Se il gruppo upstream ha cluster che sono stati aggiornati correttamente a due versioni diverse (come può accadere quando il gruppo upstream è il primo gruppo di una sequenza), il gruppo upstream qualifica la versione precedente come target di upgrade comune per il gruppo downstream. Ad esempio, se il gruppo upstream ha alcuni cluster di cui è stato eseguito l'upgrade alla versione 1.31.13-gke.1023000 e altri cluster di cui è stato eseguito l'upgrade alla versione 1.33.5-gke.1162000, il gruppo qualifica la versione 1.31.13-gke.1023000 come target dell'upgrade comune per il gruppo downstream.

I cluster che eseguono versioni successive alla destinazione dell'upgrade non impediscono gli upgrade

Se un gruppo downstream ha cluster che eseguono una versione successiva al target dell'upgrade qualificato da un gruppo upstream, GKE esegue l'upgrade dei cluster idonei per il target dell'upgrade e ignora i cluster che utilizzano già una versione successiva. Questo comportamento non impedisce l'avanzamento della sequenza di implementazione, a condizione che almeno un cluster del gruppo downstream sia idoneo per il target di upgrade.

Ad esempio, se il gruppo upstream ha qualificato l'upgrade alla versione 1.32 e il gruppo downstream ha cluster che eseguono le versioni 1.31 e 1.33, GKE esegue l'upgrade dei cluster che eseguono la versione 1.31 alla 1.32 e ignora i cluster che eseguono la versione 1.33.

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.31.13-gke.1023000, ma i cluster del secondo gruppo eseguono una versione più recente, ad esempio 1.32.9-gke.1108000, i cluster del secondo gruppo non verranno aggiornati automaticamente. Il primo gruppo ha qualificato la versione 1.31.13-gke.1023000, ma i cluster del secondo gruppo (attualmente alla versione 1.32) sono idonei solo per la versione di upgrade di destinazione 1.33.5-gke.1162000, quindi GKE non può eseguire l'upgrade automatico di questi cluster. Per far avanzare gli upgrade in questa situazione, consulta Correggere l'idoneità tra i gruppi.

Il gruppo upstream ha qualificato più target di upgrade per il gruppo downstream

Se GKE ha eseguito l'upgrade dei cluster nel gruppo upstream più volte prima di eseguire l'upgrade dei cluster nel gruppo downstream, GKE esegue l'upgrade dei cluster nel gruppo downstream all'ultima versione qualificata dal gruppo upstream, per la quale i cluster nel gruppo downstream sono idonei. Per gli upgrade del control plane, questa versione può essere al massimo una versione secondaria successiva rispetto alla versione del control plane dei cluster nel gruppo downstream. Per gli upgrade dei nodi, questa versione può essere uguale alla versione del piano di controllo dei cluster del gruppo downstream, ma non successiva.

Ad esempio, questo scenario è pertinente se hai configurato esclusioni dalla manutenzione per impedire temporaneamente gli upgrade per il tuo gruppo downstream, che include i tuoi cluster di produzione. Tuttavia, il tuo gruppo upstream, che include i cluster di pre-produzione, non ha utilizzato le esclusioni dalla manutenzione per impedire gli upgrade. Pertanto, il gruppo upstream è stato sottoposto a più upgrade, qualificando più potenziali target di upgrade, mentre il gruppo downstream non è stato sottoposto a upgrade.

Gli upgrade non completati entro 30 giorni verranno forzati per sbloccare la sequenza

Per garantire che una sequenza di implementazione completi l'upgrade dei cluster, GKE avvia il periodo di sospensione per un gruppo se gli upgrade del control plane o dei nodi, rispettivamente, non vengono completati in tutti i cluster entro il tempo massimo di upgrade (30 giorni). Gli upgrade per i cluster rimanenti nel gruppo possono comunque continuare durante il periodo di assorbimento. Per saperne di più, consulta la riga relativa a FORCED_SOAKING nella tabella delle informazioni sullo stato di una sequenza di implementazione.

Come funziona la sequenza di implementazione basata sul parco risorse con altre funzionalità di upgrade

Il sequenziamento del rollout è una delle 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 la sequenza di implementazione basata sul parco risorse 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 può eseguire l'upgrade di un cluster a causa di un periodo di manutenzione o di un'esclusione, questa circostanza 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 di 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 basata sul parco risorse con il rilevamento dell'utilizzo della deprecazione

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 quando vengono eseguiti 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. Questo comportamento può verificarsi 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 un pool di nodi di grandi dimensioni. Può anche essere esacerbato da periodi di manutenzione non abbastanza grandi da completare un upgrade del nodo.

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 la versione 1.31.12-gke.1265000, il primo gruppo della sequenza può implementare contemporaneamente la versione 1.31.13-gke.1008000.

Considerazioni per la scelta della sequenza di implementazione basata sulla flotta

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 strategia 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 flotte.
  • Esegui spesso upgrade manuali che fanno sì che i cluster di un gruppo abbiano versioni di destinazione dell'upgrade automatico diverse.

Limitazioni della sequenza di implementazione basata sul parco risorse

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. Ti consigliamo inoltre di eseguire la stessa versione secondaria su tutti i cluster per qualificare un target di upgrade. Per ulteriori informazioni, consulta la sezione Idoneità all'implementazione.
  • 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 una sequenza di implementazione tra cluster nella stessa organizzazione. Non puoi creare sequenze con cluster in più organizzazioni.

Problemi noti con la sequenza di implementazione basata sulla flotta

  • 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 comportamento è 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, 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 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 entrano nello stato COMPLETE e vengono propagati al gruppo downstream.

Passaggi successivi