Upgrade di cluster Autopilot

Questo documento descrive il funzionamento degli upgrade automatici sui cluster Google Kubernetes Engine (GKE) Autopilot, inclusi i link a ulteriori informazioni sulle attività e sulle impostazioni correlate. Puoi utilizzare queste informazioni per mantenere i cluster aggiornati per la stabilità e la sicurezza con interruzioni minime dei 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 in modo specifico per i cluster Standard, inclusi i node pool gestiti da Autopilot, consulta Upgrade dei cluster Standard.

Upgrade automatici del control plane e dei nodi

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

Per eseguire l'upgrade di un cluster, GKE aggiorna la versione in cui sono in esecuzione il control plane e i nodi. I cluster vengono sottoposti all'upgrade 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 maggiori 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 control plane e dei nodi per eseguire la stessa versione di GKE.

GKE esegue l'upgrade del control plane di un cluster prima di eseguire l'upgrade dei nodi.

Upgrade automatici del control plane

Tutti i cluster Autopilot sono cluster regionali. I cluster regionali hanno più repliche del control plane e viene eseguito l'upgrade di una sola replica alla volta, in un ordine non definito. Questo approccio contribuisce a garantire che il cluster rimanga a elevata disponibilità durante gli upgrade automatici. Ogni replica del control plane 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 durante l'upgrade del control plane. Se esegui il deployment di pod che richiedono nuovi tipi di nodi durante l'upgrade del control plane, potresti riscontrare ritardi fino al completamento dell'upgrade del control plane.

GKE esegue gli upgrade automatici del control plane utilizzando i seguenti metodi, a seconda del tipo di upgrade:

  • Upgrade della versione patch: GKE utilizza un upgrade in un unico passaggio, che esegue l'upgrade del control plane direttamente a una versione patch successiva.
  • Upgrade della versione secondaria: per l'upgrade alla versione secondaria di GKE 1.33 o successive, GKE utilizza una procedura in due passaggi in cui puoi convalidare la nuova versione secondaria per un periodo di tempo di soak e, se necessario, eseguire il rollback. Per maggiori informazioni, consulta Upgrade secondario del control plane in due passaggi con sicurezza di rollback per il rollback. Per l'upgrade a versioni precedenti, GKE utilizza invece la procedura di upgrade in un unico passaggio.

Upgrade automatici dei nodi

Dopo che GKE ha eseguito l'upgrade del control plane del cluster Autopilot, 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 la continuità dell'alta affidabilità di nodi e workload.

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 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, vengono eseguiti i seguenti passaggi:

  1. GKE crea un nuovo nodo di sovraccarico con la nuova versione di GKE e attende che il nodo di sovraccarico si registri con il control plane.
  2. GKE seleziona un nodo esistente, il nodo di destinazione, di cui eseguire l'upgrade.
  3. GKE isola il nodo di destinazione, impedendo il posizionamento di nuovi pod sul nodo di destinazione.
  4. GKE svuota il nodo di destinazione, eliminando i pod esistenti dal nodo di destinazione.

  5. GKE ripianifica i pod gestiti da un controller di workload su altri nodi disponibili. I pod che non possono essere ripianificati rimangono nello stato PENDING finché GKE non può ripianificarli.

  6. GKE elimina il nodo di destinazione.

Se un numero significativo di upgrade automatici a una versione specifica di GKE genera 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 idonea come target di upgrade automatico, la versione di GKE deve accumulare un utilizzo sufficiente per dimostrare la stabilità nel tempo.

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

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

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

Fattori che influiscono sulla tempistica di implementazione della versione

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

Queste pratiche includono, a titolo esemplificativo:

  • GKE implementa gradualmente le modifiche nelle Google Cloud regioni e nelle zone.
  • GKE implementa gradualmente le versioni patch nei canali di rilascio. A una patch viene assegnato un periodo di soak nel canale di rilascio rapido, quindi nel canale di rilascio regolare, prima di essere promossa al canale di rilascio stabile una volta che ha accumulato utilizzo e ha continuato a dimostrare stabilità. Se viene rilevato un problema con una versione patch durante il periodo di soak in un canale di rilascio, la versione non viene promossa al canale successivo e il problema viene risolto in una versione patch più recente.
  • GKE implementa gradualmente le versioni secondarie, seguendo una procedura di soak simile a quella delle versioni patch. Le versioni secondarie hanno periodi di soak più lunghi perché 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à deprecata che verrà rimossa nella versione secondaria successiva.
  • GKE potrebbe ritardare l'implementazione di nuove versioni durante i periodi di punta (ad esempio, le festività principali) per garantire la continuità operativa.

Configurazione del momento in cui possono verificarsi gli upgrade automatici

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

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

Eseguire manualmente l'upgrade di un cluster Autopilot

Puoi eseguire manualmente l'upgrade della versione di GKE del control plane del cluster a una versione secondaria o 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 la versione di GKE 1.35.6-gke.1250000 nel canale di rilascio regolare. Si applica il seguente comportamento:

  • Puoi eseguire l'upgrade a qualsiasi versione patch disponibile in Regolare.
  • Puoi eseguire l'upgrade a qualsiasi versione patch di 1.35 nel canale rapido. Per maggiori informazioni sull'upgrade al di fuori del tuo canale, consulta Eseguire versioni patch da un canale più recente channel.
  • Puoi eseguire l'upgrade a una nuova versione secondaria disponibile in Regolare. Ad esempio, puoi eseguire l'upgrade alla versione 1.36.

Puoi utilizzare i seguenti metodi per eseguire l'upgrade della versione del control plane, a seconda del tipo di upgrade:

  • Upgrade della versione patch: puoi utilizzare un upgrade in un unico passaggio.
  • Upgrade della versione secondaria: puoi utilizzare l'upgrade in un unico passaggio o l' upgrade in due passaggi.

Per maggiori informazioni su questi metodi e su come utilizzarli, consulta Eseguire l'upgrade del control plane del cluster.

GKE esegue automaticamente l'upgrade dei nodi in modo che corrispondano alla versione del control plane il prima possibile, in base alla disponibilità della manutenzione. Non puoi gestire manualmente la versione del nodo per i cluster Autopilot.

Upgrade di sovraccarico

I cluster Autopilot utilizzano gli upgrade di sovraccarico per eseguire l'upgrade di più nodi contemporaneamente. Gli upgrade di sovraccarico consentono a GKE di ridurre l'impatto degli upgrade delle versioni sui workload in esecuzione mantenendo una capacità di calcolo sufficiente per i workload in esecuzione. Autopilot gestisce il numero di nodi di sovraccarico 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 non essere disponibili contemporaneamente durante l'upgrade.

Il numero di nuovi nodi di sovraccarico e di nodi di destinazione non disponibili varia per garantire che il cluster abbia sempre una capacità di calcolo sufficiente per tutti i workload in esecuzione. Potresti riscontrare interruzioni minori quando GKE esegue la migrazione dei workload dai nodi di destinazione ai nodi di sovraccarico durante l'upgrade.

Per una descrizione di come si verificano gli upgrade di sovraccarico, consulta Upgrade automatici dei nodi.

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 addirittura causare il fallimento dell'upgrade. Come best practice per evitare problemi di scalabilità e per upgrade più prevedibili, assicurati che la quota dell'istanza Compute Engine non superi il 90%.

Per maggiori informazioni sulla quota, consulta Assicurarsi che le risorse siano disponibili 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 maggiori informazioni, consulta Ricevere notifiche dei cluster.

Upgrade dei componenti

GKE esegue i workload di sistema sui nodi worker per supportare funzionalità specifiche per i cluster. Ad esempio, il gke-metadata-server sistema workload supporta Workload Identity Federation for GKE. GKE è responsabile dell'integrità di questi workload. Per saperne 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 patch in cui sono incluse. Per ottenere l'ultima versione di un componente, consulta la documentazione o le note di rilascio associate per istruzioni sull'upgrade del control plane o dei nodi alla versione appropriata.

Passaggi successivi