Sequenzare l'implementazione degli upgrade dei cluster

Questa pagina mostra come gestire gli upgrade dei cluster GKE utilizzando la sequenza di implementazione. Per scoprire di più, consulta Informazioni sugli upgrade dei cluster con sequenza di implementazione.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti attività:

  • Attiva l'API Google Kubernetes Engine.
    • Abilita l'API Google Kubernetes Engine
  • Se vuoi utilizzare Google Cloud CLI per questa attività, installa e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, ottieni la versione più recente eseguendo gcloud components update.

Ruoli obbligatori

Configurare una sequenza di implementazione

Questo documento spiega come creare una sequenza di implementazione utilizzando gruppi di cluster organizzati in base a parchi risorse o ambito del team. In questo documento il termine gruppo si riferisce sia ai parchi risorse sia agli ambiti dei team, perché puoi creare una sequenza di implementazione organizzata con entrambi i metodi di raggruppamento.

Puoi creare una sequenza di massimo tre gruppi di cluster e scegliere quanto tempo per il test di sospensione richiesto una volta completati gli upgrade del cluster in un gruppo (massimo 30 giorni). Puoi includere sia i cluster Autopilot che quelli standard.

Per creare una sequenza di implementazione, i cluster devono essere organizzati in gruppi parchi risorse o ambiti dei team. Per indicazioni su come organizzare i cluster, consulta community bank esempio. Una volta organizzati in gruppi, puoi creare una sequenza di implementazione definendo le relazioni con i gruppi upstream e il tempo di attesa di ciascun gruppo. In una sequenza di implementazione, il termine upstream fa riferimento al gruppo precedente e il termine downstream al gruppo successivo.

Organizzare i cluster in gruppi

In una sequenza di implementazione, tutti i cluster di tutti i gruppi devono essere registrati nello stesso canale di rilascio e usare la stessa versione secondaria. Se questi requisiti non vengono soddisfatti e ci sono discrepanze nelle versioni tra i cluster, con l'implementazione della versione. Per ulteriori informazioni, vedi Idoneità all'implementazione.

Puoi creare sequenze di implementazione tra parchi risorse o tra ambiti del team di un team (anteprima).

Come spiegato in Informazioni sugli upgrade dei cluster con sequenza di implementazione, gli ambiti dei team sono un costrutto a livello di parco risorse aziendale per associare sottoinsiemi di cluster del parco risorse a team di applicazioni specifici. Per utilizzare gli ambiti di gruppo, devi abilitare GKE Enterprise. Quando utilizzi o crei ambiti dei team per la sequenza di implementazione, si applicano le seguenti limitazioni:

  • Le sequenze basate su team richiedono cluster monoutente: 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.

  • Ogni ambito del team deve trovarsi in un parco diverso per creare una sequenza di implementazione tra di loro. La creazione di una sequenza di implementazione tra ambiti dei team diversi all'interno dello stesso parco risorse non è supportata.

Se hai già organizzato i tuoi cluster in gruppi, puoi ignorare seguenti passaggi e procedi con la creazione di una sequenza di implementazione.

Parchi risorse

Per creare una sequenza di implementazione basata su parchi risorse, devi prima raggruppare i cluster in parchi risorse. Puoi organizzare i cluster in base agli ambienti di implementazione, ad esempio test, gestione temporanea e produzione, come mostrato nell'esempio di sequenza di implementazione basata su parchi risorse.

Registra ogni cluster con un parco risorse in base al raggruppamento che hai scelto.

Team

Per creare una sequenza di implementazione basata sul team, devi raggruppare i cluster in ambiti di team. Per farlo, devi prima organizzare i cluster in parchi risorse in base agli ambienti di deployment, come test, gestione temporanea e produzione, come mostrato in l'esempio di implementazione basata sull'ambito sequenza. Quindi, puoi ulteriormente suddividere i cluster in ambiti per team diversi cluster.

  1. Per ogni cluster nella sequenza, registrare il cluster con un parco risorse. Il cluster deve essere registrato nel parco risorse del progetto in cui creerai l'ambito del team per questo cluster. Se vuoi registrare un cluster in un cluster parco risorse in un altro progetto host, assicurati di aver impostato autorizzazioni per registrazione tra progetti.

  2. Crea 2-3 ambiti dei team per organizzare i cluster. Crea ogni ambito nel progetto host del rispettivo parco risorse del team. In una sequenza di implementazione puoi avere fino a tre ambiti di team.

    Consulta il riferimento per gcloud alpha container fleet scopes create per un l'elenco completo delle segnalazioni. Con il comando create, puoi utilizzare i flag nelle istruzioni per creare una sequenza di implementazione.

  3. Aggiungi ogni cluster a un ambito.

Crea una sequenza di implementazione

Una sequenza di implementazione è organizzata come un elenco collegato con un massimo di tre elementi.

Quando crei una sequenza di implementazione, devi impostare le seguenti proprietà per ogni gruppo di cluster, un ambito del parco risorse o del team:

  • Gruppo upstream: l'ambito del parco risorse o del team upstream, che qualifica i nuovi le versioni per il gruppo downstream. Non devi impostare un gruppo upstream per primo gruppo di una sequenza.
  • Tempo di sospensione: il tempo di sospensione per un gruppo è il periodo che intercorre tra il completamento degli upgrade (o sono trascorsi 30 giorni dall'inizio dell'implementazione) e il momento in cui è possibile iniziare gli upgrade sul gruppo downstream. Per saperne di più, vedi Come funziona l'idoneità della versione in una sequenza di implementazione.

Per ciascuno dei seguenti comandi, sostituisci SOAK_TIME con il tempo di attesa per il gruppo che stai aggiornando.

Parco risorse - gcloud

Le istruzioni riportate di seguito utilizzano il comando gcloud container fleet clusterupgrade update, ma puoi impostare le stesse proprietà con il comando gcloud container fleet clusterupgrade create.

Crea una sequenza di implementazione:

  1. Imposta il tempo di soak per il primo parco risorse nella sequenza:

    gcloud container fleet clusterupgrade update \
    --default-upgrade-soaking=SOAK_TIME \
    --project=FIRST_FLEET_PROJECT_ID

    Sostituisci FIRST_FLEET_PROJECT_ID con l'ID del progetto del progetto host del parco risorse.

  2. Imposta il parco risorse upstream e il tempo di soak per il secondo parco risorse della sequenza:

    gcloud container fleet clusterupgrade update \
    --upstream-fleet=FIRST_FLEET_PROJECT_ID \
    --default-upgrade-soaking=SOAK_TIME \
    --project=SECOND_FLEET_PROJECT_ID

    Sostituisci FIRST_FLEET_PROJECT_ID con l'ID progetto del progetto host del primo parco risorse SECOND_FLEET_PROJECT_ID con l'ID progetto di progetto host del parco risorse.

  3. (Facoltativo) Se vuoi avere tre parchi in una sequenza di implementazione, imposta il parco a monte per il terzo parco nella sequenza:

    gcloud container fleet clusterupgrade update \
    --upstream-fleet=SECOND_FLEET_PROJECT_ID \
    --default-upgrade-soaking=SOAK_TIME \
    --project=THIRD_FLEET_PROJECT_ID

    Sostituisci SECOND_FLEET_PROJECT_ID con l'ID progetto del progetto host del secondo parco risorse e THIRD_FLEET_PROJECT_ID con l'ID progetto del progetto host del parco risorse.

Parchi risorse - Terraform

Questa sezione mostra come creare una sequenza basata su un parco risorse utilizzando con Terraform. Puoi anche utilizzare questa risorsa per aggiornare la sequenza. Per apprendere di più, consulta la documentazione di riferimento google_gke_hub_feature

Crea una sequenza di implementazione:

  1. Aggiungi il blocco seguente alla configurazione Terraform per impostare il blocco per il primo parco risorse nella sequenza:

    resource "google_gke_hub_feature" "feature" {
  name = "clusterupgrade"
  location = "global"
  spec {
    clusterupgrade {
      upstream_fleets = []
      post_conditions {
        soaking = "SOAK_TIME"
      }
    }
  }
  project = "FIRST_FLEET_PROJECT_ID"
}

    Sostituisci FIRST_FLEET_PROJECT_ID con l'ID del progetto del progetto host del parco risorse.

  2. Aggiungi il seguente blocco alla tua configurazione Terraform per impostare l'upstream flotta e il tempo di sospensione per la seconda flotta nella sequenza:

    resource "google_gke_hub_feature" "feature" {
  name = "clusterupgrade"
  location = "global"
  spec {
    clusterupgrade {
      upstream_fleets = ["FIRST_FLEET_PROJECT_ID"]
      post_conditions {
        soaking = "SOAK_TIME"
      }
    }
  }
  project = "SECOND_FLEET_PROJECT_ID"
}

    Sostituisci FIRST_FLEET_PROJECT_ID con l'ID progetto del progetto host del primo parco risorse e SECOND_FLEET_PROJECT_ID con l'ID progetto del progetto host del parco risorse.

  3. (Facoltativo) Se vuoi avere tre parchi risorse in una sequenza di implementazione, aggiungi il il seguente blocco alla configurazione Terraform per impostare il parco risorse upstream per il parco risorse nella sequenza:

    resource "google_gke_hub_feature" "feature" {
  name = "clusterupgrade"
  location = "global"
  spec {
    clusterupgrade {
      upstream_fleets = ["SECOND_FLEET_PROJECT_ID"]
      post_conditions {
        soaking = "SOAK_TIME"
      }
    }
  }
  project = "THIRD_FLEET_PROJECT_ID"
}

    Sostituisci SECOND_FLEET_PROJECT_ID con l'ID progetto del progetto host del secondo parco e THIRD_FLEET_PROJECT_ID con l'ID progetto del progetto host del parco.

Team - gcloud

Puoi impostare queste proprietà quando crei o aggiorni l'ambito di un team. Le seguenti istruzioni usano il comando gcloud alpha container fleet scopes update, ma puoi impostare le stesse proprietà quando crei un ambito del team con Comando gcloud alpha container fleet scopes create.

Per ciascuno di questi comandi, sostituisci le variabili con il nome dell'ambito del team o con l'ID progetto host del parco del team.

Crea una sequenza di implementazione:

  1. Imposta il tempo di sospensione per il primo ambito della sequenza:

    gcloud alpha container fleet scopes update projects/FIRST_SCOPE_PROJECT_ID/locations/global/scopes/FIRST_SCOPE_NAME \
    --default-upgrade-soaking=SOAK_TIME \
    --project=FIRST_SCOPE_PROJECT_ID

  2. Imposta l'ambito upstream e il tempo di sospensione per il secondo ambito nella sequenza:

    gcloud alpha container fleet scopes update projects/SECOND_SCOPE_PROJECT_ID/locations/global/scopes/SECOND_SCOPE_NAME \
    --upstream-scope=projects/FIRST_SCOPE_PROJECT_ID/locations/global/scopes/FIRST_SCOPE_NAME \
    --default-upgrade-soaking=SOAK_TIME \
    --project=SECOND_SCOPE_PROJECT_ID

  3. (Facoltativo) Se vuoi avere tre ambiti dei team in una sequenza di implementazione, imposta l'ambito upstream per il terzo ambito della sequenza:

    gcloud alpha container fleet scopes update projects/THIRD_SCOPE_PROJECT_ID/locations/global/scopes/THIRD_SCOPE_NAME \
    --upstream-scope=projects/SECOND_SCOPE_PROJECT/locations/global/scopes/SECOND_SCOPE_NAME \
    --default-upgrade-soaking=SOAK_TIME \
    --project=THIRD_SCOPE_PROJECT_ID

Controllare lo stato di una sequenza di implementazione

Puoi controllare lo stato di una sequenza di implementazione con uno dei seguenti metodi:

Monitora una sequenza di implementazione nella console Google Cloud

  1. Vai alla pagina Sequenza di implementazione nella console Google Cloud.

    Vai a Sequenza di implementazione

  2. Visualizza la sequenza in Monitorare la sequenza di implementazione. Se non vedi una sequenza di implementazione, potresti dover seguire le istruzioni per passare a una sequenza di implementazione diversa o creare una sequenza di implementazione, se non l'hai ancora fatto.

Come utilizzare la console per monitorare una sequenza di implementazione

In questa pagina puoi visualizzare la sequenza di implementazione associata al fleet del tuo progetto. Per visualizzare l'avanzamento di una sequenza di implementazione, puoi:

  • Visualizza l'intera sequenza di implementazione o gli stati dei singoli parchi risorse e dei cluster al loro interno, nonché il tempo di attesa tra i parchi risorse. Puoi anche visualizzare la sequenza in cui non è attivo alcun upgrade se vuoi controllare la configurazione della sequenza.
  • Filtra per tipo di upgrade (piano di controllo o upgrade del nodo) e versione specifica (ad esempio, 1.31.6-gke.500).

Puoi monitorare visivamente l'intera sequenza di implementazione mentre GKE esegue l'upgrade di tutti i cluster della sequenza, qualificando una nuova versione in tutti gli ambienti prima di eseguire l'upgrade dei cluster dell'ambiente di produzione. Durante il monitoraggio, puoi gestire una sequenza di implementazione con gcloud CLI, apportando le modifiche necessarie.

Passare a una sequenza di implementazione diversa

Questa pagina mostra la sequenza di implementazione basata sul parco risorse se il progetto attivo nella console Google Cloud è un progetto host del parco risorse per un parco risorse registrato in una sequenza di implementazione.

Se vuoi visualizzare una sequenza di implementazione diversa, seleziona un progetto host del parco risorse associate a una sequenza di implementazione diversa dal selettore dei progetti in alto della pagina.

Utilizza gcloud CLI

Utilizza questi comandi nelle sezioni seguenti per verificare come vengono eseguiti gli upgrade in una sequenza di implementazione. Per scoprire di più sui dettagli forniti, consulta Informazioni sullo stato per una sequenza di implementazione

Per eseguire questi comandi, assicurati di disporre delle autorizzazioni necessarie per ogni progetto host del parco risorse. Ad esempio, se di sequenza ha ambiti tra progetti in diversi parchi risorse, devi avere le autorizzazioni ogni progetto per descrivere la sequenza.

Per i comandi che seguono, se hai bisogno solo di informazioni su un parco o un ambito nella sequenza, sostituisci il flag --show-linked-cluster-upgrade con --show-cluster-upgrade.

Parchi risorse

Controlla lo stato di una sequenza di implementazione basata sul parco:

gcloud container fleet clusterupgrade describe \
    --show-linked-cluster-upgrade --project=FLEET_PROJECT_ID

Sostituisci FLEET_PROJECT_ID con l'ID del progetto ospitante per qualsiasi parco risorse nella sequenza.

Consulta il riferimento gcloud container fleet clusterupgrade describe per un elenco completo delle segnalazioni.

Team

Controlla lo stato di una sequenza di implementazione basata sul team:

gcloud alpha container fleet scopes describe SCOPE_NAME \
    --show-linked-cluster-upgrade
    --project=SCOPE_PROJECT_ID

Sostituisci SCOPE_NAME con il nome di qualsiasi ambito di gruppo nella sequenza di implementazione e SCOPE_PROJECT_ID con l'ID progetto di questo ambito di gruppo.

Consulta il riferimento per gcloud alpha container fleet scopes describe per un l'elenco completo delle segnalazioni.

Per visualizzare lo stato di singoli cluster in un ambito del parco risorse o del team, esegui seguente comando nel progetto host del parco risorse e vedrai membershipStates sezione:

gcloud container fleet features describe clusterupgrade

Informazioni sullo stato di una sequenza di implementazione

Quando controlli lo stato dell'implementazione di una versione, puoi vedere l'avanzamento di ogni e un cluster all'interno di quel gruppo.

Consulta la tabella seguente per conoscere gli stati potenziali di un cluster o di un gruppo:

Stato Per un singolo cluster Per un gruppo (ambito parco risorse o team)
NON IDONEO Questo cluster non è idoneo per questo upgrade Uno o più cluster in questo gruppo non sono idonei per questo upgrade.
IN ATTESA L'upgrade non è stato avviato o è in corso per il cluster. L'upgrade non è stato avviato su nessuno dei cluster del gruppo.
IN_PROGRESS N/D L'upgrade è stato avviato su almeno un cluster, ma non è stato completato in tutti i cluster.
INCREDIBILE L'upgrade è stato completato sul cluster e il periodo di sospensione non è ancora terminato. L'upgrade è stato completato su tutti i cluster e non è stato completato il tempo di attesa.
FORCED_SOAKING L'upgrade ha richiesto un tempo superiore al tempo massimo (30 giorni), pertanto è stato costretto a entrare nella fase di sospensione. L'upgrade può comunque continuare nel cluster. L'upgrade ha richiesto un tempo superiore al tempo massimo (30 giorni), pertanto è stato costretto a entrare nella fase di sospensione. L'upgrade può comunque continuare nei cluster.
COMPLETA L'upgrade viene considerato "completato", il che significa che è terminata la fase di attesa su questo cluster. L'upgrade viene considerato "completato" pronto per essere utilizzato dal gruppo downstream, il che significa che l'upgrade ha terminato l'attesa.

Nell'output di questi comandi, i valori clusterUpgrade(s).spec e Gli attributi clusterUpgrade(s).state contengono informazioni aggiuntive sull'attributo dell'upgrade dei cluster, ad esempio tempo di sospensione, override dell'upgrade del cluster e upgrade .

Gestisci una sequenza di implementazione

Puoi controllare gli upgrade automatici del cluster con la sequenziazione dell'implementazione in diversi modi, come spiegato nelle sezioni seguenti.

Modificare il tempo di sospensione per un gruppo

Puoi modificare il tempo di sospensione predefinito per un gruppo o modificare il tempo di sospensione per quando il gruppo esegue l'upgrade a una versione specifica.

Aggiorna il tempo di sospensione predefinito

Per modificare il tempo di attesa predefinito per un gruppo, utilizza i comandi delle istruzioni per creare una sequenza di implementazione, omettendo i flag per impostare il gruppo a monte.

Ignora il tempo di sospensione predefinito

Puoi modificare il tempo di sospensione per l'implementazione di una specifica versione in modo che sia diverso da il tempo di sospensione predefinito per il gruppo. Ad esempio, se hai già qualificato una nuova versione e vuoi che gli upgrade inizino nel gruppo successivo, puoi impostare il tempo di soak su zero. Puoi utilizzarla anche se vuoi più tempo rispetto al tempo di sospensione predefinito per qualificare una versione specifica.

Poiché il tempo di attesa è impostato in base al gruppo, se vuoi sostituire il tempo di attesa per altri gruppi in questa sequenza, aggiornali utilizzando lo stesso comando sostituendo il nome del parco o dell'ambito, a seconda del tipo di sequenza.

Per le istruzioni riportate in questa sezione, sostituisci le seguenti variabili:

  • SOAK_TIME: il tempo di sospensione da utilizzare diverso da quello predefinito (ad esempio, "0d" se vuoi saltare il tempo di sospensione per l'implementazione di una versione).
  • UPGRADE_NAME: il tipo di upgrade, ovvero k8s_control_plane per gli upgrade del piano di controllo o k8s_node per il nodo upgrade.

  • VERSION: la versione GKE in cui vuoi per eseguire l'override del tempo di sospensione predefinito dopo la versione (ad esempio, 1.25.2-gke.400) è stato implementato in questo gruppo.

Parchi risorse - gcloud

Esegui questo comando nel progetto host del parco risorse in cui vuoi eseguire l'override il tempo di sospensione utilizzato per l'implementazione della versione di una versione specifica.

Modifica il tempo di sospensione di un parco risorse:

gcloud container fleet clusterupgrade update
    --add-upgrade-soaking-override=SOAK_TIME \
    --upgrade-selector=name=UPGRADE_NAME,version=VERSION

Parchi risorse - Terraform

Aggiungi il seguente blocco gke_upgrades_overrides a Terraform all'interno del blocco clusterupgrade per eseguire l'override tempo di sospensione utilizzato per l'implementazione della versione di una versione specifica:

gke_upgrade_overrides {
    upgrade {
      name = "UPGRADE_NAME"
      version = "VERSION"
    }
    post_conditions {
      soaking = "SOAK_TIME"
    }
  }

Teams - gcloud

Esegui questo comando nel progetto host del parco risorse dell'ambito del team. Sostituisci SCOPE_NAME con il nome dell'ambito del team per cui vuoi eseguire l'override del tempo di attesa utilizzato per l'implementazione di una versione specifica.

Modificare il tempo di attesa di un ambito del team:

gcloud alpha container fleet scopes update SCOPE_NAME \
    --add-upgrade-soaking-override=SOAK_TIME \
    --upgrade-selector=name=UPGRADE_NAME,version=VERSION

Modificare l'ordine di una sequenza

Se vuoi modificare l'ordine di una sequenza, utilizza i comandi istruzioni per creare una sequenza di implementazione per aggiornare i gruppi upstream.

Ritarda il completamento dell'implementazione della versione del gruppo

Se devi impedire temporaneamente a un gruppo di completare l'implementazione di una nuova versione nei suoi cluster, puoi aggiungere un'esclusione per la manutenzione a uno dei cluster per i quali non è stato eseguito l'upgrade alla versione di destinazione. Questo può mettere in pausa un gruppo dal procedere al suo tempo di sospensione o al gruppo downstream per un massimo di 30 giorni. Dopo 30 giorni, il gruppo inizierà il periodo di attesa.

Puoi anche modificare il tempo di attesa per il gruppo impostandolo su 30 giorni per massimizzare il tempo di attesa della sequenza di implementazione prima di passare al gruppo successivo.

Se devi ritardare ulteriormente l'inizio degli upgrade per il gruppo successivo, puoi utilizzare le esclusioni per la manutenzione per i cluster del gruppo successivo.

Passare da una sequenza di implementazione basata sul parco risorse a una basata sul team e viceversa

Puoi passare da sequenze basate sul parco risorse a sequenze basate sul team oppure da sequenze basate su team a sequenze basate su parco risorse. Le istruzioni presuppongono che tu stia trasferendo da una sequenza all'altra organizzata come quelle illustrate nei diagrammi di esempio.

Parchi risorse per i team

Per cambiare i tuoi cluster da una sequenza di implementazione basata sul parco risorse a una sequenza di implementazione basata sul team di implementazione, segui questi passaggi:

  1. Configurare le esclusioni di manutenzione per tutti i cluster in ciascuno dei tuoi parchi risorse per evitare upgrade mentre modifica la configurazione.
  2. Assicurati di aver abilitato GKE Enterprise nei progetti di hosting del parco risorse.
  3. In ciascuno dei tuoi parchi risorse, crea uno o più ambiti dei team per suddividere il gruppo di cluster in quel parco risorse.
  4. Crea una o più sequenze di implementazione tra gli ambiti dei team corrispondenti in ogni parco risorse.
  5. Aggiungi i tuoi cluster ai nuovi ambiti del team.
  6. Rimuovi le esclusioni dalla manutenzione che hai configurato per questa modifica.

Da team a parchi risorse

Per modificare i cluster da una sequenza di implementazione basata sul team a una sequenza di implementazione basata sul parco risorse:

  1. Configura le esclusioni per la manutenzione per tutti i cluster in ogni parco risorse per evitare eventuali upgrade durante la modifica della configurazione.
  2. Crea una sequenza di implementazione tra i parchi risorse.
  3. Rimuovi i cluster dagli ambiti dei team. Ora questi cluster sono registrati solo ai rispettivi parchi risorse del loro ambito, a cui hai eseguito l'accesso in una sequenza di implementazione nel passaggio precedente.
  4. Elimina gli ambiti dei team.
  5. Rimuovi le esclusioni dalla manutenzione che hai configurato per questa modifica.

Eliminare una sequenza

Per eliminare una sequenza, rimuovi le associazioni upstream per la seconda (se la sequenza di implementazione ha tre gruppi).

Per i parchi risorse

Esegui il seguente comando nel progetto host del secondo e del terzo gruppo nella sequenza di implementazione:

gcloud container fleet clusterupgrade update --reset-upstream-fleet

Per team

Esegui il seguente comando nel progetto host della flotta degli ambiti del secondo e terzo team nella sequenza di implementazione:

gcloud alpha container fleet scopes update SCOPE_NAME --reset-upstream-scope

Sostituisci SCOPE_NAME con i nomi del secondo e del terzo ambito, rispettivamente.

Risoluzione dei problemi

Risolvere i problemi relativi all'idoneità dell'implementazione

Se tutti i cluster in una sequenza di implementazione non hanno lo stesso target di upgrade, GKE potrebbe non essere in grado di procedere con gli upgrade del cluster. Gli upgrade automatici non possono procedere se un gruppo upstream non qualifica un target di upgrade da passare al gruppo downstream. Inoltre, gli upgrade automatici non possono essere eseguiti se i cluster del gruppo upstream non qualificano una destinazione di upgrade non valida per i cluster in solo al gruppo downstream.

Per verificare se la sequenza di implementazione presenta problemi di idoneità: verifica lo stato della sequenza di implementazione. Se un gruppo non è idoneo, segui le istruzioni per visualizzare lo stato dei singoli cluster in un gruppo.

Per far avanzare immediatamente gli upgrade dei cluster, rimuovi tutti i cluster con stato INELIGIBLE seguendo le istruzioni per far avanzare le implementazioni parzialmente idonee.

Correggere l'idoneità in un gruppo

In un gruppo, se un cluster non è idoneo perché utilizza una versione precedente (ad Ad esempio, la maggior parte dei cluster del gruppo viene aggiornata dalla versione 1,23 alla versione 1,24 e la versione del cluster è 1.22), puoi eseguire manualmente l'upgrade del cluster alla versione 1.24 per risolvere le discrepanze di versione.

In un gruppo, se un cluster non è idoneo perché utilizza una versione successiva (ad Ad esempio, la maggior parte dei cluster del gruppo viene aggiornata dalla versione 1,23 alla versione 1,24 e la versione del cluster è 1.25), non puoi eseguire manualmente il downgrade del cluster per risolvere le discrepanze di versione e dover rimuovere il cluster.

Correggi l'idoneità tra i gruppi

Tra i gruppi, se esiste una mancata corrispondenza nei target di upgrade in cui il gruppo downstream è in una versione più recente (ad esempio, il gruppo upstream è stato sottoposto a upgrade da 1.23 a 1.24 e i cluster del gruppo downstream sono in 1.25), puoi eseguire manualmente l'upgrade dei cluster del gruppo upstream alla versione 1.25 per assicurarti che gli upgrade procedono.

Tra i gruppi, se esiste una mancata corrispondenza nei target di upgrade in cui il gruppo downstream è in una versione precedente (ad esempio, il gruppo upstream è stato sottoposto ad upgrade da 1.24 a 1.25 e i cluster nel gruppo downstream sono in 1.23), puoi eseguire manualmente l'upgrade dei cluster nel gruppo downstream a 1.24 o 1.25 per assicurarti che gli upgrade procedano.

Avanza implementazioni parzialmente idonee

Se gli upgrade dei cluster in un gruppo non vengono completati a causa di problemi di idoneità al rollout (ad esempio discrepanze nelle versioni all'interno di un gruppo), puoi rimuovere i cluster non idonei per il target di upgrade del gruppo per completare l'implementazione della versione e iniziare il tempo di attesa o passare al gruppo successivo nella sequenza di implementazione. Puoi rimuovere un cluster da un gruppo anche per altri motivi, ad esempio se l'utilizzo di questo cluster non è più correlato agli altri cluster del gruppo.

Segui le istruzioni per annullare la registrazione di un cluster da un parco risorse o rimuovere i cluster dagli ambiti dei team, a seconda del tipo di sequenza di implementazione.

Dopo aver rimosso tutti i cluster che impediscono il completamento del rollout della versione di un gruppo, il rollout della versione del gruppo verrà completato. Conferma questo seguendo le istruzioni per controllare lo stato di un'implementazione della versione.

Passaggi successivi