Informazioni sulla sequenza di implementazione con fasi personalizzate

Autopilot Standard

Rollout sequencing with custom stages

• Sequenza di implementazione con fasi personalizzate (anteprima)
• Sequenza di implementazione (GA)

Anteprima

Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini di servizio generali dei Termini di servizio specifici. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per ulteriori informazioni, consulta le descrizioni delle fasi di lancio.

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 disponibile a livello generale della sequenza di implementazione che utilizza un modello più lineare senza fasi personalizzate.

Questo documento presuppone che tu conosca quanto segue:

• Upgrade dei cluster
• Panoramica della gestione del parco risorse
• Canali di rilascio
• Schema di controllo delle versioni in GKE
• Test di stress

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 sulla flotta (GA): questa versione è la strategia disponibile a livello generale e 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 sul parco auto, che offre un controllo e una flessibilità più granulari. Con le fasi personalizzate, puoi definire fasi specifiche all'interno di un parco risorse utilizzando le etichette, il che le rende una buona scelta per strategie di implementazione più complesse, come l'implementazione 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 in anteprima le funzionalità di sequenziamento dell'implementazione più recenti.

Il resto di questo documento riguarda solo il sequenziamento del lancio con fasi personalizzate.

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:

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.

Concetti fondamentali

• Tempo di rodaggio: questo periodo è un periodo di attesa configurabile che si verifica dopo l'upgrade di tutti i cluster in una fase. Questo periodo di attesa ti consente di convalidare la nuova versione in un ambiente e di rilevare potenziali problemi prima che l'upgrade venga eseguito nell'ambiente successivo. Puoi configurare un periodo di attesa fino a 30 giorni per ogni fase della sequenza. Un periodo di rodaggio più lungo in una fase di pre-produzione ti offre più tempo per la convalida.
• RolloutSequence: questa è la risorsa principale che utilizzi per definire la sequenza di upgrade. RolloutSequence contiene una serie ordinata di fasi, che verifica che i cluster nelle fasi precedenti siano completamente aggiornati e abbiano completato il periodo di soak prima che l'upgrade proceda alla fase successiva.
• Rollout: questo oggetto ti consente di osservare l'avanzamento di un singolo upgrade di versione nella sequenza. Puoi utilizzare Rollout per visualizzare lo stato dell'implementazione, monitorare l'avanzamento e vedere se e perché alcuni cluster non sono idonei per l'upgrade.
• Progetto host dedicato: ti consigliamo di utilizzare un progetto Google Cloud dedicato per ospitare gli oggetti RolloutSequence. L'inserimento della sequenza in un progetto dedicato fornisce un punto di controllo centrale e neutro per le sequenze di implementazione, una best practice simile per la gestione delle pipeline CI/CD.

Best practice:

Crea e gestisci le tue risorse RolloutSequence in un progetto host dedicato.

• Fasi: una fase è un passaggio nella sequenza di implementazione. Ogni fase contiene un gruppo di cluster che vengono aggiornati insieme.
• Parchi risorse: i parchi risorse sono il modo principale per raggruppare i cluster. Una fase di una sequenza di implementazione può fare riferimento a un solo parco risorse.
• Selettori di etichette: una sequenza di implementazione è composta da una o più fasi. Ogni fase contiene cluster di un parco risorse e puoi utilizzare i selettori di etichette sui cluster per suddividere ulteriormente un parco risorse in più fasi. Questo approccio consente strategie come i rollout graduali, in cui viene eseguito l'upgrade di un piccolo sottoinsieme di cluster di produzione per primi.

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 .

Avviso :GKE potrebbe non essere in grado di procedere con gli upgrade automatici in una sequenza di implementazione se ci sono discrepanze di versione tra i cluster nei gruppi della sequenza. Per ulteriori informazioni, consulta la sezione Idoneità all'implementazione.

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:

• Puoi modificare il tempo di attesa predefinito per un gruppo all'interno di una sequenza di implementazione, il che è utile se i test rivelano che una versione specifica richiede un tempo di attesa maggiore o minore. Questa modifica del tempo di ammollo aggiorna il tempo di ammollo predefinito a tutte le implementazioni attuali e future (a qualsiasi versione) create dopo la modifica.

• 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.

Attenzione :se modifichi una sequenza durante un rollout, in particolare le modifiche che interessano i cluster partecipanti, GKE annulla immediatamente tutti i rollout esistenti. Se modifichi solo il tempo di attesa di una sequenza, GKE non annulla l'implementazione.

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

Un amministratore della piattaforma di una banca comunitaria gestisce tre ambienti di deployment principali: test, gestione temporanea e produzione. I cluster di produzione sono distribuiti in più regioni, con livelli di criticità diversi. Per gestire gli upgrade in modo efficace, l'amministratore raggruppa i cluster in ogni ambiente in flotte. Come richiesto per il sequenziamento del rollout, ogni cluster in tutti e tre i parchi risorse è registrato nello stesso canale di rilascio, in questo caso il canale regolare, e tutti i cluster eseguono la stessa versione secondaria.

L'obiettivo principale dell'amministratore è garantire che le nuove versioni di GKE vengano esaminate a fondo prima di raggiungere l'ambiente di produzione critico della banca. Inoltre, vogliono eseguire l'upgrade progressivo dei cluster prima in una regione con meno traffico, poi in una regione con più traffico e infine nella regione più critica. A questo scopo, utilizzano il sequenziamento dell'implementazione con fasi personalizzate per definire una strategia di upgrade progressiva che includa l'etichettatura dei cluster di produzione in base alla regione. Questo approccio consente di convalidare una nuova versione su un piccolo sottoinsieme del traffico di produzione prima di un'implementazione completa.

Per implementare questo piano, l'amministratore applica le seguenti etichette ai cluster nel parco risorse di produzione:

• I cluster in us-west1 (traffico inferiore) sono etichettati con prod-region: us-west1.
• I cluster in europe-west1 (traffico più elevato) sono etichettati con prod-region: europe-west1.
• I cluster in us-east1 (traffico più critico) non sono etichettati. L'ultima fase per un parco risorse all'interno di una sequenza deve fungere da "catch-all" per tutti i cluster rimanenti. Pertanto, l'amministratore non deve aggiungere etichette a questi cluster rimanenti.

Successivamente, in un progetto host dedicato utilizzato per la gestione delle configurazioni CI/CD, definiscono un oggetto RolloutSequence. Questa nuova sequenza è composta da cinque fasi distinte:

1. Test: questa fase include tutti i cluster nel parco risorse testing. L'amministratore imposta un periodo di attesa di tre giorni per consentire una convalida approfondita.
2. Staging: questa fase include tutti i cluster della flotta staging, con un periodo di rodaggio di tre giorni.
3. Produzione nella regione us-west1: questa fase ha come target la flotta di produzione, ma utilizza un label-selector per includere solo i cluster con l'etichetta prod-region: us-west1. Questa fase consente all'amministratore di monitorare eventuali problemi in un piccolo sottoinsieme di cluster di produzione con un periodo di test di tre giorni.
4. Produzione nella regione europe-west1: questa fase include i cluster nel parco risorse production con l'etichetta prod-region: europe-west1. L'amministratore imposta un tempo di sospensione più lungo di quattro giorni per una convalida più approfondita.
5. Produzione nella regione us-east1: questa fase finale include i cluster rimanenti nel parco risorse production, ovvero tutti i cluster in us-east1.

Questo approccio offre all'amministratore un controllo granulare sugli upgrade di produzione, migliorando significativamente la sicurezza e l'affidabilità del processo di upgrade rilevando potenziali problemi prima che possano influire sull'intero ambiente di produzione.

Durante un upgrade di patch di routine, i test automatici della banca vengono completati correttamente nell'ambiente di staging molto più rapidamente del previsto. L'amministratore osserva che la nuova versione è stabile e decide che il periodo di prova di tre giorni dopo l'upgrade della flotta di staging è inutilmente lungo per questo tipo di aggiornamento di routine.

Per accelerare l'implementazione, l'amministratore modifica la definizione di RolloutSequence e riduce la durata del periodo di prova per la fase us-west1 del parco dispositivi di produzione. Poiché questa modifica alla definizione di RolloutSequence aggiorna il tempo di attesa predefinito per tutti gli implementazioni attuali e futuri, l'amministratore prende nota di ripristinare il tempo di attesa al periodo originale di tre giorni al termine dell'implementazione di questa patch specifica. Questo approccio consente di garantire che il tempo di test standard e più cauto sia in vigore per i futuri aggiornamenti delle versioni secondarie.

L'amministratore utilizza periodi di manutenzione ed esclusioni in modo che GKE esegua l'upgrade dei cluster quando è meno invasivo 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 i 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 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 upgrade surge e blu/verde per i nodi, bilanciando velocità e tolleranza al rischio a seconda dei carichi di lavoro in esecuzione su questi nodi.

Idoneità all'implementazione

Affinché una versione venga implementata tramite una sequenza utilizzando fasi personalizzate, i cluster devono essere idonei per una destinazione di upgrade dal proprio canale di rilascio. Quando diventa disponibile una nuova versione di GKE, il sistema crea un oggetto Rollout se i cluster nella sequenza sono idonei per la nuova versione. Anche se consigliamo di registrare tutti i cluster nello stesso canale di rilascio, se non lo sono, GKE seleziona una versione dal canale più conservativo della sequenza. Ad esempio, se i cluster sono misti tra i canali Stabile e Regolare, GKE sceglie la versione del canale Stabile.

Il Rollout avanza quindi nelle fasi definite nel tuo RolloutSequence. All'interno di una determinata fase, l'implementazione del control plane e del pool di nodi possono essere eseguite in parallelo. Una regola fondamentale che disciplina questa progressione è che, mentre una fase si trova nello stato SOAKING con una determinata versione, non è idonea per iniziare un nuovo Rollout per una versione più recente. Questa pratica contribuisce a garantire che una versione venga convalidata completamente prima dell'inizio dell'upgrade successivo. Puoi osservare l'avanzamento e l'idoneità di ciascun cluster monitorando l'oggetto Rollout. Se trovi discrepanze di versione che rendono un cluster non idoneo, potresti dover intervenire, ad esempio eseguendo l'upgrade manuale del cluster, per consentire l'avanzamento della sequenza. Se un cluster non è idoneo per alcun rollout, GKE non esegue automaticamente l'upgrade del cluster finché la versione corrente non raggiunge la fine del supporto.

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

Se una fase della sequenza contiene cluster che eseguono una versione successiva alla versione di destinazione di un rollout, GKE esegue l'upgrade dei cluster idonei per la versione di destinazione e ignora i cluster che utilizzano già una versione successiva. Questo comportamento non impedisce alla sequenza di implementazione di passare alla fase successiva.

Ad esempio, se la versione di destinazione di un rollout per una fase è 1.32 e questa fase ha cluster che eseguono sia la versione 1.31 che la 1.33, GKE esegue l'upgrade dei cluster alla versione 1.32 e ignora i cluster che utilizzano già la versione 1.33.

La fase precedente ha qualificato più target di upgrade per la fase successiva

Una fase precedente di una sequenza potrebbe completare i rollout per più nuove versioni mentre una fase successiva è in pausa (ad esempio, a causa di un'esclusione di manutenzione) o sta ancora elaborando un upgrade precedente. In questo caso, quando la fase successiva diventa pronta ad accettare un nuovo upgrade, GKE esegue l'upgrade della fase all'ultima versione qualificata. Per gli upgrade del control plane, questa versione può essere al massimo una versione secondaria successiva alla versione del control plane dei cluster nella fase successiva. Per gli upgrade dei nodi, questa versione può essere uguale o precedente alla versione del control plane dei cluster nella fase successiva.

Ad esempio, questo scenario è pertinente se hai configurato esclusioni dalla manutenzione per impedire temporaneamente gli upgrade sui cluster di produzione. Se i tuoi cluster di pre-produzione non avevano le stesse esclusioni dalla manutenzione, questi cluster potrebbero essere aggiornati più volte, qualificandosi per diverse nuove versioni, ma le tue fasi di produzione non vengono aggiornate.

In attesa forzata dopo 30 giorni

Per garantire che una sequenza di implementazione completi l'upgrade dei cluster, GKE avvia il periodo di soaking 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.

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

La sequenza di implementazione funziona insieme ad altre funzionalità di upgrade di GKE:

• Periodi di manutenzione ed esclusioni: puoi comunque utilizzare i periodi di manutenzione e le esclusioni per controllare quando possono essere eseguiti gli upgrade nei tuoi cluster. 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 una fase. Se l'upgrade di un cluster non può essere completato entro 30 giorni a causa di periodi di manutenzione o esclusioni, la fase entrerà nella fase di test indipendentemente dal fatto che tutti i cluster abbiano terminato l'upgrade. L'implementazione del control plane e del pool di nodi può essere eseguita in parallelo all'interno di una determinata fase.

• Strategie di upgrade dei nodi: il sequenziamento dell'implementazione non influisce sulle strategie di upgrade dei nodi (ad esempio, gli upgrade blu/verde). Analogamente agli upgrade dei cluster che non prevedono una sequenza di implementazione, GKE utilizza gli upgrade di sovraccarico 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 upool di nodiol di grandi dimensioni. La situazione può anche essere aggravata da periodi di manutenzione non sufficientemente ampi per completare l'upgrade di un nodo.

• Canali di rilascio: ti consigliamo di registrare tutti i cluster in una sequenza di implementazione nello stesso canale di rilascio.

• Rilevamento dell'utilizzo del ritiro: il rilevamento dell'utilizzo del ritiro di GKE funziona ancora come previsto, mettendo potenzialmente in pausa gli upgrade sui cluster che utilizzano un'API ritirata.

• Upgrade manuali: l'upgrade manuale dei cluster nella prima fase di una sequenza non qualifica di per sé la versione né attiva un'implementazione per procedere. Il processo di implementazione automatica è guidato dai target di upgrade automatico ufficiali impostati per il canale di rilascio. Un upgrade manuale aggiorna i cluster, ma la sequenza inizia ad avanzare per quella versione solo dopo che diventa la destinazione designata per l'upgrade automatico.

Ricezione di più upgrade in una sequenza

Un canale di rilascio seleziona un target di upgrade per il cluster. Se una nuova versione diventa disponibile mentre gli upgrade a un target precedente sono ancora in corso, la prima fase può iniziare l'implementazione di una nuova versione anche quando le fasi successive ricevono ancora 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 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 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.
• Esegui spesso upgrade manuali che fanno sì che i cluster di un gruppo abbiano versioni di destinazione dell'upgrade automatico diverse.

Limitazioni

Quando esegui l'upgrade dei cluster utilizzando il sequenziamento del rollout con fasi personalizzate, si applicano le seguenti limitazioni:

• Non puoi utilizzare la console Google Cloud per creare o visualizzare sequenze di implementazione con fasi personalizzate.
• Quando una sequenza di implementazione fa riferimento a un parco risorse, devi includere l'intero parco risorse. Questo vincolo significa che se definisci una fase per scegliere come target solo un sottoinsieme di cluster di un parco risorse con un label-selector (ad esempio, per un deployment in più fasi), devi anche definire una fase "catch-all" successiva che includa tutti i cluster rimanenti dello stesso parco risorse. Questa fase catch-all ha come target lo stesso parco risorse, ma non include un label-selector, pertanto include automaticamente tutti i cluster che non sono stati selezionati dalle fasi precedenti della sequenza.
• Se modifichi una sequenza durante un rollout, in particolare le modifiche che interessano i cluster partecipanti, GKE annulla immediatamente tutti i rollout esistenti. Se modifichi solo il tempo di attesa di una sequenza, GKE non annulla l'implementazione.
• Non puoi accelerare manualmente un lancio attivo per una versione specifica. Quando modifica la durata di assorbimento nella definizione della sequenza di implementazione, la modifica aggiorna il tempo di assorbimento predefinito per tutte le implementazioni attuali e future che vengono create dopo la modifica.
• GKE esegue automaticamente l'upgrade dei cluster che hanno raggiunto la fine del supporto a una versione supportata e questo upgrade potrebbe non seguire la sequenza di implementazione definita.
• Una fase può fare riferimento a un massimo di una flotta. Non puoi avere più flotte in una singola fase.
• È possibile fare riferimento a una singola flotta solo in una sequenza di implementazione. Due sequenze di implementazione non possono fare riferimento alla stessa flotta.

Problemi noti

Questa sezione descrive i problemi noti relativi al sequenziamento del lancio con fasi personalizzate.

• Se una fase della sequenza di implementazione non contiene cluster, la fase viene ignorata, ma il periodo di prova definito per quella fase trascorre comunque prima che l'implementazione proceda alla fase successiva.

Passaggi successivi

• Sequenziare l'implementazione degli upgrade dei cluster con fasi personalizzate