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 (solo software) per VMware. Questo documento illustra i passaggi da seguire per eseguire l'upgrade della workstation di amministrazione, dei cluster utente e dei cluster di amministrazione. Per cluster utente, questo documento illustra i passaggi per eseguire l'upgrade del piano di controllo pool di nodi contemporaneamente o separatamente.

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

Panoramica dell'upgrade
Tra le altre cose, questo documento descrive il disallineamento delle versioni e per gli upgrade, che sono cambiate per la versione 1.28 e versioni 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. Nel Regole firewall per i cluster di amministrazione, cerca "Controlli preflight" e assicurati che tutte le regole firewall richieste sono configurate.

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 anziché in locale sulla workstation di amministrazione. Vengono eseguiti anche i controlli preflight lato server sull'amministratore cluster 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 Kubernetes in Docker (kind) per ospitare temporaneamente i controller Kubernetes necessari per l'upgrade dell'amministratore in un cluster Kubernetes. Questo cluster temporaneo è chiamato cluster di bootstrap. Lato server I controlli preflight vengono eseguiti sul cluster di bootstrap quando esegui l'upgrade di un amministratore in un cluster Kubernetes.

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 concedi kubernetesmetadata.publisher al ruolo IAM account di servizio di logging-monitoraggio. Questi modifiche 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 in cui il cluster utente fa parte. Questo è il progetto specificato al momento della creazione del cluster. Se hai creato il cluster utilizzando gkectl, questo è l'ID progetto in gkeConnect.projectID nel file di configurazione del cluster.
Se la tua organizzazione ha configurato una lista consentita che consente al traffico API di Google e altri indirizzi passano attraverso il server proxy, aggiungi kubernetesmetadata.googleapis.com alla lista consentita.
Concedi il ruolo kubernetesmetadata.publisher a account di servizio logging-monitoraggio:
```
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member "serviceAccount:SERVICE_ACCOUNT_EMAIL" \
  --role "roles/kubernetesmetadata.publisher"
```
Sostituisci SERVICE_ACCOUNT_EMAIL con l'email dell'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 eseguire l'upgrade di un cluster utente e non sei un proprietario del progetto, devi disporre il ruolo Identity and Access Management roles/gkeonprem.admin nel progetto Google Cloud che in cui è stato creato il cluster. Per maggiori dettagli sulle autorizzazioni incluse in questo ruolo, vedi Ruoli GKE On-Prem nella documentazione di IAM.

Come minimo per utilizzare la console per l'upgrade del cluster, occorre quanto segue:

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

Apportare modifiche alla configurazione prima o dopo un upgrade

Se devi apportare modifiche alla configurazione dei cluster, esegui cluster update prima o dopo l'upgrade. L'unica modifica alla configurazione del cluster per un upgrade deve sia la versione. A seconda della versione e del tipo di cluster, altre configurazioni le modifiche vengono ignorate automaticamente o comportano la mancata riuscita dell'upgrade. Per ulteriori informazioni informazioni vedi Rimuovi le modifiche non supportate per sbloccare l'upgrade.

Esegui l'upgrade della workstation di amministrazione

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

Se prevedi di utilizzare la console, gcloud CLI Terraform per eseguire l'upgrade di un cluster utente, puoi saltare l'upgrade dell'amministrazione per il momento. Dovrai però eseguire l'upgrade della workstation di amministrazione sono pronti a eseguire l'upgrade del cluster di amministrazione perché solo gkectl supporta l'amministrazione degli upgrade dei cluster.

Il modo in cui esegui l'upgrade della workstation di amministrazione dipende da come l'hai creata: gkeadm o gestita dall'utente.

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 corrisponde al nome della workstation di amministrazione.

Individua il file di configurazione della workstation di amministrazione e il file delle informazioni. Tu per eseguire i passaggi dell'upgrade. Se questi file si trovano nella directory attuale con i nomi predefiniti, quindi non dovrai specificare quando esegui i comandi di upgrade. Se questi file si trovano in in un'altra directory o, se sono stati modificati 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 Ricrea 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, vedi 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 della tua workstation di amministrazione di configurazione del deployment. Puoi omettere questo flag se il file è nella cartella 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 corrisponde al nome della workstation di amministrazione.

Gestita dall'utente

Sulla workstation di amministrazione, vai a una directory in cui vuoi installare 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. Per esempio: 1.29.200-gke.245.

Scarica il pacchetto Google Distributed Cloud. Assicurati che la versione corrisponda uno usato 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, Terraform per l'upgrade richiede dai 7 ai 10 giorni circa sia disponibile nell'API GKE On-Prem in tutte le regioni di Google Cloud. Nella console sono elencate solo le versioni disponibili per l'utente. dell'upgrade del cluster. I passaggi per eseguire l'upgrade di un cluster utente utilizzando gcloud CLI o Terraform includono un passaggio da 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 a Terraform per eseguire l'upgrade di un cluster utente. Per informazioni su come decidere quale strumento usa, vedi Scegli 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, vedi Esegui l'upgrade del cluster utente con i pool di nodi Windows.
Nel file di configurazione del cluster utente, imposta gkeOnPremVersion alla versione di destinazione dell'upgrade.
Solo pool di nodi Ubuntu e COS: specifica i pool di nodi che vuoi 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 a cui eseguire l'upgrade, come segue:
- Per ogni pool di nodi di cui vuoi eseguire l'upgrade, rimuovi nodePools.nodePool[i].gkeOnPremVersion oppure impostalo sul campo vuoto stringa.
- Per ogni pool di nodi di cui non vuoi eseguire l'upgrade, imposta nodePools.nodePool[i].gkeOnPremVersion alla versione corrente.
Ad esempio, supponiamo che il cluster utente sia alla versione 1.15.5-gke.41 e abbia due pool di nodi: pool-1 e pool-2. Supponiamo anche che tu voglia eseguire l'upgrade del piano di controllo e pool-1 a 1.16.3-gke.45, ma vuoi pool-2 per rimanere alla versione 1.15.5-gke.41. La parte seguente di di configurazione del 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. Sebbene le versioni precedenti Google Distributed Cloud esegue controlli preflight, non possono essere eseguiti separatamente dall'upgrade. Aggiungendo il flag --dry-run, puoi trovare e correggere qualsiasi i problemi rilevati dai controlli preflight nel cluster utente prima che upgrade.

Esegui `gkectl upgrade cluster`

Esistono due varianti del comando gkectl upgrade cluster:

Asincrona: (opzione consigliata)
Con la variante asincrona, il comando avvia l'upgrade e quindi vengono completate. Non è necessario osservare l'output del comando per l'intera durata dell'upgrade. Puoi però controllare periodicamente lo stato dell'upgrade progressi 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 restituisce 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 a 1,16.

Se utilizzi credenziali preparate e un registro privato per il cluster utente, assicurati che la credenziale privata del registro preparati prima di eseguire l'upgrade del cluster utente. Per informazioni su come per preparare la credenziale privata del registro, Configura 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 il tuo e la workstation di amministrazione durante 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 il cluster è ancora Upgrade, 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 l'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 una Last GKE On Prem Version sotto 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 sulla di nodi nel cluster. Se l'upgrade richiede più tempo del timeout la durata del cluster, lo stato del cluster viene modificato da UPGRADING a ERROR, con un che indica che l'operazione di upgrade è scaduta. Tieni presente che lo stato ERROR significa che l'upgrade sta richiedendo più tempo del previsto, ma non è stato ancora terminato. Il controller continua la riconciliazione e continua a ripetere operativa.

Di solito un timeout è il risultato di un deadlock causato da un PodDisruptionBudget (PDB). In questo caso, non è possibile rimuovere i pod e quelli precedenti non possono essere svuotati. Se l'eliminazione del pod richiede più tempo dopo 10 minuti, scriviamo un evento nell'oggetto OnPremUserCluster. Puoi acquisisci l'evento eseguendo gkectl describe clusters. Dopodiché puoi regolare del PDB per consentire lo svuotamento del nodo. Dopodiché, l'upgrade può continuare e completato alla fine.

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, quando un upgrade viene bloccato o non va a buon fine, puoi eseguire gkectl diagnose per per verificare la presenza di problemi comuni relativi al 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 riesce, il comando viene bloccato. Devi correggere gli errori oppure utilizzare --skip-preflight-check-blocking flag. Dovresti saltare solo il periodo preflight e controlla 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 a 1,16.

Se utilizzi credenziali preparate e un registro privato per il cluster utente, assicurati che la credenziale privata del registro preparati prima di eseguire l'upgrade del cluster utente. Per informazioni su come per preparare la credenziale privata del registro, Configura 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 creato un nuovo file kubeconfig generato per il cluster utente che sovrascrive qualsiasi file esistente. Per visualizzare 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 di controllo e alcuni pool di nodi, ma non tutti, segui questi passaggi esegui l'upgrade dei pool di nodi:

Modifica il file di configurazione del cluster utente. Per ogni pool di nodi vuoi eseguire l'upgrade, rimuovi nodePools.nodePool[i].gkeOnPremVersion oppure impostarla sulla stringa vuota, come illustrato 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 kubeconfig del cluster di amministrazione file
- USER_CLUSTER_CONFIG: il percorso della configurazione del cluster utente file

Se riscontri un problema dopo l'upgrade di un pool di nodi, puoi eseguire il rollback la versione precedente. Per ulteriori informazioni, vedi Rollback di un pool di nodi dopo un upgrade.

Riprendi un upgrade

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

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 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 dei componenti corrisponda 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 panoramica dei cluster Google Kubernetes Engine .

Vai ai cluster GKE
Seleziona il progetto Google Cloud, quindi seleziona il cluster che 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 che 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 il cluster e l'integrità del nodo. Se i controlli preflight vengono superati, il cluster utente viene con upgrade eseguito. Il completamento dell'upgrade richiede circa 30 minuti.

Per visualizzare lo stato dell'upgrade, fai clic su Mostra dettagli nella finestra di dialogo Cluster Dettagli.

Interfaccia a riga di comando gcloud

L'upgrade di un cluster utente richiede alcune modifiche al cluster di amministrazione. La il comando gcloud container vmware clusters upgrade esegue automaticamente seguenti:

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 dei componenti corrisponda 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 dell'utente del piano di controllo del cluster e lascia tutti i pool di nodi nello stato 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 da upgrade.
- PROJECT_ID: l'ID del progetto host del parco risorse in cui il cluster utente fa parte. Questo è il progetto specificato al momento della creazione del cluster. Se hai creato il cluster utilizzando gkectl, questo è l'ID progetto in gkeConnect.projectID nel file di configurazione del cluster.
- REGION: la regione Google Cloud in cui L'API GKE On-Prem esegue e archivia i relativi 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 l'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 importa se la versione a cui stai eseguendo l'upgrade è installata nel pannello in un cluster Kubernetes. Il comando upgrade scarica ed esegue il deployment di un bundle corrispondenti alla versione specificata nel comando upgrade.

Esegui l'upgrade del cluster. Se hai eseguito il comando update per modificare l'upgrade su control-plane-only=True, solo il piano di controllo del cluster con upgrade eseguito. In caso contrario, il piano di controllo del cluster e tutti i pool di nodi vengono con upgrade eseguito.
```
gcloud container vmware clusters upgrade USER_CLUSTER_NAME \
  --project=PROJECT_ID \
  --location=REGION \
  --version=VERSION
```
Sostituisci VERSION con Google Distributed Cloud a cui vuoi eseguire l'upgrade. Specifica una versione dall'output di il comando precedente. Ti consigliamo di eseguire l'upgrade alla versione più recente versione 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 scoprire lo stato dell'operazione eseguendo questo 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, esegui la seguendo i passaggi per eseguire l'upgrade dei pool di nodi dopo la configurazione è stato eseguito l'upgrade del piano di controllo:

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 l'hai già fatto, registrare il cluster di amministrazione nell'API GKE On-Prem. Dopo aver registrato il cluster nell'API GKE On-Prem, non è necessario ripeti 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 fa parte il cluster utente. Questo è il progetto specificato al momento della creazione del cluster. Se hai creato il cluster utilizzando gkectl, questo è l'ID progetto in gkeConnect.projectID nel file di configurazione del cluster.
REGION: la regione Google Cloud in cui L'API GKE On-Prem esegue e archivia i relativi metadati. Nel file main.tf che che hai utilizzato per creare il cluster utente, la regione si trova nella zona location campo della risorsa del 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 nella Console di amministrazione cluster:
```
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 tra i componenti. Questi componenti consentono al cluster di amministrazione di gestire in quella versione.
Nel file main.tf che hai utilizzato per creare il cluster utente, modifica on_prem_version nella risorsa cluster alla nuova versione.
Solo pool di nodi Ubuntu e COS: se vuoi eseguire l'upgrade solo dell'utente del piano di controllo del cluster e lascia tutti i pool di nodi nello stato 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, come Google Cloud o il provider di servizi di terze parti.
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, esegui la seguendo i passaggi per eseguire l'upgrade dei pool di nodi aggiuntivi dopo la configurazione è stato eseguito l'upgrade del piano di controllo:

In main.tf, nella risorsa per ogni pool di nodi che vuoi 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, se necessario, rinnovarle.
Se esegui l'upgrade alla versione 1.13 o successiva, devi prima registrare il del cluster di amministrazione compilando la sezione gkeConnect nel cluster di amministrazione di configurazione del deployment. Esegui l' gkectl aggiorna il 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. Versione il disallineamento tra cluster di amministrazione e cluster utente dipende completamente gestita. 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 nell'intervallo file di configurazione del cluster di amministrazione corrisponda al percorso del bundle a cui vuoi upgrade.

Se apporti altre modifiche ai campi nel cluster di amministrazione di configurazione, queste modifiche vengono ignorate durante l'upgrade. Per rendere le modifiche diventano effettive, devi prima eseguire l'upgrade del cluster un comando update cluster 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:

Asincrona:
Con la variante asincrona, il comando avvia l'upgrade e quindi vengono completate. Non è necessario osservare l'output del comando per l'intera durata dell'upgrade. Puoi però controllare periodicamente lo stato dell'upgrade progressi eseguendo gkectl list admin e gkectl describe admin. Per utilizzare la variante asincrona, includi il flag --async nella .

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 restituisce 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 kubeconfig del cluster di amministrazione.
- ADMIN_CLUSTER_CONFIG_FILE: il percorso di configurazione del cluster di amministrazione.
- FLAGS: un insieme facoltativo di flag. Ad esempio, potresti includere il flag --skip-validation-infra per ignora il controllo dell'infrastruttura vSphere.
Il comando precedente viene completato e puoi continuare a utilizzare il tuo e la workstation di amministrazione durante 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 il cluster è ancora Upgrade, il valore di STATE è UPGRADING. Ad esempio:
```
NAME              STATE         AGE    VERSION
gke-admin-test    UPGRADING     9h     1.29.200-gke.245
```
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 l'oggetto 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.200-gke.245
```
Inoltre, al termine dell'upgrade, gkectl describe admin mostra una Last GKE On Prem Version sotto 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 dice che l'operazione di upgrade sia scaduta. Tieni presente che lo stato ERROR in questo caso indica l'upgrade sta richiedendo più tempo del previsto, ma non è stato terminato. La 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 controllare problemi comuni dei cluster. In base ai risultati, puoi decidere se eseguire una correzione manuale o contatta l'assistenza Google Cloud per ulteriore assistenza.

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 dell'amministratore kubeconfig del cluster.
- ADMIN_CLUSTER_CONFIG_FILE: il percorso dell'amministratore di configurazione del cluster.
- FLAGS: un insieme facoltativo di flag. Ad esempio, puoi includere il flag --skip-validation-infra per saltare della tua infrastruttura vSphere.
Il comando gkectl upgrade esegue i controlli preflight. Se i controlli preflight non riesce, il comando viene bloccato. Devi correggere gli errori o utilizzare il flag --skip-preflight-check-blocking con il comando per sbloccarla.
Se esegui l'upgrade alla versione 1.14.0 o successiva, viene creato un nuovo file kubeconfig generate per il cluster di amministrazione che sovrascrive qualsiasi file esistente. Per visualizzare dettagli del cluster nel file, esegui questo comando:
```
kubectl config view --kubeconfig ADMIN_CLUSTER_KUBECONFIG
```

Rimuovi l'intero bundle

Se hai scaricato un pacchetto completo e hai eseguito correttamente gkectl prepare e gkectl upgrade admin, devi eliminare i comandi un pacchetto completo 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 l'amministratore master con gkectl repair admin-master in seguito tentativo di upgrade non riuscito. Questo comporterà un errore nel cluster di amministrazione stato.

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 di nuovo il comando di upgrade, l'upgrade ripreso ricrea il cluster di amministrazione lo stato desiderato 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 eseguire l'upgrade alla versione di destinazione senza tentare di ripristinare il cluster di amministrazione della 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 corrente 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, il che consente di ridurre la frequenza di upgrade del cluster di amministrazione, se vuoi. 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 riesci a 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 di oggetti che non riesci a consentire eventuali interruzioni aggiuntive, l'upgrade dei nodi potrebbe non riuscire della versione del piano di controllo dopo ripetuti tentativi. Per evitare questo errore, ti consigliamo di fare lo scale up di Deployment o HorizontalPodAutoscaler per consenti lo svuotamento del nodo rispettando PodDisruptionBudget configurazione.

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, Google Distributed Cloud crea automaticamente VMware Pianificazione risorse distribuite (DRS) di regole di anti-affinità per i nodi del cluster utente, che vengono distribuiti su almeno tre host fisici nel tuo data center. A partire dalla versione 1.1.0-gke.6, questa funzionalità viene abilitata automaticamente per i nuovi cluster e per i cluster cluster.

Prima di eseguire l'upgrade, assicurati che il tuo ambiente vSphere soddisfi i seguenti requisiti condizioni:

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

Se il tuo ambiente vSphere non soddisfa le condizioni precedenti, puoi eseguire comunque l'upgrade, ma per l'upgrade di un cluster utente da 1.3.x a 1.4.x, è necessario per disattivare i gruppi anti-affinità. Per ulteriori informazioni, leggi 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 è inattivo, i piani di controllo e carichi di lavoro sui cluster utente continuano a essere eseguiti, a meno che non siano stati interessati un errore che ha causato il tempo di inattività.
Piano di controllo del cluster utente	In genere, non dovresti aspettarti tempi di inattività significativi per il cluster utente piani di controllo. Tuttavia, le connessioni a lunga esecuzione all'API Kubernetes potrebbe arrestarsi e deve essere ristabilito. In questi casi, il chiamante dell'API deve riprovare finché non stabilisce una connessione. Nella nel peggiore dei casi, durante un upgrade potrebbe verificarsi un tempo di inattività fino a un minuto. Nota: se i nodi del cluster utente non sono in grado di raggiungere la degli utenti durante l'upgrade, non vengono pianificati nuovi carichi di lavoro nel cluster. Esistente non sono interessati.
Nodi del cluster utente	Se un upgrade richiede una modifica dei nodi del cluster utente, Google Distributed Cloud ricrea i nodi in modo continuativo e ripianifica i pod in esecuzione su questi nodi. Puoi prevenire l'impatto sul tuo dei carichi di lavoro configurando PodDisruptionBudgets appropriati e le regole di anti-affinità.

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`