Informazioni sugli upgrade dei cluster con sequenza di implementazione

Puoi gestire l'ordine degli upgrade automatici dei cluster su Cluster Google Kubernetes Engine (GKE) in più ambienti che utilizzano l'implementazione in sequenza. Ad esempio, puoi qualificare una nuova versione in fase di pre-produzione prima di eseguire l'upgrade dei cluster di produzione. Per utilizzare questa funzionalità, devi avere familiarità con il cluster upgrade, release canali e la flotta gestione dei dispositivi.

Per iniziare, consulta Sequenza dell'implementazione degli upgrade dei cluster.

Terminologia

Questo documento utilizza il termine gruppo per fare riferimento a parchi risorse o team perché puoi creare una sequenza di implementazione organizzata in base ai raggruppamenti .

Qualificazione degli upgrade in più ambienti

Per eseguire automaticamente l'upgrade dei cluster con una sequenza di implementazione, usa parchi risorse o team ambiti in cui hai raggruppato i tuoi cluster con la stessa release channel e minore in fasi e deployment continuo. Scegli la sequenza dei parchi risorse o la sequenza degli ambiti dei team e imposta come il tempo di soak test che vuoi tra ciascun gruppo di cluster. Poi, quando GKE seleziona una nuova per i modelli di machine learning upgrade nel canale di rilascio, l'upgrade dei gruppi di cluster viene eseguito nella sequenza che hai definito, quindi puoi convalidare l'esecuzione dei carichi di lavoro come previsto con una nuova prima che gli upgrade inizino con i cluster di produzione.

Sequenza di implementazione basata sul parco risorse

Il seguente diagramma illustra come GKE esegue gli upgrade automatici di cluster in una sequenza di implementazione organizzata in base ai parchi risorse:

Sequenza di implementazione basata sul parco risorse. Puoi organizzare i cluster in parchi risorse o suddividerli ulteriormente in parchi risorse con ambiti.

Con una sequenza basata sul parco risorse, quando GKE rende disponibile una nuova target dell'upgrade nel canale di rilascio, dove tutti i cluster in questa sequenza vengono registrato, GKE esegue l'upgrade di questi parchi risorse di cluster in questa sequenza, con i cluster del parco risorse upstream che qualificano la nuova versione per i cluster in a valle, per un massimo di tre flotte. In upstream, in una sequenza di implementazione, si riferisce al gruppo precedente e downstream al gruppo successivo.

Durante il tempo di sospensione configurato tra i parchi risorse, una volta completati gli upgrade, parco risorse upstream e prima che inizino sul parco risorse downstream, puoi confermare che i carichi di lavoro vengano eseguiti come previsto sui cluster di cui è stato eseguito l'upgrade.

Sequenza di implementazione basata sul team

Se hai suddiviso ulteriormente i cluster di un parco risorse per team o applicazione, puoi creare una sequenza di implementazione tra gli ambiti dei team. Ambiti dei team sono una struttura a livello di parco risorse aziendale per associare sottoinsiemi di cluster a team di applicazioni specifici e possono essere utilizzate per abilitare una gamma di funzionalità basate sui team, tra cui il controllo dell'accesso e l'osservabilità a livello di team, nonché la sequenza di implementazione.

Sequenze di implementazione basate sull'ambito. Puoi organizzare i cluster in parchi risorse o suddividerli ulteriormente in parchi risorse con ambiti.

Con gli ambiti dei team, puoi creare più sequenze di implementazione in un parco risorse, ciascuna i propri canali di rilascio, le destinazioni degli upgrade e i tempi di sospensione indipendenti. R una sequenza di implementazione basata sul team funziona in modo identico a un'implementazione basata sul parco risorse sequenza temporale specifica, ad eccezione del fatto che gli upgrade sono qualificati tra i cluster di un team specifico in ogni parco risorse, dalla flotta alla flotta. Ciò è particolarmente utile per gli operatori di applicazioni che vogliono gestire gli upgrade all'interno dei cluster del proprio team.

La sequenza di implementazione basata sul team è in anteprima, mentre l'implementazione basata sul parco risorse la sequenza è in disponibilità generale (GA).

Come GKE esegue l'upgrade dei cluster in una sequenza di implementazione

Quando GKE esegue l'upgrade di un cluster, viene prima eseguito l'upgrade del piano di controllo, viene eseguito l'upgrade dei nodi. In una sequenza di implementazione, viene comunque eseguito l'upgrade dei cluster usando questo processo, ma puoi anche controllare l'ordine in cui i gruppi (parchi risorse o ambiti) dei cluster viene eseguito e specifichi un tempo di sospensione per scegliere lunghe pause di GKE prima che gli upgrade proseguano da un gruppo gruppo successivo.

Per eseguire gli upgrade dei cluster in una sequenza di implementazione, procedi nel seguente modo:

  1. GKE imposta un nuovo target di upgrade automatico per i cluster una versione secondaria in uno specifico canale di rilascio, con il nota in cui viene menzionato qualcosa di simile a il seguente messaggio: "Piani di controllo e nodi con upgrade automatico abilitato nel canale regolare verrà eseguito l'upgrade dalla versione 1.21 alla versione 1.22.15-gke.1000 con questa release".
  2. GKE inizia l'upgrade dei piani di controllo del cluster al nuovo nel primo gruppo di cluster. Dopo l'upgrade di un cluster GKE di controllo del cluster, GKE avvia l'upgrade nodi. GKE rispetta la disponibilità di manutenzione durante l'upgrade dei cluster in una sequenza di implementazione.
  3. GKE esegue i seguenti passaggi successivi per gli upgrade del piano di controllo:
    1. GKE inizia il periodo di sospensione per gli upgrade del piano di controllo al termine di tutti gli upgrade del piano di controllo del cluster nel primo gruppo, oppure trascorsi 30 giorni dall'inizio degli upgrade del piano di controllo.
    2. Dopo il periodo di sospensione per gli upgrade del piano di controllo del cluster nel primo viene completato, GKE avvia gli upgrade del piano di controllo secondo gruppo.
  4. In parallelo agli upgrade del piano di controllo, GKE esegue queste operazioni: passaggi successivi per gli upgrade dei nodi:
    1. GKE inizia il periodo di sospensione per gli upgrade dei nodi dei nodi nel primo gruppo sono terminati o sono trascorsi 30 giorni passato dall'inizio degli upgrade dei nodi.
    2. GKE avvia gli upgrade dei nodi nel secondo gruppo per i quali è già stato eseguito l'upgrade del piano di controllo dopo di sospensione per gli upgrade dei nodi nel primo gruppo.
  5. GKE ripete questi passaggi dal secondo al terzo gruppo finché i cluster di tutti i gruppi nella sequenza di implementazione non sono stati aggiornato al nuovo target.

Man mano che viene eseguito l'upgrade dei cluster in ogni gruppo, verifica durante il periodo di sospensione che i carichi di lavoro vengono eseguiti come previsto con i cluster che eseguono il nuovo completamente gestita.

È possibile che l'upgrade dei cluster venga impedito anche a causa di periodi di manutenzione o esclusioni, utilizzo deprecato dell'API o altri motivi. Per ulteriori informazioni, consulta l'articolo Come la sequenza di implementazione funziona con altri upgrade funzionalità.

Come controllare gli upgrade in una sequenza di implementazione

Con gli upgrade dei cluster in una sequenza di implementazione, viene eseguito l'upgrade di gruppi di cluster all'ordine che hai definito e che sono immersi in ogni gruppo per la quantità all'ora selezionata. Mentre sono in corso gli upgrade, puoi controllare le stato di un'implementazione sequenza, e gestire l'implementazione sequenza dell'oggetto o eliminare definitivamente una versione archiviata, in base alle necessità. Puoi anche controllare il processo nei seguenti modi:

Per saperne di più, scopri come funziona la sequenza di implementazione con altri upgrade funzionalità.

Esempio: la Community Bank implementa gradualmente le modifiche dal test alla produzione

Ad esempio, l’amministratore di piattaforma di una banca comunitaria gestisce tre principali ambienti di deployment, ciascuno a un gruppo di cluster organizzati in un parco risorse: test, staging e produzione. Come richiesto per la sequenza di implementazione, ha registrato ogni cluster in tutti e tre i parchi risorse nello stesso di rilascio del prodotto, in questi parchi risorse, la canale, con tutte le che eseguono la stessa versione secondaria.

L'amministratore usa la sequenza di implementazione per definire l'ordine in cui GKE esegue l'upgrade dei cluster in questi ambienti. Ordine dell'implementazione offre all'amministratore la possibilità di verificare che i carichi di lavoro vengano eseguiti previsto con i cluster su una nuova versione di GKE prima È stato eseguito l'upgrade dell'ambiente di produzione alla nuova versione. Questa sequenza è illustrato dal diagramma di sequenza di implementazione basato sul parco risorse.

L'amministratore utilizza il tempo di sospensione tra questi parchi risorse in fase di upgrade per verificare che i carichi di lavoro vengano eseguiti come previsto con i cluster sulla nuova versione con GKE. Per il parco risorse di test, l'amministratore imposta il tempo di sospensione a 14 giorni, in modo che abbiano due settimane complete per testare come vengono eseguiti i carichi di lavoro. Per la gestione temporanea, impostano il tempo di sospensione su 7 giorni in quanto non hanno bisogno di molto. di tempo in più dopo che i carichi di lavoro sono già in esecuzione nel test.

L'amministratore può anche ignorare il tempo di sospensione predefinito per gli upgrade a specifiche di queste versioni, cosa che potrebbero voler fare in una delle seguenti situazioni seguenti:

  • L'amministratore termina la qualifica della versione prima che il tempo di sospensione sia completa e desidera che gli upgrade passino al parco risorse successivo, quindi imposta di sospensione a zero.
  • L'amministratore ha bisogno di più tempo per qualificare la nuova versione prima degli upgrade passare al parco dispositivi successivo perché ha notato un problema con alcuni dei suoi carichi di lavoro, perciò impostano il tempo di sospensione al massimo di 30 giorni.

L'amministratore usa periodi di manutenzione ed esclusioni per garantire GKE esegue l'upgrade dei cluster quando è meno invasivo per la banca. GKE rispetta la disponibilità della manutenzione per i cluster di cui è stato eseguito l'upgrade in un sequenza di implementazione.

  • L'amministratore ha configurato periodi di manutenzione per i propri cluster assicura che GKE esegua gli upgrade dei cluster solo dopo l'orario di lavoro.
  • L'amministratore usa le esclusioni di manutenzione per impedire temporaneamente di eseguire l'upgrade dei cluster se rilevano problemi carichi di lavoro con scale out impegnativi.

L'amministratore utilizza una combinazione di picchi upgrade e blu-verde per i loro nodi, bilanciando velocità e tolleranza al rischio sui carichi di lavoro in esecuzione sui nodi.

L'amministratore passa alle sequenze di implementazione basate sui team

Se l'amministratore decide di dover raggruppare ulteriori cluster all'interno di un parco risorse per applicazione e offrono agli amministratori dei team delle applicazioni un maggiore controllo sugli upgrade dei cluster, possono utilizzare gli ambiti dei team. Con gli ambiti dei team, gli amministratori dei team delle applicazioni possono creare implementazioni indipendenti con i gruppi di cluster assegnati ai loro team, potenzialmente in esecuzione diversi canali di rilascio o con tempi di sospensione diversi.

Ad esempio, se il team del database vuole che i propri cluster utilizzino canale stabile e tempi di sospensione più lunghi mentre i cluster del team del sito web frontend usano il canale Rapido e tempi di sospensione più brevi, possono usare gli ambiti del team per creare sequenze di implementazione separate. Questo tipo di sequenza è illustrato dalla sequenza di implementazione basata sui team in questo diagramma. Per farlo per il tuo ambiente, segui istruzioni per passare dall'implementazione basata sul parco risorse a quella basata sul team e viceversa sequenze.

Tieni presente che l'uso di questa funzione richiede cluster a singola tenancy: in altre parole, ogni singolo cluster è associato a un solo team. I cluster condivisi (supportati nella gestione generale dei team del parco risorse) non sono supportati per la sequenza di implementazione. Puoi scoprire di più sulla gestione dei cluster per i team in Gestione dei team del parco risorse.

Idoneità all'implementazione

Per l'upgrade automatico dei cluster con la sequenza di implementazione, tutti i cluster in tutti i gruppi (parchi risorse o ambiti) in una sequenza di implementazione devono ricevere lo stesso target dell'upgrade. I cluster devono essere registrati nello stesso canale di rilascio consiglia di impostare la stessa versione secondaria dei cluster delle destinazioni dell'upgrade alla versione secondaria. Tuttavia, per alcune release, come la release nel nell'esempio seguente: i cluster di più versioni secondarie hanno ricevuto lo stesso target, il che significa che è stato possibile eseguire l'upgrade dei cluster correttamente nella sequenza di implementazione che esegue più versioni secondarie.

Puoi controllare lo stato dell'implementazione della versione in un sequenza per saperne di più sullo stato e se ci sono problemi di idoneità della versione impedendo il proseguimento degli upgrade. In base alle discrepanze nelle versioni, potrebbe richiedere azioni come l'upgrade manuale di un cluster o la sua rimozione di un gruppo per procedere con gli upgrade del cluster. Se un cluster in una sequenza di implementazione non ha un target di upgrade idoneo, GKE non eseguirà l'upgrade automatico nel cluster fino a quando la versione secondaria esistente del cluster non raggiunge la fine dell'IA.

Per risolvere i problemi relativi all'idoneità dell'implementazione, consulta Risolvere i problemi relativi all'implementazione. idoneità.

Release GKE di esempio

Ad esempio, 2022-R25 release imposta una destinazione dell'upgrade per più versioni secondarie nei cluster registrati nel canale regolare. Un target dell'upgrade può essere una nuova versione secondaria (da 1.20 a 1.21) o solo una nuova versione patch (da 1.21.x-gke.x a 1.21.14-gke.4300). In questo di Google, nel canale regolare sono state rese disponibili le nuove versioni riportate di seguito per i cluster su versioni secondarie specifiche:

  • È stato eseguito l'upgrade dei cluster 1.20 e 1.21 a 1.21.14-gke.4300.
  • È stato eseguito l'upgrade dei cluster su 1.22 a 1.23.8-gke.1900.
  • È stato eseguito l'upgrade dei cluster su 1.24 a 1.24.5-gke.600.

Il gruppo più upstream riceve tutti i target dell'upgrade

Per i cluster nel primo gruppo di una sequenza, che non ha un upstream per qualificare le nuove versioni, GKE esegue l'upgrade di qualsiasi cluster target di upgrade idonei, indipendentemente dal fatto che siano diversi l'uno dall'altro. Ad esempio, nel primo gruppo di una sequenza, se alcuni cluster la versione 1.20, è stato possibile eseguire l'upgrade di questi cluster alla versione 1.21.14-gke.4300 e è possibile eseguire l'upgrade dei cluster che eseguono la versione 1.24 a 1.24.5-gke.600. Questo perché, ad esempio, il primo gruppo di una sequenza, GKE prende in considerazione tutte le destinazioni dell'upgrade essere qualificato per questi cluster poiché non esiste un gruppo upstream per qualificare una nuova versione.

Un gruppo upstream deve qualificare solo una versione

In qualsiasi gruppo downstream, se GKE può eseguire l'upgrade dei cluster dipende da se il gruppo upstream ha qualificato un target di upgrade per il quale cluster di questo gruppo sono idonei. In genere, ciò significa che tutti i cluster iniziano dalla stessa versione secondaria. Tuttavia, dall'esempio di release, i cluster Le versioni 1.20 e 1.21 avevano lo stesso target di upgrade, quindi i cluster che eseguono entrambe le versioni nello stesso gruppo, potresti qualificare l'upgrade a 1.21.14-gke.4300.

Se tutti i cluster in un gruppo non hanno lo stesso target di upgrade, questo gruppo non possono qualificare un target di upgrade per il gruppo successivo. In questa situazione, GKE non può eseguire automaticamente l'upgrade dei cluster nei gruppi downstream. Ad esempio, se, nel primo gruppo, è stato eseguito l'upgrade di alcuni cluster a 1.21.14-gke.4300 e altri fino a 1.23.8-gke.1900, i cluster del secondo gruppo impossibile eseguire l'upgrade automatico perché il gruppo non ne ha ricevuto uno completamente gestita. Per avanzare gli upgrade in questa situazione, vedi Correggere l'idoneità in un .

Un gruppo upstream deve qualificare una versione che corrisponde ai cluster del gruppo successivo

Se i cluster in un gruppo upstream hanno qualificato una versione diversa da quella quali cluster nel gruppo successivo erano idonei, anche GKE non può l'upgrade automatico dei cluster in tutti i gruppi downstream.

Ad esempio, se è stato eseguito l'upgrade di tutti i cluster nel primo gruppo a 1.21.14-gke.4300, ma i cluster del secondo gruppo erano in esecuzione 1.22 (dove il target dell'upgrade è 1.23.8-gke.1900), i cluster del secondo gruppo non viene eseguito automaticamente. Il primo gruppo si qualificava 1.21.14-gke.4300, ma del secondo gruppo (attualmente la versione 1.22) sono idonei solo per eseguire l'upgrade della destinazione 1.23.8-gke.1900, perciò GKE non può eseguire eseguire l'upgrade di questi cluster. Per avanzare negli upgrade in questa situazione, vedi Risolvere l'idoneità tra i gruppi.

Funzionamento della sequenza di implementazione con altre funzionalità di upgrade

La sequenza di implementazione è una delle funzionalità di una raccolta che ti offre un controllo completo sull'aspetto dell'upgrade del ciclo di vita del cluster. Questa sezione spiega come questa funzionalità si integra con altre funzionalità disponibili relative ai degli upgrade dei cluster.

Come funziona la sequenza di implementazione con periodi di manutenzione ed esclusioni

GKE rispetta i periodi di manutenzione ed esclusioni di manutenzione durante l'upgrade dei cluster con una sequenza di implementazione. GKE avvia solo di eseguire l'upgrade del cluster entro il periodo di manutenzione del cluster. Puoi utilizzare uno dei seguenti per impedire temporaneamente l'upgrade di un cluster. Se GKE non può eseguire l'upgrade di un cluster a causa di un periodo di manutenzione oppure un'esclusione, questo può impedire la fine degli upgrade del cluster in un gruppo. Se l'upgrade del cluster non può essere completato entro 30 giorni a causa di periodi di manutenzione o esclusioni, il gruppo entrerà nella fase di sospensione indipendentemente dal fatto che tutti di cluster al termine dell'upgrade.

Puoi utilizzare le esclusioni dalla manutenzione come misura temporanea per evitare una sequenza dal completamento di un'implementazione in un gruppo al passaggio al gruppo successivo. Per apprendere Per saperne di più, consulta Ritardare il completamento dell'implementazione della versione del gruppo.

Come funziona la sequenza di implementazione con il rilevamento dell'utilizzo del ritiro

GKE mette in pausa gli upgrade dei cluster quando rileva l'utilizzo di le API e le funzionalità ritirate. Anche gli upgrade automatici sono in pausa per i cluster in un gruppo in una sequenza di implementazione. Per scoprire di più, vedi Come I ritiri di Kubernetes funzionano con GKE.

Come funziona la sequenza di implementazione con le strategie di upgrade dei nodi

Gli upgrade dei nodi utilizzeranno la strategia di upgrade dei nodi configurata durante l'upgrade in una sequenza di implementazione. Come per gli upgrade dei cluster senza la sequenza di implementazione, GKE usa gli upgrade di sovraccarico per i nodi Autopilot. Per ulteriori informazioni, consulta Upgrade automatici del nodo.

Se gli upgrade dei nodi non possono essere completati entro 30 giorni, il gruppo entrerà nella fase di sospensione indipendentemente dal fatto che tutti i cluster abbiano terminato l'upgrade. Questo può si verificano se la strategia di upgrade del nodo causa un nodo del cluster Standard l'upgrade potrebbe richiedere più tempo, soprattutto se si tratta di un pool di nodi di grandi dimensioni. it Può anche essere esacerbato da periodi di manutenzione non abbastanza grandi per eseguire l'upgrade di un nodo. per completare l'operazione. Per saperne di più, vedi Considerazioni per la configurazione di una manutenzione finestra.

Come funziona la sequenza di implementazione con i canali di rilascio

I canali di rilascio sono necessaria per usare la sequenza di implementazione. Tutti i cluster in tutti i gruppi in una sequenza di implementazione devono trovarsi sullo stesso canale di rilascio.

Ricezione di più upgrade in una sequenza

Se una nuova versione diventa una destinazione dell'upgrade nel canale di rilascio mentre il cluster gli upgrade a un target dell'upgrade precedente continuano nell'implementazione sequenza, un gruppo upstream può iniziare l'implementazione di una nuova versione mentre gruppo downstream sta ancora ricevendo l'upgrade precedente. Ad esempio, se il terzo gruppo di una sequenza prevede l'implementazione di 1.24.2-gke.100, il primo contemporaneamente può essere implementata con 1.24.3-gke.500.

Considerazioni sulla scelta della sequenza di implementazione

Valuta la possibilità di utilizzare la sequenza di implementazione se vuoi gestire gli upgrade del cluster qualificando le nuove versioni in un ambiente prima di implementarle in un altro.

Tuttavia, questa potrebbe non essere la scelta giusta per il tuo ambiente nel caso di uno dei le seguenti affermazioni sono vere:

  • Hai dei cluster che non si trovano nello stesso canale di rilascio o in una versione secondaria in nello stesso ambiente di produzione.
  • Devi automatizzare gli upgrade che non possono essere mappati solo a tre fasi perché puoi creare una sequenza di implementazione con un massimo di tre gruppi dei cluster. Non puoi collegare gruppi in più sequenze di implementazione per creare una sequenza di implementazione con più di tre gruppi.
  • Non puoi utilizzare la gestione del parco risorse.
  • Esegui spesso upgrade manuali che generano cluster in uno di avere più versioni target dell'upgrade automatico.

Per creare sequenze di implementazione basate sul team, devi anche poter abilitare GKE Enterprise nel tuo parco risorse per i progetti host.

Limitazioni

Per eseguire correttamente l'upgrade dei cluster con la sequenza di implementazione, devi rispettare alle seguenti limitazioni:

  • Se utilizzi una sequenza di implementazione basata sul team, registra un cluster in un solo ambito del team. Se un cluster è registrato in più di team, GKE non può eseguire automaticamente l'upgrade del cluster sequenza di implementazione.
  • Creazione di una sequenza di implementazione basata sul team con più ambiti all'interno dello stesso Il parco risorse non è supportato.
  • Creare una sequenza di implementazione lineare senza cicli (un gruppo ha un come gruppo upstream) o rami (un gruppo ha più di un downstream .
  • Crea sequenze di implementazione tra gli ambiti di un team o sequenze di implementazione tra parchi risorse. Non puoi creare sequenze miste con ambiti sia dei parchi risorse sia degli ambiti dei team nel la stessa sequenza.
  • Assicurati che i cluster in una sequenza di implementazione siano tutti registrati nello stesso canale di rilascio e che eseguono la stessa versione secondaria.

Problemi noti

  • Se un gruppo contiene cluster di località diverse, l'upgrade potrebbe essere temporaneamente disponibile solo per alcuni cluster a causa un'implementazione graduale della nuova versione. È più probabile che si verifichi la prima gruppo di cluster e dovrebbe risolversi entro una settimana.
  • Se in una sequenza di implementazione è presente un gruppo vuoto, qual è l'effetto sulla versione la qualificazione dipende dalle seguenti condizioni:
    • Se il gruppo vuoto non ha un gruppo upstream, gli upgrade del cluster non passa al gruppo downstream poiché il gruppo vuoto non può qualificare le versioni.
    • Se il gruppo vuoto ha un gruppo upstream, tutti gli upgrade del cluster in attesa vengono inseriti lo stato COMPLETE e propagarsi al gruppo downstream.
  • A causa del modo in cui GKE monitora le patch e gli upgrade secondari, due upgrade dello stesso tipo e versione ma con stati diversi quando controllando lo stato dell'ambito.

Passaggi successivi