Informazioni sulla sequenza di implementazione con fasi personalizzate

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 precedente di questa funzionalità, sequenza di implementazione basata sul parco progetti, che ha funzionalità più limitate e non è consigliata per i nuovi ambienti.

Questo documento presuppone che tu conosca quanto segue:

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

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 test 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 logicamente i cluster per il sequenziamento del rollout 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'uguaglianza dello spazio dei nomi a livello di parco risorse. Per saperne di più, consulta Abbonamenti semplici.

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 upgrade progressivi basati sul parco auto, ma consigliamo di utilizzare il sequenziamento del rollout con fasi personalizzate per i nuovi ambienti:

  • Sequenza di implementazione con fasi personalizzate (consigliata per i nuovi ambienti): questa versione è un'evoluzione del modello basato sul parco auto, che offre un controllo e una flessibilità più granulari, ma non supporta la console Cloud de Confiance . Con le fasi personalizzate, puoi definire fasi specifiche all'interno di un parco risorse utilizzando le etichette, il che lo 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. Inoltre, hai un maggiore controllo sulle implementazioni, ad esempio l'avvio di un'implementazione a una versione specifica, la scelta dei tipi di upgrade da implementare in una sequenza e la sospensione o l'annullamento delle implementazioni. Scegli questa opzione se crei una sequenza di implementazione per la prima volta.
  • Sequenza di implementazione basata sul parco auto: è l'unica versione di questa funzionalità utilizzabile con la console Cloud de Confiance , ma per il resto ha funzionalità più limitate e non è consigliata se stai creando una sequenza di implementazione per la prima volta.

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 rodaggio. 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 più 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 illustra come GKE esegue automaticamente l'upgrade dei cluster in una sequenza di implementazione che utilizza fasi personalizzate. Lo stage ha come target 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 GKE implementa una nuova versione, esegue l'upgrade dei cluster nel parco risorse per il test, seguito dai cluster nel parco risorse per la gestione temporanea. Poi, nel parco risorse 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) al termine della procedura perché questa fase non ha alcun selettore di etichette.

Durante il tempo di sospensione configurato tra le fasi, puoi verificare che i tuoi workload vengano eseguiti come previsto sui cluster di cui è stato eseguito l'upgrade. 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 attesa: 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 proceda all'ambiente successivo. Puoi configurare un tempo di attesa fino a 30 giorni per ogni fase della sequenza. Un periodo di permanenza più lungo in una fase di pre-produzione ti offre più tempo per la convalida.
  • RolloutSequence: questo oggetto è 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. Ogni RolloutSequence ha un Rollout per ogni nuova versione implementata.
  • Rollout: questo oggetto ti consente di osservare l'avanzamento dell'upgrade di una singola versione durante la sequenza. Puoi utilizzare Rollout per visualizzare lo stato dell'implementazione, monitorare l'avanzamento e verificare se e perché alcuni cluster non sono idonei per l'upgrade. Ogni Rollout è associato a un RolloutSequence specifico che rappresenta la sequenza di implementazione della versione.
  • Progetto host dedicato: ti consigliamo di utilizzare un progettoCloud de Confiance by S3NS 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 risorse RolloutSequence in un progetto host dedicato.

  • Fasi: una fase è un passaggio nella sequenza di implementazione. Ogni fase contiene un gruppo di cluster di cui viene eseguito l'upgrade 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 le implementazioni graduali, in cui viene eseguito l'upgrade di un piccolo sottoinsieme di cluster di produzione.

In che modo 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 aggiornati utilizzando questo processo, ma controlli anche l'ordine in cui vengono aggiornati i 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 avvia una nuova implementazione nella sequenza di implementazione. Un'implementazione viene avviata per impostazione predefinita quando GKE imposta un nuovo target di upgrade automatico per i cluster su una versione secondaria in un canale di rilascio specifico. Per il sequenziamento del rollout con fasi personalizzate, puoi anche attivare un nuovo rollout in una sequenza di rollout a una versione specifica che scegli.

  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 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 nel primo gruppo, GKE inizia il periodo di sospensione per gli upgrade dei nodi. GKE inizia il periodo di sospensione anche 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 a quella qualificata dal primo gruppo.

  5. GKE ripete questi passaggi dal secondo gruppo al terzo, finché i cluster in tutti i gruppi della sequenza di rollout non sono stati aggiornati alla nuova versione.

Durante l'upgrade dei cluster in ogni gruppo, 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 all'upgrade nell'ordine che hai definito e vengono sottoposti a soak test in ogni gruppo per il periodo di tempo che hai scelto. Per saperne di più sul controllo di questa procedura, consulta le seguenti risorse:

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

L'amministratore di una piattaforma presso una banca di comunità 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 in una regione con meno traffico, poi passare a una regione con più traffico e infine alla regione più critica. Per raggiungere questo obiettivo, 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. La fase finale 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 prova 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 sottoposti a 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.

Inoltre, l'amministratore può gestire un'implementazione tramite azioni come la sospensione di un'implementazione se rileva problemi o il completamento di una fase se è sicuro delle modifiche apportate in quella fase e pronto a procedere immediatamente.

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

Come GKE avvia l'implementazione di una nuova versione

Per impostazione predefinita, GKE crea una nuova implementazione quando imposta un nuovo target di upgrade automatico. La versione selezionata da GKE per l'implementazione dipende dalla versione secondaria e dal canale di rilascio dei cluster nella sequenza. Ad esempio, se i cluster eseguono la versione GKE 1.35 nel canale regolare e GKE imposta una destinazione di upgrade automatico su 1.35.5-gke.1000000, GKE crea un nuovo Rollout.

Tuttavia, puoi anche scegliere una versione che vuoi che GKE implementi.

Implementazione di una versione specifica

Puoi anche avviare un rollout a una versione specifica se, ad esempio, vuoi applicare rapidamente una patch a una vulnerabilità di sicurezza o risolvere un problema critico con i tuoi cluster GKE. Questa azione crea un oggetto Rollout, avviando un'implementazione nella sequenza di implementazione nello stesso modo in cui GKE imposta un target di upgrade automatico. Per implementare una nuova versione, vedi Implementare una versione specifica.

Se devi implementare una nuova versione in un cluster il più rapidamente possibile, puoi eseguire in alternativa aggiornamenti manuali dei cluster per i singoli cluster. Gli upgrade manuali del cluster vengono eseguiti a livello di cluster.

Scegliere i tipi di upgrade eseguiti da GKE in una sequenza di implementazione

Per impostazione predefinita, GKE implementa tutti i tipi di upgrade del cluster in una sequenza di implementazione, inclusi gli upgrade delle versioni delle patch e delle versioni secondarie del control plane e dei nodi.

Esistono quattro tipi principali di upgrade:

  • Upgrade della versione patch del control plane
  • Upgrade della versione patch dei nodi
  • Upgrade delle versioni secondarie del control plane
  • Upgrade delle versioni secondarie dei nodi

Puoi limitare l'ambito degli upgrade del cluster in una sequenza di implementazione in modo da eseguire solo tipi specifici di upgrade. Ad esempio, se vuoi che GKE esegua solo gli upgrade del control plane e non dei nodi, puoi specificarlo per la sequenza di implementazione.

Se limiti l'ambito degli upgrade del cluster per una sequenza di implementazione, GKE non eseguirà questo tipo di upgrade automatico per nessun cluster nella sequenza di implementazione, ad eccezione degli upgrade automatici obbligatori, se richiesti. Per saperne di più, consulta Implementazioni per gli upgrade automatici obbligatori. La limitazione dell'ambito degli upgrade del cluster non annulla i rollout in corso del tipo che limiti, ma impedisce solo a GKE di creare rollout futuri di quel tipo.

Poiché GKE non esegue l'upgrade dei nodi di un cluster a una versione successiva a quella del control plane, limitare l'ambito degli upgrade del control plane può limitare anche gli upgrade dei nodi.

Per limitare l'ambito degli upgrade automatici in una sequenza di implementazione, consulta Scegliere i tipi di upgrade eseguiti da GKE in una sequenza di implementazione.

La limitazione dell'ambito di una sequenza di implementazione funziona in modo simile alle esclusioni dalla manutenzione, ma le esclusioni dalla manutenzione vengono impostate per singoli cluster o node pool all'interno di un cluster.

Implementazioni per gli upgrade automatici obbligatori

Indipendentemente dal fatto che il cluster sia registrato in una sequenza di implementazione, GKE esegue upgrade automatici del cluster per sicurezza e compatibilità. Se i cluster nella sequenza di implementazione non hanno subito l'upgrade dei piani di controllo in 90 giorni o se i cluster eseguono una versione secondaria che ha raggiunto la fine del supporto, GKE crea un'implementazione obbligatoria per eseguire gli upgrade automatici. Questi rollout contribuiscono a garantire che il cluster rimanga efficiente, disponibile e sicuro. GKE crea implementazioni per questi scenari, indipendentemente dalle limitazioni all'ambito delle implementazioni, dalle esclusioni dalla manutenzione o da qualsiasi altro motivo di ritardo.

Non puoi mettere in pausa o annullare questi tipi di implementazioni. GKE esegue questi tipi di upgrade del cluster indipendentemente dalla registrazione alla sequenza di implementazione.

Per saperne di più su queste norme, consulta le sezioni seguenti:

Idoneità all'implementazione

Affinché una versione venga implementata tramite una sequenza che utilizza fasi personalizzate, i cluster devono essere idonei per una destinazione di upgrade dal loro 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 ogni 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 o ignorando un cluster in una sequenza di implementazione, per consentire l'avanzamento dell'implementazione. Se un cluster non è idoneo per alcuna implementazione, GKE non esegue automaticamente l'upgrade del cluster finché non è necessario creare implementazioni per gli upgrade automatici obbligatori, come descritto nella sezione precedente.

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 della 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, qualificando 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. Entrambi i seguenti metodi possono limitare GKE all'esecuzione di determinati tipi di upgrade:

    Tuttavia, nessuno di questi metodi che limitano l'ambito degli upgrade del cluster impedisce gli upgrade automatici obbligatori. 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 finestre di manutenzione o esclusioni, la fase di test verrà avviata indipendentemente dal fatto che tutti i cluster abbiano terminato l'upgrade.

  • Strategie di upgrade dei nodi: la sequenza di implementazione non influisce sulle strategie di upgrade dei nodi (ad esempio, gli upgrade blu/verde). Analogamente agli upgrade dei cluster che non hanno 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 un node pool di grandi dimensioni. La situazione può anche essere esacerbata 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 rollout 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.

  • Notifiche del cluster: GKE fornisce notifiche per la sequenza di implementazione, oltre ad altre notifiche del cluster disponibili. Per saperne di più, consulta Notifiche per il sequenziamento dell'implementazione.

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.

Notifiche per la sequenza di implementazione

GKE invia notifiche del cluster, che forniscono informazioni critiche sugli upgrade del cluster a livello di cluster. Inoltre, GKE fornisce notifiche sulle sequenze di implementazione con fasi personalizzate e sulle implementazioni che avvengono con queste sequenze. Ad esempio, GKE invia notifiche quando una fase di implementazione inizia, termina o viene bloccata. In alternativa, GKE invia una notifica se hai configurato in modo errato una sequenza di implementazione. Per saperne di più, consulta il documento Notifiche del cluster e le rispettive sezioni per RolloutEvent e RolloutSequenceEvent.

Gestire un'implementazione

Quando GKE implementa una nuova versione nei cluster nella sequenza di implementazione, puoi utilizzare le seguenti azioni per controllare il processo mentre valuti la risposta del cluster e dei carichi di lavoro alla modifica. Inoltre, puoi creare un nuovo lancio per lanciare una versione specifica.

Durante l'avanzamento degli upgrade, puoi controllarne lo stato. A seconda dell'avanzamento dell'upgrade, puoi utilizzare le azioni spiegate nelle sottosezioni seguenti.

Mettere in pausa un'implementazione

Puoi mettere in pausa un'implementazione in corso. Se, ad esempio, hai notato un potenziale problema con i tuoi cluster e la nuova versione in fase di implementazione, puoi mettere in pausa temporaneamente l'implementazione. GKE non avvierà nuove operazioni di upgrade a questa versione, consentendoti di esaminare eventuali problemi, se necessario. GKE non interromperà le operazioni di upgrade in corso, ma non ne avvierà di nuove, incluse quelle per le fasi successive.

Per mettere in pausa un lancio, vedi Mettere in pausa un lancio.

Dopo aver messo in pausa un'implementazione, puoi riprenderla o annullarla. Un'implementazione può essere sospesa per un massimo di 90 giorni. Dopo 90 giorni, GKE annulla l'implementazione.

La sospensione di un'implementazione non impedisce l'avvio delle implementazioni successive. Tuttavia, queste implementazioni non supereranno la fase di implementazione in pausa. Ad esempio, se GKE ha già implementato la versione 1.34.8-gke.1000000 nella prima e nella seconda fase e metti in pausa l'implementazione nella terza fase, GKE può avviare una nuova implementazione alla versione 1.35.5-gke.1163000 ed eseguire l'upgrade dei cluster nelle prime due fasi. Tuttavia, GKE non avvierà gli upgrade alla versione 1.35.5-gke.1163000 nella terza fase finché l'implementazione della versione 1.34.8-gke.1000000 non sarà completata nella terza fase o non verrà annullata.

Se sono in corso più implementazioni per una sequenza di implementazioni e vuoi metterle in pausa tutte, devi mettere in pausa ogni implementazione singolarmente. Se vuoi impedire a GKE di avviare implementazioni aggiuntive, puoi scegliere i tipi di upgrade che GKE esegue in una sequenza di implementazione.

Riprendere un'implementazione

Puoi riprendere un'implementazione in pausa che è stata sospesa per meno di 90 giorni, dopo aver esaminato eventuali problemi potenziali e quando gli aggiornamenti sono pronti per procedere. Puoi riprendere un'implementazione in pausa solo se un'altra implementazione dello stesso tipo (implementazione del control plane o dei nodi) non è in esecuzione contemporaneamente nella stessa fase. Puoi anche riprendere un rollout che è stato messo in pausa automaticamente da GKE per motivi tecnici o aziendali, anche se ti consigliamo di prestare attenzione prima di farlo.

Se riprendi l'implementazione, GKE avvia nuove operazioni di upgrade per continuare a implementare la nuova versione nelle fasi della sequenza di implementazione.

Per riprendere un'implementazione, vedi Riprendere un'implementazione.

Annullamento di un'implementazione

Puoi annullare un'implementazione, incluse quelle attive o in pausa. Quando annulli un'implementazione, GKE non crea automaticamente una nuova implementazione per la stessa versione. Tuttavia, l'annullamento di un rollout non impedisce a GKE di eseguire il rollout di versioni successive. Se vuoi impedire a GKE di implementare anche le versioni successive, annulla tutte le implementazioni in corso e limita l'ambito degli upgrade dei cluster nella sequenza di implementazione.

Per annullare un'implementazione, vedi Annullare un'implementazione.

Se devi implementare la stessa versione che è stata annullata, implementa una versione specifica.

Completare una fase di implementazione

Se ritieni che l'implementazione di una versione possa procedere alla fase successiva della sequenza di implementazione perché, ad esempio, hai completato i test in quella fase, puoi far avanzare manualmente l'implementazione completando la fase. Se completi la fase, i cluster per i quali GKE non ha ancora eseguito l'upgrade non verranno sottoposti a upgrade nell'ambito dell'implementazione. Se completi la fase, viene saltato anche il tempo di ammollo rimanente. Questa azione significa anche che non devi modificare il tempo di ammollo a livello di sequenza di implementazione.

Per completare una fase di implementazione, vedi Completare una fase di implementazione.

Gestire un'implementazione modificando la sequenza di implementazione

Puoi anche gestire un rollout eseguendo azioni che interessano l'intera sequenza di rollout. Tuttavia, prima di farlo, valuta la possibilità di intraprendere le azioni descritte nelle sezioni precedenti, ad esempio mettere in pausa un lancio. Alcune modifiche a una sequenza di implementazione possono causare l'annullamento delle implementazioni in corso, oltre a influire sul funzionamento delle implementazioni future nella sequenza. Se vuoi modificare un solo rollout, utilizza gli strumenti forniti per gestire un rollout, anziché modificare l'intera sequenza.

Tuttavia, se vuoi modificare il funzionamento di una sequenza di implementazione per tutte le implementazioni, non solo per l'implementazione di una nuova versione, consulta la sezione seguente, Gestire una sequenza di implementazione.

Controlla gli upgrade dei singoli cluster per gestire l'implementazione

Per gli upgrade dei singoli cluster, puoi utilizzare i seguenti strumenti per gestire gli upgrade:

  • 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 trovare un equilibrio tra velocità e tolleranza al rischio, a seconda dei carichi di lavoro in esecuzione su questi nodi.

Per saperne di più, consulta Come funziona il sequenziamento dell'implementazione con altre funzionalità di aggiornamento.

Gestire una sequenza di implementazione

Per gestire una sequenza di implementazione, puoi eseguire azioni di base come le seguenti:

  • Elenca le sequenze di implementazione
  • Descrivere una sequenza di implementazione

Inoltre, puoi eseguire azioni come modificare una sequenza di implementazione e ignorare un cluster in una sequenza di implementazione. Queste azioni sono descritte nelle sottosezioni seguenti.

Per scoprire di più sulla gestione dell'implementazione di una versione anziché dell'intera sequenza di implementazione, consulta la sezione precedente, Gestione di un'implementazione.

Ignorare un cluster in una sequenza di implementazione

Per impostazione predefinita, tutti i cluster che fanno parte di un parco risorse in una sequenza di implementazione vengono aggiornati nell'ambito della sequenza di implementazione. Puoi aggiungere cluster a fasi specifiche oppure eseguire l'upgrade contemporaneamente di tutti i cluster che si trovano in un parco risorse e non sono etichettati.

Tuttavia, se hai un cluster che non vuoi includere nella sequenza di implementazione, puoi etichettarlo in modo che GKE lo ignori durante l'implementazione di nuove versioni. Potrebbe essere necessario farlo, ad esempio, se hai bisogno di più tempo prima di eseguire l'upgrade di quel cluster specifico. Puoi ignorare uno o più cluster in una sequenza di implementazione.

Se ignori un cluster in una sequenza di implementazione, GKE non lo prenderà in considerazione durante l'implementazione di una nuova versione e non eseguirà upgrade automatici per il cluster, ad eccezione degli upgrade automatici obbligatori, inclusi gli upgrade automatici al termine del supporto e gli upgrade automatici per i control plane che non sono stati sottoposti ad upgrade da 90 giorni.

Per ignorare un cluster in una sequenza di implementazione, consulta Ignorare un cluster in una sequenza di implementazione.

Modifica di una sequenza di implementazione

Se vuoi modificare la modalità di implementazione in una sequenza di implementazione esistente, puoi modificare la sequenza in due modi:

  • Modifica una sequenza di implementazione modificando il file di configurazione YAML in cui hai definito la sequenza.
  • Modifica i cluster nella sequenza.

Se modifichi una sequenza di implementazione, si verifica quanto segue:

  • Se aggiungi una fase, rimuovi una fase, modifichi l'ordine delle fasi o modifichi una fase, ad esempio per cambiare l'ID progetto o i selettori di etichette di quella fase, in una sequenza di implementazione, GKE annulla tutte le implementazioni attive.
  • Se modifichi il tempo di attesa di una fase, GKE non annulla i rollout attivi.

Per modificare una sequenza di implementazione, consulta Modificare una sequenza di implementazione.

Se modifichi i cluster in una sequenza, si verifica quanto segue:

  • Se rimuovi un cluster da una sequenza di implementazione rimuovendolo da un parco risorse, le implementazioni attive continuano. GKE può eseguire automaticamente l'upgrade del cluster in base alle procedure tipiche per i cluster non registrati in una sequenza.
  • Se aggiungi un cluster a un parco risorse in una sequenza di implementazione, GKE eseguirà l'upgrade di questo cluster nell'ambito di qualsiasi implementazione attiva che non abbia ancora superato la fase in cui l'hai aggiunto. Tuttavia, se la fase è stata completata per l'implementazione, GKE non eseguirà l'upgrade del cluster in questa implementazione.

  • Se sposti un cluster in una fase diversa senza modificare la configurazione della sequenza di implementazione, si verifica quanto segue, a seconda che la fase in cui sposti il cluster sia stata completata:

    • Se sposti un cluster in una fase in cui il rollout è già stato completato, GKE non esegue l'upgrade del cluster in quel rollout.
    • Se sposti un cluster già aggiornato in un rollout in una fase successiva non completata, GKE ignora il cluster e non interrompe l'avanzamento del rollout.

Per modificare i cluster in una sequenza, consulta Registra un cluster su Cloud de Confiance by S3NS nel tuo parco risorse.

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 Cloud de Confiance 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 generica 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.
  • 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.
  • Non puoi eseguire l'upgrade dei cluster con sequenza di implementazione che utilizzano gli upgrade automatici delle patch accelerati.
  • Puoi creare una sequenza di implementazione con un massimo di 15 fasi.
  • Puoi includere fino a 250 cluster in un parco risorse. Per i cluster con appartenenze semplici, puoi richiedere un aumento della quota fino a 2000 cluster in un parco risorse. Per saperne di più, consulta Quote e limiti.
  • Puoi configurare un tempo di immersione massimo per sequenza fino a 90 giorni in tutte le fasi.

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 test definito per quella fase trascorre comunque prima che l'implementazione proceda alla fase successiva.

Passaggi successivi