Regole per l'upgrade della versione

Comprendere in che modo la versione attuale e quella di destinazione influiscono sull'upgrade del cluster ti aiuta a verificare il disallineamento delle versioni, l'ordine di upgrade e i requisiti del sistema operativo prima di iniziare.

Informazioni sull'upgrade specifiche per la versione

La tabella seguente descrive le informazioni sull'upgrade specifiche per la versione. Dopo la tabella, puoi trovare i dettagli su release specifiche. Le versioni sono ordinate dalla più recente alla meno recente. Trova la versione a cui stai eseguendo l'upgrade per i dettagli e le regole specifici che si applicano al tuo cluster.

Versione Esegui prima l'upgrade Versioni del control plane (CP) Versioni del pool di nodi worker Stato del cluster avanzato Funzionalità legacy supportate? Immagini sistema operativo predefinite e obbligatorie Comportamento dell'upgrade dei nodi Kubeception cert-manager in bundle
1.36 Cluster di amministrazione 1,36, 1,35, 1,34 1,36, 1,35, 1,34 Obbligatorio Nessuno ubuntu_cgv2, cos_cgv2 Non supportato In bundle
1.35 Cluster di amministrazione 1.35, 1.34, 1.33 1.35, 1.34, 1.33 Obbligatorio Nessuno ubuntu_cgv2, cos_cgv2 obbligatorio (cgroup v1 rimosso) Non supportato In bundle
1.34 Cluster di amministrazione 1.34, 1.33, 1.32 1.34, 1.33, 1.32 Obbligatoria (nessuna disattivazione; conversione automatica non avanzata) Nessuno ubuntu_cgv2 (predefinito), cos_cgv2, ubuntu_containerd, cos Non supportato In bundle
1.33 Cluster di amministrazione 1.33, 1.32, 1.31 1.33, 1.32, 1.31 Predefinita (conversione automatica) (disattivazione solo per le versioni da 1.32 a 1.33) Nessuno ubuntu_cgv2 (predefinito), cos_cgv2, ubuntu_containerd, cos Non supportato In bundle per i cluster avanzati
1.32 Cluster di amministrazione 1.32, 1.31, 1.30 1.32, 1.31, 1.30 GA (upgrade supportati; upgrade dei nodi separati e ignorati supportati) Nessuno ubuntu_cgv2 (predefinito), cos_cgv2, ubuntu_containerd, cos Non supportato (è necessario eseguire la migrazione a Controlplane V2) In bundle per i cluster avanzati
1.31 Cluster di amministrazione 1.31, 1.30, 1.29 1.31, 1.30, 1.29 Anteprima (nessun upgrade alla versione 1.32; nessun upgrade dei nodi separato o saltato) Sì (Seesaw, F5, Kubeception, non-HA); la migrazione alle funzionalità consigliate è vivamente consigliata; Dataplane V2 obbligatorio ubuntu_cgv2 (predefinito), cos_cgv2, ubuntu_containerd, cos Upgrade dei nodi di amministrazione eseguito con l'amministratore; upgrade dei nodi del piano di controllo utente eseguito con il cluster utente Non in bundle
1.30 Cluster utente 1,30 1.30, 1.29, 1.28 Non disponibile Sì (Seesaw, F5, Kubeception, non-HA); la migrazione alle funzionalità consigliate è vivamente consigliata ubuntu_cgv2 (predefinito), cos_cgv2, ubuntu_containerd, cos Upgrade dei nodi CP e di amministrazione eseguito durante l'upgrade del cluster di amministrazione Non in bundle
1.29 Cluster utente 1.29, 1.30 1.29, 1.28, 1.16 Non disponibile Sì (Seesaw, F5, Kubeception, non-HA) ubuntu_cgv2 (predefinito), cos_cgv2, ubuntu_containerd, cos Upgrade dei nodi CP e di amministrazione eseguito durante l'upgrade del cluster di amministrazione Non in bundle
1.28 Cluster utente 1.28, 1.29, 1.30 1.28, 1.16, 1.15 Non disponibile Sì (Seesaw, F5, Kubeception, non-HA) ubuntu_containerd (predefinito), cos, ubuntu_cgv2, cos_cgv2 Upgrade dei nodi CP e di amministrazione eseguito durante l'upgrade del cluster di amministrazione Non in bundle

Per tutte le versioni, devi eseguire l'upgrade delle versioni dei pool di nodi del bilanciatore del carico (pool di nodi con enableLoadBalancer: true) contemporaneamente e alla stessa versione del control plane del cluster utente.

Informazioni sull'upgrade per versione di release

Trova la sezione relativa alla versione a cui vuoi eseguire l'upgrade per informazioni specifiche necessarie per l'upgrade a quella versione.

Release 1.36

Esegui prima l'upgrade: cluster di amministrazione

Regole di disallineamento delle versioni:

  • Il cluster di amministrazione alla versione 1.36 può gestire i cluster utente alle versioni 1.36, 1.35 e 1.34.
  • Versioni del control plane del cluster utente: 1.36, 1.35 o 1.34.
  • Versioni del pool di nodi worker: 1.36, 1.35 o 1.34.

Stato del cluster avanzato: i cluster avanzati sono obbligatori.

Salta gli upgrade dei nodi: supportato.

Funzionalità legacy supportate: no. Blocca l'upgrade.

Immagini sistema operativo predefinite e obbligatorie: ubuntu_cgv2, cos_cgv2. Il valore predefinito di osImageType per le nuove configurazioni è ubuntu_cgv2.

Comportamento dell'upgrade dei nodi Kubeception: non supportato. Blocca l'upgrade.

Strumenti di upgrade:

  • gkectl: obbligatorio per i cluster di amministrazione. Le versioni supportate sono 1.36, 1.37 e 1.38.
  • Terraform: supportato se hai creato il cluster utente utilizzando Terraform.
  • Google Cloud console: supportato per gli upgrade dei cluster utente.
  • Google Cloud CLI: supportato per gli upgrade dei cluster utente.

Requisiti aggiuntivi:

  • Puoi eseguire gli upgrade del cluster di amministrazione in modo asincrono con gkectl upgrade admin --async.

Release 1.35

Esegui prima l'upgrade: cluster di amministrazione

Regole di disallineamento delle versioni:

  • Il cluster di amministrazione alla versione 1.35 può gestire i cluster utente alle versioni 1.35, 1.34 e 1.33.
  • Versioni del control plane del cluster utente: 1.35, 1.34 o 1.33.
  • Versioni del pool di nodi worker: 1.35, 1.34 o 1.33.

Stato del cluster avanzato: i cluster avanzati sono obbligatori.

Salta gli upgrade dei nodi: supportato.

Funzionalità legacy supportate: no. Blocca l'upgrade.

Immagini sistema operativo predefinite e obbligatorie: ubuntu_cgv2, cos_cgv2 obbligatorie (cgroup v1 eliminato). Il valore predefinito di osImageType per le nuove configurazioni è ubuntu_cgv2. Devi eseguire la migrazione dei cluster a cgroup v2 prima di eseguire l'upgrade.

Comportamento dell'upgrade dei nodi Kubeception: non supportato. Blocca l'upgrade.

Strumenti di upgrade:

  • gkectl: obbligatorio per i cluster di amministrazione. Le versioni supportate sono 1.35, 1.36 e 1.37.
  • Terraform: supportato se hai creato il cluster utente utilizzando Terraform.
  • console: supportato per gli upgrade dei cluster utente.
  • gcloud CLI: supportata per gli upgrade dei cluster utente.

Requisiti aggiuntivi:

  • Puoi eseguire gli upgrade del cluster di amministrazione in modo asincrono con gkectl upgrade admin --async.

Release 1.34

Esegui prima l'upgrade: cluster di amministrazione

Regole di disallineamento delle versioni:

  • Il cluster di amministrazione alla versione 1.34 può gestire i cluster utente alle versioni 1.34, 1.33 e 1.32.
  • Versioni del control plane del cluster utente: 1.34, 1.33 o 1.32.

  • Versioni del pool di nodi worker: 1.34, 1.33 o 1.32.

Stato del cluster avanzato: i cluster avanzati sono obbligatori.

Salta gli upgrade dei nodi: supportato.

Funzionalità legacy supportate: no. Blocca l'upgrade.

Immagini sistema operativo predefinite e obbligatorie: ubuntu_cgv2, cos_cgv2, ubuntu_containerd, cos. Il valore predefinito di osImageType è ubuntu_cgv2.

Comportamento dell'upgrade dei nodi Kubeception: non supportato. Blocca l'upgrade.

Strumenti di upgrade:

  • gkectl: obbligatorio per i cluster di amministrazione. Obbligatorio per convertire i cluster non avanzati in cluster avanzati (obbligatorio nella versione 1.34; la versione binaria gkectl deve corrispondere esattamente alla versione di release di destinazione). Le versioni supportate sono 1.34, 1.35 e 1.36.
  • Terraform: supportato se hai creato il cluster utente utilizzando Terraform.
  • console: supportato per gli upgrade avanzati dei cluster utente.
  • gcloud CLI: supportata per gli upgrade avanzati dei cluster utente.

Requisiti aggiuntivi:

Per gli upgrade alla versione 1.34 si applicano i seguenti requisiti aggiuntivi:

  • I cluster non avanzati vengono convertiti automaticamente in cluster avanzati quando esegui l'upgrade alla versione 1.34. Per informazioni sulle regole specifiche per gli upgrade da cluster non avanzati a cluster avanzati, consulta Aggiorna o esegui l'upgrade di un cluster a un cluster avanzato.

  • cert-manager in bundle è obbligatorio e aggiornato alla versione 1.19, eseguendo l'override delle installazioni cert-manager personalizzate preesistenti. Per saperne di più sugli upgrade a cert-manager in bundle, consulta Utilizza cert-manager in bundle.

  • Upgrade del runtime del container del nodo a containerd 2.0. Ciò può avere i seguenti impatti:

    • containerd 2.0 non supporta le immagini Docker Image Manifest v2 o Schema 1 legacy. Assicurati che i workload eseguano il pull delle immagini container utilizzando Docker Schema 2 o un formato conforme a OCI prima di eseguire l'upgrade alla versione 1.34.
    • La configurazione del mirror del registry viene migrata al formato hosts.toml in containerd 2.0. Se gestisci configurazioni di mirror personalizzate o endpoint di registry air-gapped direttamente sui tuoi nodi, verifica che la configurazione sia allineata a hosts.toml.
    • Se utilizzi DaemonSet o script personalizzati che applicano patch a /etc/containerd/config.toml, assicurati che non utilizzino opzioni di configurazione containerd v1 deprecate, che possono causare errori di avvio di containerd con containerd 2.0.

  • Il valore predefinito del campo nodePoolUpdatePolicy.maximumConcurrentNodePoolUpdate è stato modificato nella versione 1.34.300. Se vuoi eseguire upgrade sequenziali dei pool di nodi nelle versioni 1.34.300 e successive, imposta nodePoolUpdatePolicy.maximumConcurrentNodePoolUpdate: 1 nel file di configurazione del cluster utente:

    • Per le versioni 1.34.0-1.34.200, nodePoolUpdatePolicy.maximumConcurrentNodePoolUpdate viene impostato su 1, che aggiorna un pool di nodi alla volta in sequenza.
    • Per le versioni 1.34.300 e successive, nodePoolUpdatePolicy.maximumConcurrentNodePoolUpdate viene impostato su 0 per impostazione predefinita, che aggiorna tutti i node pool contemporaneamente.

    Per saperne di più, consulta Configura la policy di aggiornamento pool di nodi pool.

  • I controlli preflight dell'upgrade convalidano attivamente tutte le configurazioni PodDisruptionBudget (PDB) nel cluster. Prima di eseguire l'upgrade, verifica che i tuoi workload non abbiano PDB eccessivamente restrittivi (ad esempio, maxUnavailable: 0 o minAvailable corrispondenti alle repliche totali) che bloccano lo svuotamento dei nodi o che i controlli preflight non possano avere esito negativo.

  • Se un upgrade viene interrotto, esegui l'upgrade direttamente alla versione 1.34.300-gke.59 o successiva. Questa versione impedisce l'eliminazione del cluster di bootstrap se devi eseguire nuovamente gkectl upgrade admin dopo un errore. Per saperne di più, consulta La riesecuzione di gkectl upgrade admin elimina il cluster di bootstrap.

  • Puoi eseguire gli upgrade dei cluster di amministrazione in modo asincrono con gkectl upgrade admin --async per i cluster avanzati, tranne quando esegui la conversione da un cluster non avanzato a un cluster avanzato.

Release 1.33

Esegui prima l'upgrade: cluster di amministrazione

Regole di disallineamento delle versioni:

  • Il cluster di amministrazione alla versione 1.33 può gestire i cluster utente alle versioni 1.33, 1.32 e 1.31.
  • Versioni del control plane del cluster utente: 1.33, 1.32 o 1.31.

  • Versioni del pool di nodi worker: 1.33, 1.32 o 1.31.

Stato dei cluster avanzati: i cluster avanzati sono il tipo di cluster predefinito e vengono convertiti automaticamente. Disattivazione consentita. Per saperne di più, consulta Esegui l'upgrade e la manutenzione dei cluster non avanzati. Se imposti enableAdvancedCluster su false, la creazione del nuovo cluster non va a buon fine.

Salta gli upgrade dei nodi: supportato.

Funzionalità legacy supportate: no. Blocca l'upgrade.

Immagini sistema operativo predefinite e obbligatorie: ubuntu_cgv2, cos_cgv2, ubuntu_containerd, cos. Il valore predefinito di osImageType è ubuntu_cgv2.

Comportamento dell'upgrade dei nodi Kubeception: non supportato. Blocca l'upgrade.

Strumenti di upgrade:

  • gkectl: obbligatorio per convertire i cluster non avanzati in cluster avanzati (la versione binaria di gkectl deve corrispondere esattamente alla versione di release di destinazione). Obbligatorio per i cluster di amministrazione. Le versioni supportate sono 1.33, 1.34 e 1.35.
  • Terraform: supportato se hai creato il cluster utente utilizzando Terraform.
  • console: supportato per gli upgrade avanzati dei cluster utente.
  • gcloud CLI: supportata per gli upgrade avanzati dei cluster utente.

Requisiti aggiuntivi:

Per gli upgrade alla versione 1.33 si applicano i seguenti requisiti aggiuntivi:

  • Gli upgrade dalla versione 1.32 alla 1.33 convertono automaticamente i cluster non avanzati in cluster avanzati per impostazione predefinita. Puoi mantenere i cluster non avanzati. Per saperne di più su come mantenere i cluster non avanzati, consulta Esegui l'upgrade e la manutenzione dei cluster non avanzati.

  • I cluster avanzati installano e raggruppano automaticamente cert-manager v1.18, eseguendo l'override delle installazioni cert-manager personalizzate preesistenti. Per saperne di più sugli upgrade a cert-manager in bundle, consulta Utilizza cert-manager in bundle.

  • Se esegui l'upgrade ai cluster avanzati in questa release, la versione binaria di gkectl deve corrispondere esattamente alla versione di release di destinazione quando esegui la conversione da cluster non avanzati a cluster avanzati. Questo requisito si applica solo durante l'upgrade a un cluster avanzato. Per tutti gli altri upgrade del cluster avanzato, si applicano le regole di disallineamento delle versioni standard.

  • Se un upgrade viene interrotto, esegui l'upgrade direttamente alla versione 1.33.700-gke.71 o successiva. Questa versione impedisce l'eliminazione del cluster di bootstrap se devi eseguire nuovamente gkectl upgrade admin dopo un errore.

  • Puoi eseguire gli upgrade dei cluster di amministrazione in modo asincrono con gkectl upgrade admin --async per i cluster avanzati e i cluster ad alta disponibilità non avanzati se tutti i cluster utente eseguono Controlplane V2. Non puoi utilizzare il flag --async quando esegui la conversione da un cluster non avanzato a un cluster avanzato.

Release 1.32

Esegui prima l'upgrade: cluster di amministrazione

Regole di disallineamento delle versioni:

  • Il cluster di amministrazione alla versione 1.32 può gestire i cluster utente alle versioni 1.32, 1.31 e 1.30.
  • Versioni del control plane del cluster utente: 1.32, 1.31 o 1.30.

  • Versioni del pool di nodi worker: 1.32, 1.31 o 1.30.

Stato del cluster avanzato: supportato.

Salta gli upgrade dei nodi: supportato.

Funzionalità legacy supportate: no. Blocca l'upgrade.

Immagini sistema operativo predefinite e obbligatorie: ubuntu_cgv2, cos_cgv2, ubuntu_containerd, cos. Il valore predefinito di osImageType è ubuntu_cgv2.

Comportamento dell'upgrade dei nodi Kubeception: non supportato. Blocca l'upgrade. Devi eseguire la migrazione a Controlplane V2.

Strumenti di upgrade:

  • gkectl: obbligatorio per convertire i cluster non avanzati in cluster avanzati (la versione binaria di gkectl deve corrispondere esattamente alla versione di release di destinazione). Obbligatorio per i cluster di amministrazione. Le versioni supportate sono 1.32, 1.33 e 1.34.
  • Terraform: supportato se hai creato il cluster utente utilizzando Terraform.
  • console: supportato per gli upgrade avanzati dei cluster utente.
  • gcloud CLI: supportata per gli upgrade avanzati dei cluster utente.

Requisiti aggiuntivi:

Per gli upgrade alla versione 1.32 si applicano i seguenti requisiti aggiuntivi:

  • Questa è la prima versione che consente un upgrade facoltativo a un cluster avanzato GA completamente supportato. Puoi scegliere di:

    • Esegui l'upgrade a un cluster non avanzato e mantieni il cluster non avanzato. Se scegli questa opzione, a partire da questa release puoi:

      • Esegui l'upgrade del control plane del cluster utente e dei pool di nodi worker separatamente. I pool di nodi worker possono essere precedenti di un massimo di due versioni secondarie rispetto al control plane.
      • Esegui l'upgrade in modo asincrono per i cluster di amministrazione e utente.

    • Esegui l'upgrade a un cluster non avanzato, quindi converti il cluster non avanzato in un cluster avanzato. Se scegli questa opzione, a partire da questa release puoi:

      • Esegui l'upgrade del control plane del cluster utente e dei pool di nodi worker separatamente quando esegui l'upgrade del cluster non avanzato, ma non quando esegui la conversione in un cluster avanzato. I pool di nodi worker possono essere precedenti al control plane di un massimo di 2 versioni secondarie.
      • Esegui l'upgrade in modo asincrono per i cluster di amministrazione e utente quando esegui l'upgrade del cluster non avanzato.
      • Quando esegui la conversione al cluster avanzato, esegui l'upgrade alla versione di release 1.32.1000-gke.57 o successiva, perché incorpora una correzione a un problema noto che impedisce l'eliminazione del cluster di bootstrap.

    • Esegui l'upgrade direttamente a un cluster Advanced. Se scegli questa opzione, a partire da questa release si applica quanto segue:

      • Devi eseguire l'upgrade del control plane e di tutti i node pool contemporaneamente.
      • Puoi eseguire l'upgrade in modo asincrono per i cluster utente, ma non per i cluster di amministrazione.
      • Esegui l'upgrade alla versione di release 1.32.1000-gke.57 o successiva perché incorpora una correzione a un problema noto che impedisce l'eliminazione del cluster di bootstrap.

  • Le seguenti funzionalità legacy non sono supportate a partire da questa versione. Per saperne di più, consulta Funzionalità legacy:

    • Dataplane V1 (Calico). Esegui l'upgrade a Dataplane V2 prima di eseguire l'upgrade alla versione 1.32.
    • Altalena. Esegui l'upgrade a un bilanciatore del carico alternativo prima di eseguire l'upgrade alla versione 1.32.
    • BIG-IP di F5 integrato. Esegui l'upgrade a un bilanciatore del carico alternativo prima di eseguire l'upgrade alla versione 1.32.
    • Kubeception. Esegui l'upgrade a un cluster non Kubeception prima di eseguire l'upgrade alla versione 1.32.
    • Cluster di amministrazione non ad alta disponibilità. Esegui l'upgrade a un cluster di amministrazione ad alta affidabilità prima di eseguire l'upgrade alla versione 1.32.

  • La versione binaria di gkectl deve corrispondere esattamente alla versione di release di destinazione quando esegui la conversione da cluster non avanzati a cluster avanzati. Questo requisito si applica solo durante l'upgrade a un cluster avanzato. Per tutti gli altri upgrade del cluster avanzato, si applicano le regole di disallineamento delle versioni standard.

  • Se un upgrade viene interrotto, esegui l'upgrade direttamente alla versione 1.32.1000-gke.57 o successiva. Questa versione impedisce l'eliminazione del cluster di bootstrap se devi eseguire nuovamente gkectl upgrade admin dopo un errore.

  • Nella versione 1.32 e successive, puoi eseguire gli upgrade dei cluster di amministrazione in modo asincrono con gkectl upgrade admin --async per i cluster avanzati e i cluster ad alta disponibilità non avanzati se tutti i cluster utente eseguono Controlplane V2. Non puoi utilizzare il flag --async quando esegui la conversione da un cluster non avanzato a un cluster avanzato.

Release 1.31

Esegui prima l'upgrade: cluster di amministrazione

Regole di disallineamento delle versioni:

  • Il cluster di amministrazione alla versione 1.31 può gestire i cluster utente alle versioni 1.31, 1.30 e 1.29.
  • Versioni del control plane del cluster utente: 1.31, 1.30 o 1.29.
  • Versioni del pool di nodi worker: 1.31, 1.30 o 1.29. (Non supportato sui cluster avanzati 1.31).
  • Per eseguire l'upgrade dalla versione 1.29/1.30 alla versione 1.31, devi eseguire l'upgrade di tutti i cluster alla versione 1.30 prima di eseguire l'upgrade del cluster di amministrazione alla versione 1.31.

Stato del cluster avanzato: solo anteprima. Impossibile eseguire l'upgrade a versioni successive.

Salta gli upgrade dei nodi: supportato.

Funzionalità legacy supportate: Dataplane V2 obbligatorio; Kubeception, Seesaw e F5 ancora supportati.

Immagini sistema operativo predefinite e obbligatorie: ubuntu_cgv2, cos_cgv2, ubuntu_containerd, cos. Il valore predefinito di osImageType è ubuntu_cgv2.

Comportamento dell'upgrade dei nodi Kubeception: i nodi di amministrazione vengono aggiornati con il cluster di amministrazione; i nodi del control plane utente vengono aggiornati con il cluster utente.

Strumenti di upgrade:

  • gkectl: obbligatorio per i cluster di amministrazione, i cluster non avanzati e i cluster avanzati (anteprima, per questa release). Le versioni supportate sono 1.31, 1.32 e 1.33.
  • Terraform: supportato per i cluster utente registrati se hai creato il cluster utente utilizzando Terraform.
  • console: supportato per gli upgrade dei cluster utente registrati.
  • gcloud CLI: supportata per gli upgrade dei cluster utente registrati.

Requisiti aggiuntivi:

Per gli upgrade alla versione 1.31 si applicano i seguenti requisiti aggiuntivi:

  • Questa release ha introdotto i cluster avanzati in modalità di anteprima. In questa release non puoi eseguire la migrazione di cluster non avanzati a cluster avanzati. Puoi creare nuovi cluster come cluster avanzati, ma non puoi eseguire l'upgrade di questi cluster avanzati in versione di anteprima a una versione successiva. Sconsigliamo di creare cluster avanzati in questa release. Per saperne di più sulle fasi di lancio del prodotto, come l'anteprima, consulta Fasi di lancio del prodotto.

  • Nella versione 1.31 e successive, l'architettura degli upgrade è cambiata in un modello in cui il cluster di amministrazione deve essere superiore o uguale ai cluster utente. In precedenza, i cluster utente potevano essere fino a due versioni secondarie più recenti rispetto al cluster di amministrazione.

  • Devi eseguire l'upgrade del cluster di amministrazione prima di eseguire l'upgrade dei cluster utente gestiti dal cluster di amministrazione. I cluster di amministrazione possono gestire i cluster utente con la stessa versione secondaria o con un massimo di due versioni secondarie precedenti. Ad esempio, un cluster di amministrazione con versione 1.31 può gestire cluster utente con versioni 1.31, 1.30 e 1.29.

  • Per eseguire l'upgrade dalla versione 1.29 alla 1.31, devi eseguire lo stage del bundle 1.30 come passaggio intermedio. Per eseguire l'upgrade alla versione 1.31, devi scaricare i bundle 1.30 e 1.31 sulla workstation di amministrazione. Per eseguire un upgrade con salto di versione da 1.29 a 1.31, segui questi passaggi:

    1. Esegui l'upgrade solo del control plane del cluster utente dalla versione 1.29 alla 1.30 (lasciando i pool di nodi worker alla versione 1.29).
    2. Esegui l'upgrade del cluster di amministrazione dalla versione 1.29 alla 1.30.
    3. Esegui l'upgrade del cluster di amministrazione dalla versione 1.30 alla versione 1.31 di destinazione.
    4. Esegui l'upgrade del control plane del cluster utente e dei pool di nodi worker insieme alla versione 1.31.

  • Se utilizzi Kubeception, l'upgrade dei nodi del cluster di amministrazione viene eseguito durante l'upgrade del cluster di amministrazione, mentre l'upgrade dei nodi del control plane del cluster utente viene eseguito durante l'upgrade del cluster utente.

  • Per eseguire l'upgrade alla versione 1.31, devi abilitare Dataplane V2. Per evitare conflitti delle policy di rete e cali di traffico durante la migrazione di CNI, devi salvare ed eliminare manualmente tutti gli oggetti NetworkPolicy e ripristinarli dopo l'upgrade. Per eseguire la transizione a Dataplane V2, segui questi passaggi:

    1. Esporta e salva tutte le policy di rete personalizzate:

      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    get networkpolicy -A -o wide \
    --field-selector metadata.namespace!=kube-system
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    get networkpolicy POLICY_NAME \
    -n NAMESPACE -o yaml > policy.yaml

      Sostituisci quanto segue:

      • USER_CLUSTER_KUBECONFIG: il percorso del file kubeconfig per il cluster utente
      • POLICY_NAME: il nome dell'oggetto NetworkPolicy
      • NAMESPACE: lo spazio dei nomi dell'oggetto NetworkPolicy

    2. Elimina le policy di rete dal cluster:

      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    delete networkpolicy POLICY_NAME \
    -n NAMESPACE

    3. Imposta enableDataplaneV2: true nel file di configurazione del cluster utente ed esegui l'upgrade alla versione 1.31.

    4. Applica le policy salvate al termine dell'upgrade alla versione 1.31 in modo che Cilium le compili in modo pulito in extended Berkeley Packet Filter (eBPF):

      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    apply -f policy.yaml

  • Se hai cluster di amministrazione ad alta affidabilità e tutti i cluster utente eseguono Controlplane V2, puoi eseguire l'upgrade in modo asincrono con il comando gkectl upgrade admin --async.

  • Dataplane V2 è obbligatorio per tutti i cluster utente. Prima di eseguire l'upgrade di un cluster utente alla versione 1.31, segui i passaggi descritti in Abilita Dataplane V2.

  • Le funzionalità legacy non sono supportate nella versione 1.32 e puoi sostituirle nelle versioni 1.30 e 1.31 per evitare problemi durante l'upgrade alla versione 1.32.

Release 1.30

Esegui prima l'upgrade: cluster utente

Regole di disallineamento delle versioni:

  • Il cluster utente alla versione 1.30 può essere gestito da un cluster di amministrazione alla versione 1.30, 1.29 o 1.28.
  • Il cluster di amministrazione alla versione 1.30 può gestire solo i cluster utente alla versione 1.30. Tutti i cluster utente e il cluster di amministrazione devono raggiungere la versione 1.30 prima di poter eseguire l'upgrade del cluster di amministrazione alla versione 1.31. Inoltre, devi eseguire l'upgrade del cluster di amministrazione alla versione 1.31 prima che qualsiasi cluster utente possa eseguire l'upgrade alla versione 1.31.
  • Versioni del control plane del cluster utente: 1.30.
  • Versioni del pool di nodi worker: 1.30, 1.29 o 1.28.

Stato avanzato del cluster: non disponibile.

Salta gli upgrade dei nodi: supportato.

Funzionalità legacy supportate: supportate. La migrazione alle funzionalità consigliate è vivamente consigliata.

Immagini sistema operativo predefinite e obbligatorie: ubuntu_cgv2, cos_cgv2, ubuntu_containerd, cos. Il valore predefinito di osImageType è ubuntu_cgv2.

  • **Comportamento dell'upgrade dei nodi Kubeception:** l'upgrade dei nodi del control plane e di amministrazione viene eseguito durante l'upgrade del cluster di amministrazione

Strumenti di upgrade:

  • gkectl: obbligatorio per i cluster di amministrazione. Le versioni supportate sono 1.30, 1.31 e 1.32.
  • Terraform: supportato per i cluster utente registrati se hai creato il cluster utente utilizzando Terraform.
  • console: supportato per gli upgrade dei cluster utente registrati.
  • gcloud CLI: supportata per gli upgrade dei cluster utente registrati.

Requisiti aggiuntivi:

Per gli upgrade alla versione 1.30 si applicano i seguenti requisiti aggiuntivi:

  • Per questa versione e tutte le versioni precedenti, devi eseguire la migrazione di tutti i cluster utente prima di eseguire l'upgrade del cluster di amministrazione di gestione. Il cluster di amministrazione deve avere la stessa versione secondaria o una versione secondaria precedente rispetto a qualsiasi cluster utente gestito.

  • Se utilizzi Kubeception, durante un upgrade si verifica quanto segue:

    1. Esegui l'upgrade del cluster utente. Poiché il control plane utente si trova all'interno del cluster di amministrazione, l'esecuzione di gkectl upgrade cluster esegue l'upgrade solo dei pool di nodi worker.
    2. Esegui l'upgrade del cluster di amministrazione. L'upgrade del cluster di amministrazione esegue l'upgrade dei nodi di amministrazione e, contemporaneamente, esegue automaticamente l'upgrade di tutti i control plane dei cluster utente.

  • Se hai Controlplane V2, durante l'upgrade si verifica quanto segue:

    1. Esegui l'upgrade del cluster utente. In questo modo viene eseguito l'upgrade del control plane e dei pool di nodi worker.
    2. Esegui l'upgrade del cluster di amministrazione. In questo modo viene eseguito l'upgrade dei nodi di amministrazione.

  • Quando crei un nuovo cluster utente, devi impostare il campo enableControlplaneV2 su true, che è il valore predefinito, a partire da questa release. Se imposti il campo enableControlplaneV2 su false, gkectl rifiuta il file e non crea il cluster.

  • Se hai cluster di amministrazione ad alta affidabilità e tutti i cluster utente eseguono Controlplane V2, puoi eseguire l'upgrade in modo asincrono con il comando gkectl upgrade admin --async.

  • Le funzionalità legacy non sono supportate nella versione 1.32 e puoi sostituirle nelle versioni 1.30 e 1.31 per evitare problemi durante l'upgrade alla versione 1.32.

Release 1.29

Esegui prima l'upgrade: cluster utente

Regole di disallineamento delle versioni:

  • Un cluster utente con versione 1.29 può essere gestito da un cluster di amministrazione con versione 1.29, 1.28 o 1.16.
  • Il cluster di amministrazione alla versione 1.29 può gestire i cluster utente alle versioni 1.29 e 1.30. Un cluster di amministrazione alla versione 1.29 non può gestire i cluster utente alla versione 1.31 perché tutti i cluster devono prima raggiungere la versione 1.30 e il cluster di amministrazione deve essere aggiornato alla versione 1.31 prima che qualsiasi cluster utente possa eseguire l'upgrade alla versione 1.31.
  • Versioni del control plane del cluster utente: 1.29 o 1.30, ovvero fino a una versione secondaria successiva.
  • Versioni del pool di nodi worker: 1.29, 1.28 o 1.16.

Stato avanzato del cluster: non disponibile.

Salta gli upgrade dei nodi: supportato.

Funzionalità legacy supportate: supportate.

Immagini sistema operativo predefinite e obbligatorie: ubuntu_cgv2, cos_cgv2, ubuntu_containerd, cos. Il valore predefinito di osImageType è ubuntu_cgv2.

Comportamento dell'upgrade dei nodi Kubeception: upgrade dei nodi del control plane e dei nodi di amministrazione durante l'upgrade del cluster di amministrazione

Strumenti di upgrade:

  • gkectl: obbligatorio per i cluster di amministrazione. Le versioni supportate sono 1.29, 1.30 e 1.31.
  • Terraform: supportato per i cluster utente registrati se hai creato il cluster utente utilizzando Terraform.
  • console: supportato per gli upgrade dei cluster utente registrati.
  • gcloud CLI: supportata per gli upgrade dei cluster utente registrati.

Requisiti aggiuntivi:

Per gli upgrade alla versione 1.29 si applicano i seguenti requisiti aggiuntivi:

  • I nodi worker possono essere precedenti al control plane di un massimo di due versioni secondarie (n+2).
  • Puoi saltare una versione secondaria quando esegui l'upgrade dei pool di nodi worker. Ad esempio, puoi eseguire l'upgrade di un pool di nodi worker dalla versione 1.28 alla 1.30.
  • I controlli preflight vengono eseguiti come pod all'interno del cluster di amministrazione o di un cluster kind di bootstrap temporaneo, anziché sulla workstation di amministrazione.
  • A partire da questa versione, puoi eseguire un controllo preflight senza eseguire l'upgrade del cluster utilizzando gkectl upgrade cluster --dry-run.
  • Se hai cluster di amministrazione ad alta affidabilità e tutti i cluster utente eseguono Controlplane V2, puoi eseguire l'upgrade in modo asincrono con il comando gkectl upgrade admin --async.

Release 1.28

Esegui prima l'upgrade: cluster utente

Regole di disallineamento delle versioni:

  • Il cluster utente alla versione 1.28 può essere gestito da un cluster di amministrazione alla versione 1.28, 1.16 o 1.15.
  • Il cluster di amministrazione alla versione 1.28 può gestire i cluster utente alle versioni 1.28, 1.29 e 1.30.
  • Versioni del control plane del cluster utente: 1.28, 1.29 o 1.30, ovvero fino a due versioni secondarie successive.
  • Versioni del pool di nodi worker: 1.28, 1.16 o 1.15, ovvero fino a 2 versioni secondarie precedenti.

Stato avanzato del cluster: non disponibile.

Salta gli upgrade dei nodi: supportato.

Funzionalità legacy supportate: supportate.

Immagini sistema operativo predefinite e obbligatorie: ubuntu_containerd, cos, ubuntu_cgv2, cos_cgv2. Il valore predefinito di osImageType è ubuntu_containerd.

Comportamento dell'upgrade dei nodi Kubeception: upgrade dei nodi del control plane e dei nodi di amministrazione durante l'upgrade del cluster di amministrazione

Strumenti di upgrade:

  • gkectl: obbligatorio per i cluster di amministrazione. Le versioni supportate sono 1.28, 1.29 e 1.30.
  • Terraform: supportato per i cluster utente registrati se hai creato il cluster utente utilizzando Terraform.
  • console: supportato per gli upgrade dei cluster utente registrati.
  • gcloud CLI: supportata per gli upgrade dei cluster utente registrati.

Requisiti aggiuntivi:

Per gli upgrade alla versione 1.28 si applicano i seguenti requisiti aggiuntivi:

  • Devi attivare kubernetesmetadata.googleapis.com e concedere roles/kubernetesmetadata.publisher al service account di logging-monitoring. In caso contrario, i controlli preflight potrebbero non riuscire o potresti visualizzare errori 403 PERMISSION_DENIED. Abilita l'API e concedi il ruolo al account di servizio di logging-monitoring esistente:

    gcloud services enable kubernetesmetadata.googleapis.com
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:LOGGING_SA" \
    --role="roles/kubernetesmetadata.publisher"

    Sostituisci quanto segue:

    • PROJECT_ID: l'ID del progetto host del parco risorse di cui il cluster utente è membro.
    • LOGGING_SA: l'indirizzo email del tuo account di servizio di logging-monitoring.

  • Sebbene sia tecnicamente possibile saltare le versioni durante l'upgrade di un pool di nodi, questa funzionalità è stata introdotta come funzionalità in anteprima e non è consigliata per questa versione. Per saperne di più sulle fasi di lancio del prodotto, come l'anteprima, consulta Fasi di lancio del prodotto.

  • I node pool con un bilanciatore del carico integrato devono corrispondere esattamente alla versione del cluster.

  • Puoi eseguire l'upgrade di più nodi contemporaneamente impostando il campo nodePools[i].updateStrategy.rollingUpdate.maxSurge. Il cluster vSphere deve disporre di CPU, RAM e indirizzi IP disponibili sufficienti per ospitare le VM aggiuntive durante l'upgrade:

    • Imposta maxSurge: 1 (valore predefinito) per eseguire l'upgrade di un nodo alla volta (svuota, sostituisci, verifica, quindi ripeti).
    • Imposta maxSurge: N (dove N > 1) per eseguire il provisioning e lo svuotamento di un massimo di N nodi worker contemporaneamente (ad esempio, maxSurge: 3 esegue l'upgrade di 3 nodi worker contemporaneamente).

  • Per eseguire l'upgrade della workstation di amministrazione, devi avere almeno 100 GB di spazio libero su disco.

  • La versione di gkectl che utilizzi per l'upgrade può essere superiore di un massimo di due versioni secondarie rispetto al cluster attuale. Non puoi utilizzare una versione secondaria precedente.

Release precedenti alla 1.28

Per gli upgrade alle release precedenti alla versione 1.28 si applicano i seguenti requisiti aggiuntivi. Non sono state rilasciate versioni tra la 1.16 e la 1.28:

Release 1.16:

  • La differenza di versione tra i cluster di amministrazione e utente e tra il control plane e i pool di nodi può essere di una sola versione secondaria. Ad esempio, un cluster di amministrazione alla versione 1.15 può gestire solo cluster utente con versioni 1.15 o 1.16. Un control plane del cluster utente di cui è stato eseguito l'upgrade alla versione 1.16 può gestire i pool di nodi worker che eseguono la versione 1.15 o 1.16. Un pool alla versione 1.14 deve essere sottoposto ad upgrade alla versione 1.15 prima che il control plane possa passare alla versione 1.16. Per saperne di più sul disallineamento delle versioni, consulta Regole per il disallineamento delle versioni.
  • I cluster vengono registrati automaticamente nell'API GKE On-Prem quando vengono creati o viene eseguito l'upgrade alla versione 1.16. Con questa modifica, puoi visualizzare, monitorare ed eseguire l'upgrade dei cluster utente utilizzando la console, gcloud CLI e Terraform anziché solo la shell della workstation di amministrazione.

Release 1.14:

  • Puoi eseguire l'upgrade solo del control plane del cluster utente, in modo da non dover svuotare ed eseguire l'upgrade di ogni pool di nodi worker contemporaneamente.
  • Durante l'upgrade, il sistema ispeziona e aggiorna automaticamente i file kubeconfig dei cluster di amministrazione e utente esistenti sulla workstation, rinnovando automaticamente le credenziali.

Release 1.13:

  • Prima di questa versione, potevi avere un cluster di amministrazione offline. Questa versione richiede la registrazione del cluster di amministrazione in Google Cloud. Per informazioni su come registrare un cluster, consulta Registra un cluster esistente.
  • Per eseguire l'upgrade di un cluster alla versione 1.13 o successive di Google Distributed Cloud software only on VMware, devi prima aggiornare tutti i node pool dei cluster utente che utilizzano ancora Docker Engine a containerd.

Utilizza cert-manager in bundle

Devi utilizzare il cert-manager in bundle, che viene installato automaticamente sui cluster avanzati. Quando esegui la migrazione da un cluster non avanzato a un cluster avanzato, cert-manager integrato sostituisce automaticamente tutte le versioni di cert-manager installate dal cliente. Assicurati di non avere configurazioni o funzionalità personalizzate critiche applicate ai tuoi cert-manager esistenti prima di eseguire l'aggiornamento o l'upgrade ai cluster avanzati.

Per verificare se hai applicato configurazioni o funzionalità personalizzate critiche al tuo cert-manager, segui questi passaggi:

  • Sospendi gli strumenti di deployment continuo. Se gestisci cert-manager utilizzando strumenti GitOps (come Config Sync, ArgoCD o Flux), sospendi la sincronizzazione o rimuovi i manifest cert-manager dal repository prima di eseguire l'upgrade. Se un controller GitOps tenta di riconciliare cert-manager con una versione precedente o un manifest personalizzato durante l'upgrade del cluster, crea un loop di riconciliazione che può bloccare l'upgrade del cluster.
  • Non disinstallare o eliminare manualmente pod, spazi dei nomi o CRD cert-manager prima di eseguire l'upgrade. gkectl gestisce questi upgrade in loco.
  • Se hai modificato i flag di deployment, i selettori di nodi o i limiti delle risorse dei pod di cert-manager, ripristinali. I cluster avanzati non supportano argomenti binari personalizzati o override a livello di deployment su cert-manager.
  • Se utilizzi emittenti esterni specializzati, plug-in webhook DNS-01 ACME privati o webhook personalizzati, verifica che i plug-in di terze parti siano compatibili con la versione cert-manager in bundle per la release di cui stai eseguendo l'upgrade.

Per saperne di più, consulta Esegui l'upgrade a cert-manager in bundle con cluster avanzati.

La tabella seguente elenca le versioni di release che richiedono cert-manager in bundle:

Versione Stato dei nuovi cluster Stato degli upgrade dei cluster esistenti cert-manager in bundle obbligatoria?
1.34+ Obbligatorio Conversione obbligatoria (v1.19 in bundle) Obbligatorio per tutti i clienti. I cluster non avanzati non possono più esistere.
1,33 Standard/Predefinito per tutti i nuovi cluster Conversione automatica in cluster avanzati per impostazione predefinita (v1.18 in bundle) Obbligatorio per quasi tutti i cluster, a meno che non venga disattivato esplicitamente con enableAdvancedCluster: false (solo dalla versione 1.32 alla 1.33).
1.32 (GA) Questa opzione è attiva per impostazione predefinita Conversione facoltativa in cluster avanzati Obbligatorio se i cluster avanzati sono abilitati.
1.31 (anteprima) Facoltativo (enableAdvancedCluster: true) Non supportata Obbligatorio se i cluster avanzati sono abilitati.

Per vedere quale versione di cert-manager è inclusa in ogni release supportata, consulta Versioni di cert-manager incluse.

Control plane V2

Quando Controlplane V2 è abilitato, il control plane del cluster utente viene eseguito sul cluster utente stesso. Per Controlplane V2, l'upgrade dei nodi del control plane del cluster utente viene eseguito durante l'upgrade del cluster utente, mentre l'upgrade dei nodi del control plane del cluster di amministrazione viene eseguito durante l'upgrade del cluster di amministrazione.

Funzionalità legacy

La tabella seguente elenca le funzionalità legacy bloccate nella versione 1.32 e successive. Se utilizzi queste funzionalità, devi eseguire la migrazione alle alternative consigliate prima di poter eseguire l'upgrade alla versione 1.32 o successive.

| Funzionalità legacy (bloccata nella versione 1.32) | Sostituisci con (consigliato) | Link alle istruzioni per la migrazione | | --- | --- | --- | | Dataplane V1 (Calico) | Dataplane V2 (Cilium/eBPF) | Esegui la migrazione a Dataplane V2| | Kubeception | Controlplane V2 | Esegui la migrazione a Controlplane V2 | | Cluster di amministrazione non ad alta affidabilità (1 replica) | Cluster di amministrazione ad alta affidabilità (3 repliche) | Esegui la migrazione al cluster di amministrazione ad alta affidabilità | | Bilanciatore del carico Seesaw | MetalLB o ManualLB | Esegui la migrazione a MetalLB o Esegui la migrazione del tipo di bilanciatore del carico| | F5 BIG-IP integrato (loadBalancer.kind: "F5BigIP") | ManualLB (accoppiato con il controller F5 Big-IP o CCGI) | Esegui la migrazione a ManualLB |

Per maggiori dettagli su come eseguire la migrazione dalle funzionalità legacy alle funzionalità consigliate, consulta Pianifica la migrazione del cluster alle funzionalità consigliate.

Comportamento della versione e della migrazione di Kubeception

Kubeception è una funzionalità legacy di cui è necessario eseguire la migrazione a Controlplane V2 prima di poter eseguire l'upgrade alla versione 1.32 o successive.

Gli upgrade si comportano in modo diverso per i cluster con Kubeception a seconda della versione:

  • Per la versione 1.28: upgrade dei nodi del control plane e di amministrazione durante l'upgrade del cluster di amministrazione
  • Per la versione 1.29: upgrade dei nodi del control plane e dei nodi di amministrazione durante l'upgrade del cluster di amministrazione

  • Per la versione 1.30: upgrade del control plane e dei nodi di amministrazione durante l'upgrade del cluster di amministrazione. Se utilizzi Kubeception, durante un upgrade si verifica quanto segue:

    1. Esegui l'upgrade del cluster utente. Poiché il control plane utente si trova all'interno del cluster di amministrazione, l'esecuzione di gkectl upgrade cluster esegue l'upgrade solo dei pool di nodi worker.
    2. Esegui l'upgrade del cluster di amministrazione. L'upgrade del cluster di amministrazione esegue l'upgrade dei nodi di amministrazione e, contemporaneamente, esegue automaticamente l'upgrade di tutti i control plane dei cluster utente.

  • Per la versione 1.31: upgrade dei nodi di amministrazione con il cluster di amministrazione; upgrade dei nodi del control plane utente con il cluster utente.

  • Per la versione 1.32 e successive: Kubeception non è supportato. Devi eseguire la migrazione a Controlplane V2 prima di poter eseguire l'upgrade alla versione 1.32 o successive.

    Per maggiori dettagli sulla migrazione di Kubeception a Controlplane V2, consulta Pianifica la migrazione dei cluster alle funzionalità consigliate.

Disallineamento delle versioni rispetto al salto di una versione durante l'upgrade

La deviazione della versione è la differenza consentita nelle versioni secondarie tra un cluster di amministrazione e i cluster utente gestiti o la differenza nelle versioni secondarie tra il control plane di un cluster utente e i node pool nel cluster utente.

La deviazione della versione è diversa dal saltare una versione secondaria durante l'upgrade.

Puoi saltare una versione secondaria solo quando esegui l'upgrade dei pool di nodi worker, dopo aver eseguito l'upgrade del control plane. Questo vale per i cluster avanzati e non avanzati, ad eccezione dei cluster avanzati che eseguono la versione 1.31 e le versioni precedenti alla 1.28. Ad esempio, se un pool di nodi worker è alla versione 1.29, aggiorna il control plane del cluster utente alla versione 1.30 e poi alla versione 1.31. Dopo che il control plane è alla versione 1.31, esegui l'upgrade del pool di nodi worker direttamente dalla versione 1.29 alla 1.31, senza eseguire l'upgrade alla versione 1.30. Per ulteriori informazioni, consulta Salta una versione durante l'upgrade dei node pool.

Per eseguire l'upgrade a una release secondaria successiva rispetto alla release secondaria sequenziale successiva, esegui prima l'upgrade alla release secondaria successiva, quindi esegui l'upgrade alla release secondaria successiva. Non puoi saltare una versione secondaria quando esegui l'upgrade dei control plane dei cluster di amministrazione e utente. Ad esempio, se vuoi eseguire l'upgrade dalla versione 1.34.x alla versione 1.36.x, non puoi eseguire l'upgrade direttamente. Devi prima eseguire l'upgrade dalla versione 1.34.x alla versione 1.35.x, quindi eseguire l'upgrade alla versione 1.36.x.

Il control plane di un cluster utente può essere fino a due versioni secondarie successive rispetto ai pool di nodi worker nel cluster. Ad esempio, se il control plane di un cluster utente è alla versione 1.36, i pool di nodi worker nel cluster possono essere alla versione 1.34, 1.35 o 1.36.

Quali disallineamenti di versione sono consentiti?

Un cluster di amministrazione può gestire cluster utente fino a 2 versioni secondarie precedenti. Ad esempio, se un cluster di amministrazione è alla versione 1.31, i cluster utente gestiti da quel cluster di amministrazione possono essere alla versione 1.29, 1.30 o 1.31.

Prima della versione 1.31, si applicano le seguenti regole di disallineamento delle versioni:

  • Per le versioni dalla 1.28 alla 1.30, i cluster utente possono essere fino a due versioni secondarie superiori rispetto al cluster di amministrazione. Ad esempio, se un cluster di amministrazione è alla versione 1.15, i cluster utente gestiti da quel cluster di amministrazione possono essere alla versione 1.15, 1.16 o 1.28. Non puoi eseguire l'upgrade di un cluster utente 1.28 alla versione 1.29 finché non viene eseguito l'upgrade del cluster di amministrazione almeno alla versione 1.16. Poiché la versione 1.31 modifica l'ordine di upgrade in modo da richiedere prima l'upgrade del cluster di amministrazione, un cluster di amministrazione alla versione 1.29 o 1.30 non può gestire i cluster utente alla versione 1.31 o 1.32. Tutti i cluster utente e il cluster di amministrazione devono raggiungere la versione 1.30 prima di poter eseguire l'upgrade del cluster di amministrazione alla versione 1.31.
  • Per le versioni 1.16 e precedenti, i cluster utente possono essere solo di una versione secondaria superiore rispetto al cluster di amministrazione. Ad esempio, se un cluster di amministrazione è alla versione 1.15, i cluster utente gestiti da quel cluster di amministrazione possono essere alla versione 1.15 o 1.16.

Devo eseguire l'upgrade dei cluster utente tutti contemporaneamente?

Quando esegui l'upgrade dei cluster utente, puoi scegliere una delle seguenti opzioni:

  • Esegui l'upgrade dell'intero cluster utente con il control plane e tutti i node pool nel cluster contemporaneamente.
  • Eseguire l'upgrade del control plane del cluster utente e lasciare i node pool alla versione attuale.
  • Esegui l'upgrade del control plane del cluster utente ed esegui l'upgrade selettivo dei node pool.

L'approccio da adottare dipende da diversi fattori, tra cui:

  • L'ambiente (di produzione o non di produzione) in cui si trova il cluster.
  • La durata del periodo di manutenzione.
  • La versione del cluster utente.

Ad esempio, potresti voler eseguire l'upgrade sia del control plane del cluster utente sia di tutti i node pool in un ambiente di sviluppo. Tuttavia, in un ambiente di produzione con un periodo di manutenzione breve, potresti voler eseguire l'upgrade solo del control plane perché richiede meno tempo e l'upgrade del control plane non dovrebbe interrompere i workload degli utenti.

I node pool del bilanciatore del carico (node pool con enableLoadBalancer: true) devono avere la stessa versione del cluster per ogni versione.

Regole per le versioni per gkectl

La versione di gkectl che puoi utilizzare per l'upgrade dipende dalla versione del cluster di destinazione (ovvero la versione del cluster di cui stai eseguendo l'upgrade). In genere, utilizzi la stessa versione di gkectl della versione di destinazione del cluster. Durante l'upgrade vengono applicate le seguenti regole:

  • La versione di gkectl deve essere uguale o superiore alla versione secondaria del cluster di destinazione. Ad esempio, se esegui l'upgrade di un cluster 1.29 alla versione 1.30, devi utilizzare gkectl 1.30 o versioni successive. Le versioni patch non sono importanti.

  • La versione gkectl può essere fino a due versioni secondarie superiore alla versione attuale del cluster. Ad esempio, per eseguire l'upgrade di un cluster 1.28 alla versione 1.29, utilizza gkectl versione 1.29 o 1.30, ma non la versione 1.31 perché è di tre versioni secondarie superiore alla versione del cluster.

La versione binaria di gkectl deve corrispondere esattamente alla versione di release di destinazione quando esegui la conversione da cluster non avanzati a cluster avanzati. Questo requisito rigoroso relativo alla versione si applica solo durante l'upgrade a un cluster avanzato. Per tutti gli altri upgrade dei cluster avanzati, si applicano le regole di disallineamento delle versioni standard.

Regole di upgrade della versione patch

Esegui l'upgrade alla versione patch più recente, se possibile, per assicurarti che i cluster dispongano delle correzioni di sicurezza più recenti. Le versioni patch non influiscono sulle regole di disallineamento e upgrade delle versioni. Per una determinata versione secondaria, puoi eseguire l'upgrade a qualsiasi versione patch successiva. Ad esempio, puoi eseguire l'upgrade da 1.35.0 a 1.35.1 e da 1.35.1 a 1.35.3.

Passaggi successivi