Upgrade di cluster Autopilot

Questa pagina illustra come funzionano gli upgrade automatici sui cluster Google Kubernetes Engine (GKE) Autopilot, inclusi i link a ulteriori informazioni su attività e impostazioni correlate. Puoi utilizzare queste informazioni per mantenere aggiornati i cluster in termini di stabilità e sicurezza con interruzioni minime dei carichi di lavoro.

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 di GKE sono selezionate per l'upgrade automatico, osserva gli upgrade automatici in tutti i cluster e interviene se si verificano problemi come nodi non integri. Non puoi disabilitare gli upgrade automatici, ma puoi controllarne le tempistiche con periodi di manutenzione ed esclusioni.

Per eseguire l'upgrade di un cluster, GKE aggiorna la versione del piano di controllo e dei nodi in esecuzione. 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, quindi GKE esegue automaticamente l'upgrade del piano di controllo e dei nodi per 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 dei piani di controllo

Tutti i cluster Autopilot sono cluster a livello di regione. 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. Ciò garantisce che il cluster rimanga ad alta disponibilità durante gli upgrade automatici. Ogni replica del piano di controllo non è disponibile solo mentre è in corso l'upgrade.

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

GKE non può creare nuovi nodi mentre è 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, potrebbero verificarsi ritardi fino al completamento dell'upgrade del piano di controllo.

Upgrade automatici del nodo

Dopo che GKE ha eseguito l'upgrade del piano di controllo del cluster Autopilot, GKE esegue l'upgrade dei nodi alla stessa versione di 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 un massimo di 20 nodi in un gruppo contemporaneamente. Il numero esatto di nodi di cui viene eseguito l'upgrade contemporaneamente varia per garantire un'alta disponibilità continua di nodi e carichi di lavoro.

Gli upgrade dei nodi possono richiedere diverse ore, a seconda del numero di nodi e della configurazione dei carichi di lavoro in esecuzione nei nodi. Ad esempio, le seguenti configurazioni potrebbero contribuire a upgrade più lunghi:

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

Quando GKE esegue l'upgrade di un nodo, si verificano i seguenti passaggi:

  1. GKE crea un nuovo nodo di picco con la nuova versione di GKE e attende che il nodo venga registrato con il piano di controllo.
  2. GKE seleziona un nodo esistente, il nodo target, di cui eseguire l'upgrade.
  3. GKE contrassegna il nodo di destinazione come non pianificabile, impedendo il posizionamento di nuovi pod sul nodo target.
  4. GKE scarica il nodo target, eliminando i pod esistenti dal nodo target.

  5. GKE ripianifica i pod gestiti da un controller del carico di lavoro su altri nodi disponibili. I pod che non possono essere ripianificati rimangono in stato PENDING finché GKE non può riprogrammarli.

  6. GKE elimina il nodo target.

Se un numero significativo di upgrade automatici a una specifica versione di GKE comporta nodi non integri in tutto il parco risorse 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 essere considerata un target di upgrade automatico, la versione GKE deve accumulare un utilizzo sufficiente per dimostrare la stabilità nel tempo.

Google Cloud seleziona quindi quella versione come destinazione dell'upgrade automatico per i cluster che eseguono un sottoinsieme specifico di versioni precedenti di GKE. Ad esempio, poco dopo che una nuova versione secondaria diventa disponibile, la versione secondaria meno recente disponibile 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 degli upgrade automatici nelle note di rilascio. A volte, viene selezionata una versione per gli upgrade automatici del piano di controllo e degli upgrade automatici dei nodi durante diverse settimane. GKE esegue gli upgrade automatici alle nuove release delle patch all'interno di una versione secondaria (ad esempio v1.21.x).

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

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 nelle regioni e nelle zone di Google Cloud.
  • GKE implementa gradualmente le versioni delle patch nei canali di rilascio. A una patch viene concesso il tempo di sospensione nel canale di rilascio rapido, quindi nel canale di rilascio regolare, per poi passare al canale di rilascio Stabile dopo che ha accumulato utilizzo e continuato a dimostrare stabilità. Se viene rilevato un problema con una versione patch durante il periodo di sospensione su un canale di rilascio, la versione non viene promossa al canale successivo e il problema viene risolto su una versione più recente della patch.
  • GKE implementa gradualmente le versioni secondarie, seguendo un processo di sospensione simile alle versioni patch. Le versioni secondarie hanno periodi di sospensione più lunghi poiché introducono modifiche più significative.
  • GKE può ritardare gli upgrade automatici quando una nuova versione interessa 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à deprecata che verrà rimossa nella versione secondaria successiva.
  • GKE potrebbe ritardare l'implementazione delle nuove versioni durante i periodi di punta (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. Gli upgrade automatici causano il minimo interruzioni, soprattutto per i cluster Autopilot. Tuttavia, alcuni carichi di lavoro potrebbero richiedere un controllo più granulare. Puoi configurare periodi di manutenzione ed esclusioni per stabilire quando possono e non devono essere eseguiti gli upgrade automatici.

Se configuri periodi di manutenzione ed esclusioni, l'upgrade non viene eseguito finché l'ora attuale non rientra nel periodo di manutenzione. Se un 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.

Esegui 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 il prima possibile alla versione del piano di controllo, in base alla disponibilità di manutenzione. Per le istruzioni, consulta Eseguire l'upgrade manuale del piano di controllo. Non puoi gestire manualmente la versione dei nodi per i cluster Autopilot.

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

Ad esempio, considera 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 nella versione Regular.
  • Puoi eseguire l'upgrade a qualsiasi versione di patch 1.22 nel canale rapido.

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

Upgrade di Surge

I cluster Autopilot utilizzano gli upgrade di incremento per eseguire l'upgrade di più nodi contemporaneamente. Gli upgrade di sovraccarico consentono a GKE di ridurre il livello di disturbo degli upgrade delle versioni per i 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 che vengono aggiunti al cluster durante l'upgrade. Il numero varia in base alla dimensione totale 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 di destinazione non disponibili varia per garantire che il cluster abbia sempre una capacità di calcolo sufficiente per tutti i carichi di lavoro in esecuzione. Potresti riscontrare interruzioni minori durante la migrazione dei carichi di lavoro dai nodi di destinazione ai nodi di picco durante l'upgrade.

Per una descrizione delle modalità di esecuzione degli upgrade di sovraccarico, consulta Upgrade automatici del nodo.

Requisiti di quota 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 di Compute Engine disponibile. A seconda della configurazione, questa quota può limitare il numero di upgrade paralleli o persino causare un errore dell'upgrade. Come buona prassi per evitare problemi di scalabilità e per eseguire upgrade più prevedibili, assicurati che la quota delle istanze Compute Engine non superi il 90%.

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

Ricevi 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 Ricezione di notifiche sul cluster.

Upgrade dei componenti

GKE esegue 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à dei carichi di lavoro per GKE. GKE è responsabile dell'integrità di questi carichi di lavoro. Per saperne di più su questi componenti, consulta la documentazione relativa alle funzionalità associate.

Quando nuove funzionalità o correzioni diventano disponibili per un componente, GKE indica la versione 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