Sequenza dell'implementazione degli upgrade dei cluster

Questa pagina mostra come gestire gli upgrade dei cluster GKE utilizzando la sequenza di implementazione. Per saperne di più, vedi 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à, install e poi inizializzare con 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 team ambiti. Questo documento utilizza il termine gruppo per fare riferimento 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 i test di sospensione richiesto una volta completati gli upgrade del cluster in un gruppo (massimo 30 giorni). Puoi che includono 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. Dopo averli organizzati in gruppi, puoi creare una sequenza di implementazione definendo le relazioni con i gruppi upstream e il tempo di sospensione di ciascun gruppo. A monte in una sequenza di implementazione, si riferisce al gruppo precedente, mentre a valle si intende gruppo successivo.

Organizza i tuoi 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 sequenze di implementazione tra gli ambiti dei team di un team (anteprima).

Come hai visto in Informazioni sugli upgrade dei cluster con sequenza di implementazione, gli ambiti dei team sono una struttura 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:

  • Sequenze basate su team richiedono 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.

  • Per creare una sequenza di implementazione, ogni ambito del team deve trovarsi in un parco risorse diverso. 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 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 sul parco risorse, devi prima raggruppare i cluster in flotte. Puoi organizzare i tuoi cluster per ambienti di deployment come Test, gestione temporanea e produzione, come mostrato nell'esempio di implementazione basata sul parco risorse sequenza.

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 negli ambiti dei 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 per creare l'ambito del team per questo cluster. Se vuoi registrare un cluster in una 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 il rispettivo parco risorse. Un'implementazione può includere fino a tre ambiti di team sequenza.

    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, imposti 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 tempo che intercorre tra quando upgrade completati (o l'implementazione ha richiesto 30 giorni) e quando è possibile iniziano sul gruppo downstream. Per saperne di più, vedi Come funziona l'idoneità della versione in una sequenza di implementazione.

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

Parco risorse - gcloud

Le seguenti istruzioni utilizzano il comando gcloud container fleet clusterupgrade update, come puoi imposta le stesse proprietà con il parametro gcloud container fleet clusterupgrade create .

Crea una sequenza di implementazione:

  1. Imposta il tempo di sospensione 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 progetto del progetto host del parco risorse.

  2. Imposta il parco risorse upstream e il tempo di sospensione per il secondo parco risorse nel 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 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 THIRD_FLEET_PROJECT_ID con l'ID progetto di progetto host del parco risorse.

Parco risorse - Terraform

Questa sezione mostra come creare una sequenza basata su un parco risorse utilizzando con Terraform. Puoi utilizzare questa risorsa anche 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 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 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 risorse THIRD_FLEET_PROJECT_ID con l'ID progetto del progetto host del parco risorse.

Team - gcloud

Puoi impostare queste proprietà quando crei o aggiorni un ambito del 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 ognuno di questi comandi, sostituisci le variabili con il valore o l'ID progetto host del parco risorse dell'ambito 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

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

Per eseguire questi comandi, assicurati di avere la richiesta autorizzazioni 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 seguenti, se hai bisogno di informazioni su un solo parco risorse nell'ambito della 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 progetto del progetto host 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 del team in la sequenza di implementazione e SCOPE_PROJECT_ID con all'ID progetto di questo ambito del team.

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 è iniziato oppure è in corso per il in un cluster Kubernetes. L'upgrade non è stato avviato in 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 è terminato su tutti i cluster e il periodo di sospensione non è ancora terminato.
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 l'upgrade è terminato in 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 dei cluster con la sequenza di implementazione in diverse descritti 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 sospensione predefinito per un gruppo, utilizza i comandi della istruzioni per creare una sequenza di implementazione, omettere i flag per impostare il gruppo upstream.

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 per una nuova versione e sono pronti per l'avvio degli upgrade nel gruppo successivo, puoi impostare il tempo di sospensione su zero. Puoi utilizzarla anche se vuoi più tempo rispetto al tempo di sospensione predefinito per qualificare una versione specifica.

Poiché il tempo di sospensione è impostato per gruppo, se si desidera ignorare la sospensione per gli altri gruppi in questa sequenza, aggiornali utilizzando lo stesso comando il nome del parco risorse o dell'ambito sostituito, 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.

Parco 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

Parco 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"
    }
  }

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 eseguire l'override del tempo di sospensione utilizzato per l'implementazione della versione completamente gestita.

Modifica il tempo di sospensione dell'ambito di un 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 un nuovo ai propri cluster, puoi aggiungere esclusione di manutenzione a qualsiasi cluster per cui non è stato eseguito l'upgrade alla versione di destinazione. Questo può mettere in pausa un gruppo dal procedere al tempo di sospensione o al gruppo downstream per un massimo di 30 giorni. Dopo 30 giorni, il gruppo inizierà a essere sospeso.

Puoi anche impostare il tempo di sospensione di 30 giorni per il gruppo per massimizzare il tempo di attesa della sequenza di implementazione prima di procedere con la successiva gruppo.

Se devi ritardare ulteriormente gli upgrade per il gruppo successivo, puoi utilizzare per i cluster nel gruppo successivo.

Passa da sequenze di implementazione basate sul parco risorse a quelle basate sui team

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 vengono trasferiti tra sequenze organizzate come quelle illustrate nel esempio diagrammi.

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. Configura 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 nell'host del parco risorse dei progetti.
  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 le gli ambiti dei team corrispondenti in ogni parco risorse.
  5. Aggiungi i tuoi cluster al nuovo team ambiti.
  6. Rimuovere le esclusioni di manutenzione configurato per questa modifica.

Da team a parchi risorse

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

  1. Configura esclusioni di manutenzione per tutti i cluster in ciascuno dei tuoi parchi risorse per impedire upgrade mentre modifichi la 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 a cui hai partecipato in una sequenza di implementazione nel passaggio precedente.
  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 la seconda (se la sequenza di implementazione ha tre gruppi).

Per i parchi risorse

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

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

Per team

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

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

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

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. Automatica impossibile procedere se un gruppo upstream non soddisfa 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 viene 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 un Stato di 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é 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, in caso di mancata corrispondenza nei target dell'upgrade in caso di mancata corrispondenza Il gruppo utilizza una versione più recente (ad esempio, l'upgrade del gruppo upstream dalla versione 1.23 alla 1.24 e i cluster nel gruppo downstream sono sulla 1.25), puoi aggiorna i cluster del gruppo upstream alla versione 1.25 per garantire che procedere.

Tra i gruppi, in caso di mancata corrispondenza nei target dell'upgrade in caso di mancata corrispondenza sia su una versione precedente (ad esempio, è stato eseguito l'upgrade del gruppo upstream da dalla versione 1.24 alla versione 1.25 e i cluster nel gruppo downstream sono nella versione 1.23), puoi eseguire manualmente l'upgrade dei cluster del gruppo downstream a 1.24 o 1.25 per garantire che gli upgrade vengano eseguiti.

Avanza implementazioni parzialmente idonee

Se gli upgrade dei cluster in un gruppo non vengono completati a causa di problemi con l'implementazione idoneità (ad esempio, discrepanze di versione all'interno di un gruppo), puoi rimuovere i cluster che non sono idonei per il target dell'upgrade del gruppo da un gruppo al fine di completare dell'implementazione della versione e iniziare il tempo di sospensione o passare al gruppo successivo 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, nel gruppo.

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

Dopo aver rimosso tutti i cluster che impediscono la versione di un gruppo l'implementazione della versione del gruppo sarà completata. Conferma questo seguendo le istruzioni per controllare lo stato di un'implementazione della versione.

Passaggi successivi