Sequenza dell'implementazione degli upgrade del cluster

Questa pagina mostra come gestire gli upgrade dei cluster GKE utilizzando la sequenza di implementazione. Per saperne 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à:

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

Ruoli obbligatori

Configura una sequenza di implementazione

Questo documento spiega come creare una sequenza di implementazione utilizzando gruppi di cluster organizzati per parchi risorse o ambiti dei team. In questo documento viene utilizzato il termine gruppo per fare riferimento sia ai parchi risorse che 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 il tempo necessario per i test di soak dopo il completamento degli upgrade del cluster in un gruppo (massimo 30 giorni). Puoi includere cluster sia Autopilot sia Standard.

Per creare una sequenza di implementazione, i cluster devono essere organizzati in gruppi di parchi risorse o ambiti dei team. Per indicazioni su come organizzare i cluster, vedi l'esempio della Community Bank. Dopo aver organizzato le relazioni in gruppi, puoi creare una sequenza di implementazione definendo le relazioni dei gruppi upstream e il tempo di inattività di ciascun gruppo. "Upstream", in una sequenza di implementazione, si riferisce al gruppo precedente e "downstream" al gruppo successivo.

Organizza i cluster in gruppi

In una sequenza di implementazione, tutti i cluster in tutti i gruppi devono essere registrati nello stesso canale di rilascio e avere la stessa versione secondaria. Se questi requisiti non vengono soddisfatti e ci sono discrepanze di versione tra i cluster, questo può causare problemi con l'implementazione della versione. Per maggiori informazioni, consulta Idoneità all'implementazione.

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

Come hai visto in Informazioni sugli upgrade dei cluster con la 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. Devi abilitare GKE Enterprise per utilizzare gli ambiti dei team. Quando utilizzi o crei ambiti dei team per la sequenza di implementazione, si applicano le seguenti limitazioni:

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

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

Se hai già organizzato i cluster in gruppi, puoi saltare i passaggi seguenti e passare a Creare una sequenza di implementazione.

Parchi risorse

Per creare una sequenza di implementazione basata sul parco risorse, devi prima raggruppare i cluster in parchi risorse. Puoi organizzare i cluster per ambienti di deployment come test, gestione temporanea e produzione, come mostrato nella sequenza di implementazione basata sul parco risorse di esempio.

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

Team

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

  1. Per ogni cluster nella sequenza, registra 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 parco risorse in un progetto host diverso, assicurati di aver impostato le autorizzazioni necessarie per la registrazione tra progetti.

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

    Per un elenco completo dei flag, consulta il riferimento per gcloud alpha container fleet scopes create. 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 elenco collegato con un massimo di tre elementi.

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

  • Gruppo upstream:l'ambito del parco risorse o del team upstream, che qualifica le nuove versioni per il gruppo downstream. Non devi impostare un gruppo upstream per il primo gruppo di una sequenza.
  • Tempo di inattività: il tempo di attesa per un gruppo è il periodo di tempo che intercorre tra il completamento degli upgrade (o l'implementazione ha richiesto 30 giorni) e il momento in cui possono iniziare gli upgrade nel gruppo a valle. Per scoprire di più, consulta Come funziona l'idoneità della versione in una sequenza di implementazione.

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

Parchi risorse - gcloud

Le seguenti istruzioni 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 attesa per il primo parco risorse della 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 host del parco risorse.

  2. Imposta il parco risorse a monte e il tempo di attesa per il secondo parco risorse nella 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 e con SECOND_FLEET_PROJECT_ID con l'ID del progetto host del parco risorse.

  3. (Facoltativo) Se vuoi avere tre parchi risorse in una sequenza di implementazione, imposta il parco risorse upstream per il terzo parco risorse 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 del progetto host del parco risorse.

Parchi risorse - Terraform

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

Crea una sequenza di implementazione:

  1. Aggiungi il blocco seguente alla configurazione di Terraform per impostare il tempo di soak per il primo parco risorse della 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 host del parco risorse.

  2. Aggiungi il blocco seguente alla configurazione Terraform per impostare il parco risorse upstream e il tempo di attesa per il secondo parco risorse 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 del progetto host del primo parco risorse e con l'ID SECOND_FLEET_PROJECT_ID del progetto host del parco risorse.

  3. (Facoltativo) Se vuoi avere tre parchi risorse in una sequenza di implementazione, aggiungi il blocco seguente alla configurazione di 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 risorse e THIRD_FLEET_PROJECT_ID con l'ID del progetto host del parco risorse.

Team - gcloud

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

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

Crea una sequenza di implementazione:

  1. Imposta il tempo di attesa per il primo ambito nella 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 a monte e il tempo di attesa 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 nella 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

Utilizza questi comandi nelle sezioni seguenti per verificare l'avanzamento degli upgrade in una sequenza di implementazione. Per scoprire di più sui dettagli forniti, consulta Informazioni sullo stato di una sequenza di implementazione

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

Per i comandi seguenti, se ti servono solo informazioni su un parco risorse 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 risorse:

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

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

Consulta il riferimento gcloud container fleet clusterupgrade describe per un elenco completo dei flag.

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 del team nella sequenza di implementazione e SCOPE_PROJECT_ID con l'ID progetto dell'ambito di questo team.

Per un elenco completo dei flag, consulta il riferimento per gcloud alpha container fleet scopes describe.

Per visualizzare lo stato di singoli cluster all'interno di un ambito del parco risorse o del team, esegui questo comando nel progetto host del parco risorse e consulta la sezione membershipStates:

gcloud container fleet features describe clusterupgrade

Informazioni sullo stato di una sequenza di implementazione

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

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

Stato Per cluster Per gruppo
NON IDONEA 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 in nessuno dei cluster del gruppo.
IN_PROGRESS N/A L'upgrade è stato avviato su almeno un cluster, ma non è stato completato su tutti i cluster.
AMBIENTE L'upgrade sul cluster è stato completato e non si è verificato il completamento dell'archiviazione. L'upgrade è stato completato in tutti i cluster e non è stato completato.
FORCED_SOAKING L'upgrade ha richiesto più del tempo massimo previsto per l'upgrade (30 giorni), pertanto lo abbiamo costretto a entrare nella fase di ammollo. L'upgrade può continuare nel cluster. L'upgrade ha richiesto più del tempo massimo previsto per l'upgrade (30 giorni), pertanto lo abbiamo costretto a entrare nella fase di ammollo. L'upgrade può continuare nei cluster.
COMPLETE L'upgrade viene considerato "completato", il che significa che ha terminato l'archiviazione in questo cluster. L'upgrade viene considerato "completato" e pronto per essere utilizzato dal gruppo a valle, il che significa che è stato completato.

Nell'output di questi comandi, gli attributi clusterUpgrade(s).spec e clusterUpgrade(s).state contengono informazioni aggiuntive sull'upgrade del cluster, come tempo di attesa, override dell'upgrade del cluster e stato dell'upgrade.

Gestisci una sequenza di implementazione

Puoi controllare gli upgrade automatici dei cluster con la sequenza di implementazione in diversi modi, come spiegato nelle sezioni seguenti.

Modificare il tempo di attesa per un gruppo

Puoi modificare il tempo di attesa predefinito per un gruppo o il tempo di attesa durante l'upgrade del gruppo a una versione specifica.

Aggiornare il tempo di attesa predefinito

Per modificare il tempo di soak predefinito per un gruppo, utilizza i comandi nelle istruzioni per creare una sequenza di implementazione, omettendo i flag per configurare il gruppo a monte.

Esegui l'override del tempo di attesa predefinito

Puoi modificare il tempo di attesa per l'implementazione di una versione specifica in modo che sia diverso dal tempo di attesa predefinito per il gruppo. Ad esempio, se hai già qualificato una nuova versione e vuoi che inizi l'upgrade nel gruppo successivo, puoi impostare il tempo di attesa su zero. Potete usarla anche se volete avere più tempo rispetto al tempo di attesa predefinito per qualificare una versione specifica.

Poiché il tempo di soak viene impostato in base al gruppo, se vuoi eseguire l'override del tempo di soak per altri gruppi in questa sequenza, aggiornali utilizzando questo stesso comando, sostituendo il nome del parco risorse o dell'ambito, a seconda del tipo di sequenza.

Per le istruzioni di questa sezione, sostituisci le seguenti variabili:

  • SOAK_TIME: il tempo di attesa da utilizzare in modo diverso da quello predefinito (ad esempio, "0d" se vuoi saltare il tempo di attesa 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 gli upgrade dei nodi.

  • VERSION: la versione di GKE in cui vuoi eseguire l'override del tempo di soak predefinito dopo l'implementazione della versione (ad esempio 1.25.2-gke.400) in questo gruppo.

Parchi risorse - gcloud

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

Modificare il tempo di attesa 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 alla tua configurazione Terraform all'interno del blocco clusterupgrade per sostituire il tempo di attesa utilizzato per l'implementazione della versione di una versione specifica:

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

Team - 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 il quale vuoi eseguire l'override del tempo di attesa utilizzato per l'implementazione della versione 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 nelle 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 propri cluster, puoi aggiungere un'esclusione di manutenzione a uno qualsiasi dei cluster per cui non è stato eseguito l'upgrade alla versione di destinazione. In questo modo è possibile mettere in pausa un gruppo dal procedere al relativo tempo di attesa o al gruppo a valle per un massimo di 30 giorni. Dopo 30 giorni, il gruppo inizierà a bagnarsi.

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

Se hai bisogno di ritardare ulteriormente gli upgrade per il gruppo successivo, puoi utilizzare le esclusioni di manutenzione per i cluster nel gruppo successivo.

Passa dalla sequenza di implementazione basata sul parco risorse a quella basata sui team e viceversa

Puoi passare da sequenze basate su parco risorse a sequenze basate su team o da sequenze basate su team a sequenze basate su parco risorse. Le istruzioni presuppongono che tu stia eseguendo il trasferimento tra sequenze organizzate come quelle illustrate negli diagrammi di esempio.

Da parchi risorse a team

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

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

Da team a parchi risorse

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

  1. Configura le esclusioni dalla manutenzione per tutti i cluster in ciascuno dei tuoi parchi 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 nei rispettivi parchi risorse dell'ambito che, nel passaggio precedente, hai unito in una sequenza di implementazione.
  4. Elimina gli ambiti dei team.
  5. Rimuovi le esclusioni di manutenzione che hai configurato per questa modifica.

Eliminare una sequenza

Per eliminare una sequenza, rimuovi le associazioni upstream per il secondo e il terzo gruppo (se la sequenza di implementazione ha tre gruppi).

Per le flotte

Esegui questo comando nel progetto host del parco risorse del secondo e del terzo parco risorse nella sequenza di implementazione:

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

Per team

Esegui questo comando nel progetto host del parco risorse dell'ambito del secondo e del terzo team nella sequenza di implementazione:

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

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

Risoluzione dei problemi

Risolvere i problemi di idoneità dell'implementazione

Se tutti i cluster in una sequenza di implementazione non hanno la stessa destinazione di upgrade, GKE potrebbe non essere in grado di procedere con gli upgrade del cluster. Gli upgrade automatici non possono procedere se un gruppo a monte non soddisfa un target dell'upgrade da passare al gruppo a valle. Inoltre, gli upgrade automatici non possono procedere se i cluster nel gruppo upstream qualificano un target di upgrade non valido per i cluster nel gruppo downstream.

Per verificare se la sequenza di implementazione presenta problemi di idoneità all'implementazione, controlla 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 avanzare immediatamente gli upgrade dei cluster, rimuovi tutti i cluster con uno stato INELIGIBLE seguendo le istruzioni per avanzare le implementazioni parzialmente idonee.

Correggere l'idoneità in un gruppo

In un gruppo, se un cluster non è idoneo perché si trova su una versione precedente (ad esempio, viene eseguito l'upgrade della maggior parte dei cluster del gruppo da 1.23 a 1.24 e un cluster è nella versione 1.22), puoi eseguire manualmente l'upgrade del cluster alla versione 1.24 per risolvere la discrepanza di versione.

In un gruppo, se un cluster non è idoneo perché si trova a una versione successiva (ad esempio, la maggior parte dei cluster del gruppo viene aggiornata dalla versione 1.23 alla versione 1.24 e un cluster alla versione 1.25), non puoi eseguire manualmente il downgrade del cluster per risolvere la discrepanza di versione e rimuoverlo.

Correggi l'idoneità tra i gruppi

Tra i gruppi, se si verifica una mancata corrispondenza nei target di upgrade in cui il gruppo a valle è su una versione più recente (ad esempio, il gruppo upstream ha eseguito l'upgrade da 1.23 a 1.24 e i cluster del gruppo downstream sono la versione 1.25), puoi eseguire manualmente l'upgrade dei cluster nel gruppo upstream a 1.25 per garantire che gli upgrade procedono.

Tra i gruppi, se si verifica una mancata corrispondenza nelle destinazioni di upgrade in cui il gruppo downstream è su una versione precedente (ad esempio, il gruppo upstream da 1.24 a 1.25 e i cluster del gruppo downstream sono sulla versione 1.23), puoi eseguire manualmente l'upgrade dei cluster nel gruppo downstream a 1.24 o 1.25 per garantire che gli upgrade proseguano.

Prosegui con implementazioni parzialmente idonee

Se gli upgrade dei cluster in un gruppo non vengono completati a causa di problemi di idoneità all'implementazione (ad esempio discrepanze tra le versioni all'interno di un gruppo), puoi rimuovere da un gruppo i cluster non idonei per il target dell'upgrade del gruppo per completare l'implementazione della versione e iniziare il periodo di attesa oppure passare al gruppo successivo nella sequenza di implementazione. Puoi anche rimuovere un cluster da un gruppo 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 dell'implementazione della versione di un gruppo, l'implementazione della versione del gruppo verrà completata. Segui le istruzioni per controllare lo stato di un'implementazione della versione.

Passaggi successivi