Upgrade di GKE su VMware

Questa pagina spiega come eseguire l'upgrade di GKE su VMware. Questa pagina fornisce i passaggi per eseguire l'upgrade della workstation di amministrazione, del cluster utente e del cluster di amministrazione. Per i cluster utente, questa pagina fornisce i passaggi per eseguire l'upgrade del piano di controllo e dei pool di nodi contemporaneamente o separatamente.

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

  • Panoramica dell'upgrade
    Tra le altre cose, questo documento descrive il disallineamento delle versioni e le regole delle versioni 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.

Requisiti IAM per l'upgrade dei cluster utente

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

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

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

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

  • roles/gkehub.viewer. Questo ruolo consente agli utenti di visualizzare i cluster nella console. Per maggiori dettagli sulle autorizzazioni incluse in questo ruolo o per concedere un ruolo con autorizzazioni di lettura/scrittura, consulta Ruoli dell'hub GKE nella documentazione di IAM.

Esegui l'upgrade della workstation di amministrazione

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

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

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

Individua il file di configurazione della workstation di amministrazione e il file delle informazioni. Ti serviranno per eseguire l'upgrade. Se questi file si trovano nella directory attuale e hanno i nomi predefiniti, non dovrai specificarli quando esegui i comandi di upgrade. Se questi file si trovano in un'altra directory o se hai modificato i nomi dei file, puoi specificarli utilizzando i flag --config e --info-file.

Se il file delle informazioni di output non è presente, puoi ricrearlo. Consulta la pagina Ricreare un file di informazioni, se mancante.

Per eseguire l'upgrade della workstation di amministrazione:

  1. 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 GKE su VMware, consulta Cronologia delle versioni.

  2. Esegui l'upgrade della workstation di amministrazione:

    gkeadm upgrade admin-workstation --config AW_CONFIG_FILE \
    --info-file INFO_FILE

    Sostituisci quanto segue:

    • AW_CONFIG_FILE: il percorso del file di configurazione della workstation di amministrazione. Puoi omettere questo flag se il file si trova nella directory attuale e si chiama 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 workstation di amministrazione.

    Il comando precedente esegue le seguenti attività:

    • Esegue il backup di tutti i file nella home directory della workstation di amministrazione attuale. Questi includono:

      • Il file di configurazione del cluster di amministrazione. Il nome predefinito è admin-cluster.yaml.
      • Il file di configurazione del cluster utente. Il nome predefinito è user-cluster.yaml.
      • I file kubeconfig per il cluster di amministrazione e i cluster utente.
      • Il certificato radice per il server vCenter. Tieni presente che questo file deve disporre dell'autorizzazione di lettura e scrittura del proprietario.
      • Il file della chiave JSON per il tuo account di servizio di accesso ai componenti. Tieni presente che questo file deve disporre dell'autorizzazione di lettura e scrittura del proprietario.
      • I file di chiavi JSON per i tuoi account di servizio Connect-registra e logging-monitoring.

    • Crea una nuova workstation di amministrazione e copia tutti i file di cui è stato eseguito il backup nella nuova workstation di amministrazione.

    • Elimina la workstation di amministrazione precedente.

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 attuale e le versioni disponibili per l'upgrade.

Se prevedi di utilizzare la console, gcloud CLI o Terraform per l'upgrade, saranno necessari circa 7-10 giorni dopo il rilascio prima che la versione sia disponibile nell'API GKE On-Prem in tutte le regioni di Google Cloud. La console elenca solo le versioni disponibili per l'upgrade del cluster utente. I passaggi per eseguire l'upgrade di un cluster utente utilizzando gcloud CLI o Terraform includono un passaggio per eseguire gcloud container vmware clusters query-version-config al fine di 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

Preparati per l'upgrade di un cluster utente

Segui questi passaggi sulla workstation di amministrazione:

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

  2. Se il cluster ha un pool di nodi Windows, esegui gkectl prepare windows e aggiorna il campo osImage per il pool di nodi. Per istruzioni dettagliate, consulta Eseguire l'upgrade del cluster utente con i pool di nodi Windows.

  3. Nel file di configurazione del cluster utente, imposta gkeOnPremVersion sulla versione di destinazione dell'upgrade.

  4. Solo pool di nodi Ubuntu e COS: specifica i pool di nodi che 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 quali pool di nodi vuoi eseguire l'upgrade, come segue:

    • Per ogni pool di nodi di cui vuoi eseguire l'upgrade, rimuovi il campo nodePools.nodePool[i].gkeOnPremVersion o impostalo sulla stringa vuota.

    • Per ogni pool di nodi di cui non vuoi eseguire l'upgrade, imposta nodePools.nodePool[i].gkeOnPremVersion sulla versione attuale.

    Ad esempio, supponiamo che il tuo cluster utente abbia la 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 di pool-1 alla versione 1.16.3-gke.45, ma vuoi che pool-2 rimanga alla versione 1.15.5-gke.41. La parte seguente di un file 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

Esegui gkectl upgrade cluster

Esistono due varianti del comando gkectl upgrade cluster:

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

  • Sincrono:
    con la variante sincrona, il comando gkectl upgrade cluster invia messaggi di stato alla workstation di amministrazione durante l'avanzamento dell'upgrade.

Upgrade asincrono

  1. Sulla workstation di amministrazione, avvia un upgrade asincrono:

    gkectl upgrade cluster \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --config USER_CLUSTER_CONFIG \
  --async

    Il comando precedente viene completato e puoi continuare a utilizzare la tua workstation di amministrazione durante l'upgrade.

  2. 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 in fase di upgrade, il valore di STATE è UPGRADING. Ad esempio:

    NAMESPACE             NAME    READY   STATE       AGE   VERSION
my-uc-gkeonprem-mgmt  my-uc   False   UPGRADING   9h    1.15.0-gke.1

    I valori possibili per STATE sono PROVISIONING, UPGRADING, DELETING, UPDATING, RUNNING, RECONCILING, ERROR e UNKNOWN.

  3. Per maggiori dettagli sull'avanzamento dell'upgrade e sugli eventi del cluster:

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

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

    Registriamo gli eventi per l'inizio e la fine di ogni fase critica di 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

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

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

    Inoltre, al termine dell'upgrade, gkectl describe clusters mostra un campo LastGKEOnPremVersion in Status. Ad esempio:

    Status:
Cluster State:  RUNNING
LastGKEOnOremVersion:  1.15.0-gke.1

Risoluzione dei 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 e un evento indica che l'operazione di upgrade è scaduta. Tieni presente che lo stato ERROR in questo caso indica che l'upgrade sta richiedendo più tempo del previsto, ma non è stato terminato. Il controller continua la riconciliazione e continua a ripetere l'operazione.

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

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 verificare la presenza di problemi comuni del cluster. In base al risultato, puoi decidere se eseguire una correzione manuale o contattare il team di assistenza Anthos per ulteriore supporto.

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 o utilizzare il flag --skip-preflight-check-blocking. Dovresti saltare i controlli preflight solo se hai la certezza che non ci siano errori critici.

Procedi con i seguenti passaggi sulla workstation di amministrazione:

  1. Esegui l'upgrade del cluster:

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

  2. Se esegui l'upgrade alla versione 1.14.0 o successive, viene generato un nuovo file kubeconfig per il cluster utente che sovrascrive qualsiasi file esistente. Per visualizzare i dettagli del cluster nel file, esegui questo comando:

    kubectl config view --kubeconfig USER_CLUSTER_KUBECONFIG

Esegui l'upgrade di pool di nodi aggiuntivi

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

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

  2. 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 tuo cluster di amministrazione

    • USER_CLUSTER_CONFIG: il percorso del file di configurazione del cluster utente

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

Riprendi un upgrade

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

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

Console

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

  • Registra il cluster di amministrazione nell'API GKE On-Prem, se non è già registrato.

  • Scarica ed esegue il deployment di un bundle di componenti nel cluster di amministrazione. La versione dei componenti corrisponde alla versione 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:

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

    Vai ai cluster GKE

  2. Seleziona il progetto Google Cloud, quindi il cluster di cui vuoi eseguire l'upgrade.

  3. Nel riquadro Dettagli, fai clic su Ulteriori dettagli.

  4. Nella sezione Impostazioni di base del cluster, fai clic su Esegui l'upgrade.

  5. Nell'elenco Scegli la versione di destinazione, seleziona la versione a cui vuoi eseguire l'upgrade. L'elenco selezionato contiene solo le ultime release delle patch.

  6. Fai clic su Esegui l'upgrade.

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

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

Interfaccia a riga di comando gcloud

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

  • Registra il cluster di amministrazione nell'API GKE On-Prem, se non è già registrato.

  • Scarica ed esegue il deployment di un bundle di componenti nel cluster di amministrazione. La versione dei componenti corrisponde alla versione 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:

  1. Aggiorna i componenti di Google Cloud CLI:

    gcloud components update

  2. Solo pool di nodi Ubuntu e COS: se vuoi eseguire l'upgrade solo del piano di controllo del cluster utente e lasciare che tutti i pool di nodi rimangano alla versione attuale, modifica il criterio di upgrade sul cluster:

    gcloud container vmware clusters update USER_CLUSTER_NAME \
  --project=PROJECT_ID \
  --location=REGION \
  --upgrade-policy control-plane-only=True

    Sostituisci quanto segue:

    • USER_CLUSTER_NAME: il nome del cluster utente di cui eseguire l'upgrade.

    • PROJECT_ID: l'ID del progetto host del parco risorse in cui il cluster utente è membro. Questo è il progetto che hai specificato al momento della creazione del cluster. Se hai creato il cluster utilizzando gkectl, questo è l'ID progetto nel campo gkeConnect.projectID del file di configurazione del cluster.

    • REGION: la regione Google Cloud in cui l'API GKE On-Prem esegue e archivia i 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 quando hai registrato il cluster nell'API GKE On-Prem.

  3. Ottieni un elenco delle versioni disponibili per l'upgrade a:

    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 esegui l'upgrade è installata sul cluster di amministrazione. Il comando upgrade scarica ed esegue il deployment di un bundle di componenti che corrisponde alla versione specificata nel comando upgrade.

  4. Esegui l'upgrade del cluster. Se hai eseguito il comando update per modificare il criterio di upgrade in control-plane-only=True, verrà eseguito solo l'upgrade del piano di controllo del cluster. In caso contrario, viene eseguito l'upgrade del piano di controllo del cluster e di tutti i pool di nodi.

    gcloud container vmware clusters upgrade USER_CLUSTER_NAME \
  --project=PROJECT_ID \
  --location=REGION \
  --version=VERSION

    Sostituisci VERSION con la versione di GKE su VMware di cui vuoi eseguire l'upgrade. Specifica una versione dall'output del comando precedente. Ti consigliamo di eseguire l'upgrade alla versione più recente della patch.

    L'output del comando è simile al seguente:

    Waiting for operation [projects/example-project-12345/locations/us-west1/operations/operation-1679543737105-5f7893fd5bae9-942b3f97-75e59179] to complete.

    Nell'output di esempio, la stringa operation-1679543737105-5f7893fd5bae9-942b3f97-75e59179 è la stringa OPERATION_ID dell'operazione a lunga esecuzione. Puoi trovare lo stato dell'operazione eseguendo il comando seguente in un'altra finestra del terminale:

    gcloud container vmware operations describe OPERATION_ID \
  --project=PROJECT_ID \
  --location=REGION

Esegui l'upgrade dei pool di nodi

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

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

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

  1. Aggiorna i componenti di Google Cloud CLI:

    gcloud components update

  2. Se non lo hai già fatto, registra il cluster di amministrazione nell'API GKE On-Prem. Dopo aver registrato il cluster nell'API GKE On-Prem, non devi eseguire di nuovo questo passaggio.

  3. Ottieni un elenco delle versioni disponibili per l'upgrade a:

    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 in cui il cluster utente è membro. Questo è il progetto che hai specificato al momento della creazione del cluster. Se hai creato il cluster utilizzando gkectl, questo è l'ID progetto nel campo gkeConnect.projectID del file di configurazione del cluster.

    • REGION: la regione Google Cloud in cui l'API GKE On-Prem esegue e archivia i relativi metadati. Nel file main.tf che hai utilizzato per creare il cluster utente, la regione si trova nel campo location della risorsa cluster.

    L'output del comando è simile al seguente:

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

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

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

  4. Scarica la nuova versione dei componenti e implementali nel cluster di amministrazione:

    gcloud vmware admin-clusters update ADMIN_CLUSTER_NAME \
  --project=PROJECT_ID \
  --location=REGION \
  --required-platform-version=VERSION

    Questo comando scarica la versione dei componenti specificati in --required-platform-version nel cluster di amministrazione, quindi esegue il deployment dei componenti. Questi componenti consentono al cluster di amministrazione di gestire i cluster utente in quella versione.

  5. Nel file main.tf che hai utilizzato per creare il cluster utente, imposta on_prem_version nella risorsa cluster alla nuova versione.

  6. Solo pool di nodi Ubuntu e COS: se vuoi eseguire l'upgrade solo del piano di controllo del cluster utente e lasciare che tutti i pool di nodi rimangano alla versione attuale, aggiungi quanto segue alla risorsa cluster:

    upgrade_policy {
  control_plane_only = true
}

  7. Inizializza e crea il piano Terraform:

    terraform init

    Terraform installa tutte le librerie necessarie, come il provider Google Cloud.

  8. Rivedi la configurazione e apporta modifiche, se necessario:

    terraform plan

  9. Applica il piano Terraform per creare il cluster utente:

    terraform apply

Esegui l'upgrade dei pool di nodi

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

  1. 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"
}

  2. Inizializza e crea il piano Terraform:

    terraform init

  3. Rivedi la configurazione e apporta modifiche, se necessario:

    terraform plan

  4. Applica il piano Terraform per creare il cluster utente:

    terraform apply

Esegui l'upgrade del cluster di amministrazione

Prima di iniziare:

  • Determina se i certificati sono aggiornati e rinnovali, se necessario.

  • Se esegui l'upgrade alla versione 1.13 o successive, devi prima registrare il cluster di amministrazione compilando la sezione gkeConnect nel file di configurazione del cluster di amministrazione. Esegui il comando update cluster con le modifiche al file di configurazione.

Esegui i passaggi descritti in questa sezione sulla nuova workstation di amministrazione. Assicurati che gkectl e i cluster siano la versione appropriata per un upgrade e di aver scaricato il bundle appropriato.

  1. Assicurati che il campo bundlepath nel file di configurazione del cluster di amministrazione corrisponda al percorso del bundle a cui vuoi eseguire l'upgrade.

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

  2. Esegui questo comando:

    gkectl upgrade admin \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG_FILE \
    FLAGS

    Sostituisci quanto segue:

    • ADMIN_CLUSTER_KUBECONFIG: il file kubeconfig del cluster di amministrazione.

    • ADMIN_CLUSTER_CONFIG_FILE: il file di configurazione del cluster di amministrazione di GKE su VMware sulla nuova workstation di amministrazione.

    • FLAGS: un insieme facoltativo di flag. Ad esempio, potresti includere il flag --skip-validation-infra per saltare il controllo dell'infrastruttura vSphere.

Se esegui l'upgrade alla versione 1.14.0 o successive, viene generato un nuovo file kubeconfig per il cluster di amministrazione che sovrascrive qualsiasi file esistente. Per visualizzare i dettagli del cluster nel file, esegui questo comando:

  kubectl config view --kubeconfig ADMIN_CLUSTER_KUBECONFIG

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

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 va a buon fine, è possibile riprenderlo se il checkpoint del cluster di amministrazione contiene lo stato necessario per ripristinare lo stato prima dell'interruzione.

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

Segui questi passaggi:

  1. Verifica che il piano di controllo dell'amministratore sia integro prima di iniziare il tentativo di upgrade iniziale. Consulta la pagina Diagnostica dei problemi del cluster. Come discusso nell'argomento, esegui il comando gkectl diagnose cluster per il cluster di amministrazione.

  2. Se il piano di controllo dell'amministratore non è integro prima del tentativo di upgrade iniziale, riparalo con il comando gkectl repair admin-master.

  3. Quando esegui nuovamente il comando di upgrade dopo che l'upgrade è stato interrotto o non è riuscito, utilizza lo stesso bundle e la stessa versione di destinazione che hai usato nel precedente tentativo di upgrade.

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

L'upgrade riprenderà dal punto in cui non è riuscito o è stato chiuso se il checkpoint del cluster di amministrazione è disponibile. Se il checkpoint non è disponibile, l'upgrade si baserà nuovamente sul piano di controllo di amministrazione. Di conseguenza, per procedere con l'upgrade, quest'ultimo deve essere in stato integro. Dopo un upgrade riuscito, il checkpoint viene rigenerato.

Se gkectl si chiude in modo imprevisto durante l'upgrade di un cluster di amministrazione, il cluster di tipo non viene pulito. Prima di eseguire nuovamente 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 tipo, esegui nuovamente 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 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:

  1. Scarica la versione di rollback di gkeadm.
  2. Esegue il backup della home directory della workstation di amministrazione attuale.
  3. Crea una nuova workstation di amministrazione utilizzando la versione di rollback di gkeadm.
  4. 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, ovvero la versione a cui vuoi eseguire l'upgrade.

  1. Per verificare le versioni attuali di gkectl e del cluster, esegui questo comando. Per informazioni più dettagliate, utilizza il flag --details/-d.

    gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG --details

    L'output fornisce informazioni sulle versioni del cluster.

  2. In base all'output ottenuto, 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 sia 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 arrivi alla versione 1.11.x, quindi procedi seguendo le istruzioni riportate in questo argomento.

    • Se la versione di gkectl è precedente a quella di TARGET_VERSION, esegui l'upgrade della workstation di amministrazione a TARGET_VERSION.

  3. Quando hai 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à nella workstation di amministrazione.

    stat /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz

    Se il bundle non si trova nella 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/

  4. Installa il bundle.

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

    Sostituisci ADMIN_CLUSTER_KUBECONFIG con il percorso del file kubeconfig. Puoi omettere questo flag se il file si trova nella directory attuale e ha il nome kubeconfig.

  5. Elenca le versioni disponibili dei cluster e assicurati che la versione di destinazione sia inclusa tra quelle disponibili dei cluster utente.

    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 segui la procedura di upgrade consigliata, segui questi consigli per risolverli. Questi suggerimenti presuppongono che tu abbia iniziato con una configurazione della versione 1.11.x e che tu stia continuando il processo di upgrade consigliato.

Vedi anche: Risolvere i problemi relativi alla creazione e all'upgrade del cluster

Risoluzione di un problema di upgrade del cluster utente

Supponi di riscontrare un problema con la versione dell'upgrade durante l'upgrade di un cluster utente. Stabilisci dall'Assistenza Google che il problema verrà risolto in una release patch futura. Puoi procedere come segue:

  1. Continua a utilizzare la versione corrente per la produzione.
  2. Testa la release della patch in un cluster non di produzione quando viene rilasciata.
  3. Esegui l'upgrade di tutti i cluster utente di produzione alla versione di rilascio della patch quando hai la certezza.
  4. Esegui l'upgrade del cluster di amministrazione alla versione di rilascio 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 risolverlo.

Nel frattempo, con il nuovo flusso di upgrade, puoi comunque trarre vantaggio dalle nuove funzionalità dei cluster utente senza essere bloccato dall'upgrade del cluster di amministrazione, il che ti consente di ridurre la frequenza di upgrade del cluster di amministrazione, se vuoi. Il processo di upgrade può procedere come segue:

  1. Esegui l'upgrade dei cluster utente di produzione a 1.12.x.
  2. Mantieni la versione precedente del cluster di amministrazione e continua a ricevere patch di sicurezza.
  3. Testare l'upgrade del cluster di amministrazione da 1.11.x a 1.12.x in un ambiente di test e segnalare eventuali problemi.
  4. Se il problema viene risolto con una release patch 1.12.x, puoi scegliere di eseguire l'upgrade del cluster di amministrazione di produzione a questa release patch, se vuoi.

Problemi noti relativi alle versioni recenti

I seguenti problemi noti potrebbero influire sugli upgrade se esegui l'upgrade dalla versione 1.7 o successiva.

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 dell'attuale workstation di amministrazione in locale durante l'upgrade a una nuova workstation di amministrazione. Se non riesci a liberare spazio sufficiente sul disco dati, usa il comando gkectl upgrade admin-workstation con il flag aggiuntivo --backup-to-local=false per evitare di eseguire un backup locale della workstation di amministrazione attuale.

Interruzione dei carichi di lavoro con PodDisruptionBudgets

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

I nodi non riescono a completare il processo di upgrade

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

Per visualizzare tutti gli oggetti PodDisruptionBudget che non consentono interruzioni:

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

Appendice

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

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

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

Se il tuo ambiente vSphere non soddisfa le condizioni precedenti, puoi comunque eseguire l'upgrade, ma per eseguire l'upgrade di un cluster utente da 1.3.x a 1.4.x, devi disabilitare i gruppi anti-affinità. Per maggiori informazioni, consulta questo problema noto nelle note di rilascio di GKE su VMware.

Informazioni sul tempo di inattività durante gli upgrade

Risorsa Descrizione
Cluster di amministrazione

Quando un cluster di amministrazione non è attivo, i piani di controllo e i carichi di lavoro dei cluster utente continuano a essere eseguiti, a meno che non siano stati interessati da un errore che ha causato il tempo di inattività.
Piano di controllo del cluster utente

In genere, non dovresti aspettarti tempi di inattività significativi per i piani di controllo dei cluster utente. Tuttavia, le connessioni a lunga esecuzione al server API Kubernetes potrebbero interrompersi e dovrebbero essere ristabilite. In questi casi, il chiamante dell'API deve riprovare fino a quando non stabilisce una connessione. Nel peggiore dei casi, durante un upgrade può verificarsi fino a un minuto di tempo di inattività.
Nodi del cluster utente

Se un upgrade richiede una modifica ai nodi dei cluster utente, GKE su VMware ricrea i nodi in modo continuativo e ripianifica i pod in esecuzione su questi nodi. Puoi prevenire l'impatto sui carichi di lavoro configurando PodDisruptionBudgets e regole di anti-affinità appropriati.

Ricrea un file di informazioni, se mancante

Se il file delle informazioni di output per la workstation di amministrazione non è presente, è necessario ricrearlo per poter procedere con l'upgrade. Questo file è stato creato quando hai creato inizialmente la workstation e, se in seguito hai eseguito un upgrade, è stato aggiornato con nuove informazioni.

Il file delle informazioni di output ha il seguente 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 con le 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