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 aggiornati i tuoi cluster in termini di stabilità e sicurezza con interruzioni minime ai 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 del software e dell'infrastruttura separatamente dall'ambiente di produzione. Come minimo, devi avere un ambiente di produzione e un ambiente di pre-produzione o test.

Valuta i seguenti ambienti consigliati:

Ambiente Descrizione
Produzione Utilizzato per pubblicare traffico in tempo reale per gli utenti finali per applicazioni aziendali mission-critical.
Gestione temporanea Viene utilizzato per assicurarsi che tutte le nuove modifiche implementate dagli ambienti precedenti funzionino come previsto prima che vengano implementate in produzione.
Test Utilizzato per eseguire benchmark sul rendimento, test e QA dei carichi di lavoro rispetto alla release 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 produzione. In questo ambiente, crei correzioni e modifiche incrementali da eseguire in produzione.
Canary Utilizzato come ambiente di sviluppo secondario per testare le release di Kubernetes, le funzionalità e le API di GKE più recenti al fine di ottenere un migliore time to market una volta che queste release vengono promosse e diventano target di upgrade automatico.

Registra 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 GKE ti consentono 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 la stabilità e la maturità della versione, utilizza il canale stabile o regolare per i carichi di lavoro di produzione.
Gestione temporanea Uguale alla 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 Rapida Per testare le ultime release di Kubernetes e anticipare le tendenze testando nuove API o funzionalità 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 in una versione secondaria per più tempo continuando a ricevere patch di sicurezza dopo la fine della data di assistenza standard, utilizza il canale esteso. Per scoprire di più, consulta Utilizzare il canale esteso quando hai bisogno di 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.

Crea una strategia di upgrade continuo

Dopo aver registrato il cluster in un canale di rilascio, viene eseguito regolarmente un upgrade alla versione che soddisfa gli standard di qualità e stabilità del canale. Questi aggiornamenti includono correzioni di bug e della sicurezza, applicate con un controllo sempre più approfondito in ogni canale:

  • Le patch vengono inviate gradualmente al piano di controllo e ai nodi in tutti i canali, accumulando tempo di attesa nei canali Rapido e Regolare prima di essere pubblicate nel canale Stabile.
  • Viene eseguito prima l'upgrade del piano di controllo, seguito dai nodi per rispettare le norme relative ai progetti open source di Kubernetes che richiedono 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 di note di rilascio semplificata e dedicata (ad es. Note di rilascio per il canale stabile) con informazioni sulla versione di GKE consigliata per quel canale.

Per ricevere proattivamente aggiornamenti sugli upgrade di GKE prima dell'esecuzione degli upgrade, 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 dell'upgrade automatico per il cluster. Questo approccio offre maggiore controllo e prevedibilità, se necessario, perché GKE non esegue l'upgrade automatico di un cluster se il target di upgrade automatico disponibile è precedente o uguale alla versione a cui hai già eseguito l'upgrade manuale del cluster. Per ottenere i target di upgrade automatico per un cluster specifico, consulta Ottenere informazioni sugli upgrade di un cluster (anteprima).

Testare e verificare le nuove patch e le versioni minori

Tutte le release superano i test interni, indipendentemente dal canale su cui vengono rilasciate. Tuttavia, con gli aggiornamenti e le patch frequenti di Kubernetes e GKE upstream, ti consigliamo vivamente di testare le nuove release negli ambienti di test e/o di staging prima che vengano implementate nell'ambiente di produzione, in particolare gli upgrade delle versioni minori 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 obiettivi di upgrade automatico.
  • Le nuove release minori 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 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.
  • Notifiche di upgrade configurate sul cluster per informare il team delle nuove versioni disponibili da testare e certificare.
  • Un ambiente di produzione iscritto a un canale di release 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 nella versione esistente, seguito da ulteriori upgrade di piccole parti fino a quando non viene eseguito l'upgrade del 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 avvia l'upgrade automatico alla destinazione di upgrade automatico. Valuta la possibilità di eseguire l'upgrade della produzione prima del parco.
GKE avvia l'upgrade automatico dei cluster. Consenti l'upgrade automatico dei cluster o rimanda l'upgrade utilizzando periodi di esclusione per la manutenzione.

Strategia di upgrade per le release delle patch

Di seguito è riportata una strategia di upgrade consigliata per le release delle 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.
  • 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 La nuova versione del patch diventa disponibile. Esegui l'upgrade dell'ambiente di staging.
T La versione patch diventa la destinazione dell'upgrade automatico. Valuta la possibilità di eseguire l'upgrade del piano di controllo di produzione in anticipo per una maggiore prevedibilità.
T GKE inizierà l'upgrade dei control plane al target di upgrade automatico. Valuta la possibilità di eseguire l'upgrade dei pool di nodi di produzione in anticipo per una maggiore prevedibilità.
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, ignorando quelli di cui è stato eseguito l'upgrade manualmente.

Strategia di upgrade per le nuove release secondarie

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

Ora Evento Che cosa devo fare?
T - 3 settimane Viene resa disponibile una nuova versione minore Control plane di test dell'upgrade
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 la destinazione dell'upgrade automatico.
T GKE inizierà a eseguire l'upgrade dei control plane dei cluster al target di upgrade automatico. Crea una finestra di esclusione se sono necessari ulteriori test o mitigazioni prima del lancio in produzione.
T + 1 settimana GKE inizierà a eseguire l'upgrade dei pool di nodi del cluster al target di upgrade automatico. GKE eseguirà l'upgrade automatico dei cluster, ignorando quelli di cui è stato eseguito l'upgrade manualmente.

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 periodici proteggono i carichi di lavoro 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 sia del control plane sia dei nodi creando un periodo di manutenzione. GKE rispetta i periodi di manutenzione. In particolare, se il processo di upgrade supera il periodo di manutenzione definito, GKE tenta di mettere in pausa l'operazione e la riprende durante il successivo periodo di manutenzione.

GKE segue una pianificazione di implementazione di più giorni per la messa a disposizione di nuove versioni, nonché per l'upgrade automatico dei piani di controllo e dei nodi dei cluster in regioni diverse. L'implementazione in genere dura quattro o più giorni e include un periodo di tempo di riserva per osservare e monitorare la presenza di problemi. In un ambiente multi-cluster, puoi utilizzare una periodo di manutenzione separata per ciascun 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 ciascun cluster.

Un altro strumento per ridurre le interruzioni, soprattutto durante i periodi di elevata domanda, sono le esclusioni per manutenzione. Utilizza le esclusioni di manutenzione per impedire la manutenzione automatica 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 posticipare un 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

Probabilmente conosci il concetto di repliche in Kubernetes. Le repliche garantiscono la ridondanza dei carichi di lavoro per migliorare le prestazioni e la reattività. Se impostato, il parametro replicas regola il numero di repliche di pod in esecuzione in un determinato momento. Tuttavia, durante la manutenzione, Kubernetesrimuove le VM dei nodi sottostanti, il che può ridurre il numero di repliche. Per assicurarti che i tuoi carichi di lavoro dispongano di 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 fa scendere il numero di repliche corrente al di sotto del valore desiderato. Questo processo può velocizzare lo svuotamento dei nodi rimuovendo la necessità di attendere che i pod di cui è stata eseguita la migrazione diventino completamente operativi. Al contrario, il comando drain consente di eliminare i pod da un nodo in base alla configurazione del PDB, consentendo 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 in che modo viene eseguito l'upgrade dei nodi nei pool di nodi. Per impostazione predefinita, i pool di nodi utilizzano gli upgrade di picco. 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 upgrade) in un aggiornamento in sequenza. Ciò richiede la disattivazione di tutti i pod in esecuzione sul vecchio nodo e il trasferimento dei pod al nuovo nodo. I tuoi workload possono essere eseguiti con una ridondanza (repliche) sufficiente e puoi fare affidamento su Kubernetes per spostare e riavviare i pod in base alle esigenze. Tuttavia, un numero ridotto temporaneamente delle repliche può comunque causare interruzioni nella tua attività e potrebbe rallentare le prestazioni del carico di lavoro finché Kubernetes non è in grado di soddisfare nuovamente lo stato preferito (ovvero soddisfare il numero minimo di repliche necessarie). Puoi evitare questo tipo di interruzione utilizzando gli upgrade per picchi.

Durante un upgrade con l'upgrade di incremento abilitato, GKE prima protegge le risorse (macchine) necessarie per l'upgrade, poi crea un nuovo nodo di cui è stato eseguito l'upgrade e solo dopo rimuove il vecchio nodo e lo spegne. In questo modo, la capacità prevista rimane invariata durante la procedura 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 esteso quando hai bisogno di assistenza a lungo termine

Se vuoi mantenere il cluster su una versione secondaria per più tempo, segui la migliore prassi di registrazione del cluster nel canale esteso. Con questo canale, GKE supporta una versione secondaria per circa 24 mesi. Per scoprire di più, consulta Ricevere assistenza a lungo termine con il canale Extended.

Per ottenere il massimo dal canale, ti consigliamo di attenerti alle seguenti best practice. Alcune di queste best practice richiedono alcune azioni manuali, tra cui l'upgrade manuale di un cluster e la modifica del canale di rilascio di un cluster. Esamina i seguenti scenari supportati, nonché la sezione Quando non usare il canale esteso.

Rimanere temporaneamente con una versione secondaria per più tempo

Se devi mantenere temporaneamente un cluster su una versione secondaria per più del periodo di assistenza standard di 14 mesi, ad esempio per ridurre l'utilizzo delle API deprecate rimosse nella versione secondaria successiva, utilizza la procedura riportata di seguito. 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 spostalo nuovamente sul canale di rilascio originale.

Upgrade delle versioni secondarie 1-2 volte all'anno

Se vuoi che il tuo cluster subisca interruzioni minime, pur continuando a ricevere alcune nuove funzionalità quando è pronto per l'upgrade a una nuova versione secondaria, svolgi i seguenti passaggi:

  • 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 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 alle 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. Il seguente scenario illustra le conseguenze dell'utilizzo del canale esteso senza la 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 devi fare altro. Tutte le versioni secondarie vengono ritirate 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, in media ogni circa 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 elenco di controllo

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

Best practice Tasks
Configurare 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