Upgrade di cluster Autopilot

Questa pagina illustra il funzionamento degli upgrade automatici sui cluster Autopilot di Google Kubernetes Engine (GKE), inclusi i link per ulteriori informazioni su attività e impostazioni correlate. Puoi utilizzare queste informazioni per mantenere aggiornati i tuoi cluster per garantire stabilità e sicurezza con interruzioni minime ai tuoi workload.

Per una panoramica generale degli upgrade dei cluster, consulta Informazioni sugli upgrade dei cluster GKE. Per informazioni su come funzionano gli upgrade dei cluster specificamente per Standard, consulta Upgrade dei cluster Standard.

Upgrade automatici del piano di controllo e dei nodi

Gli upgrade automatici sono abilitati su tutti i cluster Autopilot. GKE avvia gli upgrade automatici quando le versioni GKE sono selezionate per l'upgrade automatico, osserva gli upgrade automatici in tutti i cluster e interviene in caso di problemi come nodi non operativi. Non puoi disattivare gli upgrade automatici, ma puoi controllarne la tempistica con periodi di manutenzione ed esclusioni.

Per eseguire l'upgrade di un cluster, GKE aggiorna la versione in esecuzione del piano di controllo e dei nodi. Viene eseguito l'upgrade dei cluster a una versione secondaria più recente (ad esempio da 1.24 a 1.25) o a 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.

Tutti i cluster Autopilot sono registrati in un canale di rilascio, pertanto GKE esegue automaticamente l'upgrade del control plane e dei nodi in modo da eseguire la stessa versione di GKE.

GKE esegue l'upgrade del piano di controllo di un cluster prima di eseguire l'upgrade dei nodi.

Upgrade automatici del piano di controllo

Tutti i cluster Autopilot sono regionali. I cluster a livello di regione hanno più repliche del piano di controllo e viene eseguito l'upgrade di una sola replica alla volta, in un ordine indefinito. In questo modo, il cluster rimane altamente disponibile durante gli upgrade automatici. Ogni replica del piano di controllo non è disponibile solo durante l'upgrade.

Se configuri un periodo di manutenzione o un'esclusione, GKE rispetta la configurazione, se possibile.

GKE non può creare nuovi nodi quando è in corso un upgrade del piano di controllo. Se esegui il deployment di pod che richiedono nuovi tipi di nodi mentre è in corso un upgrade del piano di controllo, potresti riscontrare ritardi fino al completamento dell'upgrade.

Upgrade automatici del nodo

Dopo che GKE ha eseguito l'upgrade del piano di controllo del cluster Autopilot, esegue l'upgrade dei nodi alla stessa versione GKE.

In Autopilot, GKE raggruppa i nodi che condividono caratteristiche simili. GKE utilizza gli upgrade di sovraccarico per i nodi Autopilot, eseguendo l'upgrade di massimo 20 nodi in un gruppo contemporaneamente. Il numero esatto di nodi di cui viene eseguito l'upgrade contemporaneamente varia per garantire la continuità dell'alta disponibilità di nodi e carichi di lavoro.

Gli upgrade dei nodi potrebbero richiedere diverse ore, a seconda del numero di nodi e della configurazione dei workload in esecuzione nei nodi. Ad esempio, le seguenti configurazioni potrebbero contribuire a prolungare gli upgrade:

Se configuri un periodo di manutenzione o un'esclusione, GKE rispetta la configurazione, se possibile.

Quando GKE esegue l'upgrade di un nodo, vengono eseguiti i seguenti passaggi:

  1. GKE crea un nuovo nodo di picco con la nuova versione di GKE e attende che si registri al piano di controllo.
  2. GKE seleziona un nodo esistente, il nodo di destinazione, per l'upgrade.
  3. GKE isola il nodo di destinazione, impedendo l'inserimento di nuovi pod sul nodo di destinazione.
  4. GKE svuota il nodo di destinazione, espellendo i pod esistenti dal nodo di destinazione.

  5. GKE ripianifica i pod gestiti da un controller dei carichi di lavoro su altri nodi disponibili. I pod che non possono essere riprogrammati rimangono nello stato PENDING finché GKE non può riprogrammarli.

  6. GKE elimina il nodo target.

Se un numero significativo di upgrade automatici a una versione GKE specifica comporta nodi non integri nell'intera flotta GKE, GKE interrompe gli upgrade a quella versione mentre esaminiamo il problema.

Come vengono selezionate le versioni per l'upgrade automatico

GKE rilascia regolarmente nuove versioni secondarie, ma una versione rilasciata non viene selezionata immediatamente per gli upgrade automatici. Per poter essere considerata come destinazione di upgrade automatico, la versione GKE deve accumulare un utilizzo sufficiente per dimostrare la stabilità nel tempo.

Google Cloud seleziona quindi la versione come destinazione dell'upgrade automatico per i cluster che eseguono un sottoinsieme specifico di versioni GKE precedenti. Ad esempio, poco dopo la disponibilità di una nuova versione minore, la versione minore disponibile più vecchia in genere non è più supportata. GKE esegue l'upgrade dei cluster che eseguono versioni secondarie non supportate alla versione di destinazione dell'upgrade automatico.

GKE annuncia le nuove versioni di destinazione dell'upgrade automatico nelle note di rilascio. A volte, una versione viene selezionata per gli upgrade automatici del piano di controllo e dei nodi in settimane diverse. GKE esegue automaticamente l'upgrade alle nuove release delle patch all'interno di una versione minore (ad esempio la v1.21.x). Per ottenere i target di upgrade automatico per un cluster specifico, consulta Ottenere informazioni sugli upgrade di un cluster (anteprima).

Per informazioni sul ciclo di vita e sullo schema di controllo delle versioni, consulta Controllo delle versioni e assistenza di GKE.

Fattori che influiscono sulle tempistiche di implementazione della versione

Per garantire la stabilità e l'affidabilità dei cluster sulle nuove versioni, GKE segue determinate pratiche durante l'implementazione delle versioni.

Queste pratiche includono, a titolo esemplificativo:

  • GKE implementa gradualmente le modifiche nelle regioni e nelle zone di Google Cloud.
  • GKE implementa gradualmente le versioni delle patch nei canali di rilascio. A una patch viene assegnato un tempo di attesa nel canale di rilascio rapido, quindi nel canale di rilascio regolare, prima di essere promossa al canale di rilascio stabile dopo aver accumulato utilizzo e aver continuato a dimostrare stabilità. Se viene rilevato un problema con una versione della patch durante il periodo di attesa in un canale di rilascio, la versione non viene promossa al canale successivo e il problema viene risolto in una versione della patch più recente.
  • GKE implementa gradualmente le versioni secondarie, seguendo un processo di assorbimento simile a quello delle versioni patch. Le versioni minori hanno periodi di attesa più lunghi in quanto introducono modifiche più significative.
  • GKE potrebbe ritardare gli upgrade automatici quando una nuova versione influisce su un gruppo di cluster. Ad esempio, GKE mette in pausa gli upgrade automatici per i cluster che rileva essere esposti a un'API o a una funzionalità non più supportata che verrà rimossa nella versione secondaria successiva.
  • GKE potrebbe ritardare l'implementazione delle nuove versioni durante i periodi di picco (ad esempio le festività principali) per garantire la continuità aziendale.

Configurare quando possono verificarsi gli upgrade automatici

Per impostazione predefinita, gli upgrade automatici possono avvenire in qualsiasi momento. Gli upgrade automatici sono minimamente perturbanti, in particolare per i cluster Autopilot. Tuttavia, alcuni carichi di lavoro potrebbero richiedere un controllo più granulare. Puoi configurare periodi di manutenzione ed esclusioni per gestire quando possono e non devono verificarsi gli upgrade automatici.

Se configuri periodi di manutenzione ed esclusioni, l'upgrade non viene eseguito finché l'ora corrente non rientra in un periodo di manutenzione. Se una periodo di manutenzione scade prima del completamento dell'upgrade, GKE tenta di metterlo in pausa. GKE riprende l'upgrade durante il successivo periodo di manutenzione disponibile.

Eseguire l'upgrade manuale di un cluster Autopilot

Puoi eseguire manualmente l'upgrade della versione GKE del piano di controllo del cluster Autopilot. GKE esegue automaticamente l'upgrade dei nodi in modo che corrispondano alla versione del piano di controllo il prima possibile, in base alla disponibilità della manutenzione. Per le istruzioni, consulta Eseguire l'upgrade manuale del piano di controllo. Non puoi gestire manualmente la versione del nodo per i cluster Autopilot.

Puoi eseguire l'upgrade della versione del piano di controllo a una versione secondaria o patch supportata nello stesso canale di rilascio oppure a una versione patch della stessa versione secondaria del tuo cluster in un altro canale di rilascio.

Ad esempio, prendi in considerazione un cluster Autopilot che esegue GKE versione 1.22.8-gke.202 nel canale di rilascio regolare. Si applica il seguente comportamento:

  • Puoi eseguire l'upgrade a qualsiasi versione in versione standard.
  • Puoi eseguire l'upgrade a qualsiasi versione con patch della 1.22 nel canale rapido.

Per ulteriori informazioni sull'upgrade al di fuori del tuo canale, consulta Eseguire le versioni patch da un canale più recente.

Upgrade di incremento

I cluster Autopilot utilizzano gli upgrade di picco per eseguire l'upgrade di più nodi contemporaneamente. Gli upgrade di picco consentono a GKE di ridurre l'impatto degli upgrade delle versioni sui carichi di lavoro in esecuzione mantenendo una capacità di calcolo sufficiente per i carichi di lavoro in esecuzione. Autopilot gestisce il numero di nodi di picco aggiunti al cluster durante l'upgrade. Questo numero varia in base alle dimensioni totali del cluster. GKE gestisce anche il numero totale di nodi di destinazione che possono essere contemporaneamente non disponibili durante l'upgrade.

Il numero di nuovi nodi di picco e di nodi target non disponibili varia per garantire che il cluster disponga sempre di una capacità di calcolo sufficiente per tutti i carichi di lavoro in esecuzione. Potresti riscontrare interruzioni minori durante la migrazione dei workload da parte di GKE dai nodi di destinazione ai nodi di picco durante l'upgrade.

Per una descrizione di come vengono eseguiti gli upgrade per picco, consulta Upgrade automatici dei nodi.

Requisiti delle quote per gli upgrade di sovraccarico

A differenza della ricreazione dei nodi, gli upgrade di sovraccarico richiedono risorse Compute Engine aggiuntive. L'allocazione delle risorse dipende dalla quota Compute Engine disponibile. A seconda della configurazione, questa quota può limitare il numero di upgrade paralleli o addirittura causare il fallimento dell'upgrade. Come best practice per evitare problemi di scalabilità e per aggiornamenti più prevedibili, assicurati che la quota di istanze Compute Engine non superi il 90%.

Per ulteriori informazioni sulla quota, consulta Garantire le risorse per gli upgrade dei nodi.

Ricevere notifiche di upgrade

GKE pubblica notifiche di upgrade su Pub/Sub, fornendoti un canale per ricevere informazioni da GKE sui tuoi cluster.

Per ulteriori informazioni, consulta la sezione Ricevere notifiche del cluster.

Upgrade dei componenti

GKE esegue i carichi di lavoro di sistema sui nodi worker per supportare funzionalità specifiche per i cluster. Ad esempio, il carico di lavoro del sistema gke-metadata-server supporta la federazione delle identità per i carichi di lavoro per GKE. GKE è responsabile dell'integrità di questi carichi di lavoro. Per scoprire di più su questi componenti, consulta la documentazione relativa alle funzionalità associate.

Quando diventano disponibili nuove funzionalità o correzioni per un componente, GKE indica la versione della patch in cui sono incluse. Per ottenere la versione più recente di un componente, consulta la documentazione associata o le note di rilascio per istruzioni su come eseguire l'upgrade del piano di controllo o dei nodi alla versione appropriata.

Passaggi successivi