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 aumentare la disponibilità e l'affidabilità dei tuoi ambienti. Puoi utilizzare queste informazioni per mantenere i cluster aggiornati per la stabilità e la sicurezza con interruzioni minime dei 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 workflow 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 software e dell'infrastruttura separatamente dall'ambiente di produzione. Come minimo, devi avere un ambiente di produzione e un ambiente di pre-produzione o di test.

Considera i seguenti ambienti consigliati:

Ambiente Descrizione
Produzione Utilizzato per erogare traffico in tempo reale agli utenti finali per le applicazioni aziendali mission critical applicazioni.
Gestione temporanea Utilizzato per assicurarsi che tutte le nuove modifiche di cui è stato eseguito il deployment dagli ambienti precedenti funzionino come previsto prima che venga eseguito il deployment delle modifiche in produzione.
Test Utilizzato per il benchmarking delle prestazioni, il test e il QA dei workload rispetto alla GKE release 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, crei correzioni e modifiche incrementali di cui eseguire il deployment in produzione.
Canary Utilizzato come ambiente di sviluppo secondario per testare le release di Kubernetes più recenti, le funzionalità e le API di GKE per ottenere un time-to-market migliore una volta che queste release vengono promosse e diventano target di upgrade automatico.

Registrare i cluster nei canali di rilascio

Kubernetes rilascia spesso aggiornamenti per fornire aggiornamenti di sicurezza, correggere problemi noti e introdurre nuove funzionalità. I canali di rilascio di GKE 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 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 il canale regolare per i workload di produzione.
Gestione temporanea Uguale alla produzione Per assicurarti che i test siano indicativi della versione di cui verrà eseguito l'upgrade della tua produzione, utilizza lo stesso canale di rilascio della produzione.
Test
Sviluppo
Canary Rapido Per testare le ultime release di Kubernetes e rimanere al passo con 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 data di fine dell'assistenza standard, utilizza il canale Esteso. Per saperne di più, consulta Utilizzare il canale Esteso quando è necessaria l'assistenza a lungo termine.

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

Creare 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 la qualità e la stabilità del canale. Questi aggiornamenti includono correzioni di sicurezza e di bug, applicate con una scrupolosità crescente in ogni canale:

  • Le patch vengono distribuite gradualmente al piano di controllo e ai nodi in tutti i canali, accumulando tempo di soak nei canali Rapido e Regolare prima di arrivare al canale Stabile.
  • Viene eseguito prima l'upgrade del piano di controllo, seguito dai nodi, in conformità con la policy OSS di Kubernetes secondo cui kubelet non deve essere più recente di kube-apiserver.
  • GKE eseguirà automaticamente il rollout delle patch ai 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 e 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 abbonati 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 il target di upgrade automatico disponibile è precedente o uguale alla versione di cui hai già eseguito l'upgrade manuale del cluster. Per ottenere i target di upgrade automatico per un cluster specifico, consulta Visualizzare le informazioni sugli upgrade di un cluster.

Testare e verificare le nuove versioni patch e secondarie

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

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

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

GKE esegue automaticamente l'upgrade dei cluster alle versioni più recenti. Se è necessario un maggiore controllo sulla procedura 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.
  • Notifiche di upgrade configurate nel cluster per informare il team sulle nuove versioni disponibili da testare e certificare.
  • Un ambiente di produzione abbonato a un canale di rilascio che utilizza una versione che hai già testato nell'ambiente di pre-produzione.
  • Implementazione graduale delle nuove versioni disponibili nei cluster di produzione. Ad esempio, se sono presenti più cluster di produzione, un piano di upgrade graduale inizierà eseguendo l'upgrade di una parte di questi cluster alla versione disponibile, mantenendo gli altri sulla versione esistente, seguito da upgrade di altre piccole parti fino al 100% di upgrade.

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

Evento Comportamento consigliato
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 un target 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 risorse.
GKE inizia 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 patch

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

  • Tutti i cluster sono abbonati al canale Stabile.
  • Le nuove versioni disponibili vengono implementate prima nel cluster di gestione temporanea.
  • Viene eseguito automaticamente l'upgrade del cluster di produzione al nuovo target di upgrade automatico.
  • Monitoraggio regolare delle nuove versioni disponibili per GKE.
Ora Evento Che cosa devo fare?
T - 1 settimana È disponibile una nuova versione patch. Esegui l'upgrade dell'ambiente di gestione temporanea.
T La versione patch diventa il target di upgrade automatico. Per una maggiore prevedibilità, valuta la possibilità di eseguire l'upgrade del piano di controllo di produzione in anticipo.
T GKE inizierà l'upgrade dei piani di controllo al target di upgrade automatico. Per una maggiore prevedibilità, valuta la possibilità di eseguire l'upgrade dei pool di nodi di produzione in anticipo.
T + 1 settimana GKE inizierà l'upgrade dei pool di nodi del cluster al target di upgrade automatico. GKE eseguirà l'upgrade automatico dei cluster, saltando quelli di cui è stato eseguito l'upgrade manuale.

Strategia di upgrade per le nuove release secondarie

Di seguito è riportata 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 piano di controllo di test
T - 2 settimane
  1. Se l'upgrade del piano di controllo è andato a buon fine, valuta la possibilità di eseguire l'upgrade del piano di controllo di produzione 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 il target di upgrade automatico.
T GKE inizierà l'upgrade dei piani di controllo del cluster al target di upgrade automatico. Crea una finestra di esclusione se sono necessari ulteriori test o mitigazioni prima del rollout in produzione.
T + 1 settimana GKE inizierà l'upgrade dei pool di nodi del cluster al target di upgrade automatico. GKE eseguirà l'upgrade automatico dei cluster, saltando quelli di cui è stato eseguito l'upgrade manuale.

Ridurre le interruzioni dei workload esistenti durante un upgrade

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

Pianificare periodi di manutenzione ed esclusioni

Per aumentare la prevedibilità degli upgrade ed eseguirli in orari non di punta, puoi controllare gli upgrade automatici sia del control plane sia dei nodi creando un periodo di manutenzione. GKE rispetta i periodi di manutenzione. In particolare, se la procedura di upgrade supera 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 rollout di più giorni per rendere disponibili le nuove versioni, nonché per eseguire l'upgrade automatico dei piani di controllo e dei nodi dei cluster in diverse regioni. Il rollout in genere dura quattro o più giorni e include un buffer di tempo per osservare e monitorare i problemi. In un ambiente multi-cluster, puoi utilizzare un periodo di manutenzione separato per ogni cluster per sequenziare il rollout tra i 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 attività aziendale ad alta richiesta, sono le esclusioni della manutenzione. Utilizza le esclusioni della manutenzione per impedire che la manutenzione automatica venga eseguita durante questi periodi; le esclusioni della 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 di gestione temporanea 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 workload per prestazioni e reattività migliori. Quando sono impostate, le repliche regolano il numero di repliche dei 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 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 numero di repliche corrente al di sotto del valore desiderato. Questa procedura può accelerare lo svuotamento dei nodi eliminando la necessità di attendere che i pod migrati diventino completamente operativi. Al contrario, lo svuotamento elimina i pod da un nodo seguendo la configurazione del 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 come viene eseguito l'upgrade dei nodi nei pool di nodi. Per impostazione predefinita, i pool di nodi utilizzano gli upgrade di sovraccarico. Con gli upgrade di sovraccarico, la procedura di upgrade per i pool di nodi GKE prevede la ricreazione di ogni VM nel pool di nodi. Viene creata una nuova VM con la nuova versione (immagine di cui è stato eseguito l'upgrade) in modo da eseguire un aggiornamento in sequenza. A sua volta, ciò richiede l'arresto di tutti i pod in esecuzione sul nodo precedente e lo spostamento dei pod sul nuovo nodo. I 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 essere dannoso per la tua attività e potrebbe rallentare le prestazioni del workload finché Kubernetes non è in grado di raggiungere di nuovo lo stato desiderato (ovvero raggiungere il numero minimo di repliche necessarie). Puoi evitare questa interruzione utilizzando gli upgrade di sovraccarico.

Durante un upgrade con l'upgrade di sovraccarico abilitato, GKE protegge prima le risorse (macchine) necessarie per l'upgrade, poi crea un nuovo nodo di cui è stato eseguito l'upgrade, quindi svuota il nodo precedente e infine lo arresta. In questo modo, la capacità prevista rimane intatta durante la procedura di upgrade.

Per i cluster di grandi dimensioni in cui la procedura 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 sovraccarico con maxSurge=20, maxUnavailable=0 per indicare a GKE di eseguire l'upgrade di 20 nodi alla volta, senza utilizzare la capacità esistente.

Utilizzare il canale Esteso quando è necessaria l'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 Esteso channel.

Per ottenere il massimo vantaggio dal canale, ti consigliamo di attenerti alle seguenti best practice. Alcune di queste best practice richiedono l'esecuzione di alcune azioni manuali, 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 rispetto al periodo di assistenza standard di 14 mesi, ad esempio per mitigare l'utilizzo delle 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 versione secondaria successiva. Quando è tutto pronto per eseguire l'upgrade alla versione secondaria successiva, esegui l'upgrade manuale del cluster, quindi lo sposti di nuovo nel canale di rilascio originale.

Upgrade delle versioni secondarie 1-2 volte all'anno

Se vuoi ridurre al minimo le interruzioni del cluster, continuando a ricevere 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 delle versioni secondarie 1-2 volte all'anno. Ad esempio, esegui l'upgrade da 1.30 a 1.31 a 1.32.

Questa procedura consente di assicurarsi 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 secondari con la stessa frequenza

Se vuoi mantenere il cluster su una versione secondaria per sempre, registralo nel canale Esteso e non eseguire altre azioni. 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 non sarà più supportata a breve, con una media di circa ogni 4 mesi. Ciò significa che il cluster riceve upgrade delle versioni secondarie con la stessa frequenza degli altri canali di rilascio, ma riceve le nuove funzionalità in un secondo momento.

Riepilogo dell'elenco 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
Creare una strategia di upgrade continuo
Ridurre le interruzioni dei workload esistenti

Passaggi successivi