Informazioni sulla sequenza di implementazione con fasi personalizzate

Autopilot Standard

Rollout sequencing with custom stages

• Sequenza di implementazione con fasi personalizzate
• Sequenza di implementazione basata sul parco risorse

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

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
• Soak testing

Per configurare una sequenza di implementazione, consulta Sequenzia l'implementazione degli upgrade dei cluster con fasi personalizzate.

Panoramica

La sequenza di implementazione di GKE consente di definire una sequenza specifica e ordinata per gli upgrade dei cluster in diversi ambienti, ad esempio eseguendo prima l'upgrade dei cluster nell'ambiente di sviluppo, poi nell'ambiente di test e infine in quello di produzione. Questa strategia progressiva offre un periodo di prova 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 parchi risorse, ovvero raggruppamenti logici di cluster GKE mappati a un ambiente (ad esempio, test). Per utilizzare questa funzionalità, devi definire una sequenza composta da parchi risorse e impostare il tempo di soak tra ogni gruppo. Quando GKE seleziona una nuova versione, i cluster vengono aggiornati nell'ordine definito, consentendoti di convalidare i workload prima che venga eseguito il deployment completo della versione nel tuo ambiente di produzione.

I parchi risorse supportano le appartenenze leggere, che consentono di raggruppare i cluster logicamente per la sequenza di implementazione senza abilitare tutte le configurazioni e le funzionalità a livello di parco risorse. L'appartenenza leggera è una buona scelta se vuoi utilizzare la sequenza di implementazione senza alcune delle altre implicazioni della gestione completa del parco risorse, come l'uguaglianza degli spazi dei nomi a livello di parco risorse. Per saperne di più, consulta Iscrizioni leggere.

Scegli una strategia di sequenza di implementazione

GKE offre due versioni di sequenziamento dell'implementazione. Entrambe le versioni si basano sugli stessi principi fondamentali di upgrade progressivi basati sul parco risorse, ma ti consigliamo di utilizzare la sequenza di implementazione 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 risorse e offre maggiore controllo e flessibilità granulari, ma non dispone di un supporto completo della console Google Cloud . 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 il deployment 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 puoi avviarne una per una versione specifica, scegliere i tipi di upgrade da implementare in una sequenza e mettere in pausa o annullare le implementazioni. Scegli questa opzione se stai creando una sequenza di implementazione per la prima volta.
• Sequenza di implementazione basata sul parco risorse: questa versione della funzionalità offre un supporto più completo nella console Google Cloud , 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 la sequenza di implementazione 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 soak. 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 le implementazioni in fasi.
• Ottieni un maggiore controllo e una maggiore osservabilità tramite i nuovi oggetti API RolloutSequence e Rollout.

Questo metodo offre la massima flessibilità e un 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. La fase ha come target i cluster con un label-selector denominato canary nel parco risorse prod:

Figura: una sequenza di implementazione con fasi personalizzate

Quando GKE implementa una nuova versione, esegue prima l'upgrade dei cluster nel parco risorse di test, poi di quelli nel parco risorse di gestione temporanea. Poi, nel parco risorse di produzione, GKE dà la priorità ai cluster che corrispondono a label-selector. Poiché prod-cluster-1 è etichettato con canary: true, GKE esegue l'upgrade di questo cluster successivamente. 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 un selettore di etichette.

Durante il tempo di soak 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 nel parco risorse di produzione, ma puoi aggiungere più fasi a qualsiasi parco risorse o utilizzare un solo parco risorse con più fasi.

Concetti fondamentali

• Tempo di soak: un periodo di attesa configurabile che si verifica dopo l'upgrade di tutti i cluster di una fase. Questo tempo di soak ti consente di convalidare la nuova versione in un ambiente e di rilevare potenziali problemi prima che l'upgrade passi all'ambiente successivo. Puoi configurare un tempo di soak fino a 30 giorni per ogni fase della sequenza. Un tempo di soak 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 stati 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 di un singolo upgrade di versione tramite la tua 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 in cui viene implementata la versione.
• Progetto host dedicato: ti consigliamo di utilizzare un progettoGoogle Cloud dedicato per ospitare gli oggetti RolloutSequence. L'inserimento della sequenza in un progetto dedicato fornisce un punto di controllo neutrale e centrale per le sequenze di implementazione, che è 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 di cui viene eseguito l'upgrade contemporaneamente.
• Parchi risorse: i parchi risorse sono il modo principale per raggruppare i cluster. Una fase di una sequenza di implementazione può fare riferimento a uno o più parchi risorse. Una singola sequenza di implementazione può includere parchi risorse ospitati in più organizzazioniGoogle Cloud .
• 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 di adottare strategie come i rollout in fasi, in cui viene eseguito prima 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, viene eseguito prima l'upgrade del control plane, poi quello dei nodi. In una sequenza di implementazione, l'upgrade dei cluster viene comunque eseguito utilizzando questo processo, ma puoi anche controllare l'ordine in cui viene eseguito l'upgrade dei gruppi (parchi risorse) di cluster. Specifichi anche un tempo di soak che definisce per quanto tempo GKE mette in pausa gli upgrade prima di passare da un gruppo al gruppo successivo.

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

1. GKE avvia una nuova implementazione nella sequenza di implementazione. Per impostazione predefinita, un'implementazione viene avviata quando GKE imposta un nuovo target di upgrade automatico per i cluster su una versione secondaria in un canale di rilascio specifico. Per la sequenza di implementazione con fasi personalizzate, in alternativa puoi attivare una nuova implementazione in una sequenza di implementazione per una versione specifica che scegli.

2. GKE inizia l'upgrade dei control plane dei cluster alla nuova versione nel primo gruppo di cluster. Dopo aver eseguito l'upgrade del control plane di un cluster, GKE 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 soaking per gli upgrade del control plane. GKE inizia il periodo di soak anche se sono trascorsi più di 30 giorni dall'inizio degli upgrade del control plane.

   2. Al termine del periodo di soak 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 quanto segue:

      • In alcuni casi, GKE potrebbe eseguire l'upgrade dei control plane dei cluster del primo gruppo più volte prima di eseguire l'upgrade dei control plane dei cluster del secondo gruppo. In questo caso, GKE sceglie l'ultima versione che ha anche i seguenti attributi:
        • La versione è idonea per il 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 del secondo gruppo che hanno una versione successiva a quella qualificata dal primo gruppo.

4. In parallelo 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 avvia il periodo di soak per gli upgrade dei nodi. GKE inizia il periodo di soak anche se sono trascorsi più di 30 giorni dall'inizio degli upgrade dei nodi.
   2. Al termine del periodo di soaking per gli upgrade dei nodi del primo gruppo, GKE inizia l'upgrade dei nodi del secondo gruppo alla nuova versione. Tuttavia, tieni presente quanto segue:
      • 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. In questo caso, GKE sceglie l'ultima versione che ha anche i seguenti attributi:
        • La versione è idonea per il 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 del secondo gruppo che hanno una versione successiva a quella idonea per il primo gruppo.

5. GKE ripete questi passaggi dal secondo al terzo gruppo, finché non viene eseguito l'upgrade alla nuova versione dei cluster in tutti i gruppi della sequenza di implementazione.

Mentre i cluster vengono aggiornati in ogni gruppo, durante il tempo di soak, verifica che i tuoi workload con 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 esistono discrepanze di versione tra i cluster nei gruppi della sequenza. Per saperne di più, consulta Idoneità all'implementazione.

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

Come controllare gli upgrade in una sequenza di implementazione

Con gli upgrade dei cluster in una sequenza di implementazione, viene eseguito l'upgrade dei gruppi di cluster nell'ordine che hai definito e vengono sottoposti a soak in ogni gruppo per il periodo di tempo che hai scelto. Per saperne di più sul controllo di questo processo, consulta le seguenti risorse:

• Per scoprire come gestire l'implementazione di una versione specifica, consulta Gestione di un'implementazione.
• Per scoprire come gestire la sequenza di implementazione per tutte le implementazioni, consulta Gestione di una sequenza di implementazione.

Esempio: una banca locale implementa gradualmente le modifiche dal test alla produzione

Un amministratore della piattaforma di una banca locale gestisce tre ambienti di deployment principali: test, gestione temporanea e produzione. I cluster di produzione sono distribuiti in più regioni, con diversi livelli di criticità. Per gestire gli upgrade in modo efficace, l'amministratore raggruppa i cluster di ogni ambiente in parchi risorse. Come richiesto per la sequenza di implementazione, 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 attentamente prima di raggiungere l'ambiente di produzione critico della banca. Inoltre, vuole eseguire l'upgrade progressivo dei cluster prima in una regione con traffico ridotto, poi passare a una regione con traffico più elevato e infine alla regione più critica. Per farlo, utilizza la sequenza di implementazione con fasi personalizzate per definire una strategia di upgrade progressivo che include l'etichettatura dei cluster di produzione in base alla regione. Questo approccio consente di convalidare una nuova versione su un piccolo sottoinsieme di 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 di 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.

In seguito, in un progetto host dedicato utilizzato per la gestione delle configurazioni CI/CD, definiscono un oggetto RolloutSequence. Questa nuova sequenza prevede cinque fasi distinte:

1. Test: questa fase include tutti i cluster nel parco risorse testing. L'amministratore imposta un tempo di soak di tre giorni per consentire una convalida approfondita.
2. Staging: questa fase include tutti i cluster del parco risorse staging, con un tempo di soak di tre giorni.
3. Produzione nella regione us-west1: questa fase ha come target il parco risorse 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 su un piccolo sottoinsieme di cluster di produzione con un tempo di soak 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 soak 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 in modo significativo 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 gestione temporanea molto più velocemente del previsto. L'amministratore osserva che la nuova versione è stabile e decide che il tempo di soak di tre giorni dopo l'upgrade del parco risorse di gestione temporanea è inutilmente lungo per questo tipo di aggiornamento di routine.

Per accelerare questa implementazione, l'amministratore modifica la definizione di RolloutSequence e riduce la durata del periodo di attesa per la fase us-west1 del parco risorse di produzione. Poiché questa modifica alla definizione di RolloutSequence aggiorna il tempo di soak predefinito per tutti i rollout attuali e futuri, l'amministratore prende nota di ripristinare il tempo di soak al periodo originale di tre giorni dopo il completamento di questo specifico rollout della patch. Questo approccio consente di garantire che il tempo di soak standard e più prudente sia attivo per i futuri upgrade 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 viene 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 apertura.
• L'amministratore utilizza anche le esclusioni dalla manutenzione per impedire temporaneamente l'upgrade dei cluster se rileva problemi con i workload del cluster.

Inoltre, l'amministratore può gestire un'implementazione tramite azioni come la messa in pausa di un'implementazione se rileva problemi o il completamento di una fase se ritiene che le modifiche apportate in quella fase siano corrette ed è pronto a procedere immediatamente.

L'amministratore utilizza una combinazione di upgrade surge e upgrade blu/verde per i nodi, bilanciando velocità e tolleranza al rischio a seconda dei workload in esecuzione su questi nodi.

In che modo 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 tuoi cluster eseguono GKE versione 1.35 nel canale regolare e GKE imposta un target 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'implementazione per 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, consulta Implementa una versione specifica.

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

Scelta dei tipi di upgrade eseguiti da GKE in una sequenza di implementazione

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

Esistono quattro tipi principali di upgrade:

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

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

Se limiti l'ambito degli upgrade dei cluster per una sequenza di implementazione, GKE non eseguirà questo tipo di upgrade automatico per i 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ò anche limitare gli upgrade dei nodi.

Per limitare l'ambito degli upgrade automatici in una sequenza di implementazione, consulta Scegli 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 queste ultime vengono impostate per singoli cluster o pool di nodi all'interno di un cluster.

Implementazioni per gli upgrade automatici obbligatori

Indipendentemente dal fatto che il tuo cluster sia registrato in una sequenza di implementazione, GKE esegue upgrade automatici dei cluster per motivi di sicurezza e compatibilità. Se i cluster nella sequenza di implementazione non hanno subito l'upgrade dei control plane entro 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 performante, disponibile e sicuro. GKE crea implementazioni per questi scenari, indipendentemente dalle limitazioni sull'ambito delle implementazioni, dalle esclusioni di 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 dei cluster indipendentemente dalla registrazione alla sequenza di implementazione.

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

• Upgrade automatici alla fine del supporto
• Policy di 90 giorni per le patch del control plane

Idoneità all'implementazione

Affinché una versione possa essere implementata tramite una sequenza che utilizza fasi personalizzate, i cluster devono essere idonei per un target di upgrade dal relativo canale di rilascio. Quando è 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 distribuiti tra i canali Stabile e Regolare, GKE sceglie la versione del canale Stabile.

Rollout avanza quindi attraverso le fasi definite in RolloutSequence. All'interno di una determinata fase, l'implementazione del control plane e l'implementazione del pool di nodi possono essere eseguite in parallelo. Una regola fondamentale che regola questa progressione è che, mentre una fase si trova in uno stato SOAKING con una determinata versione, non è idonea per iniziare una nuova Rollout per una versione più recente. Questa pratica contribuisce a garantire che una versione sia completamente convalidata 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 all'implementazione di procedere. Se un cluster non è idoneo per i rollout, GKE non eseguirà l'upgrade automatico del cluster finché non dovrà creare rollout per gli upgrade automatici obbligatori, come descritto nella sezione precedente.

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

Se una fase della sequenza contiene cluster che eseguono una versione successiva alla versione target di un'implementazione, GKE esegue l'upgrade dei cluster idonei per la versione target e ignora i cluster che sono già in 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'implementazione per una fase è 1.32 e quella fase ha cluster che eseguono sia la versione 1.31 sia la versione 1.33, GKE esegue l'upgrade dei cluster dalla versione 1.31 alla versione 1.32 e ignora i cluster che sono già alla versione 1.33.

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

Una fase precedente di una sequenza potrebbe completare le implementazioni per più nuove versioni mentre una fase successiva è in pausa (ad esempio, a causa di un'esclusione dalla manutenzione) o sta ancora elaborando un upgrade precedente. In questo caso, quando la fase successiva diventa pronta per accettare un nuovo upgrade, GKE esegue l'upgrade della fase all'ultima versione idonea. 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, ma non successiva, 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, potrebbero essere aggiornati più volte, qualificando diverse nuove versioni, ma le 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 di tutti i cluster rimanenti nel gruppo possono comunque continuare durante il periodo di soaking.

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 o meno gli upgrade nei tuoi cluster. GKE avvia un upgrade del cluster solo durante il periodo di manutenzione del cluster. Puoi utilizzare un'esclusione dalla manutenzione per impedire temporaneamente l'upgrade di un cluster. Entrambi i seguenti metodi possono limitare GKE all'esecuzione di determinati tipi di upgrade:

  • A livello di cluster o node pool: esclusioni dalla manutenzione
  • Livello della sequenza di implementazione: scegli i tipi di upgrade che GKE esegue in una sequenza di implementazione

  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 un upgrade del cluster non può essere completato entro 30 giorni a causa di periodi di manutenzione o esclusioni, la fase entrerà nella fase di soak indipendentemente dal fatto che l'upgrade di tutti i cluster sia stato completato.

• Strategie di upgrade dei nodi: la sequenza di implementazione non influisce sulle strategie di upgrade dei nodi configurate (ad esempio, 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 l'upgrade di tutti i cluster sia stato completato. 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, soprattutto se si tratta di un node pool di grandi dimensioni. La situazione può anche essere aggravata da periodi di manutenzione non sufficientemente ampi per il completamento di un upgrade dei nodi.

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

• Rilevamento dell'utilizzo di funzionalità deprecate: il rilevamento dell'utilizzo di funzionalità deprecate di GKE continua a funzionare come previsto, mettendo potenzialmente in pausa gli upgrade sui cluster che utilizzano un'API deprecata.

• Upgrade manuali: l'upgrade manuale dei cluster nella prima fase di una sequenza non qualifica di per sé la versione né attiva l'avanzamento di un'implementazione. 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 il target di upgrade automatico designato.

• 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 la sequenza di 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 sono ancora in corso gli upgrade a un target precedente, la prima fase può iniziare l'implementazione di una nuova versione anche se 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 per la 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 target di upgrade automatico diverse.

Notifiche per la sequenza di implementazione

GKE invia notifiche sui cluster, che forniscono informazioni critiche sugli upgrade dei cluster a livello di cluster. Inoltre, GKE fornisce notifiche sulle sequenze di implementazione con fasi personalizzate e sulle implementazioni che avvengono con queste sequenze di implementazione. Ad esempio, GKE invia notifiche quando una fase di implementazione inizia, viene completata 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.

Gestione di un'implementazione

Quando GKE implementa una nuova versione nei cluster della sequenza di implementazione, puoi utilizzare le seguenti azioni per esercitare il controllo sul processo mentre valuti in che modo il cluster e i workload rispondono alla modifica. Inoltre, puoi creare una nuova implementazione per implementare una versione specifica.

Mentre gli upgrade sono in corso, puoi controllarne lo stato. In base all'avanzamento dell'upgrade, puoi utilizzare le azioni descritte nelle sottosezioni seguenti.

Metti 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'implementazione, consulta Metti in pausa un'implementazione.

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

La messa in pausa di un'implementazione non impedisce l'avvio di implementazioni successive. Tuttavia, queste implementazioni non supereranno la fase di implementazione in pausa. Ad esempio, se GKE ha già implementato 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 implementazione e vuoi metterle in pausa tutte, devi mettere in pausa ogni implementazione singolarmente. Se vuoi impedire a GKE di avviare ulteriori implementazioni, puoi scegliere i tipi di upgrade eseguiti da GKE in una sequenza di implementazione.

Ripresa di un'implementazione

Puoi riprendere un'implementazione messa in pausa da meno di 90 giorni dopo aver esaminato eventuali potenziali problemi e quando è tutto pronto per procedere con gli upgrade. 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'implementazione che è stata messa 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 l'implementazione della nuova versione nelle fasi della sequenza di implementazione.

Per riprendere un'implementazione, consulta Riprendi un'implementazione.

Annullamento di un'implementazione

Puoi annullare un'implementazione, incluse quelle attive o che sono state messe in pausa. Quando annulli un'implementazione, GKE non ne crea automaticamente una nuova per la stessa versione. Tuttavia, l'annullamento di un'implementazione non impedisce a GKE di implementare 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, consulta Annulla un'implementazione.

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

Completamento di una fase di implementazione

Se hai la certezza che l'implementazione di una versione possa procedere alla fase successiva della sequenza di implementazione, ad esempio perché hai completato i test in quella fase, puoi far avanzare manualmente l'implementazione completando la fase. Se completi la fase, i cluster di cui GKE non ha ancora eseguito l'upgrade non verranno aggiornati nell'ambito di questa implementazione. Il completamento della fase comporta anche il salto del tempo di soak rimanente. Questa azione significa anche che non devi modificare il tempo di soak a livello di sequenza di implementazione.

Per completare una fase di implementazione, consulta Completa una fase di implementazione.

Gestione di un'implementazione modificando la sequenza di implementazione

Puoi anche gestire un'implementazione eseguendo azioni che influiscono sull'intera sequenza di implementazione. Tuttavia, prima di farlo, valuta la possibilità di intraprendere le azioni descritte nelle sezioni precedenti, ad esempio mettere in pausa un'implementazione. 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 una sola implementazione, utilizza gli strumenti forniti per gestire una singola implementazione, 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, Gestione di 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 dei pool di nodi.
• Utilizza i periodi di manutenzione e le esclusioni per decidere quando un cluster può essere sottoposto a upgrade e quando no.
• Configura le strategie di upgrade dei nodi per trovare un equilibrio tra velocità e tolleranza al rischio, a seconda dei workload in esecuzione su questi nodi.

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

Gestione di una sequenza di implementazione

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

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

Inoltre, puoi eseguire azioni come la modifica di una sequenza di implementazione e l'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 tutti i cluster di un parco risorse che non sono etichettati verranno sottoposti ad upgrade insieme.

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. Potresti doverlo fare, 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à gli 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 per i quali non è stato eseguito l'upgrade per 90 giorni.

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

Modifica di una sequenza di implementazione

Se vuoi modificare il modo in cui procedono le implementazioni in una sequenza di implementazione esistente, puoi modificare la sequenza in uno dei seguenti 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, ne rimuovi una, ne modifichi l'ordine o ne modifichi una, 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 soak di una fase, GKE non annulla i rollout attivi.

Per modificare una sequenza di implementazione, consulta Modifica 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 eventuali implementazioni attive che non hanno ancora superato la fase in cui lo hai aggiunto. Tuttavia, se la fase è stata completata per l'implementazione, GKE non eseguirà l'upgrade del cluster in quell'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 o meno:

  • Se sposti un cluster in una fase che ha già completato l'implementazione, GKE non esegue l'upgrade del cluster in quell'implementazione.
  • Se sposti un cluster di cui è già stato eseguito l'upgrade in un'implementazione in una fase successiva non completata, GKE ignora il cluster e non interrompe l'avanzamento dell'implementazione.

Per modificare i cluster in una sequenza, consulta Registra un cluster su Google Cloud nel tuo parco risorse.

Limitazioni

Quando esegui l'upgrade dei cluster utilizzando la sequenza di implementazione con fasi personalizzate, si applicano le seguenti limitazioni:

• Non puoi utilizzare la console Google Cloud per creare o modificare sequenze di implementazione con fasi personalizzate. Tuttavia, puoi utilizzare la console per monitorare un'implementazione (anteprima).
• 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 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'implementazione, in particolare modifiche che interessano i cluster partecipanti, GKE annulla immediatamente tutte le implementazioni esistenti. Se modifichi solo il tempo di soak di una sequenza, GKE non annulla l'implementazione.
• Una fase può fare riferimento a un massimo di un parco risorse. Non puoi avere più parchi risorse in una singola fase.
• Un singolo parco risorse può essere referenziato in una sola sequenza di implementazione. Due sequenze di implementazione non possono fare riferimento allo stesso parco risorse.
• 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 membership leggere, 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 soak massimo per sequenza fino a 90 giorni in tutte le fasi.

Problemi noti

Questa sezione descrive i problemi noti relativi alla sequenza di implementazione con fasi personalizzate.

• Se una fase della sequenza di implementazione non contiene cluster, viene saltata, ma il tempo di soak definito per quella fase trascorre comunque prima che l'implementazione passi alla fase successiva.

Passaggi successivi

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