Best practice per l'upgrade dei cluster

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

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

configura più ambienti

Come parte del 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. Dovresti avere un ambiente di produzione e un ambiente di pre-produzione o test.

Considera i seguenti ambienti consigliati:

Ambiente Descrizione
Produzione Utilizzato per distribuire traffico in tempo reale agli utenti finali per applicazioni aziendali mission critical.
Gestione temporanea Utilizzato per garantire che tutte le nuove modifiche di cui è stato eseguito il deployment da ambienti precedenti funzionino come previsto prima del deployment in produzione.
Test in corso Utilizzato per il benchmark delle prestazioni, il test e il QA dei carichi di lavoro 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 nuove release di Kubernetes, le funzionalità e le API GKE per ottenere un time to market migliore dopo che queste release vengono promosse e diventano predefinite.

Registra i cluster nei canali di rilascio

Kubernetes rilascia spesso aggiornamenti per fornire aggiornamenti della sicurezza, risolvere problemi noti e introdurre nuove funzionalità. I canali di rilascio di GKE offrono la possibilità di bilanciare la stabilità e l'insieme 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 cadenza della versione e dell'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 regolare per i carichi di lavoro di produzione.
Gestione temporanea Uguale al canale di 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 in corso
Sviluppo
Canary Rapido Per testare le ultime release di Kubernetes e stare al passo con i tempi testando nuove funzionalità o API GKE, utilizza il canale Rapido. Puoi migliorare il time to market quando la versione in rapida viene promossa sul canale che utilizzi per la produzione.

L'upgrade dei piani di controllo dei 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 la registrazione del cluster in un canale di rilascio, viene eseguito regolarmente l'upgrade del cluster alla versione che soddisfa i requisiti di qualità e stabilità per il canale. Questi aggiornamenti includono correzioni di bug e di sicurezza, applicate con controlli sempre più frequenti in ogni canale:

  • Le patch vengono inviate gradualmente al piano di controllo e ai nodi in tutti i canali, accumulando il tempo di sospensione nei canali rapidi e regolari prima di raggiungere il canale stabile.
  • Viene eseguito prima l'upgrade del piano di controllo, seguito dai nodi per la conformità ai criteri di Kubernetes OSS (ad es. kubelet non deve essere più recente di kube-apiserver).
  • GKE implementerà 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 in un feed RSS. Ogni canale di rilascio dispone di una pagina semplificata e dedicata alle note di rilascio (ad esempio: Note di rilascio per il canale stabile) con informazioni sulla versione 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.

Quando una nuova versione diventa disponibile, devi pianificare un upgrade prima che la versione diventi predefinita nel parco risorse. Questo approccio offre maggiore controllo e prevedibilità se necessario, poiché GKE ignorerebbe l'upgrade automatico per i cluster di cui è già stato eseguito l'upgrade in anticipo.

Testare e verificare le nuove patch e le versioni secondarie

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

Ogni canale di rilascio offre due versioni: predefinita e disponibile.

  • Nuove release di 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 automaticamente l'upgrade dei cluster alla versione predefinita in modo graduale. Se è necessario un maggiore controllo sul processo di upgrade, ti consigliamo di eseguire l'upgrade in anticipo a una versione disponibile. Gli upgrade automatici di GKE saltano i cluster con upgrade manuale.

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 tuo team delle nuove versioni disponibili da testare e certificare.
  • Un ambiente di produzione iscritto 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 del 100%.

La seguente tabella riassume gli eventi relativi alle release 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, quindi 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 posponi l'upgrade utilizzando le finestre di esclusione di 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 prima implementate 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 patch. Esegui l'upgrade dell'ambiente di gestione temporanea.
T La versione patch diventa predefinita. Valuta la possibilità di eseguire l'upgrade del piano di controllo della produzione in anticipo per una migliore prevedibilità.
T GKE avvierà l'upgrade dei piani di controllo alla versione predefinita. Valuta la possibilità di eseguire l'upgrade dei pool di nodi di produzione in anticipo per una migliore prevedibilità.
T + 1 settimana GKE inizierà l'upgrade dei pool di nodi cluster alla versione predefinita. GKE eseguirà l'upgrade automatico dei cluster, saltando quelli con upgrade manuale.

Strategia di upgrade per le nuove uscite secondarie

Ecco una strategia di upgrade consigliata per le nuove uscite di minore entità:

Tempo Evento Che cosa devo fare?
T - 3 settimane È disponibile una nuova versione secondaria Esegui l'upgrade del piano di controllo per il test
T - 2 settimane
  1. Dato che l'upgrade del piano di controllo è andato a buon fine, valuta la possibilità di eseguire in anticipo l'upgrade del piano di controllo di produzione.
  2. Esegui l'upgrade dei pool di nodi di test.
T - 1 settimana Dato che 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 inizierà l'upgrade dei piani di controllo del cluster alla versione predefinita. 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 pool di nodi cluster alla versione predefinita. GKE eseguirà l'upgrade automatico dei cluster, saltando 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. Aggiornamenti regolari proteggono i carichi di lavoro da vulnerabilità e errori.

Pianifica periodi di manutenzione ed esclusioni

Per aumentare la prevedibilità degli upgrade e allineare gli upgrade in orari di punta, puoi controllare gli upgrade automatici sia del piano di controllo che dei nodi creando un periodo 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 successivo periodo di manutenzione.

GKE segue una pianificazione di implementazione di più giorni per rendere disponibili nuove versioni, nonché l'upgrade automatico dei piani di controllo e dei nodi del cluster in diverse regioni. L'implementazione 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 al fine di sequenza l'implementazione nei vari 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à più richiesta, sono le esclusioni di manutenzione. Utilizza le esclusioni di manutenzione per evitare che la manutenzione automatica si verifichi 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 un upgrade a un cluster di produzione se un ambiente di test o di gestione temporanea ha esito negativo a causa di un upgrade.

Imposta la tolleranza alle interruzioni

Potresti già conoscere il concetto di replicas in Kubernetes. Le repliche garantiscono la ridondanza dei carichi di lavoro per migliorare prestazioni e reattività. Se impostato, le repliche regolano 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 carichi di lavoro dispongano di un numero sufficiente di repliche per le 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 pienamente operativi. Elimina invece 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 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 del pool di nodi

Con GKE, puoi scegliere una strategia di upgrade dei nodi per determinare in che modo verrà eseguito l'upgrade dei nodi nei tuoi pool di nodi. Per impostazione predefinita, i pool di nodi utilizzano gli upgrade di sovraccarico. Con gli upgrade di sovraccarico, il processo 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 con upgrade eseguito) in modalità di 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 tuoi carichi di lavoro possono essere eseguiti con una ridondanza sufficiente (repliche) e puoi fare affidamento su Kubernetes per spostare e riavviare i pod in base alle necessità. Tuttavia, un numero temporaneamente ridotto di repliche può comunque influire negativamente sulla tua attività e rallentare le prestazioni del carico di lavoro finché Kubernetes non riesce a raggiungere nuovamente lo stato desiderato (ovvero il numero minimo di repliche necessario). Puoi evitare questo tipo di interruzione utilizzando gli upgrade di sovraccarico.

Durante un upgrade in cui è abilitato l'upgrade di sovraccarico, GKE prima protegge le risorse (macchine) necessarie per l'upgrade, quindi crea un nuovo nodo sottoposto ad upgrade, svuota il nodo precedente e infine lo arresta. In questo modo, la capacità prevista rimane intatta durante tutto il 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 contemporaneamente 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 tabella seguente riassume le attività consigliate per una strategia di upgrade al fine di mantenere i tuoi cluster GKE sempre aggiornati:

Best practice Attività
configura 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