Upgrade di cluster Autopilot

Questa pagina illustra come funzionano gli upgrade automatici su Google Kubernetes Engine (GKE) Autopilot, con link a ulteriori informazioni e le relative impostazioni. Puoi utilizzare queste informazioni per mantenere i cluster aggiornato per garantire 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 GKE sono selezionati per l'upgrade automatico, osserva upgrade automatici in tutti i cluster e interviene se problemi come che si verificano nodi non integri. Non puoi disattivare gli upgrade automatici, ma puoi controllare la tempistica con periodi di manutenzione e esclusioni.

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.

Tutti i cluster Autopilot sono registrati in un canale di rilascio, quindi GKE esegue automaticamente l'upgrade del piano di controllo e dei nodi la stessa versione di GKE.

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

Upgrade automatici dei piani di controllo

Tutti i cluster Autopilot vengono regionale cluster. I cluster a livello di regione hanno più repliche del piano di controllo viene eseguito l'upgrade di una sola replica alla volta, in un ordine non definito. Ciò garantisce che rimane ad alta disponibilità durante gli upgrade automatici. Ogni controllo la replica del piano 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 quando è in corso un upgrade del piano di controllo progressi. Se esegui il deployment di pod che richiedono nuovi tipi di nodi mentre un piano di controllo upgrade in corso, potrebbero verificarsi ritardi fino al momento L'upgrade è stato completato.

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 nodi che condividono caratteristiche insieme. GKE utilizza gli upgrade di sovraccarico per 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 continua ad alta disponibilità di nodi e carichi di lavoro.

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

Se configuri periodo di manutenzione o 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 Surge con GKE e attende che il nodo di picco venga registrato con dal 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 ai nuovi pod di essere posizionati sul nodo target.
  4. GKE scarica il nodo target, eliminando i pod esistenti nodo target.

  5. GKE ripianifica i pod gestiti da una controller del carico di lavoro ad altri nodi disponibili. I pod che non possono essere ripianificati rimangono in PENDING fino a quando GKE non potrà riprogrammarli.

  6. GKE elimina il nodo target.

Se un numero significativo di upgrade automatici causa nodi non integri in tutto il parco risorse GKE, GKE interrompe gli upgrade a quella versione mentre analizziamo il problema.

Come vengono selezionate le versioni per l'upgrade automatico

GKE rilascia regolarmente nuove versioni secondarie, ma una versione rilasciata non sia selezionato immediatamente per gli upgrade automatici. Per l'idoneità come upgrade automatico target, la versione GKE deve accumulare un utilizzo sufficiente per dimostrare stabile nel tempo.

Google Cloud seleziona poi quella versione come destinazione dell'upgrade automatico per i cluster che eseguono un sottoinsieme specifico di versioni GKE precedenti. Ad esempio: subito dopo che diventa disponibile una nuova versione secondaria, la meno recente disponibile versione in genere non è più supportato. GKE esegue l'upgrade dei cluster che eseguono versioni secondarie non supportate della versione di destinazione dell'upgrade automatico.

GKE annuncia nuove versioni di destinazione degli upgrade automatici nel note di rilascio. A volte, una versione è selezionata per gli upgrade automatici del piano di controllo e dei nodi durante settimane diverse. 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 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. Gli upgrade automatici sono minimi e invasivi, 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 gli upgrade automatici possono o non devono essere eseguiti.

Se configuri periodi di manutenzione ed esclusioni, l'upgrade avrà luogo solo all'inizio di un'operazione di manutenzione finestra. Se un periodo di manutenzione scade prima del completamento dell'upgrade, GKE tenta di mettere in pausa l'upgrade. GKE ripristina eseguire 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 dal piano di controllo del cluster Autopilot. GKE è in esecuzione esegui l'upgrade dei nodi affinché corrispondano il prima possibile alla versione del piano di controllo soggetto a manutenzione la disponibilità del servizio. Per istruzioni, consulta la sezione Eseguire manualmente l'upgrade del controllo aereo. 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 o in una versione patch della stessa versione secondaria di il tuo cluster in un altro canale di rilascio.

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

  • 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 i disturbi gli upgrade delle versioni interessano i carichi di lavoro in esecuzione mantenendo una quantità di per i carichi di lavoro in esecuzione. Autopilot gestisce il numero di nodi surf aggiunti al cluster durante upgrade. Il numero varia in base alla dimensione totale del cluster. GKE gestisce anche il numero totale di nodi di destinazione che possono non saranno disponibili contemporaneamente durante l'upgrade.

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

Per una descrizione di come avvengono gli 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 Compute Engine aggiuntivo Google Cloud. L'allocazione delle risorse dipende dalla disponibilità Quota di Compute Engine. In base configurazione, questa quota può limitare il numero di upgrade paralleli o addirittura l'upgrade non andrà a buon fine. È buona prassi evitare problemi di scalabilità e per più prevedibili, assicurati che la quota di istanza 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 Pub/Sub, che ti offre un canale ricevere informazioni da GKE sui cluster.

Per ulteriori informazioni, vedi Ricezione di notifiche relative al cluster.

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