Google Cloud ha annunciato che il suo servizio GKE offre ora aggiornamenti del piano di controllo in due fasi (two-step control-plane upgrades) generalmente disponibili, consentendo ai clienti di separare l'aggiornamento del binario software dalla migrazione del formato dei dati e di mantenere aperta una finestra di rollback durante i cambiamenti di versione minore.

Perché GKE aveva bisogno di un percorso più sicuro

Aggiornare un piano di controllo Kubernetes da una versione minore alla successiva ha sempre comportato dei rischi. Il passaggio dalla versione 1.33 alla 1.34 non sostituisce solo i binari, ma riscrive anche le strutture dati sottostanti. Se la nuova versione contiene un bug, il cluster non può essere semplicemente ripristinato; gli amministratori devono ripristinare vecchi snapshot del database o ricostruire l'intero cluster, un processo lungo e soggetto a errori.

Come funziona l'aggiornamento in due fasi

Il nuovo flusso suddivide l'aggiornamento in due fasi distinte:

  • Fase 1 – Aggiornamento binario (modalità emulata). GKE sostituisce i binari del piano di controllo con la versione di destinazione preservando il vecchio formato dei dati. Poiché non vengono scritti nuovi dati, il cluster rimane protetto per il rollback durante questa fase.
  • Fase 2 – Finalizzazione. Dopo un periodo di attesa configurabile, GKE converte i dati memorizzati nel nuovo formato. Una volta terminata questa conversione, un rollback richiederebbe lo stesso sforzo di ripristino degli snapshot che il processo in due fasi è stato progettato per evitare.

La separazione crea una "finestra di osservazione" (soak window) in cui gli operatori possono monitorare i binari aggiornati in produzione senza impegnarsi in una migrazione dei dati irreversibile.

La finestra di osservazione in pratica

GKE monitora automaticamente le metriche di salute principali durante il periodo di osservazione: latenza API, tassi di errore e salute dei pod. Se il servizio rileva anomalie, interrompe il rollout, lasciando il cluster nello stato "solo binari" in cui il rollback è ancora possibile. Google cita un tasso di successo del 99,999% per gli aggiornamenti che seguono questo schema.

Per i cluster che utilizzano la funzione di auto-aggiornamento di GKE, la piattaforma orchestra l'intera sequenza in due fasi senza intervento manuale. Gli utenti che preferiscono il controllo totale possono invocare il processo tramite Cloud CLI o Terraform.

Eseguire un aggiornamento manuale in due fasi

Un tipico aggiornamento manuale con una finestra di sicurezza di 48 ore è il seguente:

gcloud beta container clusters upgrade my-cluster \
  --location=us-central1 \
  --cluster-version=1.34.1-gke.1829001 \
  --control-plane-soak-duration=48h \
  --master

Per ispezionare lo stato attuale:

gcloud container clusters describe my-cluster \
  --location=us-central1 \
  --format="yaml(rollbackSafeUpgradeStatus)"

Se emerge un difetto durante la fase di osservazione, l'amministratore può emettere un comando di rollback e tornare alla versione precedente senza perdita di dati. Quando il cluster si dimostra stabile, l'aggiornamento può essere completato anticipatamente con il comando complete-control-plane-upgrade.

Limiti e requisiti

  • La funzione si applica ai cluster GKE con versione 1.33 o successiva.
  • È possibile aggiornare una sola versione minore alla volta; il salto di versioni non è supportato.
  • Sia i cluster Autopilot che quelli regionali rimangono disponibili durante l'intero processo in due fasi.

Potenziali svantaggi

Separare gli aggiornamenti dei binari da quelli dei dati aggiunge un passaggio extra alla cronologia dell'aggiornamento, il che potrebbe estendere la finestra temporale complessiva per le organizzazioni che necessitano di cambiamenti di versione rapidi. Il periodo di osservazione si affida inoltre ai controlli di salute automatizzati; i team che gestiscono carichi di lavoro altamente personalizzati potrebbero dover integrare il monitoraggio di GKE con i propri strumenti di osservabilità per rilevare regressioni in casi limite.

Cosa aspettarsi in futuro

Google non ha rivelato una roadmap per estendere il modello in due fasi agli aggiornamenti di versione maggiore, che in molti casi richiedono ancora la ricreazione completa del cluster. Gli osservatori rimarranno in attesa di annunci riguardanti simili reti di sicurezza per gli aggiornamenti dei node-pool e per qualsiasi integrazione con pipeline CI/CD di terze parti che possa automatizzare i controlli durante la finestra di osservazione.

In sintesi: Disaccoppiando gli aggiornamenti dei binari dalle migrazioni dei dati, GKE offre agli ingegneri di piattaforma una finestra di rollback pratica per i cambiamenti di versione minore, riducendo il costo operativo della manutenzione del cluster e mantenendo al minimo i tempi di inattività.