Best practice per l'upgrade dei cluster

Questa pagina fornisce linee guida per mantenere sempre aggiornato il tuo cluster Google Kubernetes Engine (GKE) e suggerimenti per creare una strategia di upgrade che si adatti alle tue esigenze e aumenti la disponibilità e l'affidabilità dei tuoi ambienti. Puoi utilizzare queste informazioni per mantenere i cluster aggiornati per stabilità e sicurezza con interruzioni minime dei carichi di lavoro.

In alternativa, per gestire gli upgrade automatici dei cluster negli ambienti di produzione organizzati in parchi risorse, consulta Informazioni sugli upgrade dei cluster con la sequenza di implementazione.

Configurazione di più ambienti

Nell'ambito del tuo flusso di lavoro per la distribuzione di aggiornamenti software, ti consigliamo di utilizzare più ambienti. La presenza di più ambienti consente di ridurre al minimo i rischi e i tempi di inattività indesiderati testando gli aggiornamenti del software e dell'infrastruttura separatamente dall'ambiente di produzione. Come minimo, dovresti avere un ambiente di produzione e un ambiente di pre-produzione o test.

Considera i seguenti ambienti consigliati:

Ambiente Descrizione
Produzione Utilizzato per gestire il traffico in tempo reale agli utenti finali per applicazioni aziendali mission critical.
Gestione temporanea Utilizzato per garantire che tutte le nuove modifiche sottoposte a deployment dagli ambienti precedenti funzionino come previsto prima del deployment delle modifiche in produzione.
Test Utilizzato per benchmark delle prestazioni, test e carichi di lavoro di QA rispetto alla release di GKE che utilizzerai in produzione. In questo ambiente, puoi testare l'upgrade del piano di controllo e dei nodi prima di farlo in produzione.
Sviluppo Utilizzato per lo sviluppo attivo che si basa sulla stessa versione in esecuzione in produzione. In questo ambiente, puoi creare correzioni e modifiche incrementali di cui eseguire il deployment in produzione.
Canary Utilizzato come ambiente di sviluppo secondario per testare le ultime release di Kubernetes, funzionalità e API GKE per ottenere un time to market migliore una volta che queste release vengono promosse e diventano predefinite.

Registra i cluster nei canali di rilascio

Kubernetes spesso rilascia aggiornamenti per fornire aggiornamenti di sicurezza, risolvere problemi noti e introdurre nuove funzionalità. I canali di rilascio di GKE offrono la possibilità di bilanciare tra stabilità e set di funzionalità della versione di cui è stato eseguito il deployment nel cluster. Quando registri un nuovo cluster in un canale di rilascio, Google gestisce automaticamente la versione e la cadenza dell'upgrade per il cluster e i relativi pool di nodi.

Per mantenere i cluster aggiornati con gli ultimi aggiornamenti per GKE e Kubernetes, ecco alcuni ambienti consigliati e i rispettivi canali di rilascio in cui devono essere registrati i cluster:

Ambiente Canale di rilascio Descrizione
Produzione Stabile o regolare Per la stabilità e la maturità della versione, utilizza il canale stabile o regolare per i carichi di lavoro di produzione.
Gestione temporanea Come la produzione Per assicurarti che i test siano indicativi della versione a cui verrà eseguito l'upgrade della tua produzione, utilizza lo stesso canale di rilascio della versione di produzione.
Test
Sviluppo
Canary Rapido Per testare le ultime release di Kubernetes e giocare d'anticipo testando le nuove funzionalità o API GKE, utilizza il canale rapido. Puoi migliorare il time to market se la versione in rapido viene promossa sul canale che utilizzi per la produzione.

L'upgrade dei piani di controllo del cluster viene sempre eseguito regolarmente, indipendentemente dal fatto che il cluster sia registrato o meno in un canale di rilascio.

Crea una strategia di upgrade continuo

Dopo aver registrato il cluster in un canale di rilascio, viene eseguito regolarmente l'upgrade del cluster alla versione che soddisfa i requisiti di qualità e stabilità del canale. Questi aggiornamenti includono correzioni di bug e di sicurezza, applicati con un controllo crescente su ciascun canale:

  • Le patch vengono inviate al piano di controllo e ai nodi in tutti i canali gradualmente, accumulando il tempo di attesa nei canali rapidi e regolari prima di raggiungere il canale stabile.
  • Viene eseguito prima l'upgrade del piano di controllo, seguito dai nodi per rispettare il criterio del sistema operativo Kubernetes (ad es. kubelet non deve essere più recente di kube-apiserver).
  • GKE distribuirà automaticamente le patch ai canali in base alla loro criticità e importanza.
  • Il canale stabile riceve solo patch critiche.

Ricevi aggiornamenti sulle nuove versioni di GKE

Le informazioni sulle nuove versioni vengono pubblicate nella pagina principale delle note di rilascio di GKE e su un feed RSS. Ogni canale di rilascio dispone di una pagina delle note di rilascio semplificata e dedicata (ad esempio: Note di rilascio per il canale stabile) con informazioni sulla versione di GKE consigliata per il canale in questione.

Per ricevere proattivamente aggiornamenti sugli upgrade di GKE prima dell'esecuzione degli upgrade, utilizza Pub/Sub e iscriviti per ricevere le notifiche relative agli upgrade.

Quando una nuova versione diventa disponibile, devi pianificare un upgrade prima che la versione diventi la predefinita nel parco risorse. Questo approccio offre maggiore controllo e prevedibilità quando necessario, in quanto GKE ignorerebbe l'upgrade automatico per i cluster già aggiornati in anticipo.

Testa e verifica nuove patch e versioni secondarie

Tutte le release superano i test interni, indipendentemente dal canale in cui vengono rilasciate. Tuttavia, per via degli aggiornamenti e delle patch frequenti dell'upstream Kubernetes e GKE, ti consigliamo vivamente di testare le nuove release in ambienti di test e/o gestione temporanea prima dell'implementazione delle release nell'ambiente di produzione, in particolare gli upgrade delle versioni secondarie di Kubernetes.

Ogni canale di rilascio offre due versioni: default e available.

  • Le nuove release delle patch sono disponibili una settimana prima di diventare predefinite.
  • Le nuove release secondarie di Kubernetes saranno disponibili quattro settimane prima di diventare predefinite.

GKE esegue gradualmente l'upgrade automatico dei cluster alla versione predefinita. Se è necessario un maggiore controllo sul processo di upgrade, ti consigliamo di eseguire in anticipo l'upgrade a una versione disponibile. L'upgrade automatico di GKE ignora i cluster con upgrade manuale.

Un approccio consigliato per automatizzare e semplificare gli upgrade potrebbe prevedere:

  • Un ambiente di pre-produzione che utilizza la versione disponibile.
  • Esegui l'upgrade delle notifiche configurate sul cluster per informare il tuo team delle nuove versioni disponibili da testare e certificare.
  • Un ambiente di produzione ha effettuato l'iscrizione a un canale di rilascio utilizzando la versione predefinita nel canale.
  • Implementazione graduale delle nuove versioni disponibili nei cluster di produzione. Ad esempio, se sono presenti più cluster di produzione, un piano di upgrade graduale dovrebbe iniziare eseguendo l'upgrade di una parte di questi cluster alla versione disponibile, mantenendo gli altri sulla versione predefinita, seguiti da ulteriori upgrade di piccole parti fino all'upgrade al 100%.

La tabella seguente riassume gli eventi di release e le azioni consigliate:

Evento Azione consigliata
La nuova versione X viene resa disponibile in un canale. Esegui manualmente l'upgrade del cluster di test, qualifica e testa la nuova versione.
La versione X diventa la versione predefinita. GKE avvia l'upgrade automatico alla versione predefinita. Valuta la possibilità di eseguire l'upgrade della produzione prima del parco risorse.
GKE avvia l'upgrade automatico dei cluster. Consenti l'upgrade automatico dei cluster o posticipa l'upgrade utilizzando le finestre di esclusione della manutenzione.

Strategia di upgrade per le release delle patch

Di seguito è riportata una strategia di upgrade consigliata per le release delle patch, in uno scenario in cui:

  • Tutti i cluster sono iscritti al canale stabile.
  • Le nuove versioni disponibili vengono implementate prima nel cluster di gestione temporanea.
  • L'upgrade del cluster di produzione viene eseguito automaticamente con le nuove versioni predefinite.
  • Monitoraggio regolare delle nuove versioni disponibili per GKE.
Tempo Evento Che cosa devo fare?
T - 1 settimana È disponibile una nuova versione della patch. Esegui l'upgrade dell'ambiente di gestione temporanea.
T La versione patch diventa predefinita. Valuta la possibilità di aggiornare in anticipo il piano di controllo della produzione per migliorare la prevedibilità.
T GKE inizierà l'upgrade dei piani di controllo alla versione predefinita. Valuta la possibilità di eseguire in anticipo l'upgrade dei pool di nodi di produzione per migliorare la prevedibilità.
T + 1 settimana GKE avvierà l'upgrade dei pool di nodi cluster alla versione predefinita. GKE esegue l'upgrade automatico dei cluster, ignorando quelli con upgrade manuale.

Strategia di upgrade per le nuove release secondarie

Ecco una strategia di upgrade consigliata per le nuove release secondarie:

Tempo Evento Che cosa devo fare?
T - 3 settimane È disponibile una nuova versione secondaria Esegui l'upgrade del piano di controllo di test
T - 2 settimane
  1. Dato che l'upgrade del piano di controllo è andato a buon fine, valuta la possibilità di eseguirne l'upgrade in anticipo.
  2. Esegui l'upgrade dei pool di nodi di test.
T - 1 settimana Se l'upgrade è andato a buon fine, valuta la possibilità di eseguire l'upgrade dei pool di nodi di produzione in anticipo.
T La versione secondaria diventa predefinita.
T GKE avvierà l'upgrade dei piani di controllo del cluster alla versione predefinita. Crea una finestra di esclusione se sono necessari ulteriori test o misure di mitigazione prima dell'implementazione in produzione.
T + 1 settimana GKE inizierà l'upgrade dei pool di nodi cluster alla versione predefinita. GKE esegue l'upgrade automatico dei cluster, ignorando quelli con upgrade manuale.

Riduci le interruzioni dei carichi di lavoro esistenti durante un upgrade

Mantenere aggiornati i cluster con patch di sicurezza e correzioni di bug è fondamentale per garantire la vitalità dei cluster e la continuità aziendale. Gli aggiornamenti regolari proteggono i carichi di lavoro da vulnerabilità e errori.

Pianifica periodi di manutenzione ed esclusioni

Per aumentare la prevedibilità degli upgrade e allinearli alle ore lavorative non di punta, puoi controllare gli upgrade automatici del piano di controllo e dei nodi creando una finestra di manutenzione. GKE rispetta i periodi di manutenzione. In particolare, se il processo di upgrade viene eseguito oltre il periodo di manutenzione definito, GKE tenta di mettere in pausa l'operazione e la riprende durante il periodo di manutenzione successivo.

GKE segue una pianificazione di implementazione su più giorni per rendere disponibili nuove versioni, oltre all'upgrade automatico dei piani di controllo e dei nodi dei cluster in regioni diverse. L'implementazione richiede in genere quattro o più giorni e include un margine di tempo per osservare e monitorare i problemi. In un ambiente multi-cluster, puoi utilizzare un periodo di manutenzione separato per ogni cluster al fine di mettere in sequenza l'implementazione nei tuoi cluster. Ad esempio, potresti voler controllare quando i cluster in regioni diverse ricevono la manutenzione impostando periodi di manutenzione diversi per ogni cluster.

Un altro strumento per ridurre le interruzioni, soprattutto durante i periodi aziendali di forte richiesta, sono le esclusioni di manutenzione. Utilizza le esclusioni dalla manutenzione per evitare che durante questi periodi si verifichi la manutenzione automatica. Le esclusioni dalla manutenzione possono essere impostate su cluster nuovi o esistenti. Puoi anche utilizzare le esclusioni in combinazione con la strategia di upgrade. Ad esempio, potresti voler posticipare un upgrade a un cluster di produzione se un ambiente di test o gestione temporanea non funziona a causa di un upgrade.

Imposta la tolleranza per l'interruzione

Potresti già conoscere il concetto di replicas in Kubernetes. Le repliche assicurano la ridondanza dei carichi di lavoro per migliorare le prestazioni e la reattività. Se impostate, le repliche controllano il numero di repliche dei pod in esecuzione in un dato momento. Tuttavia, durante la manutenzione, Kubernetes rimuove le VM dei nodi sottostanti, riducendo il numero di repliche. Per assicurarti che i carichi di lavoro abbiano un numero sufficiente di repliche per le tue applicazioni, anche durante la manutenzione, utilizza un budget di interruzione dei pod (PDB).

In un budget di interruzione dei pod, puoi definire un numero (o una percentuale) di pod che possono essere arrestati, anche se l'arresto dei pod porta il numero di repliche attuale al di sotto del valore desiderato. Questo processo può accelerare lo svuotamento dei nodi eliminando la necessità di attendere che i pod di cui è stata eseguita la migrazione diventino completamente operativi. Svuota invece i pod da un nodo che segue la configurazione PDB, consentendo al deployment di eseguire il deployment dei pod mancanti su altri nodi disponibili. Una volta impostato il PDB, GKE non arresta i pod nell'applicazione se il numero di pod è uguale o inferiore a un limite configurato. GKE segue un PDB per un massimo di 60 minuti.

Controlla gli upgrade dei pool di nodi

Con GKE, puoi scegliere una strategia di upgrade dei nodi per determinare la modalità di upgrade dei nodi nei pool di nodi. Per impostazione predefinita, i pool di nodi utilizzano gli upgrade di picco. Con gli upgrade di sovraccarico, il processo di upgrade per i pool di nodi GKE prevede la creazione di ogni VM nel pool di nodi. Viene creata una nuova VM con la nuova versione (immagine sottoposta ad upgrade) in modalità di aggiornamento in sequenza. A sua volta, è necessario arrestare tutti i pod in esecuzione sul nodo precedente e spostarli in quello nuovo. I carichi di lavoro possono essere eseguiti con ridondanza sufficiente (repliche) e puoi fare affidamento su Kubernetes per spostare e riavviare i pod in base alle tue esigenze. Tuttavia, un numero temporaneamente ridotto di repliche può comunque essere un problema per la tua attività e potrebbe rallentare le prestazioni dei carichi di lavoro finché Kubernetes non riesce a raggiungere di nuovo lo stato desiderato, ovvero raggiungere il numero minimo di repliche necessario. Puoi evitare questo tipo di interruzione utilizzando gli upgrade di picco.

Durante un upgrade in cui è abilitato l'upgrade di sovraccarico, GKE protegge prima le risorse (macchine) necessarie per l'upgrade, quindi crea un nuovo nodo sottoposto ad upgrade. Solo a quel punto svuota il nodo precedente e infine lo arresta. In questo modo, la capacità prevista rimane invariata durante il processo di upgrade.

Per cluster di grandi dimensioni in cui il processo di upgrade potrebbe richiedere più tempo, puoi accelerare il tempo di completamento dell'upgrade eseguendo l'upgrade di più nodi alla volta. Utilizza l'upgrade di sovraccarico con maxSurge=20, maxUnavailable=0 per indicare a GKE di eseguire l'upgrade di 20 nodi alla volta, senza utilizzare la capacità esistente.

Riepilogo elenco di controllo

La seguente tabella riassume le attività consigliate per una strategia di upgrade al fine di mantenere sempre aggiornati i cluster GKE:

Best practice Attività
Configurazione di più ambienti
Registra i cluster nei canali di rilascio
Crea una strategia di upgrade continuo
Riduci le interruzioni dei carichi di lavoro esistenti

Passaggi successivi