Informazioni sugli upgrade dei cluster con sequenza di implementazione

Puoi gestire l'ordine degli upgrade automatici dei cluster Google Kubernetes Engine (GKE) in più ambienti utilizzando la sequenza di implementazione. Ad esempio, puoi qualificare una nuova versione nei cluster di pre-produzione prima di eseguire l'upgrade dei cluster di produzione. GKE fornisce anche una versione più recente di questa funzionalità, la sequenza di implementazione con fasi personalizzate, che offre maggiori funzionalità. Questa versione include un controllo più granulare sugli upgrade dei cluster ed è consigliata per i nuovi ambienti.

Questo documento presuppone che tu conosca quanto segue:

Per configurare una sequenza di implementazione, consulta Sequenza di implementazione degli upgrade dei cluster.

Panoramica

La sequenza di implementazione di GKE consente di definire una sequenza specifica e ordinata per gli upgrade dei cluster in diversi ambienti, ad esempio eseguendo prima l'upgrade dei cluster nell'ambiente di sviluppo, poi nell'ambiente di test e infine in quello di produzione. Questa strategia progressiva offre un periodo di prova integrato, che ti consente di scoprire e mitigare potenziali problemi prima che l'upgrade raggiunga i tuoi sistemi più critici.

La sequenza di implementazione si basa sul concetto di parchi risorse, ovvero raggruppamenti logici di cluster GKE mappati a un ambiente (ad esempio, test). Per utilizzare questa funzionalità, devi definire una sequenza composta da parchi risorse e impostare il tempo di soak tra ogni gruppo. Quando GKE seleziona una nuova versione, i cluster vengono aggiornati nell'ordine definito, consentendoti di convalidare i workload prima che venga eseguito il deployment completo della versione nel tuo ambiente di produzione.

I parchi risorse supportano le appartenenze leggere, che consentono di raggruppare i cluster logicamente per la sequenza di implementazione senza abilitare tutte le configurazioni e le funzionalità a livello di parco risorse. L'appartenenza leggera è una buona scelta se vuoi utilizzare la sequenza di implementazione senza alcune delle altre implicazioni della gestione completa del parco risorse, come l'uguaglianza degli spazi dei nomi a livello di parco risorse. Per saperne di più, consulta Iscrizioni leggere.

Scegli una strategia di sequenza di implementazione

GKE offre due versioni di sequenziamento dell'implementazione. Entrambe le versioni si basano sugli stessi principi fondamentali di upgrade progressivi basati sul parco risorse, ma ti consigliamo di utilizzare la sequenza di implementazione con fasi personalizzate per i nuovi ambienti:

  • Sequenza di implementazione con fasi personalizzate (consigliata per i nuovi ambienti): questa versione è un'evoluzione del modello basato sul parco risorse e offre maggiore controllo e flessibilità granulari, ma non dispone di un supporto completo della console Google Cloud . Con le fasi personalizzate, puoi definire fasi specifiche all'interno di un parco risorse utilizzando le etichette, il che le rende una buona scelta per strategie di implementazione più complesse, come il deployment di una nuova versione su un piccolo sottoinsieme di cluster di produzione prima di un'implementazione più ampia. Inoltre, hai un maggiore controllo sulle implementazioni, ad esempio puoi avviarne una per una versione specifica, scegliere i tipi di upgrade da implementare in una sequenza e mettere in pausa o annullare le implementazioni. Scegli questa opzione se stai creando una sequenza di implementazione per la prima volta.
  • Sequenza di implementazione basata sul parco risorse: questa versione della funzionalità offre un supporto più completo nella console Google Cloud , ma per il resto ha funzionalità più limitate e non è consigliata se stai creando una sequenza di implementazione per la prima volta.

Il resto di questo documento riguarda solo la sequenza di implementazione basata sul parco risorse.

Sequenza di implementazione basata sul parco risorse

Per eseguire l'upgrade automatico dei cluster con la sequenza di implementazione, utilizza i parchi risorse in cui hai raggruppato i cluster con lo stesso canale di rilascio e la stessa versione secondaria in fasi di deployment. Definisci la sequenza dei parchi risorse e il tempo di soak che vuoi tra ogni gruppo di cluster. In seguito, quando GKE seleziona una nuova versione per gli upgrade automatici nel canale di rilascio, i gruppi di cluster vengono aggiornati nella sequenza che hai definito e puoi verificare che i workload vengano eseguiti come previsto con una nuova versione prima che inizino gli upgrade con i cluster di produzione.

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

Sequenza di implementazione basata su parchi risorse, in cui i cluster vengono raggruppati in parchi risorse.
Figura: una sequenza di implementazione basata sul parco risorse

Con una sequenza basata sul parco risorse, quando GKE rende disponibile un nuovo target di upgrade nel canale di rilascio in cui sono registrati tutti i cluster di questa sequenza, 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 del parco risorse downstream, per un massimo di cinque parchi risorse. In una sequenza di implementazione, upstream si riferisce al gruppo precedente e downstream al gruppo successivo.

Durante il tempo di soak configurato tra i parchi risorse, puoi verificare che i tuoi workload vengano eseguiti come previsto sui cluster di cui è stato eseguito l'upgrade.

In che modo GKE esegue l'upgrade dei cluster in una sequenza di implementazione

Quando GKE esegue l'upgrade di un cluster, viene eseguito prima l'upgrade del control plane, poi quello dei nodi. In una sequenza di implementazione, l'upgrade dei cluster viene comunque eseguito utilizzando questo processo, ma puoi anche controllare l'ordine in cui viene eseguito l'upgrade dei gruppi (parchi risorse) di cluster. Specifichi anche un tempo di soak che definisce per quanto tempo GKE mette in pausa gli upgrade prima di passare da un gruppo al gruppo successivo.

Gli upgrade dei cluster in una sequenza di implementazione procedono con i seguenti passaggi:

  1. GKE avvia una nuova implementazione nella sequenza di implementazione. Per impostazione predefinita, un'implementazione viene avviata quando GKE imposta un nuovo target di upgrade automatico per i cluster su una versione secondaria in un canale di rilascio specifico. Per la sequenza di implementazione con fasi personalizzate, in alternativa puoi attivare una nuova implementazione in una sequenza di implementazione per una versione specifica che scegli.

  2. GKE inizia l'upgrade dei control plane dei cluster alla nuova versione nel primo gruppo di cluster. Dopo aver eseguito l'upgrade del control plane di un cluster, GKE inizia l'upgrade dei nodi del cluster. GKE rispetta la disponibilità della manutenzione quando esegue l'upgrade dei cluster in una sequenza di implementazione.

  3. GKE esegue i seguenti passaggi per gli upgrade del control plane:

    1. Al termine di tutti gli upgrade del control plane del cluster nel primo gruppo, GKE inizia il periodo di soaking per gli upgrade del control plane. GKE inizia il periodo di soak anche se sono trascorsi più di 30 giorni dall'inizio degli upgrade del control plane.

    2. Al termine del periodo di soak per gli upgrade del control plane del cluster del primo gruppo, GKE inizia l'upgrade dei control plane del secondo gruppo alla nuova versione. Tuttavia, tieni presente quanto segue:

      • In alcuni casi, GKE potrebbe eseguire l'upgrade dei control plane dei cluster del primo gruppo più volte prima di eseguire l'upgrade dei control plane dei cluster del secondo gruppo. In questo caso, GKE sceglie l'ultima versione che ha anche i seguenti attributi:
        • La versione è idonea per il primo gruppo.
        • La versione è al massimo una versione secondaria successiva alla versione del control plane dei cluster del secondo gruppo.
      • GKE non esegue l'upgrade del control plane dei cluster del secondo gruppo che hanno una versione successiva a quella qualificata dal primo gruppo.

  4. In parallelo agli upgrade del control plane, GKE esegue i seguenti passaggi per gli upgrade dei nodi:

    1. Al termine degli upgrade dei nodi di tutti i cluster del primo gruppo, GKE avvia il periodo di soak per gli upgrade dei nodi. GKE inizia il periodo di soak anche se sono trascorsi più di 30 giorni dall'inizio degli upgrade dei nodi.
    2. Al termine del periodo di soaking per gli upgrade dei nodi del primo gruppo, GKE inizia l'upgrade dei nodi del secondo gruppo alla nuova versione. Tuttavia, tieni presente quanto segue:
      • In alcuni casi, GKE potrebbe eseguire l'upgrade dei nodi del cluster del primo gruppo più volte prima di eseguire l'upgrade dei nodi del cluster del secondo gruppo. In questo caso, GKE sceglie l'ultima versione che ha anche i seguenti attributi:
        • La versione è idonea per il primo gruppo.
        • La versione non è successiva alla versione del control plane del cluster del secondo gruppo.
      • GKE non esegue l'upgrade dei nodi dei cluster del secondo gruppo che hanno una versione successiva a quella idonea per il primo gruppo.

  5. GKE ripete questi passaggi dal secondo al terzo gruppo, finché non viene eseguito l'upgrade alla nuova versione dei cluster in tutti i gruppi della sequenza di implementazione.

Mentre i cluster vengono aggiornati in ogni gruppo, durante il tempo di soak, verifica che i tuoi workload con cluster che eseguono la nuova versione di GKE funzionino come previsto.

L'upgrade dei cluster potrebbe anche essere impedito a causa di periodi di manutenzione o esclusioni, utilizzo di API deprecate o altri motivi.

Come controllare gli upgrade in una sequenza di implementazione

Con gli upgrade dei cluster in una sequenza di implementazione, viene eseguito l'upgrade dei gruppi di cluster nell'ordine che hai definito e vengono sottoposti a soak in ogni gruppo per il periodo di tempo che hai scelto. Durante gli upgrade, puoi controllare lo stato e gestire la sequenza di implementazione in base alle tue esigenze. Puoi anche controllare il processo nei seguenti modi:

Esempio: una banca locale implementa gradualmente le modifiche dal test alla produzione

Ad esempio, l'amministratore della piattaforma di una banca locale gestisce tre ambienti di deployment principali: test, gestione temporanea e produzione. Ogni ambiente ha un gruppo di cluster organizzato in un parco risorse. Come richiesto per la sequenza di implementazione, l'amministratore ha registrato ogni cluster in tutti e tre i parchi risorse nello stesso canale di rilascio, in questo caso il canale regolare, con tutti i cluster che eseguono la stessa versione secondaria.

L'amministratore utilizza la sequenza di implementazione per definire l'ordine in cui GKE esegue l'upgrade dei cluster in questi ambienti. L'ordinamento dell'implementazione offre all'amministratore l'opportunità di verificare che i workload vengano eseguiti come previsto con i cluster su una nuova versione di GKE prima che venga eseguito l'upgrade dell'ambiente di produzione alla nuova versione. Questa sequenza è illustrata dal diagramma della sequenza di implementazione basata sul parco risorse.

L'amministratore utilizza il tempo di soak tra i parchi risorse per verificare che i workload vengano eseguiti come previsto sulla nuova versione di GKE. Per il parco risorse di test, l'amministratore imposta il tempo di soak su 14 giorni in modo da avere due settimane intere per testare l'esecuzione dei workload. Per l'ambiente di gestione temporanea, imposta il tempo di soak su 7 giorni, poiché non ha bisogno di molto tempo aggiuntivo dopo che i workload sono già stati eseguiti nell'ambiente di test.

L'amministratore può anche eseguire l'override del tempo di soak predefinito per gli upgrade a versioni specifiche, cosa che potrebbe voler fare in una delle seguenti situazioni:

  • L'amministratore termina la qualifica della versione prima che il tempo di soak sia completato e vuole che gli upgrade procedano al parco risorse successivo, quindi imposta il tempo di soak su zero.
  • L'amministratore ha bisogno di più tempo per qualificare la nuova versione prima che gli upgrade procedano al parco risorse successivo, poiché ha notato un problema con alcuni dei suoi workload, quindi imposta il tempo di soak sul valore massimo di 30 giorni.

L'amministratore utilizza periodi di manutenzione ed esclusioni per consentire a GKE di eseguire l'upgrade dei cluster quando è meno invasivo per la banca. GKE rispetta la disponibilità della manutenzione per i cluster di cui viene eseguito l'upgrade in una sequenza di implementazione.

  • L'amministratore ha configurato i periodi di manutenzione per i cluster in modo che GKE esegua l'upgrade dei cluster solo al di fuori dell'orario di apertura.
  • L'amministratore utilizza anche le esclusioni dalla manutenzione per impedire temporaneamente l'upgrade dei cluster se rileva problemi con i workload del cluster.

L'amministratore utilizza una combinazione di upgrade surge e upgrade blu/verde per i nodi, bilanciando velocità e tolleranza al rischio a seconda dei workload in esecuzione su questi nodi.

Idoneità all'implementazione basata sul parco risorse

Affinché l'upgrade dei cluster venga eseguito automaticamente con la sequenza di implementazione, tutti i cluster di tutti i parchi risorse in una sequenza di implementazione devono ricevere la stessa destinazione di upgrade. I cluster devono essere registrati nello stesso canale di rilascio e consigliamo che eseguano la stessa versione secondaria, poiché i target di upgrade sono impostati per versione secondaria. Tuttavia, per alcune release, come quella 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 nella sequenza di implementazione eseguendo più versioni secondarie.

Puoi controllare lo stato dell'implementazione della versione in una sequenza per ottenere ulteriori informazioni sullo stato e se i problemi di idoneità della versione impediscono l'esecuzione degli upgrade. A seconda delle discrepanze tra le versioni, potresti dover eseguire azioni come l'upgrade manuale di un cluster o la sua rimozione da 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 del cluster finché la versione secondaria esistente del cluster non raggiungerà la fine del supporto.

Per risolvere i problemi di idoneità all'implementazione, consulta Risolvi i problemi di idoneità all'implementazione.

Esempio di release di GKE

Ad esempio, la release 2025-R45 ha impostato un target di upgrade per più versioni secondarie nei cluster registrati nel canale regolare. Un target di upgrade può essere una nuova versione secondaria (da 1.30 a 1.31) o semplicemente una nuova versione patch (da 1.31.x-gke.x a 1.31.13-gke.1023000). In questa release, nel canale regolare, sono state rese disponibili le seguenti nuove versioni per i cluster su versioni secondarie specifiche:

  • È stato eseguito l'upgrade dei cluster dalla versione 1.30 alla versione 1.31.13-gke.1023000.
  • È stato eseguito l'upgrade dei cluster alla versione 1.31 alla versione 1.32.9-gke.1108000.
  • È stato eseguito l'upgrade dei cluster dalla versione 1.32 alla versione 1.33.5-gke.1162000.

Il gruppo più a monte riceve tutti i target di upgrade

Per i cluster del primo gruppo di una sequenza, che non ha un gruppo upstream per qualificare le nuove versioni, GKE esegue l'upgrade di tutti i cluster con target di upgrade idonei, indipendentemente dal fatto che questi target siano diversi tra loro. Ad esempio, nel primo gruppo di una sequenza, se alcuni cluster eseguivano la versione 1.30, questi cluster potevano essere sottoposti ad upgrade alla versione 1.31.13-gke.1023000 e i cluster che eseguivano la versione 1.32 potevano essere sottoposti ad upgrade alla versione 1.33.5-gke.1162000. Questo perché, per il primo gruppo di una sequenza, GKE considera tutti i target di upgrade idonei per questi cluster, in quanto non esiste un gruppo upstream per qualificare una nuova versione.

Un gruppo upstream deve qualificare una sola versione

Affinché i cluster di un gruppo downstream possano iniziare l'upgrade, il gruppo upstream deve aver qualificato correttamente un unico target di upgrade comune per il quale sono idonei tutti i cluster del gruppo downstream. Se il gruppo upstream ha cluster di cui è stato eseguito l'upgrade a due versioni diverse (come può accadere quando il gruppo upstream è il primo gruppo di una sequenza), il gruppo upstream qualifica la versione più bassa delle due come target di upgrade comune per il gruppo downstream. Ad esempio, se nel gruppo upstream alcuni cluster sono stati aggiornati alla versione 1.31.13-gke.1023000 e altri alla versione 1.33.5-gke.1162000, il gruppo qualifica la versione 1.31.13-gke.1023000 come target di upgrade comune per il gruppo downstream.

I cluster che eseguono versioni successive alla versione di destinazione dell'upgrade non impediscono gli upgrade

Se un gruppo downstream ha cluster che eseguono una versione successiva rispetto al target dell'upgrade qualificato da un gruppo upstream, GKE esegue l'upgrade dei cluster idonei per il target dell'upgrade e ignora i cluster già su una versione successiva. Questo comportamento non impedisce l'avanzamento della sequenza di implementazione, purché almeno un cluster del gruppo downstream sia idoneo per il target dell'upgrade.

Ad esempio, se il gruppo upstream ha qualificato l'upgrade alla versione 1.32 e il gruppo downstream ha cluster che eseguono le versioni 1.31 e 1.33, GKE esegue l'upgrade dei cluster che eseguono la versione 1.31 alla versione 1.32 e ignora i cluster che eseguono la versione 1.33.

Un gruppo upstream deve qualificare una versione corrispondente ai cluster del gruppo successivo

Se i cluster di un gruppo upstream hanno qualificato una versione diversa da quella per cui i cluster del gruppo successivo erano idonei, GKE non può eseguire automaticamente l'upgrade dei cluster in nessun gruppo downstream.

Ad esempio, se è stato eseguito l'upgrade di tutti i cluster del primo gruppo alla versione 1.31.13-gke.1023000, ma i cluster del secondo gruppo eseguivano una versione più recente, ad esempio 1.32.9-gke.1108000, non verrà eseguito l'upgrade automatico dei cluster del secondo gruppo. Il primo gruppo è idoneo per la versione 1.31.13-gke.1023000, ma i cluster del secondo gruppo (attualmente alla versione 1.32) sono idonei solo per la versione di upgrade target 1.33.5-gke.1162000, quindi GKE non può eseguire l'upgrade automatico di questi cluster. Per far avanzare gli upgrade in questa situazione, consulta Correggi l'idoneità tra i gruppi.

Il gruppo upstream ha qualificato più target di upgrade per il gruppo downstream

Se GKE ha eseguito l'upgrade dei cluster nel gruppo upstream più volte prima di eseguire l'upgrade dei cluster nel gruppo downstream, GKE esegue l'upgrade dei cluster nel gruppo downstream all'ultima versione qualificata dal gruppo upstream, per la quale i cluster nel gruppo downstream sono idonei. Per gli upgrade del control plane, questa versione può essere al massimo una versione secondaria successiva alla versione del control plane dei cluster nel gruppo downstream. Per gli upgrade dei nodi, questa versione può essere uguale, ma non successiva, alla versione del control plane dei cluster nel gruppo downstream.

Ad esempio, questo scenario è pertinente se hai configurato esclusioni dalla manutenzione per impedire temporaneamente gli upgrade per il gruppo downstream, che include i cluster di produzione. Tuttavia, il gruppo upstream, che include i cluster di pre-produzione, non ha utilizzato le esclusioni dalla manutenzione per impedire gli upgrade. Pertanto, è stato eseguito l'upgrade del gruppo upstream più volte, qualificando più potenziali target di upgrade, mentre non è stato eseguito l'upgrade del gruppo downstream.

Gli upgrade non completati entro 30 giorni verranno forzati per sbloccare la sequenza

Per garantire che una sequenza di implementazione completi l'upgrade dei cluster, GKE avvia il periodo di soak per un gruppo se gli upgrade del control plane o dei nodi, rispettivamente, non vengono completati in tutti i cluster entro il tempo massimo di upgrade (30 giorni). Gli upgrade di eventuali cluster rimanenti nel gruppo possono comunque continuare durante il periodo di soaking. Per saperne di più, consulta la riga relativa a FORCED_SOAKING nella tabella Informazioni sullo stato di una sequenza di implementazione.

Come funziona la sequenza di implementazione basata sul parco risorse con altre funzionalità di upgrade

La sequenza di implementazione è una delle funzionalità di una raccolta che ti consente di controllare l'aspetto dell'upgrade del ciclo di vita del cluster. Questa sezione spiega come funziona questa funzionalità con alcune delle altre funzionalità disponibili relative agli upgrade dei cluster.

Come funziona la sequenza di implementazione basata sul parco risorse con periodi di manutenzione ed esclusioni

GKE rispetta i periodi di manutenzione e le esclusioni dalla manutenzione durante l'upgrade dei cluster con sequenza di implementazione. GKE avvia l'upgrade di un cluster solo all'interno del periodo di manutenzione del cluster. Puoi utilizzare un'esclusione dalla manutenzione 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 o di un'esclusione, questa circostanza può impedire il completamento degli upgrade del cluster in un gruppo. Se un upgrade del cluster non può essere completato entro 30 giorni a causa di periodi di manutenzione o esclusioni, il gruppo entrerà nella fase di soak indipendentemente dal fatto che l'upgrade di tutti i cluster sia stato completato.

Puoi utilizzare le esclusioni dalla manutenzione come misura temporanea per impedire a una sequenza di completare l'implementazione in un gruppo e passare al gruppo successivo. Per saperne di più, consulta Ritarda il completamento dell'implementazione della versione del gruppo.

Come funziona la sequenza di implementazione basata sul parco risorse con il rilevamento dell'utilizzo della deprecazione

GKE mette in pausa gli upgrade dei cluster quando rileva l'utilizzo di determinate API e funzionalità deprecate. Gli upgrade automatici vengono messi in pausa anche per i cluster di un gruppo in una sequenza di implementazione. Per saperne di più, consulta Come funzionano i ritiri di Kubernetes 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 sequenza di implementazione, GKE utilizza gli upgrade surge per i nodi Autopilot. Per saperne di più, consulta Upgrade automatici dei nodi.

Se gli upgrade dei nodi non possono essere completati entro 30 giorni, il gruppo entrerà nella fase di soak, indipendentemente dal fatto che l'upgrade di tutti i cluster sia stato completato. Questo comportamento può verificarsi se la strategia di upgrade dei nodi fa sì che l'upgrade dei nodi di un cluster Standard richieda più tempo, soprattutto se si tratta di un pool di nodi di grandi dimensioni. Può anche essere aggravato da periodi di manutenzione non abbastanza ampi da consentire il completamento di un upgrade dei nodi.

Come funziona la sequenza di implementazione con i canali di rilascio

I canali di rilascio sono obbligatori per utilizzare la sequenza di implementazione. Tutti i cluster di tutti i gruppi in una sequenza di implementazione devono trovarsi nello stesso canale di rilascio.

Ricezione di più upgrade in una sequenza

Se una nuova versione diventa un target di upgrade sul canale di rilascio mentre gli upgrade del cluster a un target di upgrade precedente sono ancora in corso nella sequenza di implementazione, un gruppo upstream può iniziare l'implementazione di una nuova versione mentre un gruppo downstream sta ancora ricevendo l'upgrade precedente. Ad esempio, se il terzo gruppo di una sequenza sta implementando 1.31.12-gke.1265000, il primo gruppo della sequenza può implementare contemporaneamente 1.31.13-gke.1008000.

Considerazioni per la scelta della sequenza di implementazione basata sul parco risorse

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

Tuttavia, questa strategia potrebbe non essere la scelta giusta per il tuo ambiente se una delle seguenti affermazioni è vera:

  • Hai cluster che non si trovano nello stesso canale di rilascio o nella stessa versione secondaria nello stesso ambiente di produzione.
  • Devi automatizzare gli upgrade che non possono essere mappati solo a cinque fasi di deployment, poiché puoi creare una sequenza di implementazione con un massimo di cinque gruppi di cluster. Non puoi collegare gruppi in più sequenze di implementazione per creare una sequenza di implementazione con più di cinque gruppi. Le sequenze basate su parchi risorse possono includere fino a cinque parchi risorse.
  • Esegui spesso upgrade manuali che fanno sì che i cluster di un gruppo abbiano versioni target di upgrade automatico diverse.

Limitazioni della sequenza di implementazione basata sul parco risorse

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

  • Assicurati che tutti i cluster in una sequenza di implementazione siano registrati nello stesso canale di rilascio e non utilizzino gli upgrade automatici delle patch accelerati. Ti consigliamo inoltre di eseguire la stessa versione secondaria su tutti i cluster per qualificare un target di upgrade. Per saperne di più, consulta Idoneità all'implementazione.
  • Crea una sequenza di implementazione lineare senza cicli (un gruppo ha un gruppo downstream come gruppo upstream) o rami (un gruppo ha più di un gruppo downstream).
  • Crea una sequenza di implementazione tra i cluster della stessa organizzazione. Non puoi creare sequenze con cluster in più organizzazioni.

Problemi noti relativi alla sequenza di implementazione basata sul parco risorse

  • Se un gruppo contiene cluster di località diverse, l'upgrade di un cluster potrebbe essere temporaneamente disponibile solo per alcuni cluster a causa dell'implementazione graduale della nuova versione. Questo comportamento è più probabile che si verifichi nel primo gruppo di cluster e dovrebbe risolversi entro una settimana.
  • Se è presente un gruppo vuoto in una sequenza di implementazione, l'impatto sulla qualifica della versione dipende dalle seguenti condizioni:
    • Se il gruppo vuoto non ha un gruppo upstream, gli upgrade dei cluster non procedono al gruppo downstream, poiché il gruppo vuoto non può qualificare le versioni.
    • Se il gruppo vuoto ha un gruppo upstream, tutti gli upgrade dei cluster in attesa entrano nello stato COMPLETE e vengono propagati al gruppo downstream.

Passaggi successivi