Best practice per gli upgrade dei cluster GKE

Questo documento fornisce le best practice per gli amministratori della piattaforma per gestire gli upgrade dei cluster Google Kubernetes Engine (GKE). Per impostazione predefinita, GKE esegue automaticamente l'upgrade della versione del control plane e dei nodi del cluster per fornire nuove funzionalità, correzioni di bug e patch di sicurezza per mantenere l'ambiente efficiente e sicuro.

Per garantire che questi upgrade automatici siano in linea con le tue esigenze operative e ridurre al minimo le interruzioni dei carichi di lavoro, GKE offre strumenti che ti consentono di esercitare il massimo controllo. Questa guida spiega come utilizzare in modo efficace questi strumenti per mantenere prestazioni e disponibilità elevate. Per una comprensione di base, consulta Informazioni sugli upgrade dei cluster GKE.

Oltre agli upgrade del cluster, che sono solo aggiornamenti alla versione GKE del control plane e dei nodi, GKE esegue periodicamente aggiornamenti aggiuntivi al cluster. L'implementazione delle best practice descritte in questo documento può aiutarti a prepararti ad alcuni di questi tipi di modifiche. Per saperne di più, consulta Gestire le modifiche al ciclo di vita del cluster per ridurre al minimo le interruzioni.

Per una panoramica consolidata di tutte le best practice di GKE, consulta Best practice per GKE.

Elenco di controllo

La tabella seguente riassume le attività spiegate in dettaglio nelle sezioni successive. Ti consigliamo di eseguire queste attività quando prepari l'ambiente per gli upgrade del cluster.

Best practice Tasks
Scegli il giusto equilibrio tra velocità delle funzionalità e stabilità degli upgrade con i canali di rilascio
Scegliere i tempi degli upgrade con le policy di manutenzione
Controlla l'implementazione degli upgrade nei cluster
Controllare come vengono attivati gli upgrade
Monitorare gli upgrade dei cluster
Ridurre al minimo le interruzioni dei workload esistenti durante gli upgrade dei nodi

Scegli il giusto equilibrio tra velocità delle funzionalità e stabilità degli upgrade con i canali di rilascio

Con i canali di rilascio, puoi scegliere un equilibrio tra la velocità delle funzionalità e la stabilità degli upgrade. Per impostazione predefinita, i cluster GKE sono registrati nel canale di rilascio regolare. Quando GKE esegue l'upgrade del piano di controllo e dei nodi del cluster per fornire patch di sicurezza, correggere problemi noti e introdurre nuove funzionalità, il canale di rilascio determina le versioni GKE eseguite dal cluster. Ad esempio, se vuoi nuove funzionalità in tempi più brevi, puoi scegliere il canale Rapido. Se invece vuoi versioni con una stabilità più dimostrata, scegli il canale Stabile. Per saperne di più sulla scelta tra canali specifici, vedi Quali canali sono disponibili.

Se vuoi eseguire l'upgrade manuale dei cluster, puoi comunque trarre vantaggio dalla scelta del canale di rilascio esaminando le versioni disponibili e i target di upgrade automatico per il canale prima di selezionare una nuova versione.

Inoltre, se vuoi ricevere le versioni patch in un canale di rilascio il prima possibile, ad esempio per ricevere patch di sicurezza critiche, consulta Informazioni su come ricevere le versioni patch in anticipo.

Scegli il livello di assistenza di cui hai bisogno per una versione secondaria

GKE fornisce un totale di 24 mesi di assistenza per una versione secondaria dopo che questa è stata resa disponibile nel canale regolare. Questo supporto include 14 mesi di supporto standard e circa 10 mesi di supporto esteso disponibile con il canale Extended. Per maggiori informazioni su come GKE supporta una versione secondaria, consulta Supporto delle versioni secondarie.

Se devi mantenere il cluster su una versione secondaria più a lungo continuando a ricevere patch di sicurezza dopo la data di fine dell'assistenza standard o se vuoi impedire l'applicazione della fine dell'assistenza standard, puoi utilizzare anche il canale esteso. Per saperne di più, consulta la sezione successiva Utilizzare il canale Extended quando hai bisogno di assistenza a lungo termine.

Quando la versione secondaria raggiunge la fine del supporto, a seconda del canale di rilascio a cui è registrato il cluster, GKE esegue automaticamente l'upgrade del cluster per garantire che rimanga efficiente e sicuro. Per maggiori informazioni, consulta Upgrade automatici dei cluster per sicurezza e compatibilità. Se utilizzi gli strumenti descritti in questo documento per impedire o ritardare l'avanzamento degli upgrade automatici dei cluster, ti consigliamo di eseguire l'upgrade manualmente prima che la versione secondaria in esecuzione raggiunga la fine del supporto. In caso contrario, GKE esegue automaticamente l'upgrade del cluster.

Scegliere i tempi degli upgrade con le policy di manutenzione

Per controllare quando gli upgrade possono e non possono essere eseguiti, utilizza quanto segue:

  • Periodi di manutenzione: scegli un periodo di tempo ricorrente in cui GKE può eseguire l'upgrade del cluster, ad esempio durante gli orari di apertura. Se il processo di upgrade viene eseguito oltre il periodo di manutenzione, GKE tenta di sospendere l'operazione e riprenderla durante il periodo di manutenzione successivo.
  • Esclusioni dalla manutenzione: scegli un periodo di tempo specifico in cui GKE non può eseguire l'upgrade del tuo cluster, ad esempio durante un evento di vendita importante per un'attività di vendita al dettaglio. Puoi anche utilizzare le esclusioni dalla manutenzione per posticipare temporaneamente gli upgrade automatici di un cluster quando, ad esempio, noti un problema con altri cluster di cui è stato eseguito l'upgrade a una nuova versione.
    • Per i casi d'uso avanzati, potrebbe essere necessario eseguire manualmente determinati tipi di upgrade anziché farli eseguire da GKE. Puoi utilizzare le esclusioni per la manutenzione per disattivare questi tipi di upgrade automatici. Ad esempio, puoi utilizzare l'ambito "Nessun upgrade secondario o dei nodi" per disattivare tutti gli upgrade secondari e tutti gli upgrade dei nodi. Devi eseguire manualmente questi upgrade oppure GKE esegue l'upgrade dei cluster al termine del supporto per la versione secondaria.
  • Frequenza di manutenzione: per casi d'uso avanzati, controlla l'intervallo minimo tra due upgrade automatici consecutivi con il budget di interruzione del cluster.

Configurando le policy di manutenzione, puoi aumentare la prevedibilità degli upgrade e assicurarti che vengano eseguiti nel momento più opportuno per i tuoi workload.

Controlla l'implementazione degli upgrade nei cluster

Ti consigliamo di utilizzare più ambienti per ridurre al minimo i rischi e i tempi di inattività indesiderati testando separatamente le modifiche al software e all'infrastruttura rispetto all'ambiente di produzione. Come minimo, ti consigliamo di avere un ambiente di produzione e un ambiente di pre-produzione o ambiente di test.

Prendi in considerazione i seguenti ambienti consigliati:

Ambiente Descrizione
Produzione Eroga traffico in tempo reale agli utenti finali per le applicazioni aziendali mission-critical.
Canary Testa una piccola parte dell'ambiente di produzione prima dell'upgrade di tutti i cluster.
Gestione temporanea Verifica che tutte le nuove modifiche implementate dagli ambienti precedenti funzionino come previsto prima che vengano implementate in produzione.
Test Esegui benchmarking, test e garanzia di qualità (QA) per i workload con la versione di GKE che utilizzerai in produzione.
Sviluppo Utilizza la stessa versione in esecuzione in produzione per lo sviluppo attivo. In questo ambiente, crei correzioni e modifiche incrementali da implementare in produzione.

GKE fornisce funzionalità come la sequenza di implementazione per aiutarti a controllare la modalità di deployment degli upgrade nei diversi ambienti, come descritto nella sezione seguente.

Utilizzare la sequenza di implementazione per eseguire il rollout in più ambienti

Per eseguire il rollout progressivo delle nuove versioni di GKE all'interno e tra questi ambienti, ti consigliamo di utilizzare il sequenziamento del rollout. Con il sequenziamento del rollout, tutti i cluster utilizzano lo stesso canale di rilascio e la stessa versione secondaria durante le fasi di deployment. GKE implementa progressivamente le nuove versioni nella sequenza che configuri. Quando GKE implementa la nuova versione nei tuoi ambienti, puoi verificare che l'ambiente del cluster e i carichi di lavoro vengano eseguiti come previsto con la nuova versione.

Se stai configurando un nuovo ambiente, utilizza il sequenziamento del lancio con fasi personalizzate (anteprima). Questa versione più recente del sequenziamento dell'implementazione consente di dividere l'implementazione di una nuova versione in un parco dispositivi in più fasi. Con questo approccio, GKE può, ad esempio, eseguire l'upgrade di un ambiente canary in produzione prima di eseguire l'upgrade del resto della produzione. In alternativa, per una versione della funzionalità disponibile a livello generale che utilizza un modello più lineare senza fasi personalizzate, consulta Informazioni sugli upgrade dei cluster con sequenza di implementazione.

Test di patch e upgrade secondari di GKE

GKE esegue automaticamente l'upgrade dei cluster a una nuova patch anche ogni settimana. Gli upgrade delle versioni secondarie, tuttavia, vengono eseguiti solo circa tre volte all'anno. Le nuove versioni secondarie di Kubernetes introducono un volume maggiore di modifiche rispetto alle patch della stessa versione secondaria. Ti consigliamo di applicare un controllo aggiuntivo durante l'implementazione degli upgrade delle versioni secondarie nei tuoi ambienti, per assicurarti che la nuova versione secondaria funzioni come previsto con i tuoi cluster e carichi di lavoro.

Esegui i controlli prima di eseguire l'upgrade del cluster

Prima di eseguire gli upgrade automatici dei cluster, GKE qualifica le nuove versioni per un periodo di tempo che dipende dal canale di rilascio e verifica la preparazione del cluster.

Prima degli upgrade del cluster, ti consigliamo di procedere come segue:

  • Per tutti gli upgrade, inclusi gli upgrade di patch e secondari:
    • Consulta le note di rilascio di GKE per i problemi e per trovare il log delle modifiche per le nuove versioni secondarie e patch.
    • Controlla i problemi noti di GKE per eventuali problemi relativi all'ambiente del cluster e alla nuova versione.
  • Per gli upgrade secondari, esamina anche quanto segue:
    • Controlla i ritiri delle API. Per saperne di più, consulta le note di rilascio di GKE per la nuova versione, il log delle modifiche di Kubernetes e la sezione Ritiri di funzionalità e API.
    • Assicurati che la differenza di versione tra il control plane e i nodi sia supportata. GKE supporta l'esecuzione di nodi fino a due versioni secondarie precedenti rispetto al control plane. Per maggiori informazioni, consulta le norme relative alla differenza di versione di GKE.
  • Per gli upgrade dei nodi:

Controllare come vengono attivati gli upgrade

Per impostazione predefinita, GKE esegue automaticamente l'upgrade dei cluster alle nuove versioni a intervalli regolari. Tuttavia, puoi anche utilizzare gli upgrade manuali per eseguire l'upgrade del cluster esattamente quando vuoi e controllare la versione in esecuzione.

Puoi:

  • Esegui manualmente l'upgrade del cluster.

  • Esegui azioni per gli upgrade automatici o manuali dei nodi in corso, tra cui le seguenti:

    • Annullare un upgrade.
    • Riprendere un upgrade.
    • Esegui il rollback di un upgrade.
    • Completa un upgrade in corso.

Se vuoi avere un maggiore controllo sul processo di upgrade, ti consigliamo di configurare le esclusioni di manutenzione e poi eseguire gli upgrade manuali in base alle esigenze. Per saperne di più sugli upgrade manuali e su altre azioni che puoi intraprendere per gli upgrade in corso, consulta Eseguire l'upgrade manuale di un cluster o di un pool di nodi.

Monitorare gli upgrade dei cluster

Per contribuire a garantire che gli upgrade di GKE procedano come previsto e che l'ambiente del cluster rimanga efficiente e disponibile, utilizza i seguenti strumenti per monitorare gli upgrade del cluster. Per rimanere aggiornato sullo stato dei tuoi cluster, utilizza strumenti come notifiche, approfondimenti e consigli e log. Ti consigliamo in particolare di prestare attenzione alle notifiche di fine del supporto, alle notifiche di inizio dell'upgrade e alle notifiche di upgrade pianificato con attivazione per gli upgrade delle versioni secondarie. Configura policy di avviso per assicurarti di visualizzare queste notifiche.

Utilizza le seguenti risorse per informazioni dettagliate sugli upgrade attuali:

Ridurre al minimo le interruzioni dei workload esistenti durante gli upgrade dei nodi

Oltre alle best practice generali descritte nelle sezioni precedenti, ti consigliamo di prendere in considerazione una configurazione avanzata aggiuntiva per personalizzare ulteriormente la procedura di upgrade in base all'ambiente del cluster e alle esigenze dei tuoi workload.

Considerazioni aggiuntive per profili di workload specifici

Alcuni tipi di workload e ambienti cluster richiedono una preparazione aggiuntiva per gli upgrade del cluster. Se il tuo workload rientra in una o più delle seguenti categorie, tieni presente queste considerazioni aggiuntive:

  • Carichi di lavoro eseguiti su macchine che non eseguono la migrazione live: i nodi GKE, che sono istanze Compute Engine che GKE crea per tuo conto, richiedono periodicamente la manutenzione dell'infrastruttura sottostante. La maggior parte delle istanze Compute Engine può eseguire la migrazione live, il che significa che i workload in esecuzione non subiscono interruzioni durante questa manutenzione. Tuttavia, alcuni tipi di macchine non possono essere migrati live, il che significa che i carichi di lavoro in esecuzione sui nodi GKE possono essere interrotti. È fondamentale sottolineare che non è possibile eseguire la migrazione live degli acceleratori, come GPU e TPU per i workload AI/ML. Per maggiori informazioni, vedi Gestire l'interruzione dei nodi GKE che non eseguono la migrazione live.
  • Carichi di lavoro con capacità limitata: se i tuoi carichi di lavoro utilizzano tipi di macchine con capacità limitata, è necessario prestare maggiore attenzione quando esegui gli upgrade del cluster. Per ulteriori informazioni, vedi Garantisci le risorse per gli upgrade dei nodi.
  • Workload stateful: se i tuoi workload sono stateful e hanno requisiti specifici per l'arresto e il riavvio corretti, è necessario un'ulteriore considerazione quando esegui gli upgrade del cluster. Per saperne di più, consulta Assicurarsi che i workload siano pronti per le interruzioni.

Consulta le sezioni seguenti per capire come utilizzare gli strumenti disponibili per eseguire l'upgrade di questi tipi di workload.

Scegli una strategia di upgrade dei nodi

In modalità GKE Standard, GKE offre diverse strategie di upgrade dei nodi che determinano la modalità di upgrade dei singoli nodi nel pool di nodi. Scegliendo una strategia di upgrade per il tuo pool di nodil Standard, puoi selezionare il processo con il giusto equilibrio tra velocità, interruzione dei workload, mitigazione dei rischi e ottimizzazione dei costi. Puoi anche configurare i parametri della strategia in base alle tue esigenze. In modalità GKE Autopilot, GKE gestisce gli upgrade dei nodi e non devi scegliere la strategia specifica utilizzata. Per ulteriori informazioni, consulta Informazioni sulle strategie di upgrade dei nodi.

Impostare la tolleranza alle interruzioni

Utilizza i budget di interruzione dei pod (PDB) per assicurarti che, quando GKE ricrea i nodi durante gli upgrade, il che può ridurre temporaneamente il numero di repliche per un workload, i tuoi workload mantengano una ridondanza sufficiente.

Se è impostato un PDB, GKE non arresterà i pod nella tua applicazione se il numero di pod è uguale o inferiore a un limite configurato. Gli upgrade di GKE rispettano un PDB per un massimo di 60 minuti. Inoltre, GKE ti avvisa se lo svuotamento di un nodo è bloccato da un PDB o se viene raggiunto il timeout del PDB e i pod verranno eliminati forzatamente nonostante la violazione del PDB. Per saperne di più, vedi Eventi distruttivi durante l'upgrade di un pool di nodi.

Utilizza l'arresto controllato per arrestare un'applicazione

Puoi configurare l'arresto controllato per assicurarti che i carichi di lavoro abbiano tempo sufficiente per prepararsi all'arresto. Durante gli upgrade dei nodi, GKE rispetta le impostazioni di terminazione controllata per un massimo di 60 minuti con gli upgrade surge predefiniti e fino a 24 ore con gli upgrade blue-green e gli upgrade blue-green con scalabilità automatica (anteprima).

Per saperne di più sulla configurazione delle impostazioni di terminazione controllata, consulta Configurare GKE per terminare i workload in modo controllato.

Utilizza il canale Esteso 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. Con il canale Extended, controlli gli upgrade delle versioni secondarie e GKE esegue upgrade automatici solo al termine del supporto, se non avvii l'upgrade autonomamente. Per maggiori informazioni, consulta la sezione Ricevere assistenza a lungo termine con il canale Extended.

Se non devi utilizzare una versione secondaria per un periodo più lungo del periodo di assistenza standard, ma vuoi comunque controllare gli upgrade delle versioni secondarie, utilizza invece le esclusioni della manutenzione con l'ambito "Nessun upgrade secondario".

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 di seguito, nonché la sezione 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 ritirate 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 l'upgrade alla versione secondaria successiva, esegui manualmente l'upgrade del cluster, quindi riportalo al canale di rilascio originale.

Upgrade delle versioni secondarie una o due 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 una o due volte all'anno. Ad esempio, esegui l'upgrade da 1.33 a 1.34 e poi a 1.35.

Questo processo contribuisce a garantire che il cluster rimanga su una versione secondaria disponibile, riceva funzionalità dalle nuove versioni secondarie, ma riceva 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 corrisponde in media a circa ogni quattro mesi. Questo approccio 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.

Passaggi successivi