Upgrade di cluster standard

Questa pagina illustra il funzionamento degli upgrade automatici e manuali Cluster Google Kubernetes Engine (GKE) Standard, con link a ulteriori informazioni su attività e impostazioni correlate. Puoi utilizzare queste informazioni per mantenere i tuoi cluster aggiornati e garantire stabilità e sicurezza con e interruzioni dei carichi di lavoro.

Per informazioni su come funzionano gli upgrade dei cluster per Autopilot, vedi Upgrade dei cluster Autopilot.

Come funzionano gli upgrade dei cluster e dei pool di nodi

Questa sezione illustra cosa succede nel cluster durante le operazioni automatiche o manuali upgrade. Per gli upgrade automatici, GKE avvia l'upgrade automatico. GKE osserva gli upgrade automatici e manuali in tutti GKE e interviene in caso di problemi.

Per eseguire l'upgrade di un cluster, GKE aggiorna la versione del piano di controllo e nodi sono in esecuzione. Viene eseguito l'upgrade dei cluster a una versione secondaria più recente (ad esempio, dalla versione 1.24 alla 1.25) o una versione patch più recente (ad esempio, da 1.24.2-gke.100 a 1.24.5-gke.200). Per ulteriori informazioni, consulta Controllo delle versioni e assistenza di GKE.

Se registri il cluster in un canale di rilascio, i nodi eseguono la stessa versione di GKE del cluster, in un breve periodo (in genere alcuni giorni, a seconda della release corrente) tra il completamento dell'upgrade del piano di controllo del cluster e l'avvio del pool di nodi o se è stato eseguito manualmente l'upgrade del piano di controllo. Controlla il note di rilascio per ulteriori informazioni.

Upgrade dei cluster

Questa sezione illustra cosa aspettarsi quando GKE esegue l'upgrade automatico o avvii una procedura manuale upgrade.

  • Zonal di rete hanno un solo piano di controllo. Durante l'upgrade, continuano a essere eseguiti, ma non puoi eseguire il deployment di nuovi carichi di lavoro, carichi di lavoro esistenti o apportare altre modifiche alla configurazione del cluster l'upgrade è completo.

  • A livello di regione cluster hanno più repliche del piano di controllo e solo una replica viene eseguito simultaneamente, in un ordine indefinito. Durante l'upgrade, il cluster rimane ad alta disponibilità e ogni replica del piano di controllo non è disponibile solo durante l'upgrade.

Se configuri periodo di manutenzione o esclusione, se possibile.

Upgrade del pool di nodi

Questa sezione illustra cosa aspettarsi quando GKE esegue l'upgrade automatico pool di nodi o avvii un upgrade manuale del pool di nodi.

GKE esegue automaticamente l'upgrade di un pool di nodi alla volta in un cluster. In alternativa, puoi eseguire manualmente l'upgrade di uno o più pool di nodi in parallelo. Di per impostazione predefinita, l'upgrade dei nodi all'interno di un pool di nodi viene eseguito uno alla volta in ordine. In un pool di nodi distribuito zone, upgrade avvengono zona per zona. All'interno di una zona, l'upgrade dei nodi verrà eseguito in un ordine indefinito.

Con gli upgrade del pool di nodi GKE, puoi scegliere tra due strategie di upgrade integrate e configurabili in cui puoi ottimizzare il processo di upgrade in base alle esigenze dell'ambiente del cluster. A ulteriori informazioni sulle strategie di upgrade Surge e blu/verde, consulta Esegui l'upgrade delle strategie.

Durante l'upgrade di un pool di nodi, non puoi apportare modifiche alla configurazione del cluster a meno che non annulli upgrade.

GKE rispetta i periodi di manutenzione esclusioni durante gli upgrade automatici, se possibile. Gli upgrade manuali ignorano la configurazione periodi di manutenzione ed esclusioni.

Modalità di upgrade dei nodi

Durante l'upgrade di un pool di nodi, la modalità di upgrade dei nodi dipende dal pool di nodi della strategia di upgrade e come configuri . Tuttavia, i passaggi di base rimangono coerenti. Per eseguire l'upgrade di un nodo, GKE rimuove i pod dal nodo per consentirne l'upgrade.

Quando viene eseguito l'upgrade di un nodo, con i pod si verifica quanto segue:

  1. Il nodo è contrassegnato come non pianificabile in modo che Kubernetes non pianifica nuovi pod al suo interno.
  2. Il nodo viene quindi svuotato, il che significa che i pod vengono rimossi. Per picco degli upgrade, GKE rispetta il PodDisruptionBudget del pod e GracefulTerminationPeriod impostazioni per un massimo di un'ora. Con gli upgrade blu/verde, può essere esteso se configuri un periodo di sospensione più lungo.
  3. Il piano di controllo ripianifica i pod gestiti dai controller su altri nodi. I pod che non possono essere ripianificati rimangono nella fase In attesa finché non possono essere riprogrammato.

Il processo di upgrade del pool di nodi può richiedere alcune ore, a seconda del la strategia di upgrade, il numero di nodi e le configurazioni dei carichi di lavoro.

Considerazioni che influiscono sulla durata dell'upgrade dei nodi

Le configurazioni che possono comportare tempi più lunghi per il completamento dell'upgrade di un nodo includono:

Strategie di upgrade dei nodi

GKE offre strategie integrate configurabili che determinano viene eseguito l'upgrade del pool di nodi. Per scoprire di più sui tipi di modifiche che utilizzano un nodo di upgrade, consulta Quando GKE utilizza un picco upgrade e Quando GKE utilizza blu/verde upgrade.

Upgrade di Surge

Per impostazione predefinita, la strategia di upgrade dell'incremento viene utilizzata upgrade del pool di nodi. Gli upgrade di sovraccarico utilizzano un metodo in sequenza per eseguire l'upgrade dei nodi. Questo è l'ideale per le applicazioni in grado di gestire modifiche. Con questa strategia, viene eseguito l'upgrade dei nodi in una finestra temporale continua. Con le impostazioni consentono di cambiare il numero di nodi di cui è possibile eseguire l'upgrade contemporaneamente possono essere gravi, trovare l'equilibrio ottimale tra velocità e senza interruzioni per le esigenze del tuo ambiente.

Upgrade blu/verde

L'approccio alternativo sono gli upgrade blu/verde, in cui due insiemi di ambienti (quello originale e quello nuovo) vengono gestiti contemporaneamente, semplificando il più possibile il rollback. Blu-verde richiede un maggiore utilizzo di risorse e migliore per le applicazioni più sensibili alle modifiche. Con questa strategia, viene eseguita la migrazione graduale dei carichi di lavoro originale "blu" al nuovo ambiente "verde" dell'ambiente di lavoro e dato il tempo di sospensione per convalidarli con la nuova configurazione. Se necessario, i carichi di lavoro possono ha eseguito rapidamente il rollback allo stato "blu" esistente completamente gestito di Google Cloud.

Per saperne di più sul funzionamento delle strategie di upgrade dei nodi, consulta Strategie di upgrade dei nodi.

Requisiti delle risorse per le strategie di upgrade dei nodi

Gli upgrade di sovraccarico creano nodi aggiuntivi se il valore maxSurge è impostato su un valore superiore a 0 e gli upgrade blu/verde raddoppiano temporaneamente il numero di nodi in un pool di nodi. Ciò richiede risorse aggiuntive, soggette alle Quota Compute Engine, risorsa disponibilità e di prenotazione. Se il pool di nodi non dispone di risorse sufficienti, gli upgrade possono richiedere più tempo non riuscito.

Scopri di più su come assicurarti che il tuo progetto abbia risorse sufficienti per il nodo upgrade e cosa fare se il tuo ambiente è vincolato alle risorse, consulta Garantisci le risorse per il nodo upgrade.

Upgrade automatico

Quando crei un cluster Standard, per impostazione predefinita è abilitato l'upgrade automatico sul cluster e sui suoi pool di nodi.

GKE è responsabile di garantire il controllo del cluster aereo e upgrade dei cluster quando viene selezionata una nuova versione GKE upgrade automatico. La sicurezza dell'infrastruttura è elevata la priorità per GKE, per cui viene eseguito l'upgrade dei piani di controllo regolarmente e non possono essere disattivati. Tuttavia, puoi applicare una manutenzione finestre ed esclusioni, per sospendere temporaneamente gli upgrade di piani di controllo e nodi.

Nell'ambito del modello di responsabilità condivisa di GKE, sei responsabile della sicurezza di nodi, container e pod. Nodo l'upgrade automatico è abilitato per impostazione predefinita. Sebbene sconsigliato, puoi disabilita l'upgrade automatico dei nodi. La disattivazione degli upgrade automatici dei nodi non blocca il piano di controllo del cluster upgrade. Se disattivi gli upgrade automatici dei nodi, è tua responsabilità assicurarti che i nodi del cluster eseguano una versione compatibile con la versione del cluster, e che la versione sia conforme ai criteri di supporto per il disallineamento delle versioni di Kubernetes.

Per un maggiore controllo su quando può avvenire (o non deve avvenire) un upgrade automatico, puoi configurare periodi di manutenzione ed esclusioni.

I pool di nodi di un cluster possono essere costituiti da un massimo di due versioni secondarie dietro il controllo completamente gestita per mantenere la compatibilità con l'API del cluster. Il pool di nodi determina anche le versioni dei pacchetti software installati su ciascun nodo. Ti consigliamo di mantenere i pool di nodi aggiornati alla versione del cluster.

Se registri il cluster in un canale di rilascio, i nodi eseguono sempre la stessa versione di GKE del cluster stessa, tranne che per un breve periodo (in genere alcuni giorni, a seconda del attuale) tra il completamento dell'upgrade del piano di controllo del cluster e iniziare a eseguire l'upgrade di un determinato pool di nodi. Consulta le note di rilascio per ulteriori informazioni.

Come vengono selezionate le versioni per l'upgrade automatico

Vengono rilasciate nuove versioni GKE regolarmente, ma una versione disponibili subito per l'upgrade automatico. Quando una versione GKE ha accumulato un utilizzo del cluster sufficiente per dimostrarne la stabilità nel tempo, GKE la seleziona come destinazione dell'upgrade automatico per i cluster che eseguono un sottoinsieme di versioni precedenti.

I nuovi target dell'upgrade automatico sono annunciati nelle note di rilascio. Fino a quando sia selezionata la versione per l'upgrade automatico, puoi eseguire l'upgrade manuale. A volte, una versione viene selezionati per l'upgrade automatico del cluster e dei nodi in diverse settimane.

Poco dopo che una nuova versione secondaria diventa in disponibilità generale, la più vecchia disponibile la versione secondaria in genere non è più supportata. Cluster che eseguono versioni secondarie che non saranno più supportate verrà eseguito automaticamente l'upgrade alla versione secondaria successiva.

All'interno di una versione secondaria (ad esempio v1.14.x), è possibile eseguire l'upgrade automatico dei cluster a una nuova versione patch.

Canali di rilascio permettono di controllare la versione del cluster e del pool di nodi in base alla la stabilità anziché la gestione diretta della versione.

Fattori che influenzano i tempi di implementazione della versione

Per garantire la stabilità e l'affidabilità dei cluster nelle nuove versioni, GKE segue alcune pratiche durante le implementazioni delle versioni.

Queste pratiche includono, a titolo esemplificativo:

  • GKE implementa gradualmente le modifiche in Google Cloud regioni e zone.
  • GKE implementa gradualmente le versioni delle patch nei canali di rilascio. A una patch viene assegnato il tempo di sospensione nel canale di rilascio rapido, quindi nel canale canale di rilascio, prima di essere promosso al canale di rilascio Stabile una volta che ha accumulato un utilizzo e ha continuato a dimostrare stabilità. Se un problema è trovata con una versione patch durante il tempo di sospensione su un canale di rilascio, la versione non viene promossa al canale successivo e il problema è stato risolto su una versione patch.
  • GKE implementa gradualmente le versioni secondarie, seguendo un processo di sospensione simile alle versioni patch. Versioni secondarie periodi di sospensione più lunghi, in quanto introducono cambiamenti più significativi.
  • GKE può ritardare gli upgrade automatici quando una nuova versione interessa un di un gruppo di cluster. Ad esempio, GKE mette in pausa upgrade automatici per i cluster che rileva sono esposti a un'API o una funzionalità deprecata che verrà rimossa nella prossima versione secondaria.
  • GKE potrebbe ritardare l'implementazione delle nuove versioni durante i periodi di picco (ad es. durante le festività più importanti) per garantire la continuità aziendale.

Configurare il momento in cui possono essere eseguiti gli upgrade automatici

Per impostazione predefinita, gli upgrade automatici possono avvenire in qualsiasi momento per preservare l'infrastruttura sicurezza. Gli upgrade automatici causano interruzioni minime, in particolare per le regioni cluster. Tuttavia, alcuni carichi di lavoro potrebbero richiedere un controllo più granulare. Puoi configurare periodi di manutenzione ed esclusioni per stabilire quando gli upgrade automatici possono o non devono essere eseguiti.

Upgrade manuale

Puoi richiedere a eseguire l'upgrade manuale del cluster o dei relativi pool di nodi a una versione disponibile e compatibile in qualsiasi momento. Gli upgrade manuali ignorano di manutenzione ed esclusioni di manutenzione configurate.

Quando esegui l'upgrade manuale di un cluster, la sua disponibilità dipende dal fatto che il cluster sia regionale o meno:

  • Per i cluster di zona, il piano di controllo non è disponibile mentre è in corso l'upgrade. Nella maggior parte dei casi, i carichi di lavoro vengono eseguiti normalmente, ma non modificati durante l'upgrade.

  • Per i cluster a livello di regione, una replica del piano di controllo non è disponibile in per un periodo di tempo durante l'upgrade, ma il cluster rimane ad alta disponibilità l'upgrade.

Puoi avviare manualmente un upgrade del nodo a una versione compatibile con il piano di controllo.

In che modo GKE risponde agli errori di upgrade automatico

Gli upgrade automatici del pool di nodi possono non riuscire a causa di problemi con Compute Engine sottostante di Compute Engine o a causa di problemi con Kubernetes. Ad esempio, gli upgrade automatici non riescono nelle seguenti situazioni:

  • L'impostazione maxSurge configurata supera le dimensioni di Compute Engine la quota di risorse.
  • I nuovi nodi di rilevamento non sono stati registrati con il piano di controllo del cluster.
  • Lo svuotamento dei nodi ha richiesto troppo tempo o troppo tempo per l'eliminazione.

Quando si verificano problemi con gli upgrade dei singoli nodi, GKE esegue un nuovo tentativo eseguire l'upgrade più volte, con un intervallo crescente tra i nuovi tentativi. Se i nodi in non viene eseguito l'upgrade del pool di nodi, GKE non esegue il rollback per i nodi con upgrade eseguito. GKE prova invece a eseguire l'upgrade automatico del pool di nodi di nuovo finché non sarà stato eseguito l'upgrade di tutti i nodi.

Se gli upgrade dei nodi non vanno a buon fine perché le richieste dei nodi di picco superano le risorse di Compute Engine quota, GKE riduce il numero di nodi di picco simultanei da tentare per raggiungere la quota e continuare l'upgrade.

Ricezione di notifiche di upgrade

GKE pubblica notifiche sugli eventi pertinenti per il tuo cluster, come upgrade della versione e bollettini sulla sicurezza a Pub/Sub, fornendo un canale per ricevere informazioni da GKE sui tuoi cluster.

Per ulteriori informazioni, vedi Ricezione di notifiche cluster.

Controlla i log di upgrade

Eventi di upgrade del piano di controllo e del pool di nodi dei log GKE in Cloud Logging, per impostazione predefinita. Il log degli eventi di upgrade fornisce visibilità sul processo di upgrade e include informazioni preziose per la risoluzione dei problemi, se necessario.

Log di upgrade del piano di controllo

È possibile eseguire query sugli eventi di upgrade del cluster utilizzando il seguente filtro:

resource.type="gke_cluster"
protoPayload.metadata.operationType=~"(UPDATE_CLUSTER|UPGRADE_MASTER)"
resource.labels.cluster_name="CLUSTER_NAME"

Questi log vengono registrati come formati di logging strutturati. Puoi utilizzare le seguenti opzioni campi per i dettagli degli eventi di upgrade:



Campo Descrizione
protoPayload.metadata.operationType Esistono due tipi di eventi di upgrade del cluster: UPGRADE_MASTER e UPDATE_CLUSTER.
UPGRADE_MASTER cambia la versione del piano di controllo Kubernetes.
UPDATE_CLUSTER significa che un aggiornamento non modifica la versione del piano di controllo Kubernetes.
Entrambi i tipi di upgrade dei cluster possono causare la perdita della disponibilità del piano di controllo per i cluster di zona. Per saperne di più, consulta Come funzionano gli upgrade dei cluster e del pool di nodi.
protoPayload.methodName Questo campo mostra l'API che ha attivato l'upgrade del cluster.
google.container.v1.ClusterManager.UpdateCluster: upgrade manuale del piano di controllo
google.container.internal.ClusterManagerInternal.UpdateClusterInternal: upgrade automatico del piano di controllo
google.container.v1.ClusterManager.PatchCluster: modifica alla configurazione del cluster.
protoPayload.metadata.previousMasterVersion Questo campo viene utilizzato solo per il tipo di operazione MASTER_UPGRADE e contiene la versione precedente del piano di controllo utilizzata prima dell'upgrade.
protoPayload.metadata.currentMasterVersion Questo campo viene utilizzato solo per il tipo di operazione MASTER_UPGRADE e contiene il nuovo numero di versione del piano di controllo utilizzato dopo l'upgrade.

Log di upgrade del pool di nodi

Usa la seguente query per visualizzare gli eventi di upgrade del pool di nodi: 

resource.type="gke_nodepool"
protoPayload.metadata.operationType="UPGRADE_NODES"
resource.labels.cluster_name="CLUSTER_NAME"

Utilizza il campo seguente per i dettagli sull'evento di upgrade:

Il campo protoPayload.methodName mostra se l'upgrade è stato attivato manualmente o automaticamente, come segue.

Upgrade dei componenti

GKE esegue carichi di lavoro di sistema sui nodi worker per supportare per i cluster. Ad esempio, il sistema gke-metadata-server per i carichi di lavoro Federazione delle identità dei carichi di lavoro per GKE. GKE è responsabile l'integrità di questi carichi di lavoro. Per saperne di più su questi componenti, consulta: alla documentazione per le funzionalità associate.

Quando nuove funzionalità o correzioni diventano disponibili per un componente, indica la versione patch in cui sono incluse. Per ottenere le ultime notizie di un componente, consulta la documentazione o la release associata note per istruzioni sull'upgrade dal piano di controllo o dai nodi alla versione appropriata.

Passaggi successivi