Cluster Anthos su VMware è ora Google Distributed Cloud (solo software) per VMware. Per ulteriori informazioni, consulta la panoramica del prodotto.

Questa pagina è stata tradotta dall'API Cloud Translation.

Eseguire l'upgrade di un cluster o di un pool di nodi

Questo documento spiega come eseguire l'upgrade di cluster e pool di nodi in Google Distributed Cloud. Questo documento illustra i passaggi per eseguire l'upgrade della workstation di amministrazione, dei cluster utente e dei cluster di amministrazione. Per i cluster utente, questo documento fornisce i passaggi per eseguire l'upgrade del piano di controllo e dei pool di nodi contemporaneamente o separatamente.

Prima di procedere, ti consigliamo di esaminare la seguente documentazione:

Panoramica dell'upgrade
Inoltre, questo documento descrive le regole supportate per il disallineamento delle versioni e le regole per gli upgrade, che sono cambiate per la versione 1.28 e successive.
Best practice per l'upgrade
Questo documento fornisce elenchi di controllo e best practice per l'upgrade dei cluster.

Rivedi le regole firewall

Dalla versione 1.29 in poi, i controlli preflight lato server sono abilitati per impostazione predefinita. I controlli preflight lato server richiedono regole firewall aggiuntive. In Regole firewall per i cluster di amministrazione, cerca "Controlli preflight" e assicurati che siano configurate tutte le regole firewall richieste.

Con i controlli preflight lato server, quando esegui l'upgrade di un cluster utente utilizzando gkectl, i controlli preflight vengono eseguiti sul cluster di amministrazione e non localmente sulla workstation di amministrazione. I controlli preflight lato server vengono eseguiti anche sul cluster di amministrazione quando utilizzi la console Google Cloud, Google Cloud CLI o Terraform per eseguire l'upgrade di un cluster.

Quando esegui l'upgrade di un cluster di amministrazione, Google Distributed Cloud esegue il deployment di un cluster Kubernetes in Docker (kind) per ospitare temporaneamente i controller Kubernetes necessari per eseguire l'upgrade del cluster di amministrazione. Questo cluster temporaneo è chiamato cluster di bootstrap. I controlli preflight lato server vengono eseguiti sul cluster di bootstrap quando esegui l'upgrade di un cluster di amministrazione.

Requisiti IAM e API di Google

Per eseguire l'upgrade di un cluster alla versione 1.28 e successive, devi abilitare kubernetesmetadata.googleapis.com e concedere il ruolo IAM kubernetesmetadata.publisher all'account di servizio logging-monitoring. Queste modifiche sono necessarie per utilizzare Cloud Monitoring.

Attiva kubernetesmetadata.googleapis.com:
```
gcloud services enable --project PROJECT_ID  \
    kubernetesmetadata.googleapis.com
```
Sostituisci PROJECT_ID con l'ID del progetto host del parco risorse di cui è membro il cluster utente. Questo è il progetto che hai specificato al momento della creazione del cluster. Se hai creato il cluster utilizzando gkectl, questo è l'ID progetto nel campo gkeConnect.projectID del file di configurazione del cluster.
Se la tua organizzazione ha configurato una lista consentita che consente al traffico proveniente dalle API di Google e da altri indirizzi di passare attraverso il tuo server proxy, aggiungi kubernetesmetadata.googleapis.com alla lista consentita.
Concedi il ruolo kubernetesmetadata.publisher all'account di servizio logging-monitoring:
```
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member "serviceAccount:SERVICE_ACCOUNT_EMAIL" \
  --role "roles/kubernetesmetadata.publisher"
```
Sostituisci SERVICE_ACCOUNT_EMAIL con l'indirizzo email del tuo account di servizio di monitoraggio dei log.

Requisiti IAM per l'upgrade dei cluster utente

Salta questa sezione se prevedi di utilizzare gkectl per l'upgrade del cluster utente.

Se vuoi utilizzare la console Google Cloud, Google Cloud CLI o Terraform per eseguire l'upgrade di un cluster utente e non sei un proprietario del progetto, devi disporre del ruolo Identity and Access Management roles/gkeonprem.admin sul progetto Google Cloud in cui è stato creato il cluster. Per maggiori dettagli sulle autorizzazioni incluse in questo ruolo, consulta Ruoli GKE On-Prem nella documentazione IAM.

Per utilizzare la console per eseguire l'upgrade del cluster, devi disporre almeno di quanto segue:

roles/container.viewer. Questo ruolo consente agli utenti di visualizzare la pagina Cluster GKE e altre risorse container nella console. Per maggiori dettagli sulle autorizzazioni incluse in questo ruolo o per concedere un ruolo con autorizzazioni di lettura/scrittura, vedi Ruoli di Kubernetes Engine nella documentazione IAM.
roles/gkehub.viewer. Questo ruolo consente agli utenti di visualizzare i cluster nella console. Per maggiori dettagli sulle autorizzazioni incluse in questo ruolo o per concedere un ruolo con autorizzazioni di lettura/scrittura, consulta Ruoli GKE Hub nella documentazione di IAM.

Apportare modifiche alla configurazione prima o dopo un upgrade

Se devi apportare modifiche alla configurazione dei cluster, esegui l'aggiornamento del cluster prima o dopo l'upgrade. L'unica modifica alla configurazione del cluster per un upgrade deve essere la versione. A seconda della versione e del tipo di cluster, altre modifiche alla configurazione vengono ignorate automaticamente o comportano l'esito negativo dell'upgrade. Per maggiori informazioni, consulta Rimuovere le modifiche non supportate per sbloccare l'upgrade.

Esegui l'upgrade della workstation di amministrazione

Devi eseguire l'upgrade della workstation di amministrazione se prevedi di utilizzare gkectl per eseguire l'upgrade di un cluster utente.

Se prevedi di utilizzare la console, gcloud CLI o Terraform per eseguire l'upgrade di un cluster utente, per il momento puoi saltare l'upgrade della workstation di amministrazione. Tuttavia, dovrai eseguire l'upgrade della workstation di amministrazione quando vorrai eseguire l'upgrade del cluster di amministrazione, perché solo gkectl supporta gli upgrade del cluster di amministrazione.

Il modo in cui esegui l'upgrade della workstation di amministrazione dipende da come l'hai creata: gkeadm o user-mmanaged.

Gkeadm

Individua i file richiesti

Prima di creare la workstation di amministrazione, hai compilato un file di configurazione della workstation di amministrazione generato da gkeadm create config. Il nome predefinito di questo file è admin-ws-config.yaml.

Inoltre, la workstation include un file di informazioni. Il nome predefinito di questo file è lo stesso del nome della workstation di amministrazione.

Individua il file di configurazione della workstation di amministrazione e il file delle informazioni. Ti servono per eseguire i passaggi dell'upgrade. Se questi file si trovano nella directory corrente e hanno i loro nomi predefiniti, non sarà necessario specificarli quando esegui i comandi di upgrade. Se questi file si trovano in un'altra directory o se hai modificato i nomi dei file, li specifichi utilizzando i flag --config e --info-file.

Se il file con le informazioni di output non è presente, puoi ricrearlo. Consulta la sezione Ricreare un file di informazioni se mancante.

Esegui l'upgrade

Per eseguire l'upgrade della workstation di amministrazione:

Scarica gkeadm:
```
gkeadm upgrade gkeadm --target-version TARGET_VERSION
```
Sostituisci TARGET_VERSION con la versione di destinazione dell'upgrade. Devi specificare un numero di versione completo nel formato X.Y.Z-gke.N.. Per un elenco delle versioni di Google Distributed Cloud, consulta Controllo delle versioni.
Esegui l'upgrade della workstation di amministrazione:
```
gkeadm upgrade admin-workstation --config AW_CONFIG_FILE \
    --info-file INFO_FILE
```
Sostituisci quanto segue:
- AW_CONFIG_FILE: il percorso del file di configurazione della workstation di amministrazione. Puoi omettere questo flag se il file si trova nella directory corrente e ha il nome admin-ws-config.yaml.
- INFO_FILE: il percorso del file delle informazioni. Puoi omettere questo flag se il file si trova nella directory attuale. Il nome predefinito di questo file è lo stesso del nome della workstation di amministrazione.

Gestita dall'utente

Sulla workstation di amministrazione, vai a una directory in cui vuoi installare una nuova versione di gkectl.

Scarica gkectl:

gsutil cp gs://gke-on-prem-release/gkectl/VERSION/gkectl ./
chmod +x gkectl

Sostituisci VERSION con la versione di destinazione dell'upgrade. Ad esempio: 1.29.100-gke.248.

Scarica il pacchetto Google Distributed Cloud. Assicurati che la versione corrisponda a quella utilizzata per scaricare gkectl:

gsutil cp gs://gke-on-prem-release/gke-onprem-bundle/VERSION/gke-onprem-vsphere-VERSION.tgz ./

Controlla le versioni disponibili per gli upgrade del cluster

Esegui questo comando per vedere quali versioni sono disponibili per l'upgrade:

gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG

L'output mostra la versione corrente e le versioni disponibili per l'upgrade.

Se prevedi di utilizzare la console, gcloud CLI o Terraform per l'upgrade, sono necessari circa 7-10 giorni dopo la release affinché la versione sia disponibile nell'API GKE On-Prem in tutte le regioni di Google Cloud. Nella console sono elencate solo le versioni disponibili per l'upgrade del cluster utente. I passaggi per eseguire l'upgrade di un cluster utente utilizzando gcloud CLI o Terraform includono un passaggio per eseguire gcloud container vmware clusters query-version-config per ottenere le versioni disponibili per l'upgrade.

Esegui l'upgrade di un cluster utente

Puoi utilizzare gkectl, la console, gcloud CLI o Terraform per eseguire l'upgrade di un cluster utente. Per informazioni su come decidere quale strumento utilizzare, consulta Scegliere uno strumento per eseguire l'upgrade dei cluster utente.

Gkectl

Prepara l'upgrade di un cluster utente

Esegui i seguenti passaggi sulla workstation di amministrazione:

Esegui gkectl prepare per importare immagini del sistema operativo in vSphere:

gkectl prepare \
  --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Se il tuo cluster ha un pool di nodi Windows, esegui gkectl prepare windows e aggiorna il campo osImage per il pool di nodi. Per istruzioni dettagliate, consulta Eseguire l'upgrade del cluster utente con i pool di nodi Windows.
Nel file di configurazione del cluster utente, imposta gkeOnPremVersion sulla versione di destinazione dell'upgrade.
Solo pool di nodi Ubuntu e COS: specifica i pool di nodi di cui vuoi eseguire l'upgrade. L'upgrade dei pool di nodi separatamente dal piano di controllo è supportato per i pool di nodi Ubuntu e COS, ma non per i pool di nodi Windows.

Nel file di configurazione del cluster utente, indica i pool di nodi di cui vuoi eseguire l'upgrade, come segue:
- Per ogni pool di nodi di cui vuoi eseguire l'upgrade, rimuovi il campo nodePools.nodePool[i].gkeOnPremVersion o impostalo sulla stringa vuota.
- Per ogni pool di nodi di cui non vuoi eseguire l'upgrade, imposta nodePools.nodePool[i].gkeOnPremVersion sulla versione attuale.
Ad esempio, supponiamo che la versione del cluster utente sia 1.15.5-gke.41 e abbia due pool di nodi: pool-1 e pool-2. Supponiamo inoltre di voler eseguire l'upgrade del piano di controllo e di pool-1 alla versione 1.16.3-gke.45, ma di voler mantenere pool-2 alla versione 1.15.5-gke.41. La parte seguente di un file di configurazione di un cluster utente mostra come specificare questo esempio:
```
gkeOnPremVersion: 1.16.3-gke.45

nodePools:
- name: pool-1
  gkeOnPremVersion: ""
  cpus: 4
  memoryMB: 8192
  replicas: 3
  osImageType: ubuntu_containerd
- name: pool-2
  gkeOnPremVersion: 1.15.5-gke.41
  cpus: 4
  memoryMB: 8192
  replicas: 5
  osImageType: ubuntu_containerd
```

Esecuzione di controlli preliminari

Quando esegui l'upgrade alla versione 1.29 e successive, puoi eseguire i controlli preflight prima di eseguire l'upgrade di un cluster utente:

gkectl upgrade cluster \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --config USER_CLUSTER_CONFIG \
  --dry-run

Con il flag --dry-run, gkectl upgrade cluster esegue i controlli preflight, ma non avvia il processo di upgrade. Anche se le versioni precedenti di Google Distributed Cloud eseguono controlli preflight, non possono essere eseguite separatamente dall'upgrade. Aggiungendo il flag --dry-run, puoi trovare e risolvere eventuali problemi rilevati dai controlli preflight nel tuo cluster utente prima dell'upgrade.

Esegui `gkectl upgrade cluster`

Esistono due varianti del comando gkectl upgrade cluster:

Asincrono: (opzione consigliata)
Con la variante asincrona, il comando avvia l'upgrade e poi viene completato. Non è necessario osservare l'output del comando per l'intera durata dell'upgrade. Puoi però controllare periodicamente l'avanzamento dell'upgrade eseguendo gkectl list clusters e gkectl describe clusters. Per utilizzare la variante asincrona, includi il flag --async nel comando.
Sincrona:
Con la variante sincrona, il comando gkectl upgrade cluster invia messaggi di stato alla workstation di amministrazione man mano che l'upgrade procede.

Upgrade asincrono

Ignora questo passaggio se esegui l'upgrade a una versione successiva alla 1.16.

Se utilizzi credenziali preparate e un registro privato per il cluster utente, assicurati che le credenziali del registro privato siano pronte prima di eseguire l'upgrade del cluster utente. Per informazioni su come preparare la credenziale del registro privata, consulta Configurare le credenziali preparate per i cluster utente.
Sulla workstation di amministrazione, avvia un upgrade asincrono:
```
gkectl upgrade cluster \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --config USER_CLUSTER_CONFIG \
  --async
```
Il comando precedente viene completato e puoi continuare a utilizzare la workstation di amministrazione mentre è in corso l'upgrade.
Per visualizzare lo stato dell'upgrade:
```
gkectl list clusters --kubeconfig ADMIN_CLUSTER_KUBECONFIG
```
L'output mostra un valore per il cluster STATE. Se è ancora in corso l'upgrade del cluster, il valore di STATE è UPGRADING. Ad esempio:
```
NAMESPACE             NAME    READY   STATE       AGE   VERSION
my-uc-gkeonprem-mgmt  my-uc   False   UPGRADING   9h    1.29.0-gke.1
```
I valori possibili per STATE sono PROVISIONING, UPGRADING, DELETING, UPDATING, RUNNING, RECONCILING, ERROR e UNKNOWN.

Per ulteriori dettagli sull'avanzamento dell'upgrade e sugli eventi del cluster:

gkectl describe clusters --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --cluster USER_CLUSTER_NAME -v 5

L'output mostra la risorsa personalizzata OnPremUserCluster per il cluster utente specificato, che include stato, condizioni ed eventi del cluster.

Registriamo gli eventi per l'inizio e la fine di ogni fase critica dell'upgrade, tra cui:

ControlPlaneUpgrade
MasterNodeUpgrade
AddonsUpgrade
NodePoolsUpgrade

Output di esempio:

Events:
Type    Reason                      Age    From                            Message
----     ------                     ----   ----                            -------
Normal  NodePoolsUpgradeStarted     22m    onprem-user-cluster-controller  Creating or updating node pools: pool-2: Creating or updating node pool
Normal  AddonsUpgradeStarted        22m    onprem-user-cluster-controller  Creating or updating addon workloads
Normal  ControlPlaneUpgradeStarted  25m    onprem-user-cluster-controller  Creating or updating cluster control plane workloads: deploying user-kube-apiserver-base, ...: 14/15 pods are ready
Normal  ControlPlaneUpgradeFinished 23m    onprem-user-cluster-controller  Control plane is running

Al termine dell'upgrade, gkectl list clusters mostra un valore STATUS di RUNNING:

NAMESPACE             NAME    READY   STATE     AGE     VERSION
my-uc-gkeonprem-mgmt  my-uc   True    RUNNING   9h      1.29.0-gke.1

Inoltre, al termine dell'upgrade, gkectl describe clusters mostra un campo Last GKE On Prem Version in Status. Ad esempio:

Status:
Cluster State:  RUNNING
Last GKE On Prem Version:  1.29.0-gke.1

Risolvere i problemi relativi all'upgrade asincrono

Per un upgrade asincrono, la durata del timeout si basa sul numero di nodi nel cluster. Se l'upgrade richiede più tempo rispetto alla durata del timeout, lo stato del cluster viene modificato da UPGRADING a ERROR, con un evento che indica che l'operazione di upgrade è scaduta. Tieni presente che lo stato ERROR qui indica che l'upgrade sta richiedendo più tempo del previsto, ma non è stato terminato. Il controller continua la riconciliazione e continua a ripetere l'operazione.

Di solito un timeout è il risultato di un deadlock causato da un PodDisruptionBudget (PDB). In questo caso, non è possibile rimuovere i pod dai nodi vecchi e svuotare i nodi precedenti. Se l'eliminazione del pod richiede più di 10 minuti, scriviamo un evento nell'oggetto OnPremUserCluster. Puoi acquisire l'evento eseguendo gkectl describe clusters. Quindi puoi modificare il PDB per consentire lo svuotamento del nodo. Dopodiché, l'upgrade può continuare e alla fine viene completato.

Evento di esempio:

Warning  PodEvictionTooLong  96s (x2 over 4m7s)  onprem-user-cluster-controller
Waiting too long(>10m0.00000003s) for (kube-system/coredns-856d6dbfdf-dl6nz) eviction.

Inoltre, se un upgrade viene bloccato o non va a buon fine, puoi eseguire gkectl diagnose per verificare la presenza di problemi comuni del cluster. In base ai risultati, puoi decidere se eseguire una correzione manuale o contattare il team di assistenza Anthos per ulteriore aiuto.

Upgrade sincrono

Il comando gkectl upgrade esegue i controlli preflight. Se i controlli preflight non hanno esito positivo, il comando viene bloccato. Devi correggere gli errori o utilizzare il flag --skip-preflight-check-blocking. Salta i controlli preflight solo se hai la certezza che non siano presenti errori critici.

Procedi con questi passaggi sulla workstation di amministrazione:

Ignora questo passaggio se esegui l'upgrade a una versione successiva alla 1.16.

Se utilizzi credenziali preparate e un registro privato per il cluster utente, assicurati che le credenziali del registro privato siano pronte prima di eseguire l'upgrade del cluster utente. Per informazioni su come preparare la credenziale del registro privata, consulta Configurare le credenziali preparate per i cluster utente.

Esegui l'upgrade del cluster:

gkectl upgrade cluster \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --config USER_CLUSTER_CONFIG_FILE

Se esegui l'upgrade alla versione 1.14.0 o successiva, viene generato un nuovo file kubeconfig per il cluster utente che sovrascrive qualsiasi file esistente. Per visualizzare i dettagli del cluster nel file, esegui questo comando:
```
kubectl config view --kubeconfig USER_CLUSTER_KUBECONFIG
```

Esegui l'upgrade dei pool di nodi aggiuntivi

Se hai eseguito l'upgrade solo del piano di controllo del cluster utente o del piano di controllo e di alcuni, ma non di tutti i pool di nodi, segui questi passaggi per eseguire l'upgrade dei pool di nodi:

Modifica il file di configurazione del cluster utente. Per ogni pool di nodi di cui vuoi eseguire l'upgrade, rimuovi il campo nodePools.nodePool[i].gkeOnPremVersion o impostalo sulla stringa vuota, come mostrato nell'esempio seguente:

gkeOnPremVersion: 1.16.3-gke.45

nodePools:
- name: pool-1
  gkeOnPremVersion: ""
  cpus: 4
  memoryMB: 8192
  replicas: 3
  osImageType: ubuntu_containerd
- name: pool-2
  gkeOnPremVersion: ""
  cpus: 4
  memoryMB: 8192
  replicas: 5
  osImageType: ubuntu_containerd

Esegui gkectl update cluster per applicare la modifica:
```
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --config USER_CLUSTER_CONFIG
```
Sostituisci quanto segue:
- ADMIN_CLUSTER_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione
- USER_CLUSTER_CONFIG: il percorso del file di configurazione del cluster utente

Se si verifica un problema dopo l'upgrade di un pool di nodi, puoi eseguire il rollback alla versione precedente. Per ulteriori informazioni, consulta Eseguire il rollback di un pool di nodi dopo un upgrade.

Riprendi un upgrade

Se l'upgrade di un cluster utente viene interrotto, puoi riprenderlo eseguendo lo stesso comando di upgrade con il flag --skip-validation-all:

gkectl upgrade cluster \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --config USER_CLUSTER_CONFIG_FILE \
  --skip-validation-all

Console

L'upgrade di un cluster utente richiede alcune modifiche al cluster di amministrazione. La console esegue automaticamente le seguenti operazioni:

Registra il cluster di amministrazione nell'API GKE On-Prem, se non è già registrato.
Scarica ed esegue il deployment di un bundle di componenti nel cluster di amministrazione. La versione dei componenti corrisponde a quella specificata per l'upgrade. Questi componenti consentono al cluster di amministrazione di gestire i cluster utente in quella versione.

Per eseguire l'upgrade di un cluster utente:

Nella console, vai alla pagina Panoramica dei cluster Google Kubernetes Engine.

Vai ai cluster GKE
Seleziona il progetto Google Cloud, quindi seleziona il cluster di cui vuoi eseguire l'upgrade.
Nel riquadro Dettagli, fai clic su Altri dettagli.
Nella sezione Impostazioni di base del cluster, fai clic su Esegui l'upgrade.
Nell'elenco Scegli la versione di destinazione, seleziona la versione a cui vuoi eseguire l'upgrade. L'elenco selezionato contiene solo le patch più recenti.
Fai clic su Esegui l'upgrade.

Prima dell'upgrade del cluster, vengono eseguiti controlli preflight per convalidare lo stato del cluster e l'integrità del nodo. Se i controlli preflight vengono superati, viene eseguito l'upgrade del cluster utente. Il completamento dell'upgrade richiede circa 30 minuti.

Per visualizzare lo stato dell'upgrade, fai clic su Mostra dettagli nella scheda Dettagli cluster.

Interfaccia a riga di comando gcloud

L'upgrade di un cluster utente richiede alcune modifiche al cluster di amministrazione. Il comando gcloud container vmware clusters upgrade esegue automaticamente queste operazioni:

Registra il cluster di amministrazione nell'API GKE On-Prem, se non è già registrato.
Scarica ed esegue il deployment di un bundle di componenti nel cluster di amministrazione. La versione dei componenti corrisponde a quella specificata per l'upgrade. Questi componenti consentono al cluster di amministrazione di gestire i cluster utente in quella versione.

Per eseguire l'upgrade di un cluster utente:

Aggiorna i componenti di Google Cloud CLI:
```
gcloud components update
```
Solo pool di nodi Ubuntu e COS: se vuoi eseguire l'upgrade solo del piano di controllo del cluster utente e lasciare tutti i pool di nodi alla versione attuale, modifica il criterio di upgrade sul cluster:
```
gcloud container vmware clusters update USER_CLUSTER_NAME \
  --project=PROJECT_ID \
  --location=REGION \
  --upgrade-policy control-plane-only=True
```
Sostituisci quanto segue:
- USER_CLUSTER_NAME: il nome del cluster utente di cui eseguire l'upgrade.
- PROJECT_ID: l'ID del progetto host del parco risorse di cui è membro il cluster utente. Questo è il progetto che hai specificato al momento della creazione del cluster. Se hai creato il cluster utilizzando gkectl, questo è l'ID progetto nel campo gkeConnect.projectID del file di configurazione del cluster.
- REGION: la regione Google Cloud in cui l'API GKE On-Prem esegue e archivia i propri metadati. Se hai creato il cluster utilizzando un client API GKE On-Prem, questa è la regione che hai selezionato durante la creazione del cluster. Se hai creato il cluster utilizzando gkectl, questa è la regione che hai specificato al momento della registrazione del cluster nell'API GKE On-Prem.

Ottieni un elenco delle versioni disponibili a cui eseguire l'upgrade:

gcloud container vmware clusters query-version-config \
  --cluster=USER_CLUSTER_NAME \
  --project=PROJECT_ID \
  --location=REGION

L'output del comando è simile al seguente:

versions:
- version: 1.16.3-gke.45
- version: 1.16.2-gke.28
- version: 1.16.1-gke.45
- version: 1.16.0-gke.669
- version: 1.15.6-gke.25
- version: 1.15.5-gke.41

An Anthos version must be made available on the admin cluster ahead of the user
cluster creation or upgrade. Versions annotated with isInstalled=true are
installed on the admin cluster for the purpose of user cluster creation or
upgrade whereas other version are released and will be available for upgrade
once dependencies are resolved.

To install the version in the admin cluster, run:
$ gcloud container vmware admin-clusters update my-admin-cluster --required-platform-version=VERSION

Puoi ignorare il messaggio dopo l'elenco delle versioni. Non è importante se la versione a cui esegui l'upgrade è installata sul cluster di amministrazione. Il comando upgrade scarica ed esegue il deployment di un bundle dei componenti che corrisponde alla versione specificata nel comando upgrade.

Esegui l'upgrade del cluster. Se hai eseguito il comando update per modificare il criterio di upgrade in control-plane-only=True, viene eseguito solo l'upgrade del piano di controllo del cluster. In caso contrario, viene eseguito l'upgrade del piano di controllo del cluster e di tutti i pool di nodi.
```
gcloud container vmware clusters upgrade USER_CLUSTER_NAME \
  --project=PROJECT_ID \
  --location=REGION \
  --version=VERSION
```
Sostituisci VERSION con la versione Google Distributed Cloud di cui vuoi eseguire l'upgrade. Specifica una versione dall'output del comando precedente. Ti consigliamo di eseguire l'upgrade alla versione più recente della patch.

L'output del comando è simile al seguente:
```
Waiting for operation [projects/example-project-12345/locations/us-west1/operations/operation-1679543737105-5f7893fd5bae9-942b3f97-75e59179] to complete.
```
Nell'output di esempio, la stringa operation-1679543737105-5f7893fd5bae9-942b3f97-75e59179 è il OPERATION_ID dell'operazione a lunga esecuzione. Puoi conoscere lo stato dell'operazione eseguendo questo comando in un'altra finestra del terminale:
```
gcloud container vmware operations describe OPERATION_ID \
  --project=PROJECT_ID \
  --location=REGION
```

Esegui l'upgrade dei pool di nodi

Se hai scelto di eseguire l'upgrade solo del piano di controllo del cluster utente, segui questi passaggi per eseguire l'upgrade dei pool di nodi dopo l'upgrade del piano di controllo del cluster utente:

Ottieni un elenco di pool di nodi nel cluster utente:

gcloud container vmware node-pools list
  --cluster=USER_CLUSTER_NAME  \
  --project=PROJECT_ID \
  --location=REGION

Per ogni pool di nodi di cui vuoi eseguire l'upgrade, esegui questo comando:

gcloud container vmware node-pools update NODE_POOL_NAME \
  --cluster=USER_CLUSTER_NAME  \
  --project=PROJECT_ID \
  --location=REGION \
  --version=VERSION

Terraform

Aggiorna i componenti di Google Cloud CLI:
```
gcloud components update
```
Se non lo hai già fatto, registra il cluster di amministrazione nell'API GKE On-Prem. Dopo aver registrato il cluster nell'API GKE On-Prem, non devi ripetere questo passaggio.

Ottieni un elenco delle versioni disponibili a cui eseguire l'upgrade:

gcloud container vmware clusters query-version-config \
  --cluster=USER_CLUSTER_NAME \
  --project=PROJECT_ID \
  --location=REGION

Sostituisci quanto segue:

USER_CLUSTER_NAME: il nome del cluster utente.
PROJECT_ID: l'ID del progetto del parco risorse di cui è membro il cluster utente. Questo è il progetto che hai specificato al momento della creazione del cluster. Se hai creato il cluster utilizzando gkectl, questo è l'ID progetto nel campo gkeConnect.projectID del file di configurazione del cluster.
REGION: la regione Google Cloud in cui l'API GKE On-Prem esegue e archivia i propri metadati. Nel file main.tf che hai utilizzato per creare il cluster utente, la regione si trova nel campo location della risorsa cluster.

L'output del comando è simile al seguente:

versions:
- version: 1.16.3-gke.45
- version: 1.16.2-gke.28
- version: 1.16.1-gke.45
- version: 1.16.0-gke.669
- version: 1.15.6-gke.25
- version: 1.15.5-gke.41

An Anthos version must be made available on the admin cluster ahead of the user
cluster creation or upgrade. Versions annotated with isInstalled=true are
installed on the admin cluster for the purpose of user cluster creation or
upgrade whereas other version are released and will be available for upgrade
once dependencies are resolved.

To install the version in the admin cluster, run:
$ gcloud container vmware admin-clusters update my-admin-cluster --required-platform-version=VERSION

Scarica la nuova versione dei componenti ed eseguine il deployment nel cluster di amministrazione:
```
gcloud vmware admin-clusters update ADMIN_CLUSTER_NAME \
  --project=PROJECT_ID \
  --location=REGION \
  --required-platform-version=VERSION
```
Questo comando scarica la versione dei componenti specificati in --required-platform-version nel cluster di amministrazione, quindi esegue il deployment dei componenti. Questi componenti consentono al cluster di amministrazione di gestire i cluster utente in quella versione.
Nel file main.tf che hai utilizzato per creare il cluster utente, imposta on_prem_version nella risorsa del cluster sulla nuova versione.
Solo pool di nodi Ubuntu e COS: se vuoi eseguire l'upgrade solo del piano di controllo del cluster utente e lasciare tutti i pool di nodi alla versione attuale, aggiungi quanto segue alla risorsa del cluster:
```
upgrade_policy {
  control_plane_only = true
}
```
Inizializza e crea il piano Terraform:
```
terraform init
```
Terraform installa le librerie necessarie, ad esempio il provider Google Cloud.
Rivedi la configurazione e apporta le modifiche necessarie:
```
terraform plan
```
Applica il piano Terraform per creare il cluster utente:
```
terraform apply
```

Esegui l'upgrade dei pool di nodi

Se hai scelto di eseguire l'upgrade solo del piano di controllo del cluster utente, segui questi passaggi per eseguire l'upgrade dei pool di nodi aggiuntivi dopo l'upgrade del piano di controllo del cluster utente:

In main.tf nella risorsa per ogni pool di nodi di cui vuoi eseguire l'upgrade, aggiungi quanto segue:

on_prem_version = "VERSION"

Ad esempio:

resource "google_gkeonprem_vmware_node_pool" "nodepool-basic" {
name = "my-nodepool"
location = "us-west1"
vmware_cluster = google_gkeonprem_vmware_cluster.default-basic.name
config {
  replicas = 3
  image_type = "ubuntu_containerd"
  enable_load_balancer = true
}
on_prem_version = "1.16.0-gke.0"
}

Inizializza e crea il piano Terraform:
```
terraform init
```
Rivedi la configurazione e apporta le modifiche necessarie:
```
terraform plan
```
Applica il piano Terraform per creare il cluster utente:
```
terraform apply
```

Esegui l'upgrade del cluster di amministrazione

Dopo aver eseguito l'upgrade dei cluster utente, puoi eseguire l'upgrade del cluster di amministrazione.

Prima di iniziare:

Verifica se i certificati sono aggiornati e rinnovali, se necessario.
Se esegui l'upgrade alla versione 1.13 o successiva, devi prima registrare il cluster di amministrazione compilando la sezione gkeConnect nel file di configurazione del cluster di amministrazione. Esegui il comando gkectl update cluster con le modifiche al file di configurazione.
Assicurati che gkectl e i cluster siano la versione appropriata per un upgrade e di aver scaricato il bundle appropriato. Il disallineamento delle versioni tra i cluster di amministrazione e quelli utente dipende dalla versione Google Distributed Cloud. Per assicurarti di poter eseguire l'upgrade del cluster di amministrazione, consulta Disallineamento delle versioni dei cluster di amministrazione e degli utenti.
Assicurati che il campo bundlepath nel file di configurazione del cluster di amministrazione corrisponda al percorso del bundle a cui vuoi eseguire l'upgrade.

Se apporti altre modifiche ai campi nel file di configurazione del cluster di amministrazione, queste modifiche vengono ignorate durante l'upgrade. Per applicare queste modifiche, devi prima eseguire l'upgrade del cluster, quindi eseguire un comando update cluster con le modifiche al file di configurazione per apportare altre modifiche al cluster.

Esegui `gkectl upgrade admin`

Esegui i passaggi descritti in questa sezione sulla workstation di amministrazione. Esistono due varianti del comando gkectl upgrade admin:

Asincrono:
Con la variante asincrona, il comando avvia l'upgrade e quindi viene completato. Non è necessario osservare l'output del comando per l'intera durata dell'upgrade. Puoi però controllare periodicamente l'avanzamento dell'upgrade eseguendo gkectl list admin e gkectl describe admin. Per utilizzare la variante asincrona, includi il flag --async nel comando.

Requisiti per l'upgrade asincrono:
- Supportata solo per i cluster di amministrazione ad alta disponibilità con versione 1.29 o successive.
- In tutti i cluster utente deve essere abilitato il piano di controllo V2.
Sincrona:
Con la variante sincrona, il comando gkectl upgrade admin invia messaggi di stato alla workstation di amministrazione man mano che l'upgrade procede.

Upgrade asincrono

Sulla workstation di amministrazione, avvia un upgrade asincrono:
```
gkectl upgrade admin \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG_FILE \
    --async \
    FLAGS
```
Sostituisci quanto segue:
- ADMIN_CLUSTER_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.
- ADMIN_CLUSTER_CONFIG_FILE: il percorso del file di configurazione del cluster di amministrazione.
- FLAGS: un insieme facoltativo di flag. Ad esempio, potresti includere il flag --skip-validation-infra per saltare il controllo della tua infrastruttura vSphere.
Il comando precedente viene completato e puoi continuare a utilizzare la workstation di amministrazione mentre è in corso l'upgrade.
Per visualizzare lo stato dell'upgrade:
```
gkectl list admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG
```
L'output mostra un valore per il cluster STATE. Se è ancora in corso l'upgrade del cluster, il valore di STATE è UPGRADING. Ad esempio:
```
NAME              STATE         AGE    VERSION
gke-admin-test    UPGRADING     9h     1.29.100-gke.248
```
I valori possibili per STATE sono RUNNING, UPGRADING, RECONCILING, ERROR e UNKNOWN.

Per ulteriori dettagli sull'avanzamento dell'upgrade e sugli eventi del cluster:

gkectl describe admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG

L'output mostra la risorsa personalizzata OnPremAdminCluster per il cluster di amministrazione specificato, che include stato, condizioni ed eventi del cluster.

Registriamo gli eventi per l'inizio e la fine di ogni fase critica dell'upgrade.

Output di esempio:

Events:
Type    Reason                             Age   From                             Message
----       ------                                  ----     ----                                -------
Normal  ControlPlaneUpgradeStarted         40m   onprem-admin-cluster-controller  Creating or updating admin cluster API Controller
Normal  ControlPlaneMachineUpgradeStarted  40m   onprem-admin-cluster-controller  Creating or updating control plane machine
Normal  StatusChanged                      40m   onprem-admin-cluster-controller  OnPremAdminCluster status changed:
- New ClusterState condition: UPGRADING
- New Ready condition: False, CreateOrUpdateControlPlaneMachine, Creating or updating control plane machine
Normal   StatusChanged      2m                onprem-admin-cluster-controller  OnPremAdminCluster status changed:
- New ClusterState condition: RUNNING
- New Ready condition: True, ClusterRunning, Cluster is running

Al termine dell'upgrade, gkectl list admin mostra un valore STATUS di RUNNING:
```
NAME              STATE         AGE    VERSION
gke-admin-test    RUNNING       9h     1.29.100-gke.248
```
Inoltre, al termine dell'upgrade, gkectl describe admin mostra un campo Last GKE On Prem Version in Status. Ad esempio:
```
Status:
  Cluster State:  RUNNING
  Last GKE On Prem Version:  1.29.0-gke.1
```

Risolvere i problemi relativi all'upgrade asincrono

Per un upgrade asincrono, la durata del timeout si basa sul numero di nodi nel cluster. Se l'upgrade richiede più tempo della durata del timeout, lo stato del cluster viene modificato da UPGRADING a ERROR, con un evento che segnala che l'operazione di upgrade è scaduta. Tieni presente che lo stato ERROR in questo caso indica che l'upgrade sta richiedendo più tempo del previsto, ma non è stato terminato. Il controller continua la riconciliazione e continua a ripetere l'operazione. Quando un upgrade viene bloccato o non va a buon fine, puoi eseguire gkectl diagnose per verificare i problemi comuni del cluster. In base al risultato, puoi decidere se eseguire una correzione manuale o contattare l'assistenza Google Cloud per ulteriore aiuto.

Upgrade sincrono

Esegui questo comando:
```
gkectl upgrade admin \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG_FILE \
    FLAGS
```
Sostituisci quanto segue:
- ADMIN_CLUSTER_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.
- ADMIN_CLUSTER_CONFIG_FILE: il percorso del file di configurazione del cluster di amministrazione.
- FLAGS: un insieme facoltativo di flag. Ad esempio, puoi includere il flag --skip-validation-infra per saltare il controllo della tua infrastruttura vSphere.
Il comando gkectl upgrade esegue i controlli preflight. Se i controlli preflight non hanno esito positivo, il comando viene bloccato. Devi correggere gli errori o utilizzare il flag --skip-preflight-check-blocking con il comando per sbloccarlo.
Se esegui l'upgrade alla versione 1.14.0 o successiva, viene generato un nuovo file kubeconfig per il cluster di amministrazione che sovrascrive qualsiasi file esistente. Per visualizzare i dettagli del cluster nel file, esegui questo comando:
```
kubectl config view --kubeconfig ADMIN_CLUSTER_KUBECONFIG
```

Rimuovi l'intero bundle

Se hai scaricato un bundle completo e hai eseguito correttamente i comandi gkectl prepare e gkectl upgrade admin, devi eliminare l'intero bundle per risparmiare spazio su disco sulla workstation di amministrazione. Esegui questo comando per eliminare l'intero bundle:

rm /var/lib/gke/bundles/gke-onprem-vsphere-${TARGET_VERSION}-full.tgz

Ripresa dell'upgrade di un cluster di amministrazione

Se l'upgrade di un cluster di amministrazione viene interrotto o non riesce, l'upgrade può essere ripreso se il punto di controllo del cluster di amministrazione contiene lo stato necessario per ripristinare lo stato precedente all'interruzione.

Avviso: non riparare il master di amministrazione con gkectl repair admin-master dopo un tentativo di upgrade non riuscito. Questo causerà uno stato non valido del cluster di amministrazione.

Segui questi passaggi:

Verifica che il piano di controllo amministrativo sia integro prima di iniziare il tentativo di upgrade iniziale. Consulta Diagnosticare i problemi del cluster. Come discusso in questo argomento, esegui il comando gkectl diagnose cluster per il cluster di amministrazione.
Se il piano di controllo amministratore non è integro prima del tentativo di upgrade iniziale, ripara il piano di controllo amministratore con il comando gkectl repair admin-master.
Quando esegui di nuovo il comando di upgrade dopo che un upgrade è stato interrotto o non è riuscito, utilizza lo stesso bundle e la stessa versione di destinazione che hai fatto nel precedente tentativo di upgrade.

Quando esegui nuovamente il comando di upgrade, l'upgrade ripreso ricrea lo stato del cluster di amministrazione dal checkpoint ed esegue nuovamente l'intero upgrade. A partire dalla versione 1.12.0, se il piano di controllo dell'amministratore non è integro, il processo di upgrade verrà eseguito direttamente alla versione di destinazione senza tentare di ripristinare il cluster di amministrazione alla versione di origine prima di procedere con l'upgrade.

L'upgrade riprenderà dal momento in cui non è riuscito o è stato chiuso, se il checkpoint del cluster di amministrazione è disponibile. Se il checkpoint non è disponibile, l'upgrade ricorrerà al piano di controllo amministratore; di conseguenza, quest'ultimo deve essere integro per procedere con l'upgrade. Dopo un upgrade riuscito, il checkpoint viene rigenerato.

Se gkectl si chiude in modo imprevisto durante l'upgrade di un cluster di amministrazione, la pulizia del cluster di tipo non viene eseguita. Prima di eseguire di nuovo il comando di upgrade per riprendere l'upgrade, elimina il cluster di tipo:

docker stop gkectl-control-plane && docker rm gkectl-control-plane

Dopo aver eliminato il cluster di tipo, esegui di nuovo il comando di upgrade.

Esegui il rollback di una workstation di amministrazione dopo un upgrade

Puoi eseguire il rollback della workstation di amministrazione alla versione utilizzata prima dell'upgrade.

Durante l'upgrade, gkeadm registra la versione precedente all'upgrade nel file delle informazioni di output. Durante il rollback, gkeadm utilizza la versione elencata per scaricare il file precedente.

Per eseguire il rollback della workstation di amministrazione alla versione precedente:

gkeadm rollback admin-workstation --config=AW_CONFIG_FILE

Puoi omettere --config=AW_CONFIG_FILE se il file di configurazione della workstation di amministrazione è il valore predefinito di admin-ws-config.yaml. In caso contrario, sostituisci AW_CONFIG_FILE con il percorso del file di configurazione della workstation di amministrazione.

Il comando di rollback esegue questi passaggi:

Scarica la versione di rollback di gkeadm.
Esegue il backup della home directory della workstation di amministrazione corrente.
Crea una nuova workstation di amministrazione utilizzando la versione di rollback di gkeadm.
Elimina la workstation di amministrazione originale.

Installa il bundle con una versione diversa per l'upgrade

Se esegui l'upgrade della workstation, viene installato un bundle con una versione corrispondente per l'upgrade dei cluster. Se vuoi una versione diversa, segui questi passaggi per installare un bundle per TARGET_VERSION, che è la versione a cui vuoi eseguire l'upgrade.

Per controllare le versioni attuali di gkectl e del cluster, esegui questo comando. Utilizza il flag --details/-d per informazioni più dettagliate.
```
gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG --details
```
L'output fornisce informazioni sulle versioni del cluster.
In base all'output visualizzato, cerca i seguenti problemi e correggili, se necessario.
- Se la versione attuale del cluster di amministrazione è inferiore di più di una versione secondaria a TARGET_VERSION, esegui l'upgrade di tutti i cluster in modo che siano una versione secondaria inferiore a TARGET_VERSION.
- Se la versione di gkectl è precedente alla 1.11 e vuoi eseguire l'upgrade alla versione 1.12.x, dovrai eseguire più upgrade. Esegui l'upgrade di una versione secondaria alla volta, fino a quando non raggiungi la versione 1.11.x, quindi procedi con le istruzioni riportate in questo argomento.
- Se la versione di gkectl è precedente a TARGET_VERSION, esegui l'upgrade della workstation di amministrazione a TARGET_VERSION.
Una volta stabilito che le versioni di gkectl e del cluster sono appropriate per un upgrade, scarica il bundle.

Controlla se il tarball del bundle esiste già sulla workstation di amministrazione.
```
stat /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz
```
Se il bundle non si trova sulla workstation di amministrazione, scaricalo.
```
gsutil cp gs://gke-on-prem-release/gke-onprem-bundle/TARGET_VERSION/gke-onprem-vsphere-TARGET_VERSION.tgz /var/lib/gke/bundles/
```
Installa il bundle.
```
gkectl prepare --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz --kubeconfig ADMIN_CLUSTER_KUBECONFIG
```
Sostituisci ADMIN_CLUSTER_KUBECONFIG con il percorso del file kubeconfig. Puoi omettere questo flag se il file si trova nella directory attuale e ha il nome kubeconfig.

Nota: per impostazione predefinita, viene scaricato il bundle normale, anziché il bundle completo. Il bundle completo contiene tutte le immagini container e VM, mentre il bundle normale scarica le immagini container e VM da Google Cloud Platform nella workstation di amministrazione durante l'installazione. Per utilizzare invece il bundle completo, il percorso del bundle nel comando di installazione è gke-onprem-vsphere-TARGET_VERSION-full.tgz.
Elenca le versioni disponibili del cluster e assicurati che la versione di destinazione sia inclusa nelle versioni del cluster utente disponibili.
```
gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG --details
```

Ora puoi creare un cluster utente nella versione di destinazione o eseguire l'upgrade di un cluster utente alla versione di destinazione.

Risoluzione dei problemi del processo di upgrade

Se riscontri un problema mentre esegui la procedura di upgrade consigliata, segui questi consigli per risolverlo. Questi suggerimenti presuppongono che tu abbia iniziato con una configurazione della versione 1.11.x e che tu stia procedendo con il processo di upgrade consigliato.

Vedi anche: Risolvere i problemi di creazione e upgrade del cluster

Risoluzione di un problema di upgrade del cluster utente

Supponiamo che rilevi un problema con la versione di upgrade durante l'upgrade di un cluster utente. Stabilisci dall'Assistenza Google che il problema verrà risolto in una release patch futura. Puoi procedere nel seguente modo:

Continua a utilizzare la versione attuale per la produzione.
Testa la release della patch in un cluster non di produzione quando viene rilasciata.
Esegui l'upgrade di tutti i cluster utente di produzione alla versione di release della patch quando hai la certezza.
Esegui l'upgrade del cluster di amministrazione alla versione di release della patch.

Risoluzione di un problema di upgrade del cluster di amministrazione

Se si verifica un problema durante l'upgrade del cluster di amministrazione, devi contattare l'Assistenza Google per risolvere il problema con il cluster di amministrazione.

Nel frattempo, con il nuovo flusso di upgrade, puoi comunque trarre vantaggio dalle nuove funzionalità del cluster utente senza essere bloccato dall'upgrade del cluster di amministrazione. Se vuoi, puoi ridurre la frequenza di upgrade del cluster di amministrazione. La procedura di upgrade può procedere come segue:

Esegui l'upgrade dei cluster utente di produzione alla versione 1.12.x.
Mantieni il cluster di amministrazione alla versione precedente e continua a ricevere le patch di sicurezza.
Testa l'upgrade del cluster di amministrazione da 1.11.x a 1.12.x in un ambiente di test e segnala eventuali problemi;
Se il problema è stato risolto con il rilascio di una patch 1.12.x, puoi scegliere di eseguire l'upgrade del cluster di amministrazione di produzione a questa release della patch, se necessario.

Problemi noti relativi alle versioni recenti

I problemi noti riportati di seguito potrebbero influire sugli upgrade se esegui l'upgrade dalla versione 1.7 o successive.

Vedi anche: Problemi noti

L'upgrade della workstation di amministrazione potrebbe non riuscire se il disco dati è quasi pieno

Se esegui l'upgrade della workstation di amministrazione con il comando gkectl upgrade admin-workstation, l'upgrade potrebbe non riuscire se il disco dati è quasi pieno, perché il sistema tenta di eseguire il backup della workstation di amministrazione attuale in locale durante l'upgrade a una nuova workstation di amministrazione. Se non è possibile liberare spazio sufficiente sul disco dati, utilizza il comando gkectl upgrade admin-workstation con il flag aggiuntivo --backup-to-local=false per impedire di eseguire un backup locale dell'attuale workstation di amministrazione.

Interruzione per i carichi di lavoro con PodDisruptionBudget

Attualmente, l'upgrade dei cluster può causare interruzioni o tempi di inattività per i carichi di lavoro che utilizzano PodDisruptionBudgets (PDB).

I nodi non riescono a completare il processo di upgrade

Se hai configurato PodDisruptionBudget oggetti che non possono consentire ulteriori interruzioni, dopo ripetuti tentativi gli upgrade dei nodi alla versione del piano di controllo potrebbero non riuscire. Per evitare questo errore, ti consigliamo di fare lo scale up di Deployment o HorizontalPodAutoscaler per consentire lo svuotamento del nodo pur rispettando la configurazione di PodDisruptionBudget.

Per visualizzare tutti gli oggetti PodDisruptionBudget che non consentono interruzioni:

kubectl get poddisruptionbudget --all-namespaces -o jsonpath='{range .items[?(@.status.disruptionsAllowed==0)]}{.metadata.name}/{.metadata.namespace}{"\n"}{end}'

Appendice

Informazioni sulle regole VMware DRS abilitate nella versione 1.1.0-gke.6

A partire dalla versione 1.1.0-gke.6, GKE su VMware crea automaticamente regole di anti-affinità del Distributed Resource Scheduler (DRS) di VMware per i nodi del cluster utente, distribuendole in almeno tre host fisici nel tuo data center. A partire dalla versione 1.1.0-gke.6, questa funzionalità viene abilitata automaticamente per i cluster nuovi e esistenti.

Prima di eseguire l'upgrade, assicurati che l'ambiente vSphere soddisfi le seguenti condizioni:

VMware DRS è abilitato. VMware DRS richiede la versione di licenza vSphere Enterprise Plus. Per scoprire come abilitare DRS, consulta Abilitazione di VMware DRS in un cluster
Il nome utente vSphere fornito nel file di configurazione delle credenziali dispone dell'autorizzazione Host.Inventory.EditCluster.
Sono disponibili almeno tre host fisici.

Se il tuo ambiente vSphere non soddisfa le condizioni precedenti, puoi comunque eseguire l'upgrade, ma per eseguire l'upgrade di un cluster utente dalla versione 1.3.x alla versione 1.4.x, devi disabilitare i gruppi anti-affinità. Per ulteriori informazioni, consulta questo problema noto nelle note di rilascio di Google Distributed Cloud.

Informazioni sui tempi di inattività durante gli upgrade

Risorsa	Descrizione
Cluster di amministrazione	Quando un cluster di amministrazione non è attivo, i piani di controllo e i carichi di lavoro sui cluster utente continuano a essere eseguiti, a meno che non siano stati interessati da un errore che ha causato il tempo di inattività.
Piano di controllo del cluster utente	In genere, i piani di controllo dei cluster utente non prevedono tempi di inattività evidenti. Tuttavia, le connessioni a lunga esecuzione al server dell'API Kubernetes potrebbero interrompersi e dover essere ristabilite. In questi casi, il chiamante dell'API deve riprovare finché non stabilisce una connessione. Nel peggiore dei casi, durante l'upgrade potrebbe verificarsi un tempo di inattività fino a un minuto. Nota: se i nodi del cluster utente non sono in grado di raggiungere il piano di controllo utente durante l'upgrade, non vengono pianificati nuovi carichi di lavoro per il cluster. I carichi di lavoro esistenti non sono interessati.
Nodi del cluster utente	Se un upgrade richiede una modifica dei nodi del cluster utente, GKE on VMware ricrea i nodi in sequenza e riprogramma i pod in esecuzione su questi nodi. Puoi prevenire l'impatto sui tuoi carichi di lavoro configurando PodDisruptionBudgets e regole di anti-affinità appropriati.

Ricrea un file di informazioni, se mancante

Se manca il file con le informazioni di output per la workstation di amministrazione, devi ricreare questo file per poter procedere con l'upgrade. Questo file è stato creato durante la creazione iniziale della workstation e, se da allora hai eseguito un upgrade, è stato aggiornato con nuove informazioni.

Il file con le informazioni di output ha questo formato:

Admin workstation version: GKEADM_VERSION
Created using gkeadm version: GKEADM_VERSION
VM name: ADMIN_WS_NAME
IP: ADMIN_WS_IP
SSH key used: FULL_PATH_TO_ADMIN_WS_SSH_KEY
To access your admin workstation:
ssh -i FULL-PATH-TO-ADMIN-WS-SSH-KEY ubuntu@ADMIN-WS-IP

Ecco un esempio di file di informazioni di output:

Admin workstation version: v1.10.3-gke.49
Created using gkeadm version: v1.10.3-gke.49
VM name: admin-ws-janedoe
IP: 172.16.91.21
SSH key used: /usr/local/google/home/janedoe/.ssh/gke-admin-workstation
Upgraded from (rollback version): v1.10.0-gke.194
To access your admin workstation:
ssh -i /usr/local/google/home/janedoe/.ssh/gke-admin-workstation ubuntu@172.16.91.21

Crea il file in un editor, sostituendo i parametri appropriati. Salva il file con un nome file uguale a quello della VM nella directory da cui viene eseguito gkeadm. Ad esempio, se il nome della VM è admin-ws-janedoe, salva il file come admin-ws-janedoe.

Passaggi successivi

Documentazione di riferimento per gcloud CLI
Documentazione di riferimento di Terraform
- google_gkeonprem_vmware_cluster
- google_gkeonprem_vmware_node_pool

Eseguire l'upgrade di un cluster o di un pool di nodi

Rivedi le regole firewall

Requisiti IAM e API di Google

Requisiti IAM per l'upgrade dei cluster utente

Apportare modifiche alla configurazione prima o dopo un upgrade

Esegui l'upgrade della workstation di amministrazione

Gkeadm

Individua i file richiesti

Esegui l'upgrade

Gestita dall'utente

Controlla le versioni disponibili per gli upgrade del cluster

Esegui l'upgrade di un cluster utente

Gkectl

Prepara l'upgrade di un cluster utente

Esecuzione di controlli preliminari

Esegui gkectl upgrade cluster

Upgrade asincrono

Risolvere i problemi relativi all'upgrade asincrono

Upgrade sincrono

Esegui l'upgrade dei pool di nodi aggiuntivi

Riprendi un upgrade

Console

Interfaccia a riga di comando gcloud

Esegui l'upgrade dei pool di nodi

Terraform

Esegui l'upgrade dei pool di nodi

Esegui l'upgrade del cluster di amministrazione

Prima di iniziare:

Esegui gkectl upgrade admin

Upgrade asincrono

Risolvere i problemi relativi all'upgrade asincrono

Upgrade sincrono

Rimuovi l'intero bundle

Ripresa dell'upgrade di un cluster di amministrazione

Esegui il rollback di una workstation di amministrazione dopo un upgrade

Installa il bundle con una versione diversa per l'upgrade

Risoluzione dei problemi del processo di upgrade

Risoluzione di un problema di upgrade del cluster utente

Risoluzione di un problema di upgrade del cluster di amministrazione

Problemi noti relativi alle versioni recenti

L'upgrade della workstation di amministrazione potrebbe non riuscire se il disco dati è quasi pieno

Interruzione per i carichi di lavoro con PodDisruptionBudget

I nodi non riescono a completare il processo di upgrade

Appendice

Informazioni sulle regole VMware DRS abilitate nella versione 1.1.0-gke.6

Informazioni sui tempi di inattività durante gli upgrade

Ricrea un file di informazioni, se mancante

Passaggi successivi

Esegui `gkectl upgrade cluster`

Esegui `gkectl upgrade admin`