Best practice per l'upgrade dei cluster

Questa pagina fornisce linee guida per conservare Google Kubernetes Engine (GKE) aggiornato e offre suggerimenti per la creazione di un upgrade strategia più adatta alle tue esigenze e aumenta la disponibilità e l'affidabilità ambienti cloud-native. Puoi utilizzare queste informazioni per mantenere aggiornati i cluster per la stabilità e la sicurezza con interruzioni minime dei carichi di lavoro.

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

configura più ambienti

Come parte del flusso di lavoro per la distribuzione di aggiornamenti software, ti consigliamo di usano più ambienti. Ambienti multipli consentono di ridurre al minimo i rischi tempi di inattività indesiderati testando gli aggiornamenti del software e dell'infrastruttura separatamente dell'ambiente di produzione. Dovresti avere almeno un modello di produzione e un ambiente di pre-produzione o test.

Considera i seguenti ambienti consigliati:

Ambiente Descrizione
Produzione Utilizzato per fornire traffico in tempo reale agli utenti finali per attività mission critical diverse applicazioni.
Gestione temporanea Utilizzato per garantire che il deployment di tutte le nuove modifiche rispetto ai precedenti funzionino come previsto prima del deployment delle modifiche e produzione.
Test Utilizzato per benchmark delle prestazioni, test e QA dei carichi di lavoro rispetto alla GKE che utilizzerai in produzione. In questo 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 e produzione. In questo ambiente, puoi creare correzioni e delle modifiche di cui deve essere eseguito il deployment in produzione.
Canary Utilizzato come ambiente di sviluppo secondario per testare le Rilasciate da Kubernetes, funzionalità e API di GKE per ottenere un time to market migliore una volta che queste release sono state promosse e diventeranno predefinite.

Registra i cluster nei canali di rilascio

Kubernetes rilascia spesso aggiornamenti, per fornire aggiornamenti della sicurezza, risolvere i problemi e introdurre nuove funzionalità. Canali di rilascio di GKE offrono la possibilità di bilanciare la stabilità e l'insieme di funzionalità del di cui è stato eseguito il deployment nel cluster. Quando registri un nuovo cluster in una release di destinazione, Google gestisce automaticamente la versione e la cadenza di upgrade per il cluster e i relativi pool di nodi.

Per mantenere i cluster aggiornati con le ultime versioni di GKE per gli aggiornamenti di 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 garantire stabilità e maturità della versione, usa 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 verrà eseguito l'upgrade della versione di produzione, usa lo stesso canale di rilascio della versione di produzione.
Test
Sviluppo
Canary Rapida Per testare le ultime release di Kubernetes e stare al passo con i tempi testando nuove funzionalità o API GKE, utilizza il rapido canale. Per migliorare il time to market quando la versione viene viene promosso al 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 una release canale o meno.

Crea una strategia di upgrade continuo

Dopo aver registrato il cluster in un canale di rilascio, il cluster viene regolarmente aggiornato alla versione che soddisfa i requisiti di qualità e stabilità per canale. Questi aggiornamenti includono correzioni di bug e di sicurezza, applicati con controllo in ogni canale:

  • Le patch vengono inviate gradualmente al piano di controllo e ai nodi in tutti i canali, accumulando tempo di sospensione in canali rapidi e regolari prima di arrivare canale stabile.
  • Viene eseguito prima l'upgrade del piano di controllo, seguito dai nodi per rispettare le Criterio Kubernetes OSS (ad es. kubelet non deve essere più recente di kube-apiserver).
  • GKE implementerà automaticamente le patch sui canali in base sulla loro criticità e importanza.
  • Il canale stabile riceve solo patch critiche.

Ricevi aggiornamenti sulle nuove versioni di GKE

Le informazioni sulle nuove versioni sono pubblicate nelle note di rilascio principali di GKE oltre che a un feed RSS. Ogni canale di rilascio ha un pagina delle note di rilascio dedicata (esempio: Note di rilascio per canale stabile) con informazioni sulla versione GKE consigliata quel canale.

Per ricevere proattivamente aggiornamenti sugli upgrade di GKE prima gli upgrade, usa Pub/Sub e iscriviti alle notifiche di upgrade.

Quando una nuova versione diventa disponibile, è consigliabile pianificare un upgrade prima che la versione diventi predefinita nel parco risorse. Questo approccio offre maggiore controllo e prevedibilità quando 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 in. Tuttavia, a causa degli aggiornamenti e delle patch frequenti da Kubernetes upstream, GKE, consigliamo vivamente di testare le nuove release e/o ambienti di gestione temporanea prima dell'implementazione delle release nel tuo di produzione, in particolare gli upgrade di 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 per impostazione predefinita.

GKE esegue automaticamente l'upgrade dei cluster alla versione predefinita gradualmente. Se è necessario un maggiore controllo sul processo di upgrade, eseguire l'upgrade in anticipo a una versione disponibile. Upgrade automatico di GKE ignora 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 di nuove le versioni disponibili per testare e certificare.
  • Un ambiente di produzione iscritto a un canale di rilascio utilizzando l'impostazione predefinita più recente nel canale.
  • Implementazione graduale delle nuove versioni disponibili nei cluster di produzione. Per Ad esempio, nel caso in cui siano presenti più cluster di produzione, un piano di upgrade graduale inizia eseguendo l'upgrade di una parte di questi cluster mantenendo le altre sulla versione predefinita, seguita da upgrade aggiuntivi per piccole porzioni fino a quando non viene eseguito l'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 finestre 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 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.
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 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 minori

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

Ora 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 l'upgrade di controllo della produzione in anticipo.
  2. Esegui l'upgrade dei pool di nodi di test.
T - 1 settimana Dato che l'upgrade è riuscito, 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 la 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 del nodo cluster pool alla versione predefinita. GKE eseguirà l'upgrade automatico dei cluster, saltando per i cluster 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 tuoi cluster e la continuità aziendale. Regolare gli aggiornamenti proteggono i carichi di lavoro dalle vulnerabilità e gli errori.

Pianifica periodi di manutenzione ed esclusioni

Per aumentare la prevedibilità degli upgrade ed allinearli alle attività non di punta ore, 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 l'upgrade di manutenzione viene eseguito oltre il periodo di manutenzione definito, tenta di mettere in pausa l'operazione e la riprende durante periodo di manutenzione.

GKE segue una pianificazione di implementazione di più giorni rendendo disponibili nuove versioni e con l'upgrade automatico dei piani di controllo del cluster e nodi 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 multi-cluster, puoi utilizzare un periodo di manutenzione separato per ogni per sequenziare l'implementazione nei vari cluster. Ad esempio, potresti vuoi controllare quando i cluster in regioni diverse ricevono la manutenzione e impostare finestre di manutenzione diverse per ogni cluster.

Un altro strumento per ridurre le interruzioni, soprattutto durante le attività più richieste periodi, è la manutenzione esclusioni. Utilizza le esclusioni di manutenzione per evitare la manutenzione automatica durante questi periodi; le esclusioni di manutenzione possono essere impostate su modelli nuovi o esistenti cluster. 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 di test o di gestione temporanea non riesce a causa di un upgrade.

Imposta la tolleranza alle interruzioni

Forse hai già familiarità con il concetto di repliche in Kubernetes. Le repliche garantiscono la ridondanza dei carichi di lavoro per migliorare per migliorare le prestazioni e la reattività. Se impostato, le repliche regolano il numero di pod di repliche in qualsiasi momento. Tuttavia, durante la manutenzione, e rimuove le VM dei nodi sottostanti, il che può ridurre il numero di repliche. A garantire che i carichi di lavoro 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 il numero (o la percentuale) di pod che può essere arrestata, anche se l'arresto dei pod genera il numero di repliche attuale inferiore al valore desiderato. Questo processo può accelerare lo svuotamento dei nodi rimuovendo occorre attendere che i pod migrati diventino pienamente operativi. Svuota invece rimuove i pod da un nodo dopo la configurazione PDB, consentendo il deployment eseguire il deployment dei pod mancanti su altri nodi disponibili. Una volta impostato il PDB, GKE non arresta 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.

Controlla gli upgrade del pool di nodi

Con GKE, puoi scegliere una strategia di upgrade dei nodi per determinare la modalità di upgrade dei nodi nei pool. Per impostazione predefinita, che utilizzano gli upgrade delle picchi. Con gli upgrade di sovraccarico, per i pool di nodi GKE prevede la ricreazione di ogni VM del pool di nodi. Viene creata una nuova VM con la nuova versione (con upgrade eseguito dell'immagine) con un aggiornamento in sequenza. A sua volta, ciò richiede l'arresto di tutte Pod in esecuzione sul nodo precedente e che li spostano su quello nuovo. Il tuo i carichi di lavoro possono essere eseguiti con ridondanza sufficiente (repliche) e puoi fare affidamento di spostare e riavviare i pod in base alle esigenze. Tuttavia, una limitazione temporanea di repliche può comunque influire negativamente sulla tua attività e rallentare le prestazioni del carico di lavoro finché Kubernetes non riesce a soddisfare lo stato desiderato (soddisfare il numero minimo di repliche necessarie). Puoi evitare questo tipo di un'interruzione utilizzando gli upgrade di sovraccarico.

Durante un upgrade con upgrade di sovraccarico abilitato, GKE prima protegge le risorse (macchine) necessarie per l'upgrade, quindi crea ha eseguito l'upgrade del nodo, solo a quel punto svuota il vecchio nodo 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 i tempi di completamento dell'upgrade eseguendo contemporaneamente l'upgrade di più nodi alla volta. Usa l'upgrade di incremento con maxSurge=20, maxUnavailable=0 per indicare GKE a eseguire l'upgrade di 20 nodi alla volta, senza utilizzare e la capacità di archiviazione.

Riepilogo elenco di controllo

La tabella seguente riassume le attività consigliate per un upgrade per mantenere i tuoi cluster GKE perfettamente aggiornati:

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