Upgrade GKE prevedibili e sicuri con il Rollout Sequencing

Anche con un servizio completamente gestito come GKE, gli upgrade standard presentano diversi ostacoli operativi che possono mettere in difficoltà un team DevOps/Platform:

• Il rischio del "tutto in una volta": in assenza di sequencing, tutti i cluster di un Release Channel diventano idonei all'upgrade non appena una nuova versione viene impostata come predefinita. Il risultato è uno scenario in cui gli ambienti Dev e Prod vengono aggiornati nella stessa finestra temporale se condividono il release channel, senza margine per intercettare i bug negli ambienti più bassi prima che impattino i clienti.
• Controlli manuali come unico filtro: molti team ricorrono a finestre di manutenzione o esclusioni per bloccare manualmente gli upgrade in Produzione mentre testano in Sviluppo. Un approccio che impone un intervento umano costante, attività di tracciamento e un carico cognitivo elevato sul team SRE.
• Dipendenze e deprecazioni delle API: Kubernetes corre veloce. Ogni minor version (ad esempio dalla 1.33 alla 1.34) può deprecare specifiche versioni delle API. Se un upgrade interessa un cluster con una Helm chart o un operator non compatibili, i servizi rischiano di non avviarsi, generando downtime prolungati.
• Version drift: nel tentativo di muoversi con prudenza, i team aggiornano spesso i cluster manualmente, uno alla volta. Si crea così version drift, ovvero ambienti che girano su versioni patch leggermente diverse, rendendo impossibile garantire che un bug emerso in Produzione possa essere riprodotto in un ambiente più basso.

Il rollout sequencing affronta queste criticità portando struttura, prevedibilità e automazione nel processo di upgrade. Ecco perché si sta affermando come standard per la gestione enterprise di GKE:

• Ciclo di vita dell'infrastruttura dichiarativo: così come si usa Terraform per le risorse, il Rollout Sequencing consente di definire la policy di upgrade come codice. Lei definisce la relazione upstream/downstream tra i cluster e il control plane di Google si occupa dell'esecuzione.
• "Soak period" garantiti: è possibile imporre via codice un tempo di soak fino a 30 giorni. Ad esempio, può stabilire che una versione debba girare con successo nello Staging Fleet per 7 giorni senza errori prima che il Production Fleet diventi idoneo a riceverla.
• Promozione condizionale: si abilita una logica di Promotion. Una versione viene promossa allo stadio successivo solo se tutti i cluster dello stadio precedente sono stati aggiornati con successo. È una barriera di sicurezza a tutela degli ambienti più critici.
• Sincronizzazione su scala di fleet: il sistema poggia sul concetto di fleet, ovvero raggruppamenti logici di cluster GKE. Invece di configurare 100 cluster a uno a uno, si configurano una o più rollout sequence che governano l'intera struttura organizzativa.

Google propone due approcci per progettare la pipeline di upgrade dei cluster, in funzione della struttura del team e della tolleranza al rischio.

Strategia 1: Sequenza basata su Fleet

Questa strategia si fonda sul concetto di promozione a livello di ambiente. I cluster vengono organizzati in Fleet in base all'ambiente (ad esempio dev-fleet, test-fleet, prod-fleet). Tutti i cluster di tutti i gruppi che compongono una rollout sequence devono trovarsi sullo stesso release channel.

• Come funziona: si definisce una sequenza composta da fleet e si imposta il tempo di soak tra un gruppo e l'altro. Quando GKE seleziona una nuova versione per gli upgrade automatici nel release channel, i gruppi di cluster vengono aggiornati nell'ordine definito: in questo modo è possibile verificare che i workloads si comportino come previsto con la nuova versione prima che gli upgrade partano sui cluster del gruppo successivo nella catena.

Una rollout sequence basata su fleet

• Ideale per: organizzazioni con raggruppamenti di cluster ben definiti e organizzati per ambiente.

Strategia 2: Rollout Sequencing con stage personalizzati (Preview)

Per le organizzazioni di maggiori dimensioni o con esigenze di Canary, gli stage personalizzati offrono un approccio più chirurgico. Invece di muovere un intero fleet in blocco, si usano Cluster Selectors basati su label.

• Come funziona: è possibile creare un Canary Stage all'interno del Production Fleet. Si potrebbe ad esempio etichettare il 5% dei cluster di produzione come canary: true. La rollout sequence aggiornerà prima quei cluster e, se rimangono stabili, proseguirà con i cluster degli altri stage nello stesso production fleet.

Una rollout sequence con stage personalizzati

• Ideale per: footprint globali di grandi dimensioni in cui anche la Produzione va aggiornata a ondate per scongiurare interruzioni di servizio.

Il rollout sequencing è una delle funzionalità che permettono di governare la fase di upgrade nel ciclo di vita del cluster.

Quando aggiorna i cluster con il rollout sequencing, GKE rispetta le finestre di manutenzione e le esclusioni di manutenzione configurate. GKE avvia l'upgrade di un cluster solo all'interno della relativa finestra di manutenzione. Un'esclusione di manutenzione può essere usata per impedire temporaneamente l'aggiornamento di un cluster. Se GKE non riesce ad aggiornare un cluster a causa di una finestra o di un'esclusione di manutenzione, ciò può impedire il completamento degli upgrade dei cluster all'interno del gruppo.

GKE mette inoltre in pausa gli upgrade automatici dei cluster di un gruppo in una rollout sequence quando rileva l'utilizzo di determinate API e funzionalità deprecate.