Best practice per l'upgrade dei cluster

Questa pagina fornisce linee guida per mantenere aggiornato il tuo cluster Google Kubernetes Engine (GKE) e consigli 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 per garantire stabilità e sicurezza con interruzioni minime ai tuoi 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

Nell'ambito del flusso di lavoro per la distribuzione degli aggiornamenti software, ti consigliamo di utilizzare 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. 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 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, 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, 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 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 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 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 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 anticipare le tendenze testando nuove API o funzionalità di GKE, utilizza il canale Rapido. Puoi migliorare il time to market quando la versione nel Il canale rapido viene promosso al canale che utilizzi per la produzione.
N/D Esteso Per conservare il cluster in una versione secondaria più a lungo mentre se ricevi patch di sicurezza dopo la data di assistenza standard, utilizza 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 i requisiti di qualità e stabilità del 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 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 Criterio Kubernetes OSS che 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.

Ricevere 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 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 gli upgrade, usa Pub/Sub e iscriviti alle notifiche di upgrade.

Quando una nuova versione diventa available, è necessario pianificare un upgrade prima che la versione diventi l'upgrade automatico target 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.

Testare e verificare le nuove patch e le versioni secondarie

Tutte le release superano i test interni, indipendentemente dal canale su cui vengono rilasciate. 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 più versioni disponibili, inclusa una versione predefinita versione per la creazione del cluster e l'upgrade automatico target:

  • Nuove release di patch sono disponibili una settimana prima dell'upgrade automatico target.
  • Le nuove release secondarie di Kubernetes sono disponibili quattro settimane prima che diventano target di upgrade automatico.

GKE esegue automaticamente l'upgrade dei cluster alle versioni più recenti. Se è necessario avere un maggiore controllo sul processo di upgrade; consigliamo di eseguire l'upgrade prima tempo necessario a una versione disponibile. GKE non esegue l'upgrade automatico di cluster sottoposti ad upgrade manuale alla stessa destinazione.

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. 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 nella versione esistente, 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 è disponibile in un canale. Esegui l'upgrade manuale del cluster di test, quindi 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 al target di upgrade automatico. 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 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 gestione temporanea.
T La versione del patch diventa la destinazione dell'upgrade automatico. Valuta la possibilità di eseguire l'upgrade del piano di controllo della produzione in anticipo per una migliore 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 alla destinazione dell'upgrade automatico. GKE eseguirà l'upgrade automatico dei cluster, saltando quelli con upgrade manuale.

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 Esegui l'upgrade del piano di controllo per il 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 dell'upgrade automatico.
T GKE inizierà l'upgrade dei piani di controllo del cluster il target dell'upgrade automatico. Crea una finestra di esclusione se sono necessari ulteriori test o mitigazioni prima dell'implementazione 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. Regolare gli aggiornamenti proteggono i carichi di lavoro dalle vulnerabilità e gli errori.

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 piano di controllo sia dei nodi creando un periodo di manutenzione. GKE rispetta i periodi di manutenzione. Nello specifico, 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 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 ambiente con più cluster, puoi utilizzare una finestra 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.

Imposta la tolleranza alle interruzioni

Probabilmente conosci 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, 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 sottoposti a 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 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 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, 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, un calo temporaneamente 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. 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 se 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 Extended. Con questo GKE supporta una versione secondaria per circa 24 mesi. Per scoprire di più, consulta Ricevere assistenza a lungo termine con il canale Extended.

Per trarre il massimo vantaggio dal canale, ti consigliamo di rispettare le seguendo le best practice. Alcune di queste best practice richiedono un'azione manuale, incluso l'upgrade manuale di un cluster e la modifica della release canale di un cluster. Esamina i seguenti scenari supportati, nonché la sezione Quando non usare il canale esteso.

Rimani temporaneamente su una versione secondaria più a lungo

Se hai bisogno di mantenere temporaneamente un cluster in una versione secondaria per un periodo più lungo rispetto Ad esempio, un periodo di assistenza standard di 14 mesi per ridurre l'utilizzo di Per le API rimosse nella versione secondaria successiva, utilizza la procedura seguente. Puoi spostare temporaneamente il cluster da un altro canale di rilascio al canale Estenuto per continuare a ricevere patch di sicurezza mentre ti prepari a eseguire l'upgrade alla prossima versione secondaria. Quando vuoi eseguire l'upgrade alla versione secondaria successiva, esegui manualmente l'upgrade del cluster e poi riportalo alla versione originale canale di rilascio.

Upgrade della versione secondaria 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. Per Ad esempio, esegui l'upgrade da 1,30 a 1,31 a 1,32.

Questo processo garantisce che il cluster resti su una versione secondaria disponibile, riceve funzionalità dalle nuove versioni secondarie, ma solo una versione secondaria 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. La lo scenario che segue 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 conservare il cluster su una versione secondaria per sempre, registri i tuoi nel canale Extended e non intraprendi alcuna azione. Tutte le versioni secondarie alla fine non saranno più supportati e GKE esegue automaticamente l'upgrade dei cluster di istanze secondarie non supportate le versioni secondarie. Quindi, GKE esegue l'upgrade di questo cluster da una versione secondaria non supportata a una a breve una versione secondaria non supportata, con una media di circa ogni 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 senza problemi:

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