Anthos clusters on 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 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.

Questa pagina è rivolta agli amministratori IT e agli operatori che gestiscono ciclo di vita dell'infrastruttura tecnica sottostante. Per scoprire di più sui modelli ruoli e attività di esempio a cui facciamo riferimento nei contenuti di Google Cloud, vedi Ruoli e attività utente comuni di GKE Enterprise.

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

Panoramica dell'upgrade
Tra le altre cose, questo documento descrive lo scarto di versione e le regole di versione supportate 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

Nella versione 1.29 e successive, i controlli preliminari lato server sono abilitati per impostazione predefinita. I controlli preliminari lato server richiedono regole firewall aggiuntive. In Regole firewall per i cluster di amministratori, cerca "Controlli preliminari" e assicurati che tutte le regole firewall richieste siano 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. I controlli preflight lato server vengono eseguiti anche sul cluster amministrativo quando utilizzi la console Google Cloud, gcloud 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 transitorio è 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 dell'API Google e di IAM

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. 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 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 nel campo gkeConnect.projectID del 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 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 e generazione di 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 informazioni dettagliate sulle autorizzazioni incluse in questo ruolo, consulta Ruoli GKE on-premise nella documentazione 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 nella console. 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 maggiori 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. Tuttavia, dovrai eseguire l'upgrade della workstation di amministrazione quando sarà tutto pronto per 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 gestita dall'utente.

gkeadm

Individuare 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 tua workstation ha un file di informazioni. Il nome predefinito di questo file corrisponde al nome della tua workstation di amministrazione.

Individua il file di configurazione della workstation di amministrazione e il file delle informazioni. Devi eseguire i passaggi di 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 Rigenerare un file di informazioni se non è presente.

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

Gestita dall'utente

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

Scarica gkectl:

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

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

Scarica il pacchetto Google Distributed Cloud. Assicurati che la versione corrisponda uno usato per scaricare gkectl:

gcloud storage 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 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

Prepararsi a eseguire l'upgrade di un cluster utente

Esegui i seguenti passaggi sulla workstation di amministrazione:

Esegui gkectl prepare per importare le 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 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 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 inoltre che tu voglia eseguire l'upgrade del piano di controllo e di pool-1 alla versione 1.16.3-gke.45, ma che tu voglia mantenere pool-2 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 la procedura di upgrade. Sebbene le versioni precedenti di Google Distributed Cloud eseguino i 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 cluster di utenti 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 lo completa. Non è necessario osservare l'output del comando per l'intera durata dell'upgrade. In alternativa, puoi 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 restituisce messaggi di stato alla workstation di amministrazione man mano che l'upgrade procede.

Upgrade asincrono

Salta questo passaggio se stai eseguendo l'upgrade a una versione successiva alla 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 preparare la credenziale del registry privato, vedi Configurare le credenziali preparate per i cluster di utenti.
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.30.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 STATUS di RUNNING:

NAMESPACE             NAME    READY   STATE     AGE     VERSION
my-uc-gkeonprem-mgmt  my-uc   True    RUNNING   9h      1.30.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.30.0-gke.1

Risolvere i problemi di upgrade asincrono

Per un upgrade asincrono, la durata del timeout si basa sul numero di nodi del 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 qui indica che l'upgrade sta richiedendo più tempo del previsto, ma non è stato interrotto. 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, i pod non possono essere rimossi dai vecchi nodi e i vecchi nodi 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 è 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 vanno a buon fine, 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:

Salta questo passaggio se stai eseguendo l'upgrade a una versione successiva alla 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 generato un nuovo file kubeconfig per il cluster utente che sovrascrive qualsiasi file esistente. Per visualizzare i dettagli del cluster nel file, esegui il seguente comando:
```
kubectl config view --kubeconfig USER_CLUSTER_KUBECONFIG
```

Esegui l'upgrade di altri pool di nodi

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 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 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.

Riprendere un upgrade

Se un upgrade del 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 pacchetto 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 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 il 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. 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 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 relativi metadati. Se hai creato il cluster utilizzando un client API GKE On-Prem, questa è la regione selezionata 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.

Per un elenco delle versioni a cui puoi 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, viene eseguito l'upgrade del piano di controllo e di tutti i pool di nodi del cluster.
```
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 della patch più recente.

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 il seguente 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, 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 il seguente 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 ancora fatto, registra il cluster di amministrazione nell'API GKE On-Prem. Una volta registrato il cluster nell'API GKE On-Prem, non è necessario ripetere questo passaggio.

Per un elenco delle versioni a cui puoi 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 di utenti. Si tratta del progetto 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 viene eseguita l'API GKE On-Prem e in cui vengono archiviati i relativi metadati. Nel file main.tf che hai utilizzato per creare il cluster utente, la regione si trova nel campo location 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 esegui il deployment nel cluster amministrativo:
```
gcloud container vmware admin-clusters update ADMIN_CLUSTER_NAME \
  --project=PROJECT_ID \
  --location=REGION \
  --required-platform-version=VERSION
```
Questo comando scarica la versione dei componenti specificata in --required-platform-version nel cluster di amministrazione e poi esegue il deployment dei 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 del piano di controllo del cluster utente e lasciare tutti i pool di nodi nella versione corrente, 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 di utenti:
```
terraform apply
```

Esegui l'upgrade dei pool di nodi

Se hai scelto di eseguire l'upgrade solo del piano di controllo del cluster utente, svolgi i seguenti passaggi per eseguire l'upgrade di altri pool di nodi 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 di utenti:
```
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:

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 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. 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 nel file di configurazione del cluster di amministrazione corrisponda al percorso del bundle di cui vuoi eseguire l'upgrade.

Se apporti altre modifiche ai campi nel file di configurazione del cluster amministrativo, queste modifiche vengono ignorate durante l'upgrade. Per applicare queste modifiche, devi prima eseguire l'upgrade del cluster e poi 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:

Asincrona:
Con la variante asincrona, il comando avvia l'upgrade e quindi vengono completate. Non è necessario monitorare 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 variazione asincrona, includi il flag --async nel comando.

Requisiti per l'upgrade asincrono:
- Supportato solo per i cluster di amministratori HA con la versione 1.29 o successive.
- In tutti i cluster utente deve essere abilitato Controlplane 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
```
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.
Il comando precedente viene completato e puoi continuare a utilizzare il tuo e la workstation di amministrazione durante l'upgrade.

con gkectl upgrade admin, esegui questo comando:
```
gkectl upgrade admin -h
```
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.30.200-gke.101
```
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 amministrativo specificato, che include lo stato, le condizioni e gli eventi del cluster.

Registriamo gli eventi relativi all'inizio e alla 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.30.200-gke.101
```
Inoltre, al termine dell'upgrade, gkectl describe admin mostra un Last GKE On Prem Version campo in Status. Ad esempio:
```
Status:
  Cluster State:  RUNNING
  Last GKE On Prem Version:  1.30.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 passa da UPGRADING a ERROR e viene generato un evento che indica che l'operazione di upgrade ha superato il timeout. Tieni presente che lo stato ERROR in questo caso indica l'upgrade sta richiedendo più tempo del previsto, ma non è stato terminato. Il controller continua la riconciliazione e continua a riprovare l'operazione. Quando un upgrade è 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 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 \
```
Sostituisci quanto segue:
- ADMIN_CLUSTER_KUBECONFIG: il percorso dell'amministratore kubeconfig del cluster.
- ADMIN_CLUSTER_CONFIG_FILE: il percorso del file di configurazione del cluster di amministrazione.
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 i dettagli del cluster nel file, esegui il seguente comando:
```
kubectl config view --kubeconfig ADMIN_CLUSTER_KUBECONFIG
```

Rimuovi l'intero cofanetto

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

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 controllo del cluster di amministrazione contiene lo stato necessario per ripristinare lo stato precedente all'interruzione.

Avviso: non riparare il database principale dell'amministratore con gkectl repair admin-master dopo un tentativo di upgrade non riuscito. Questo comporterà un errore nel cluster di amministrazione stato.

Segui questi passaggi:

Prima di iniziare il tentativo di upgrade iniziale, controlla se il piano di controllo dell'amministratore è in stato operativo. Consulta: Diagnosticare i problemi del cluster. Come discusso in quell'argomento, esegui il comando gkectl diagnose cluster per il cluster di amministrazione.
Se il piano di controllo amministrativo non è in stato operativo prima del tentativo di upgrade iniziale, ripara il piano di controllo amministrativo 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 utilizzati nel tentativo di upgrade precedente.

Quando esegui di nuovo il comando di upgrade, l'upgrade ripreso ricrea lo stato del cluster di amministrazione dal checkpoint ed esegue di nuovo 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 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 tornerà a fare affidamento sul piano di controllo amministrativo e, pertanto, quest'ultimo deve essere integro per poter procedere con l'upgrade. Dopo un upgrade riuscito, il checkpoint viene rigenerato.

Se gkectl esce in modo imprevisto durante l'upgrade di un cluster di amministrazione, il cluster di tipo non viene ripulito. Prima di riavviare 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 con le 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 è admin-ws-config.yaml predefinito. 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.

Installare 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 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.
```
gcloud storage 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 ed è denominato 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 dalla piattaforma Google Cloud sulla 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 del cluster disponibili 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.

Risolvere i problemi del processo di upgrade

Se riscontri un problema durante 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 stia procedendo con la procedura di upgrade consigliata.

Vedi anche Risoluzione dei problemi relativi alla creazione e all'upgrade dei cluster

Risoluzione dei problemi di upgrade del cluster utente

Supponiamo che tu stia eseguendo l'upgrade di un cluster utente e riscontri un problema con la versione di upgrade. Dall'Assistenza Google viene stabilito che il problema verrà risolto in una release di patch imminente. Puoi procedere nel seguente modo:

Continua a utilizzare la versione corrente 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 della release della patch.

Risoluzione di un problema di upgrade del cluster di amministrazione

Se riscontri un problema durante l'upgrade del cluster amministrativo, devi contattare l'Assistenza Google per risolvere il problema.

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 nella versione precedente e continua a ricevere le patch di sicurezza.
Testa l'upgrade del cluster di amministrazione dalla versione 1.11.x alla versione 1.12.x in un ambiente di test e segnala eventuali problemi.
Se il problema viene risolto da una release con patch 1.12.x, puoi scegliere di eseguire l'upgrade del cluster di amministrazione di produzione a questa release con patch, se vuoi.

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 di dati è quasi pieno, perché il sistema tenta di eseguire il backup della workstation di amministrazione attuale localmente 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, 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 regole anti-affinità Distributed Resource Scheduler (DRS) di VMware per i nodi del cluster utente, in modo da distribuirli su almeno tre host fisici del 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 versione della licenza vSphere Enterprise Plus. 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 comunque eseguire l'upgrade, ma per eseguire l'upgrade di un cluster utente dalla versione 1.3.x alla versione 1.4.x, devi disattivare i gruppi di antiaffinità. Per ulteriori informazioni, leggi questo problema noto nelle note di rilascio di Google Distributed Cloud.

Informazioni sul tempo 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à.
Control plane del cluster utente	In genere, non dovresti aspettarti tempi di inattività significativi per il cluster utente piani di controllo. Tuttavia, le connessioni di lunga durata al server API Kubernetes potrebbero interrompersi e dover essere ristabilite. 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 riescono a raggiungere il piano di controllo utente durante l'upgrade, i nuovi carichi di lavoro non vengono pianificati nel cluster. I carichi di lavoro esistenti 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 evitare l'impatto sui tuoi workload configurando PodDisruptionBudget 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 che corrisponda al nome 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 dell'API Google e di IAM

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

Individuare 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

Prepararsi a eseguire l'upgrade di un cluster utente

Esecuzione di controlli preliminari

Esegui gkectl upgrade cluster

Upgrade asincrono

Risolvere i problemi di upgrade asincrono

Upgrade sincrono

Esegui l'upgrade di altri pool di nodi

Riprendere 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 cofanetto

Ripresa dell'upgrade di un cluster di amministrazione

Esegui il rollback di una workstation di amministrazione dopo un upgrade

Installare il bundle con una versione diversa per l'upgrade

Risolvere i problemi del processo di upgrade

Risoluzione dei problemi 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 sul tempo di inattività durante gli upgrade

Ricrea un file di informazioni, se mancante

Passaggi successivi

Esegui `gkectl upgrade cluster`

Esegui `gkectl upgrade admin`