Upgrade di cluster Anthos su VMware

Questa pagina spiega come eseguire l'upgrade dei cluster Anthos su VMware (GKE On-Prem).

La procedura di upgrade è cambiata in modo significativo a partire dalla versione 1.7.

Panoramica dell'upgrade per la versione 1.7

Puoi eseguire l'upgrade direttamente a qualsiasi versione nella stessa release secondaria o nella release secondaria successiva. Ad esempio, puoi eseguire l'upgrade da 1.7.0 a 1.7.3 o da 1.6.1 a 1.7.0.

Se esegui l'upgrade a una versione che non fa parte della prossima release secondaria, devi eseguire l'upgrade da una versione di ogni release secondaria tra la versione corrente e la versione desiderata. Ad esempio, se esegui l'upgrade dalla versione 1.5.2 alla versione 1.7.0, non è possibile eseguire direttamente l'upgrade. Devi prima eseguire l'upgrade dalla versione 1.5.2 alla versione 1.6.x e quindi eseguire l'upgrade alla versione 1.7.0.

Innanzitutto, esegui l'upgrade della workstation di amministrazione, quindi dei cluster utente e, infine, del cluster di amministrazione. Non è necessario eseguire l'upgrade del cluster di amministrazione subito dopo l'upgrade del cluster utente se vuoi mantenere il cluster di amministrazione nella versione attuale.

  1. Scarica lo strumento gkeadm. La versione di gkeadm deve essere uguale alla versione di destinazione dell'upgrade.
  2. Esegui l'upgrade della workstation di amministrazione.
  3. Dalla workstation di amministrazione, esegui l'upgrade dei cluster utente.
  4. Dalla workstation di amministrazione, esegui l'upgrade del cluster di amministrazione.
  • Il cluster di amministrazione utilizza la versione 1.6.x e i cluster utente la versione 1.6.x o 1.7.
  • In alternativa, sia il cluster di amministrazione che i cluster utente utilizzano la versione 1.7.

Supponi che la tua workstation di amministrazione, il cluster di amministrazione e i cluster utente utilizzino attualmente la versione 1.6.2 e che tu voglia eseguire l'upgrade del tuo cluster di amministrazione e dei tuoi cluster utente alla versione 1.7. Se segui un percorso di upgrade come il seguente, con l'utilizzo di un cluster canary per i test prima di procedere oltre, riduci al minimo il rischio di interruzioni.

Di seguito è riportata una panoramica generale di un processo di upgrade consigliato. Prima di iniziare, crea un cluster utente canary che utilizza la versione 1.6.2, se non lo hai già fatto.

  1. Testa la versione 1.7 in un cluster canary.
    • Esegui l'upgrade della workstation di amministrazione a 1.7.
    • Esegui il comando gkectl prepare, come descritto di seguito, per configurare l'upgrade.
      • Esegui l'upgrade del cluster utente canary a 1.7.
  2. Esegui l'upgrade di tutti i cluster utente di produzione alla versione 1.7 quando hai dimestichezza con la versione 1.7.
  3. Esegui l'upgrade del cluster di amministrazione alla versione 1.7.

Individuare la configurazione e i file di informazioni per prepararsi all'upgrade

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

Inoltre, gkeadm ha creato un file informativo per te. Il nome predefinito di questo file corrisponde al nome della workstation di amministrazione corrente.

Individua il file di configurazione della workstation di amministrazione e il file delle informazioni. Devi seguire i passaggi illustrati in questa guida. Se questi file si trovano nella directory attuale e hanno i loro nomi predefiniti, non li dovrai specificare quando esegui i comandi di upgrade. Se i file si trovano in un'altra directory o se hai modificato i nomi file, li specifichi utilizzando i flag --config e --info-file.

Upgrade della workstation di amministrazione

Assicurati di avere gkectl e i cluster al livello della versione appropriato per un upgrade e di aver scaricato il bundle appropriato.

Upgrade della configurazione della workstation di amministrazione

gkeadm upgrade admin-workstation --config [AW_CONFIG_FILE] --info-file [INFO_FILE]

dove:

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

Il comando precedente esegue le attività seguenti:

  • Esegui il backup di tutti i file nella home directory della workstation di amministrazione corrente. Sono inclusi:

    • Il tuo file di configurazione Cluster Anthos su VMware. Il nome predefinito di questo file è config.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 avere l'autorizzazione di lettura e scrittura del proprietario.

    • Il file della chiave JSON dell'account di servizio di accesso ai componenti. Tieni presente che questo file deve disporre dell'autorizzazione di lettura e scrittura del proprietario.

    • I file della chiave JSON per gli account di servizio Connect-Agent, connect-agent e logging-monitoring.

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

  • Elimina la vecchia workstation di amministrazione.

Verifica che siano disponibili indirizzi IP sufficienti

Esegui i passaggi descritti in questa sezione sulla nuova workstation di amministrazione.

Prima di eseguire l'upgrade, assicurati di avere a disposizione un numero sufficiente di indirizzi IP per i tuoi cluster. Puoi riservare ulteriori IP come necessario, come descritto per ciascuno di DHCP e IP statici.

DHCP

Quando esegui l'upgrade del cluster di amministrazione, i cluster Anthos su VMware creano un nodo temporaneo nel cluster di amministrazione. Quando esegui l'upgrade di un cluster utente, i cluster Anthos su VMware creano un nodo temporaneo nel cluster utente. Lo scopo del nodo temporaneo è garantire una disponibilità senza interruzioni. Prima di eseguire l'upgrade di un cluster, assicurati che il tuo server DHCP possa fornire indirizzi IP sufficienti per il nodo temporaneo. Per saperne di più, vedi Indirizzi IP necessari per cluster di amministrazione e utenti.

IP statici

Quando esegui l'upgrade del cluster di amministrazione, i cluster Anthos su VMware creano un nodo temporaneo nel cluster di amministrazione. Quando esegui l'upgrade di un cluster utente, i cluster Anthos su VMware creano un nodo temporaneo nel cluster utente. Lo scopo del nodo temporaneo è garantire una disponibilità senza interruzioni. Prima di eseguire l'upgrade di un cluster, verifica di aver prenotato un numero sufficiente di indirizzi IP. Per ogni cluster, devi prenotare almeno un indirizzo IP in più rispetto al numero di nodi del cluster. Per saperne di più, consulta Configurazione di indirizzi IP statici.

Determina il numero di nodi nel cluster di amministrazione:

kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] get nodes

dove [ADMIN_CLUSTER_KUBECONFIG] è il percorso del file kubeconfig del cluster di amministrazione.

Quindi, visualizza gli indirizzi riservati al cluster di amministrazione:

kubectl get cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -o yaml

Nell'output, nel campo reservedAddresses, puoi vedere il numero di indirizzi IP riservati ai nodi del cluster di amministrazione. Ad esempio, il seguente output mostra che sono presenti cinque indirizzi IP riservati per i nodi del cluster di amministrazione:

...
reservedAddresses:
- gateway: 21.0.135.254
  hostname: admin-node-1
  ip: 21.0.133.41
  netmask: 21
- gateway: 21.0.135.254
  hostname: admin-node-2
  ip: 21.0.133.50
  netmask: 21
- gateway: 21.0.135.254
  hostname: admin-node-3
  ip: 21.0.133.56
  netmask: 21
- gateway: 21.0.135.254
  hostname: admin-node-4
  ip: 21.0.133.47
  netmask: 21
- gateway: 21.0.135.254
  hostname: admin-node-5
  ip: 21.0.133.44
  netmask: 21

Il numero di indirizzi IP riservati deve essere almeno uno in più rispetto al numero di nodi nel cluster di amministrazione.

Per aggiungere gli indirizzi IP al cluster di amministrazione alla versione 1.7:

Innanzitutto, modifica il file di blocco IP, come mostrato in questo esempio.

blocks:
- netmask: "255.255.252.0"
  ips:
  - ip: 172.16.20.10
    hostname: admin-host1
  - ip: 172.16.20.11
    hostname: admin-host2
  # Newly-added IPs.
  - ip: 172.16.20.12
    hostname: admin-host3

Quindi, esegui questo comando per aggiornare la configurazione.

gkectl update admin --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] --config [ADMIN_CONFIG_FILE]
  • [ADMIN_CLUSTER_KUBECONFIG] è il percorso del file kubeconfig.

  • [ADMIN_CONFIG_FILE] è il percorso del file di configurazione dell'amministratore. Puoi omettere questo flag se il file si trova nella directory attuale e ha il nome admin-config.yaml.

Non puoi rimuovere gli indirizzi IP, ma solo aggiungerli.

Per le versioni precedenti alla 1.7, puoi aggiungere un indirizzo aggiuntivo modificando direttamente l'oggetto Cluster.

Apri l'oggetto Cluster per la modifica:

kubectl edit cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG]

In reservedAddresses, aggiungi un blocco aggiuntivo con gateway, hostname, ip e netmask.

Importante: a partire dalla versione 1.5.0, la stessa procedura non funziona per i cluster utente e devi utilizzare gkectl update cluster per ciascuno di essi.

Per determinare il numero di nodi in un cluster utente:

kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] get nodes

dove [USER_CLUSTER_KUBECONFIG] è il percorso del file kubeconfig del cluster utente.

Per visualizzare gli indirizzi riservati a un cluster utente:

kubectl get cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
-n [USER_CLUSTER_NAME] [USER_CLUSTER_NAME] -o yaml

dove:

  • [ADMIN_CLUSTER_KUBECONFIG] è il percorso del file kubeconfig del cluster di amministrazione.

  • [USER_CLUSTER_NAME] è il nome del cluster utente.

Il numero di indirizzi IP riservati deve essere almeno uno superiore al numero di nodi nel cluster utente. In caso contrario, puoi aprire il file di blocco IP del cluster utente per modificarlo:

  • Se uno degli indirizzi riservati a un cluster utente è incluso nel file di blocco IP, aggiungilo al blocco corrispondente in base a netmask e gateway.

  • Aggiungi tutti gli indirizzi IP statici aggiuntivi che vuoi al blocco corrispondente, quindi esegui gkectl update cluster.

(Facoltativo) Disattivare le nuove funzionalità di vSphere

Una nuova versione di Cluster Anthos su VMware potrebbe includere nuove funzionalità o supporto per specifiche funzionalità VMware vSphere. A volte, l'upgrade a una versione di Cluster Anthos su VMware abilita automaticamente tali funzionalità. Scopri di più sulle nuove funzionalità nei cluster Anthos sulle note di rilascio di VMware. A volte, le nuove funzionalità vengono visualizzate nel file di configurazione dei cluster Anthos su VMware.

Se devi disabilitare una nuova funzionalità abilitata automaticamente in una nuova versione di cluster Anthos su VMware e basata sul file di configurazione, esegui i passaggi seguenti prima di eseguire l'upgrade del cluster:

  1. Dalla workstation di amministrazione aggiornata, crea un nuovo file di configurazione con un nome diverso da quello in uso:

    gkectl create-config --config [CONFIG_NAME]
  2. Apri il nuovo file di configurazione e prendi nota del campo della funzionalità. Chiudi il file.

  3. Apri il file di configurazione corrente e aggiungi il campo della nuova funzionalità. Imposta il valore del campo su false o equivalente.

  4. Salva il file di configurazione.

Controlla le Note di rilascio prima di eseguire l'upgrade dei cluster. Non puoi modificare in modo dichiarativo una configurazione di un cluster esistente dopo aver eseguito l'upgrade.

Installa bundle per l'upgrade

Per rendere disponibile una versione per la creazione o l'upgrade del cluster, devi installare il bundle corrispondente. Segui questi passaggi per installare un bundle per TARGET_VERSION, che è il numero della versione a cui vuoi eseguire l'upgrade.

Per controllare le versioni correnti di gkectl e del cluster, esegui questo comando. Utilizza il flag --details/-d per informazioni più dettagliate.

gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG --details

Ecco un esempio di output:

gkectl version: 1.7.2-gke.2 (git-5b8ef94a3)onprem user cluster controller version: 1.6.2-gke.0
current admin cluster version: 1.6.2-gke.0
current user cluster versions (VERSION: CLUSTER_NAMES):
- 1.6.2-gke.0: user-cluster1
available admin cluster versions:
- 1.6.2-gke.0
available user cluster versions:
- 1.6.2-gke.0
- 1.7.2-gke.2
Info: The admin workstation and gkectl is NOT ready to upgrade to "1.8" yet, because there are "1.6" clusters.
Info: The admin cluster can't be upgraded to "1.7", because there are still "1.6" user clusters.

In base all'output ottenuto, cerca i problemi seguenti e correggili se necessario.

  • Se la versione di gkectl è precedente alla 1.7, il nuovo flusso di upgrade non è disponibile direttamente. Segui il flusso di upgrade originale per eseguire l'upgrade di tutti i tuoi cluster alla versione 1.6, quindi esegui l'upgrade della tua workstation di amministrazione alla versione 1.7 per iniziare a utilizzare il nuovo flusso di upgrade.

  • Se la versione corrente del cluster di amministrazione è superiore a una versione secondaria rispetto a TARGET_VERSION, esegui l'upgrade di tutti i cluster in modo che sia una versione secondaria precedente a TARGET_VERSION.

  • Se la versione di gkectl è precedente alla TARGET_VERSION, esegui l'upgrade della workstation di amministrazione a TARGET_VERSION, seguendo le istruzioni.

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à 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/

Installa il bundle.

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

dove:

  • [ADMIN_CLUSTER_KUBECONFIG] è il percorso del file kubeconfig. Puoi omettere questo flag se il file si trova nella directory attuale e ha il nome kubeconfig.

Elenca le versioni disponibili del cluster e assicurati che la versione di destinazione sia inclusa nelle versioni del cluster utente disponibili.

gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG --details

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

Upgrade di un cluster utente

Esegui i passaggi descritti in questa sezione sulla workstation di amministrazione.

gkectl upgrade cluster \
    --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
    --config [USER_CLUSTER_CONFIG_FILE] \
    [FLAGS]

dove:

  • [ADMIN_CLUSTER_KUBECONFIG] è il file kubeconfig del cluster di amministrazione.

  • [USER_CLUSTER_CONFIG_FILE] è il file di configurazione del cluster utente Anthos cluster su VMware sulla tua nuova workstation di amministrazione.

  • [FLAGS] è un insieme facoltativo di flag. Ad esempio, puoi includere il flag --skip-validation-infra per saltare il controllo della tua infrastruttura vSphere.

Ripresa dell'upgrade

Se un upgrade del cluster utente viene interrotto, puoi riprendere l'upgrade del cluster utente 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

Upgrade del cluster di amministrazione

Esegui i passaggi descritti in questa sezione sulla nuova workstation di amministrazione. Assicurati di avere il livello di versione appropriato per un upgrade in gkectl e nei cluster e di aver scaricato il bundle appropriato.

La versione target dell'upgrade non deve essere successiva alla versione gkectl e non deve contenere più di una versione secondaria precedente alla versione gkectl. Pertanto, se la versione di gkectl è la 1.7, la versione target per l'upgrade può essere la versione 1.6.x-1.7. È possibile eseguire l'upgrade del cluster di amministrazione a una versione secondaria solo quando è stato eseguito l'upgrade di tutti i cluster utente a quella versione secondaria. Ad esempio, se tenti di eseguire l'upgrade del cluster di amministrazione alla versione 1.7, quando sono ancora presenti i cluster utente 1.6.2, verrà visualizzato un errore:

admin cluster can't be upgraded to
"1.7.0-gke.0" yet, because there are still user clusters at "1.6.2-gke.0".

Esegui questo comando:

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

dove:

  • [ADMIN_CLUSTER_KUBECONFIG] è il file kubeconfig del cluster di amministrazione.

  • [ADMIN_CLUSTER_CONFIG_FILE] è il file di configurazione del cluster di amministrazione Anthos su VMware sulla tua nuova workstation di amministrazione.

  • [FLAGS] è un insieme facoltativo di flag. Ad esempio, puoi includere il flag --skip-validation-infra per saltare il controllo della tua infrastruttura vSphere. Utilizza il flag --force-upgrade-admin per ripristinare il flusso di upgrade precedente, in cui il cluster di amministrazione viene aggiornato per primo e successivamente i cluster utente.

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

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

Ripresa dell'upgrade del cluster di amministrazione

Non interrompere un upgrade del cluster di amministrazione. Al momento, gli upgrade dei cluster di amministrazione non sono sempre ripristinabili. Se un upgrade del cluster di amministrazione viene interrotto per qualsiasi motivo, devi contattare l'Assistenza Google.

Risoluzione dei problemi relativi al processo di upgrade

Se riscontri un problema durante il processo di upgrade consigliato, segui questi consigli per risolverlo. Questi suggerimenti presuppongono che tu abbia iniziato con una configurazione della versione 1.6.2 e che tu stia procedendo al processo di upgrade consigliato.

Risoluzione di un problema di upgrade del cluster utente

Supponi di trovare un problema con 1.7 durante il test del cluster canary o l'upgrade di un cluster utente. Stabilisci dall'Assistenza Google che il problema verrà risolto in una prossima versione della patch 1.7.x. Puoi procedere nel seguente modo:

  1. Continua a utilizzare 1.6.2 per la produzione;
  2. Testa la release della patch 1.7.x in un cluster canary quando viene rilasciato. 1; Esegui l'upgrade di tutti i cluster utente di produzione alla versione 1.7.x quando ti senti sicuro.
  3. Esegui l'upgrade del cluster di amministrazione alla versione 1.7.x.

Gestione di una versione di patch 1.6.x durante il test 1.7

Supponiamo che tu stia eseguendo il test o la migrazione alla versione 1.7, ma che non sia ancora sicura e che il tuo cluster di amministrazione utilizzi ancora 1.6.2. Scopri che è stata rilasciata una versione patch 1.6.x significativa. Puoi comunque sfruttare questa versione di patch 1.6.x mentre continui il test 1.7. Segui questa procedura di upgrade:

  1. Installa il bundle 1.6.x-gke.0.
  2. Aggiorna tutti i cluster utente di produzione 1.6.2 a 1.6.x.
  3. Esegui l'upgrade del cluster di amministrazione alla versione 1.6.x.

Risoluzione di un problema di upgrade del cluster di amministrazione

Se riscontri 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 continuare a trarre vantaggio dalle nuove funzionalità dei cluster utente senza essere bloccate dall'upgrade del cluster di amministrazione, il che consente di ridurre la frequenza di upgrade del cluster di amministrazione, se vuoi. Ad esempio, puoi utilizzare il pool di nodi del sistema operativo ottimizzato per i container rilasciato nella versione 1.7. La procedura di upgrade può procedere nel seguente modo:

  1. Esegui l'upgrade dei cluster utente di produzione alla versione 1.7.
  2. Mantieni il cluster di amministrazione alla versione 1.6 e continua a ricevere patch di sicurezza;
  3. Eseguire l'upgrade del cluster di amministrazione da 1.6 a 1.7 in un ambiente di test e segnalare eventuali problemi;
  4. Se il problema è risolto da una release di patch 1.7, puoi scegliere di eseguire l'upgrade del cluster di amministrazione di produzione da 1.6 a questa release di patch 1.7, se lo desideri.

Problemi noti

I seguenti problemi noti interessano l'upgrade dei cluster.

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

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 esaurito, perché il sistema tenta di eseguire il backup locale della workstation di amministrazione attuale 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 evitare di eseguire un backup locale della workstation di amministrazione corrente.

Versione 1.7.0: modifiche agli aggiornamenti di Anthos Config Management

Nelle versioni precedenti alla 1.7.0, i cluster Anthos su VMware includevano le immagini necessarie per installare ed eseguire l'upgrade di Anthos Config Management. A partire dalla versione 1.7.0, il software Anthos Config Management non è più incluso nel bundle Anthos su VMware e deve essere aggiunto separatamente. Se in precedenza utilizzavi Anthos Config Management sul tuo cluster o sui tuoi cluster, il software non verrà aggiornato finché non intervieni.

Per saperne di più sull'installazione di Anthos Config Management, consulta Installazione di Anthos Config Management.

Versione 1.1.0-gke.6, 1.2.0-gke.6: campo stackdriver.proxyconfigsecretname rimosso

Il campo stackdriver.proxyconfigsecretname è stato rimosso nella versione 1.1.0-gke.6. I cluster Anthos sui controlli preliminari di VMware restituiscono un errore se il campo è presente nel file di configurazione.

Per risolvere questo problema, prima di eseguire l'upgrade a 1.2.0-gke.6, elimina il campo proxyconfigsecretname dal file di configurazione.

Stackdriver fa riferimento alla versione precedente

Prima della versione 1.2.0-gke.6, un problema noto impedisce a Stackdriver di aggiornare la propria configurazione dopo gli upgrade del cluster. Stackdriver fa ancora riferimento a una versione precedente, che impedisce a Stackdriver di ricevere le funzionalità più recenti della pipeline di telemetria. Questo problema può rendere difficile per l'Assistenza Google risolvere i problemi dei cluster.

Dopo aver eseguito l'upgrade dei cluster a 1.2.0-gke.6, esegui il seguente comando sui cluster di amministrazione e utente:

kubectl --kubeconfig=[KUBECONFIG] \
-n kube-system --type=json patch stackdrivers stackdriver \
-p '[{"op":"remove","path":"/spec/version"}]'

dove [KUBECONFIG] è il percorso del file kubeconfig del cluster.

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 PodDisruptionBudget (PDB).

Versione 1.2.0-gke.6: Prometheus e Grafana disattivati dopo l'upgrade

Nei cluster utente, Prometheus e Grafana vengono disattivati automaticamente durante l'upgrade. Tuttavia, i dati di configurazione e delle metriche non andranno persi. Nei cluster di amministrazione, Prometheus e Grafana rimangono attivi.

Per istruzioni, consulta le note di rilascio dei cluster Anthos su VMware.

Versione 1.1.2-gke.0: i nodi del cluster utente eliminati non vengono rimossi dal datastore vSAN

Per istruzioni, consulta le note di rilascio dei cluster Anthos su VMware.

Versione 1.1.1-gke.2: il disco dati nella cartella del datastore vSAN può essere eliminato

Se utilizzi un datastore vSAN, devi creare una cartella in cui salvare il VMDK. Un problema noto richiede che il percorso UUID (Universal Unique Identifier) della cartella, anziché il suo percorso file, venga inviato a vcenter.datadisk. Questa mancata corrispondenza può causare errori degli upgrade.

Per istruzioni, consulta le note di rilascio dei cluster Anthos su VMware.

Upgrade alla versione 1.1.0-gke.6 dalla versione 1.0.2-gke.3: problema OIDC

Non è possibile eseguire l'upgrade dei cluster della versione 1.0.11, 1.0.1-gke.5 e 1.0.2-gke.3 in cui è configurato OpenID Connect (OIDC) alla versione 1.1.0-gke.6. Questo problema è stato risolto nella versione 1.1.1-gke.2.

Se hai configurato un cluster versione 1.0.11, 1.0.1-gke.5 o 1.0.2-gke.3 con OIDC durante l'installazione, non puoi eseguirne l'upgrade. Devi invece creare nuovi cluster.

Upgrade alla versione 1.0.2-gke.3 dalla versione 1.0.11

La versione 1.0.2-gke.3 introduce i seguenti campi OIDC (usercluster.oidc). Questi campi consentono di accedere a un cluster da Google Cloud Console:

  • usercluster.oidc.kubectlredirecturl
  • usercluster.oidc.clientsecret
  • usercluster.oidc.usehttpproxy

Se vuoi utilizzare OIDC, il campo clientsecret è obbligatorio anche se non vuoi accedere a un cluster da Google Cloud Console. Per utilizzare OIDC, potrebbe essere necessario fornire un valore segnaposto per clientsecret:

oidc:
  clientsecret: "secret"

I nodi non riescono a completare il processo di upgrade

Se hai configurato PodDisruptionBudget oggetti che non sono in grado di consentire ulteriori interruzioni, dopo gli ripetuti tentativi gli upgrade dei nodi potrebbero non riuscire a eseguire la versione del piano di controllo. Per evitare questo errore, ti consigliamo di fare lo scale up di Deployment o HorizontalPodAutoscaler per consentire lo svuotamento del nodo pur continuando a rispettare 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 DRS di VMware abilitate nella versione 1.1.0-gke.6

A partire dalla versione 1.1.0-gke.6, i cluster Anthos su VMware creano automaticamente regole anti-affinità VMware Distributed Resource Scheduler(DRS) per i nodi del cluster utente, facendoli sparsi in almeno tre host fisici nel tuo data center. A partire dalla versione 1.1.0-gke.6, questa funzionalità è abilitata automaticamente per i nuovi cluster e i cluster 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 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 ulteriori informazioni, consulta questo problema noto nelle note di rilascio di Cluster Anthos su VMware.

Tempo di riposo

Informazioni sul tempo di inattività durante gli upgrade

Risorsa Descrizione
Cluster di amministrazione

Quando un cluster di amministrazione è inattivo, i piani di controllo e i carichi di lavoro dei cluster utente 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 sono previsti tempi di inattività visibili per i piani di controllo del cluster utente. Tuttavia, le connessioni a lunga durata al server API Kubernetes potrebbero interrompersi e dovrebbero essere ripristinate. In questi casi, il chiamante dell'API deve riprovare finché non stabilisce una connessione. Nel peggiore dei casi, può essere necessario fino a un minuto di tempo di inattività durante un upgrade.

Nodi del cluster utente

Se un upgrade richiede una modifica ai nodi del cluster utente, i cluster Anthos su VMware ricreano i nodi in modo continuativo e ripianificano i pod in esecuzione su questi nodi. Puoi evitare l'impatto sui tuoi carichi di lavoro configurando PodDisruptionBudget e regole di affinità appropriati.

Problemi noti

Vedi Problemi noti.

Risolvere i problemi

Consulta Risoluzione dei problemi di creazione e upgrade del cluster