Best practice per l'upgrade dei cluster

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

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

Configurare più ambienti

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

Prendi in considerazione i seguenti ambienti consigliati:

Ambiente Descrizione
Produzione Utilizzato per gestire il traffico live verso gli utenti finali per le applicazioni aziendali mission critical.
Gestione temporanea Utilizzato per garantire che tutte le nuove modifiche di cui è stato eseguito il deployment dagli ambienti precedenti funzionino come previsto prima che vengano implementate nell'ambiente di produzione.
Test Utilizzato per il benchmark delle prestazioni, i test e i carichi di lavoro QA rispetto alla versione GKE che utilizzerai in produzione. In questo ambiente, puoi testare l'upgrade del control plane 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, crei correzioni e modifiche incrementali da implementare in produzione.
Canary Utilizzato come ambiente di sviluppo secondario per testare le versioni più recenti di Kubernetes, le funzionalità e le API di GKE per ottenere un time to market migliore una volta che queste versioni vengono promosse e diventano target di upgrade automatico.

Registrare i cluster nei canali di rilascio

Kubernetes rilascia spesso aggiornamenti per fornire aggiornamenti della sicurezza, correggere problemi noti e introdurre nuove funzionalità. I canali di rilascio di GKE ti offrono la possibilità di trovare un equilibrio tra la stabilità e il 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 degli upgrade per il cluster e i relativi pool di nodi.

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

Ambiente Canale di rilascio Descrizione
Produzione Stabile o Regolare Per stabilità e maturità della versione, utilizza il canale stabile o regolare per i carichi di lavoro di produzione.
Gestione temporanea Uguale a produzione Per assicurarti che i test siano indicativi della versione a cui verrà eseguito l'upgrade della produzione, utilizza lo stesso canale di rilascio della produzione.
Test
Sviluppo
Canary Rapido Per testare le ultime release di Kubernetes e anticipare i tempi testando nuove funzionalità o API di GKE, utilizza il canale rapido. Puoi migliorare il time to market quando la versione nel canale rapido viene promossa al canale che utilizzi per la produzione.
N/D Esteso Per mantenere il cluster su una versione secondaria più a lungo continuando a ricevere patch di sicurezza dopo la fine del periodo di assistenza standard, utilizza il canale esteso. Per saperne di più, consulta Utilizzare il canale esteso quando hai bisogno di assistenza a lungo termine.

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

Crea una strategia di upgrade continuo

Dopo aver registrato il cluster in un canale di rilascio, questo viene regolarmente aggiornato alla versione che soddisfa i requisiti di qualità e stabilità del canale. Questi aggiornamenti includono correzioni di bug e della sicurezza, applicate con un controllo sempre più rigoroso in ogni canale:

  • Le patch vengono inviate gradualmente al control plane e ai nodi di tutti i canali, accumulando tempo di test nei canali Rapido e Regolare prima di arrivare nel canale Stabile.
  • Per rispettare le norme OSS di Kubernetes, il piano di controllo viene aggiornato per primo, seguito dai nodi, in modo che kubelet non sia più recente di kube-apiserver.
  • GKE implementerà automaticamente le patch nei canali in base alla loro criticità e importanza.
  • Il canale stabile riceve solo patch critiche.

Ricevere aggiornamenti sulle nuove versioni di GKE

Le informazioni sulle nuove versioni vengono pubblicate nella pagina principale delle note di rilascio di GKE, nonché in un feed RSS. Ogni canale di rilascio ha 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 quel canale.

Per ricevere in modo proattivo aggiornamenti sugli upgrade di GKE prima che vengano eseguiti, utilizza Pub/Sub e iscriviti alle notifiche di upgrade.

Una volta che una nuova versione diventa disponibile, devi pianificare un upgrade prima che la versione diventi il target di upgrade automatico per il cluster. Questo approccio offre maggiore controllo e prevedibilità quando necessario, perché GKE non esegue l'upgrade automatico di un cluster se la destinazione dell'upgrade automatico disponibile è precedente o uguale alla versione a cui hai già eseguito l'upgrade manuale del cluster. Per ottenere le destinazioni dell'upgrade automatico per un cluster specifico, consulta Ottenere informazioni sugli upgrade di un cluster.

Testare e verificare le nuove patch e le versioni secondarie

Tutte le release superano i test interni indipendentemente dal canale in cui vengono pubblicate. Tuttavia, con gli aggiornamenti e le patch frequenti di Kubernetes e GKE, ti consigliamo vivamente di testare le nuove release in ambienti di test e/o di gestione temporanea prima che vengano implementate nel tuo ambiente di produzione, in particolare gli upgrade delle versioni secondarie di Kubernetes.

Ogni canale di rilascio offre più versioni disponibili, tra cui una versione predefinita per la creazione del cluster e target di upgrade automatico:

  • Le nuove release delle patch sono disponibili una settimana prima di diventare target dell'upgrade automatico.
  • Le nuove versioni secondarie di Kubernetes sono disponibili quattro settimane prima di diventare target di upgrade automatico.

GKE esegue automaticamente l'upgrade dei cluster a versioni più recenti. Se è necessario un maggiore controllo sul processo di upgrade, ti consigliamo di eseguire l'upgrade in anticipo a una versione disponibile. GKE non esegue l'upgrade automatico dei cluster di cui è stato eseguito l'upgrade manuale allo stesso target di upgrade automatico.

Un approccio consigliato per automatizzare e semplificare gli upgrade prevede:

  • Un ambiente di pre-produzione che utilizza la versione disponibile.
  • Configura le notifiche di upgrade sul cluster per informare il tuo team delle nuove versioni disponibili da testare e certificare.
  • Un ambiente di produzione iscritto a un canale di rilascio che utilizza una versione che hai già testato nel tuo ambiente di pre-produzione.
  • Rilascio graduale delle nuove versioni disponibili nei cluster di produzione. Ad esempio, se esistono più cluster di produzione, un piano di upgrade graduale inizierebbe eseguendo l'upgrade di una parte di questi cluster alla versione disponibile mantenendo gli altri sulla versione esistente, seguito da ulteriori upgrade di piccole porzioni fino al completamento dell'upgrade al 100%.

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

Evento Azione consigliata
La nuova versione X viene resa disponibile in un canale. Esegui l'upgrade manuale del cluster di test, qualifica e testa la nuova versione.
La versione X diventa una destinazione di upgrade automatico per la versione secondaria del cluster. GKE inizia l'upgrade automatico al target di upgrade automatico. Valuta la possibilità di eseguire l'upgrade della produzione prima del parco dispositivi.
GKE avvia l'upgrade automatico dei cluster. Consenti l'upgrade automatico dei cluster o posticipalo utilizzando periodi di esclusione dalla manutenzione.

Strategia di upgrade per le release di patch

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

  • Tutti i cluster sono iscritti al canale stabile.
  • Le nuove versioni disponibili vengono implementate prima nel cluster di staging.
  • Il cluster di produzione viene aggiornato automaticamente al nuovo target di upgrade automatico.
  • Monitorare regolarmente le nuove versioni disponibili per GKE.
Ora 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 la destinazione dell'upgrade automatico. Valuta la possibilità di eseguire l'upgrade del control plane di produzione in anticipo per una migliore prevedibilità.
T GKE inizierà a eseguire l'upgrade dei control plane al target dell'upgrade automatico. Per una migliore prevedibilità, valuta la possibilità di eseguire l'upgrade dei pool di nodi di produzione in anticipo.
T + 1 settimana GKE inizierà l'upgrade dei node pool del cluster al target dell'upgrade automatico. GKE eseguirà l'upgrade automatico dei cluster, ignorando quelli di cui è stato eseguito l'upgrade manualmente.

Strategia di upgrade per le nuove versioni secondarie

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

Ora Evento Che cosa devo fare?
T - 3 settimane È disponibile una nuova versione secondaria Esegui l'upgrade del control plane di test
T - 2 settimane
  1. Se l'upgrade del control plane è riuscito, valuta la possibilità di eseguire l'upgrade del control plane di produzione in anticipo.
  2. Esegui l'upgrade dei node pool di test.
T - 1 settimana Se l'upgrade è riuscito, valuta la possibilità di eseguire l'upgrade dei pool di nodi di produzione in anticipo.
T La versione secondaria diventa la destinazione dell'upgrade automatico.
T GKE inizierà l'upgrade dei control plane dei cluster al target dell'upgrade automatico. Crea una finestra di esclusione se sono necessari ulteriori test o mitigazioni prima dell'implementazione in produzione.
T + 1 settimana GKE inizierà l'upgrade dei node pool del cluster al target dell'upgrade automatico. GKE eseguirà l'upgrade automatico dei cluster, saltando quelli di cui è stato eseguito l'upgrade manualmente.

Ridurre le interruzioni ai carichi di lavoro esistenti durante un upgrade

Mantenere i cluster aggiornati con patch di sicurezza e correzioni di bug è fondamentale per garantire la vitalità dei cluster e la continuità operativa. Gli aggiornamenti regolari proteggono i tuoi workload da vulnerabilità e guasti.

Pianificare periodi di manutenzione ed esclusioni

Per aumentare la prevedibilità degli upgrade ed eseguirli in orari di punta, puoi controllare gli upgrade automatici del control plane e dei nodi creando un periodo di manutenzione. GKE rispetta i periodi di manutenzione. ovvero, se la procedura di upgrade viene eseguita oltre il periodo di manutenzione definito, GKE tenta di sospendere l'operazione e la riprende durante il periodo di manutenzione successivo.

GKE segue una pianificazione di implementazione di più giorni per rendere disponibili nuove versioni, nonché per l'upgrade automatico dei nodi e dei piani di controllo dei cluster in diverse regioni. Il lancio in genere dura quattro o più giorni e include un periodo di tempo per osservare e monitorare eventuali problemi. In un ambiente multicluster, puoi utilizzare una periodo di manutenzione separata per ogni cluster per sequenziare l'implementazione nei 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 di maggiore richiesta, è rappresentato dalle esclusioni di manutenzione. Utilizza le esclusioni di manutenzione per impedire che la manutenzione automatica venga eseguita durante questi periodi. Le esclusioni di manutenzione possono essere impostate su cluster nuovi o esistenti. Puoi anche utilizzare le esclusioni in combinazione con la tua strategia di upgrade. Ad esempio, potresti voler posticipare l'upgrade a un cluster di produzione se un ambiente di test o di staging non funziona a causa di un upgrade.

Impostare la tolleranza alle interruzioni

Potresti avere familiarità con il concetto di repliche in Kubernetes. Le repliche garantiscono la ridondanza dei carichi di lavoro per prestazioni e reattività migliori. Se impostate, le repliche controllano il numero di repliche di pod in esecuzione in un dato momento. Tuttavia, durante la manutenzione, Kubernetes rimuove le VM dei nodi sottostanti, il che può ridurre il numero di repliche. Per assicurarti che i tuoi workload 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 terminati, anche se la terminazione dei pod porta il conteggio delle repliche corrente al di sotto del valore desiderato. Questo processo può accelerare lo svuotamento del nodo eliminando la necessità di attendere che i pod migrati diventino completamente operativi. Al contrario, l'eliminazione espelle i pod da un nodo seguendo la configurazione PDB, consentendo al deployment di eseguire il deployment dei pod mancanti su altri nodi disponibili. Una volta impostato il PDB, GKE non arresterà i pod nella tua applicazione se il numero di pod è uguale o inferiore a un limite configurato. GKE segue un PDB per un massimo di 60 minuti.

Controllare 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 inattivi. Con gli upgrade di sovraccarico, la procedura di upgrade per i node pool GKE prevede la ricreazione di ogni VM nel pool di nodi. Viene creata una nuova VM con la nuova versione (immagine aggiornata) in modo sequenziale. A sua volta, ciò richiede l'arresto di tutti i pod in esecuzione sul vecchio nodo e lo spostamento dei pod sul nuovo nodo. I tuoi workload possono essere eseguiti con una ridondanza sufficiente (repliche) e puoi fare affidamento su Kubernetes per spostare e riavviare i pod in base alle esigenze. Tuttavia, un numero di repliche temporaneamente ridotto può comunque influire negativamente sulla tua attività e potrebbe rallentare le prestazioni del workload finché Kubernetes non sarà in grado di soddisfare di nuovo lo stato desiderato (ovvero raggiungere il numero minimo di repliche necessarie). Puoi evitare questo disagio utilizzando gli upgrade per picchi di domanda.

Durante un upgrade con l'upgrade di incremento abilitato, GKE prima protegge le risorse (macchine) necessarie per l'upgrade, poi crea un nuovo nodo sottoposto ad upgrade e solo allora svuota il nodo precedente e infine lo arresta. In questo modo, la capacità prevista rimane intatta durante l'intero processo di upgrade.

Per i 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 contemporaneamente. Utilizza l'upgrade di incremento con maxSurge=20, maxUnavailable=0 per indicare a GKE di eseguire l'upgrade di 20 nodi alla volta, senza utilizzare la capacità esistente.

Utilizza il canale Extended quando hai bisogno di assistenza a lungo termine

Se vuoi mantenere il cluster su una versione secondaria più a lungo, segui la best practice di registrare il cluster nel canale esteso. Con questo canale, GKE supporta una versione secondaria per circa 24 mesi. Per saperne di più, consulta Ricevere assistenza a lungo termine con il canale Extended.

Per ottenere il massimo dal canale, ti consigliamo di rispettare le seguenti best practice. Alcune di queste best practice richiedono un'azione manuale, tra cui l'upgrade manuale di un cluster e la modifica del canale di rilascio di un cluster. Esamina gli scenari supportati riportati di seguito, nonché Quando non utilizzare il canale esteso.

Rimanere temporaneamente su una versione secondaria più a lungo

Se devi mantenere temporaneamente un cluster su una versione secondaria per un periodo più lungo del periodo di assistenza standard di 14 mesi, ad esempio per mitigare l'utilizzo di API deprecate rimosse nella versione secondaria successiva, utilizza la seguente procedura. Puoi spostare temporaneamente il cluster da un altro canale di rilascio al canale esteso per continuare a ricevere patch di sicurezza mentre ti prepari a eseguire l'upgrade alla successiva versione secondaria. Quando è tutto pronto per l'upgrade alla versione secondaria successiva, esegui manualmente l'upgrade del cluster, quindi riportalo al canale di rilascio originale.

Upgrade delle versioni secondarie 1-2 volte l'anno

Se vuoi ridurre al minimo le interruzioni per il tuo cluster e ricevere comunque alcune nuove funzionalità quando il cluster è pronto per l'upgrade a una nuova versione secondaria, procedi nel seguente modo:

  • Registra un cluster nel canale esteso.
  • Esegui due upgrade successivi della versione secondaria 1-2 volte all'anno. Ad esempio, esegui l'upgrade da 1.30 a 1.31 e poi a 1.32.

Questo processo garantisce che il cluster rimanga su una versione secondaria disponibile, riceva le funzionalità delle nuove versioni secondarie, ma riceva gli upgrade delle versioni secondarie solo quando decidi che il cluster è pronto.

Quando non utilizzare il canale esteso

Per utilizzare il canale esteso per lo scopo previsto è necessaria un'azione manuale. Lo scenario seguente illustra le conseguenze dell'utilizzo del canale esteso senza una gestione attiva della versione secondaria del cluster.

Non fare nulla e ricevere upgrade minori con la stessa frequenza

Se vuoi mantenere il cluster su una versione secondaria per sempre, registralo nel canale esteso e non fare altro. Tutte le versioni secondarie alla fine non sono più supportate e GKE esegue automaticamente l'upgrade dei cluster dalle versioni secondarie non supportate. Pertanto, GKE esegue l'upgrade di questo cluster da una versione secondaria non supportata a una versione secondaria che presto non sarà più supportata, il che si traduce in una media di circa ogni 4 mesi. Ciò significa che il cluster riceve gli upgrade delle versioni secondarie con la stessa frequenza degli altri canali di rilascio, ma riceve le nuove funzionalità in un secondo momento.

Riepilogo della lista di controllo

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

Best practice Tasks
Configurare più ambienti
Registrare i cluster nei canali di rilascio
Crea una strategia di upgrade continuo
Ridurre le interruzioni ai carichi di lavoro esistenti

Passaggi successivi