Eseguire l'upgrade di Apigee hybrid alla versione 1.8

Al momento stai visualizzando la versione 1.8 della documentazione di Apigee hybrid. This version is end of life. You should upgrade to a newer version. Per ulteriori informazioni, consulta Versioni supportate.

Version 1.8 (unsupported)

   Versioni supportate:

• v1.13 (ultima versione)                        
• v1.12                         
• v1.11                         
• Elenco delle versioni supportate

   Versioni non supportate:

• v1.10                                      
• v1.9                                         
• v1.8                                         
• v1.7                                         
• v1.6                                         
• v1.5                                         
• v1.4                                         
• v1.3                                         
• v1.2                                         
• v1.1                                         

Utilizza le stesse procedure per gli upgrade delle versioni minori (ad esempio dalla versione 1.7 alla 1.8) e per gli upgrade delle release delle patch (ad esempio dalla 1.8.0 alla 1.8.8).

Se stai eseguendo l'upgrade da Apigee hybrid 1.6 o versioni precedenti, devi prima eseguire l'upgrade alla versione 1.7 di hybrid prima di eseguire l'upgrade alla versione 1.8.8. Consulta le istruzioni per l'upgrade di Apigee Hybrid alla versione 1.7.

Se utilizzi già la versione ibrida 1.8.0 e vuoi eseguire la migrazione ad Apigee ingress gateway da Anthos Service Mesh, consulta Eseguire la migrazione ad Apigee ingress gateway.

Introduzione al gateway di ingresso Apigee

A partire dalla versione 1.8, Apigee Hybrid offre una nuova funzionalità per gestire il gateway di ingresso per la tua installazione ibrida, Apigee ingress gateway. Anthos Service Mesh non è più un prerequisito per l'installazione ibrida. Con il gateway di ingresso Apigee, Apigee smetterà di fornire la configurazione di routing ad Anthos Service Mesh. Dopo l'upgrade, devi eseguire la migrazione del traffico al nuovo gateway di ingresso Apigee prima di poter iniziare a utilizzare la funzionalità.

Apigee utilizza un piccolo sottoinsieme di funzionalità di Anthos Service Mesh per il gateway di ingresso. A partire dalla versione ibrida 1.8, Apigee hybrid include un gateway di ingresso che viene installato e sottoposto ad upgrade nell'ambito degli upgrade di Apigee hybrid. Di conseguenza, non è necessario acquisire competenze su Anthos Service Mesh per installare, eseguire l'upgrade e gestire Apigee Hybrid. I problemi relativi alle versioni del gateway di ingresso e alla compatibilità con le release ibride di Apigee vengono gestiti automaticamente.

Esistono due scenari per la migrazione:

• Migrazione multi-cluster o multi-regione (opzione consigliata):

  Prima di passare a un nuovo Ingress per Apigee, scarica tutto il traffico su un altro cluster o regione dal cluster di cui stai eseguendo la migrazione. In questo modo, avrai il tempo di verificare se il nuovo gateway di ingresso Apigee funziona come previsto. Poi sposta nuovamente il traffico sul cluster sottoposto ad upgrade.

• Upgrade in situ (non consigliato negli ambienti di produzione):

  Durante l'upgrade, Apigee attiverà il nuovo gateway di ingresso con un indirizzo IP specificato. Puoi quindi verificare se il nuovo gateway di ingresso Apigee funziona come previsto e poi spostare il traffico sul nuovo ingresso. Durante l'upgrade potrebbero verificarsi tempi di inattività.

Quando esegui l'upgrade di Apigee hybrid alla versione 1.8, devi configurare il gateway di ingresso Apigee nel file delle sostituzioni. Dopo l'upgrade, puoi controllare il tipo di gateway di ingresso utilizzato dai tuoi cluster indirizzando i record A o CNAME del tuo registrar all'indirizzo IP del gateway di ingresso Apigee o di Anthos Service Mesh.

Attenzione: poiché Apigee Ingress Gateway è una nuova funzionalità che introduce modifiche significative, Apigee consiglia di eseguire l'upgrade e testare prima un'installazione non di produzione, prima di eseguire l'upgrade di un'installazione di produzione.

Panoramica dell'upgrade alla versione 1.8.8

L'upgrade alla versione 1.8 di Apigee hybrid potrebbe richiedere il tempo di riposo.

Durante l'upgrade del controller Apigee alla versione 1.8.8, tutti i deployment di Apigee vengono sottoposti a un riavvio graduale. Per ridurre al minimo i tempi di inattività negli ambienti ibridi di produzione durante un riavvio graduale, assicurati di eseguire almeno due cluster (nella stessa regione/nel medesimo data center o in regioni/data center diversi). Deviare tutto il traffico di produzione su un singolo cluster e mettere offline il cluster di cui vuoi eseguire l'upgrade, quindi procedere con la procedura di upgrade. Ripeti la procedura per ogni cluster.

Apigee consiglia di eseguire l'upgrade di tutti i cluster il prima possibile per ridurre le probabilità di impatto sulla produzione. Non esiste un limite di tempo per l'upgrade di tutti i cluster rimanenti dopo l'upgrade del primo. Tuttavia, fino a quando non verrà eseguito l'upgrade di tutti i cluster rimanenti, le seguenti operazioni saranno interessate:

• Il backup e il ripristino di Cassandra non possono funzionare con versioni miste. Ad esempio, un backup di Hybrid 1.7 non può essere utilizzato per ripristinare un'istanza di Hybrid 1.8.
• Lo streaming di dati Cassandra non funzionerà tra versioni ibride miste. Di conseguenza, i tuoi cluster Cassandra non possono essere scalati orizzontalmente.
• L'espansione e il ritiro delle regioni saranno interessati, in quanto queste operazioni dipendono dall'analisi in streaming dei dati di Cassandra.

Le procedure per l'upgrade di Apigee hybrid sono organizzate nelle seguenti sezioni:

1. Preparati all'upgrade.
2. Installa la versione 1.8.8 del runtime di hybrid.
3. Per la porta di accesso, scegli una delle seguenti opzioni:
   • (Consigliato) Utilizza il nuovo gateway di ingresso Apigee, segui i passaggi descritti in Spostare il traffico da Anthos Service Mesh al gateway di ingresso Apigee.
   • Continua a utilizzare Anthos Service Mesh per il gateway in entrata.

Prerequisito

Queste istruzioni per l'upgrade presuppongono che tu abbia installato Apigee hybrid 1.7.x o una release di patch precedente della versione 1.8.x e che tu voglia eseguire l'upgrade alla versione 1.8.8. Se esegui l'aggiornamento da una versione precedente, consulta le istruzioni per l'upgrade di Apigee hybrid alla versione 1.7.

Se preferisci continuare a utilizzare Anthos Service Mesh, devi assicurarti che venga eseguito l'upgrade ad una versione supportata. Consulta la tabella Piattaforme supportate per le versioni supportate di Anthos Service Mesh.

Prepararsi all'upgrade alla versione 1.8

Esegui il backup dell'installazione ibrida (opzione consigliata)

1. Queste istruzioni utilizzano la variabile di ambiente APIGEECTL_HOME per la directory nel file system in cui hai installato apigeectl. Se necessario, cambia directory nella directory apigeectl e definisci la variabile con il seguente comando:

   Linux

   export APIGEECTL_HOME=$PWD
   echo $APIGEECTL_HOME

   Mac OS

   export APIGEECTL_HOME=$PWD
   echo $APIGEECTL_HOME

   Windows

   set APIGEECTL_HOME=%CD%
   echo %APIGEECTL_HOME%

2. Crea una copia di backup della directory $APIGEECTL_HOME/ della versione 1.7. Ad esempio:

   tar -czvf $APIGEECTL_HOME/../apigeectl-v1.7-backup.tar.gz $APIGEECTL_HOME

3. Esegui il backup del database Cassandra seguendo le istruzioni riportate in Backup e recupero di Cassandra

Aggiungi il ruolo Agente Cloud Trace all'account di servizio per il runtime Apigee. (facoltativo)

(Facoltativo) Se prevedi di utilizzare Cloud Trace e non hai ancora eseguito questo passaggio sull'installazione ibrida 1.7, assicurati che l'account di servizio per i servizi di runtime Apigee abbia il ruolo Google Agente Cloud Trace. (roles/cloudtrace.agent).

Per gli ambienti di produzione, in genere si tratta dell'account di servizio apigee-runtime. Per gli ambienti non di produzione, in genere si tratta dell'account di servizio apigee-non-prod.

Puoi aggiungere il ruolo nell'interfaccia utente di Cloud Console > IAM & Amministrazione > Account di servizio o con i seguenti comandi:

1. Ottieni l'indirizzo email del tuo account di servizio con il seguente comando:

   Produzione

   gcloud iam service-accounts list --filter "apigee-runtime"

   Se corrisponde allo schema apigee-runtime@$ORG_NAME.iam.gserviceaccount.com, puoi utilizzarlo nel passaggio successivo.

   Non prod

   gcloud iam service-accounts list --filter "apigee-non-prod"

   Se corrisponde allo schema apigee-non-prod@$ORG_NAME.iam.gserviceaccount.com, puoi utilizzarlo nel passaggio successivo.

2. Assegna il ruolo Agente Cloud Trace all'account di servizio:

   Produzione

   gcloud projects add-iam-policy-binding $PROJECT_ID \
       --member="serviceAccount:apigee-runtime@$PROJECT_ID.iam.gserviceaccount.com" \
       --role="roles/cloudtrace.agent"

   Non prod

   gcloud projects add-iam-policy-binding $PROJECT_ID \
       --member="serviceAccount:apigee-non-prod@$PROJECT_ID.iam.gserviceaccount.com" \
       --role="roles/cloudtrace.agent"

   Esempio

   gcloud projects add-iam-policy-binding hybrid-example-project \
       --member="serviceAccount:[e-mail]" \
       --role="roles/cloudtrace.agent"

   Dove: $PROJECT_ID è il nome del progetto Google Cloud in cui è installato Apigee Hybrid.

   Nota: se la tua installazione utilizza un nome personalizzato per l'account di servizio, sostituiscilo con apigee-runtime o apigee-non-prod nel comando.

Prepararsi a installare il gateway di ingresso Apigee

Per installare il gateway di ingresso Apigee nell'ambito dell'upgrade. Devi aggiungere la seguente proprietà ingressGateways al file delle sostituzioni.

Sintassi

ingressGateways:
- name: INGRESS_NAME
  replicaCountMin: REPLICAS_MIN
  replicaCountMax: REPLICAS_MAX
  resources:
    requests:
      cpu: CPU_COUNT_REQ
      memory: MEMORY_REQ
    limits:
      cpu: CPU_COUNT_LIMIT
      memory: MEMORY_LIMIT
  svcAnnotations:  # optional. See Known issue 243599452.
    SVC_ANNOTATIONS_KEY: SVC_ANNOTATIONS_VALUE
  svcLoadBalancerIP: SVC_LOAD_BALANCER_IP # optional

Esempio

ingressGateways:
- name: prod1
  replicaCountMin: 2
  replicaCountMax: 100
  resources:
    requests:
      cpu: 1
      memory: 1Gi
    limits:
      cpu: 2
      memory: 2Gi 

• INGRESS_NAME è il nome del deployment di Ingress. Può essere qualsiasi nome che soddisfi i seguenti requisiti:
  • Avere una lunghezza massima di 17 caratteri
  • Contenere solo caratteri alfanumerici minuscoli, "-" o "."
  • Deve iniziare con un carattere alfanumerico
  • Deve terminare con un carattere alfanumerico

  Consulta ingressGateways[].name nel riferimento per le proprietà di configurazione

• REPLICAS_MIN e REPLICAS_MAX sono i conteggi delle repliche minimo e massimo per Gateway di ingresso Apigee nella tua installazione. Per ulteriori informazioni e impostazioni predefinite, consulta ingressGateways[].replicaCountMin e ingressGateways[].replicaCountMax nella pagina di riferimento della proprietà Configuration.
• CPU_COUNT_REQ e MEMORY_REQ sono le richieste di CPU e memoria per ogni replica del gateway di ingresso Apigee nella tua installazione.
  Imposta queste proprietà solo se le hai impostate in precedenza per il gateway di ingresso Anthos Service Mesh, ad esempio nel file overlay.yaml.

  Per ulteriori informazioni e impostazioni predefinite, consulta ingressGateways[].resources.requests.cpu e ingressGateways[].resources.requests.memory nel riferimento alla proprietà Configuration.

• CPU_COUNT_LIMIT e MEMORY_LIMIT I limiti massimi di CPU e memoria per ogni replica del gateway di ingresso Apigee nell'installazione.
  Imposta queste proprietà solo se le hai impostate in precedenza per il gateway di ingresso Anthos Service Mesh, ad esempio nel file overlay.yaml.

  Per ulteriori informazioni e impostazioni predefinite, consulta ingressGateways[].resources.limits.cpu e ingressGateways[].resources.limits.memory nel riferimento alla proprietà Configuration.

• SVC_ANNOTATIONS_KEY e SVC_ANNOTATIONS_VALUE (facoltativo):
  Nota: il campo ingressGateways[].svcAnnotations in overrides.yaml non funziona come previsto. Vedi Problema noto 243599452

  Si tratta di una coppia chiave-valore che fornisce annotazioni per il servizio di importazione predefinito. Le annotazioni vengono utilizzate dalla piattaforma cloud per aiutarti a configurare l'installazione ibrida, ad esempio impostando il tipo di bilanciatore del carico su interno o esterno. Ad esempio:

  ingressGateways:
    svcAnnotations:
      networking.gke.io/load-balancer-type: "Internal"

  Le annotazioni variano da una piattaforma all'altra. Fai riferimento alla documentazione della piattaforma per le annotazioni richieste e suggerite.

  Nota: non è necessario impostare Annotations se crei il tuo servizio Kubernetes per il deployment in ingresso come descritto in Esporre il gateway di ingresso Apigee.
  Consulta ingressGateways[].svcAnnotations nel riferimento per le proprietà di configurazione.
• SVC_LOAD_BALANCER_IP (facoltativo) Ti consente di assegnare un indirizzo IP statico per il bilanciatore del carico. Sulle piattaforme che supportano l'indicazione dell'indirizzo IP del bilanciatore del carico, il bilanciatore del carico verrà creato con questo indirizzo IP. Sulle piattaforme che non consentono di specificare l'indirizzo IP del bilanciatore del carico, questa proprietà viene ignorata.

  Se non hai allocato un indirizzo IP statico per il bilanciatore del carico, lascia questa proprietà fuori dal file delle sostituzioni.

  Attenzione: assicurati di non specificare lo stesso indirizzo IP dell'attuale istio-ingressgateway. Ciò potrebbe causare problemi mentre il servizio è ancora nel cluster.
  Nota: non è necessario impostare LoadBalancerIP se crei il tuo servizio Kubernetes per il deployment di ingress come descritto in Esporre il gateway di ingresso Apigee.
  Consulta ingressGateways[].svcLoadBalancerIP nel riferimento per le proprietà di configurazione.

Apporta modifiche aggiuntive al file delle sostituzioni per attivare o disattivare le funzionalità facoltative della versione 1.8

Aggiungi le seguenti proprietà al file overrides.yaml per attivare le nuove funzionalità in hybrid v1.8. Queste funzionalità sono facoltative.

• L'accesso a dati sensibili a livello di organizzazione è ora attivo per impostazione predefinita. L'utilizzo di un singolo deployment UDCA per gestire il traffico per tutti gli ambienti impedisce il sottoutilizzo dei pod UDCA e aumenta la disponibilità delle risorse dei nodi per altri componenti Apigee. L'accesso a dati sensibili a livello di organizzazione utilizza un unico account di servizio per tutti gli ambienti, apigee-udca.

  Se utilizzi account di servizio diversi per l'UDCA in ambienti diversi, tieni presente che ora verrà utilizzato l'account di servizio specificato a livello di organizzazione nel file di override con udca:serviceAccountPath, anziché quelli specificati a livello di ambiente con envs:udca:serviceAccountPath.

  Apigee hybrid versione 1.8 supporta le UDCA basate sull'ambiente. Per mantenere l'impostazione UDCA per ambiente, imposta orgScopedUDCA: false.

  Nota: il supporto per le autorizzazioni basate sugli ambienti non sarà disponibile nelle release future di Apigee Hybrid.

  Consulta orgScopedUDCA nel riferimento per le proprietà di configurazione.

• Attiva validateOrg per richiedere una convalida rigorosa dell'organizzazione e dell'ambiente Apigee, che devono essere attivi e funzionare con il progetto Google Cloud Platform specificato nel file overrides.

  validateOrg: true

  Nota: Apigee Hybrid supporta la mancata applicazione della convalida dell'organizzazione rigorosa. Per disattivare la funzionalità, imposta validateOrg: false.

  Consulta validateOrg nel Riferimento per le proprietà di configurazione.

Installa il runtime di hybrid 1.8.8

Attenzione: non creare nuovi ambienti durante la procedura di upgrade.

1. Assicurati di essere nella directory di base ibrida (la directory principale in cui si trova il file eseguibile apigeectl):

   cd $APIGEECTL_HOME/..

2. Scarica il pacchetto della release per il tuo sistema operativo utilizzando il seguente comando. Assicurati di selezionare la tua piattaforma nella tabella seguente:

   Linux

   Linux a 64 bit:

   curl -LO \
     https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.8.8/apigeectl_linux_64.tar.gz

   Mac OS

   Mac 64 bit:

   curl -LO \
     https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.8.8/apigeectl_mac_64.tar.gz

   Windows

   Windows a 64 bit:

   curl -LO ^
     https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.8.8/apigeectl_windows_64.zip

3. Rinomina la directory apigeectl/ attuale con il nome di una directory di backup. Ad esempio:

   Linux

   mv $APIGEECTL_HOME/ $APIGEECTL_HOME-v1.7/

   Mac OS

   mv $APIGEECTL_HOME/ $APIGEECTL_HOME-v1.7/ 

   Windows

   rename %APIGEECTL_HOME% %APIGEECTL_HOME%-v1.7 

4. Estrai i contenuti del file gzip scaricato nella directory di base ibrida. La directory di base ibrida è la directory in cui si trova la directory apigeectl-v1.7 rinominata:

   Linux

   tar xvzf filename.tar.gz -C ./

   Mac OS

   tar xvzf filename.tar.gz -C ./

   Windows

   tar xvzf filename.zip -C ./

5. Per impostazione predefinita, i contenuti del file tar vengono espansi in una directory con la versione e la piattaforma nel nome. Ad esempio: ./apigeectl_1.8.8-xxxxxxx_linux_64. Rinomina la directory in apigeectl utilizzando il seguente comando:

   Linux

   mv apigeectl_1.8.8-xxxxxxx_linux_64 apigeectl

   Mac OS

   mv apigeectl_1.8.8-xxxxxxx_mac_64 apigeectl

   Windows

   rename apigeectl_1.8.8-xxxxxxx_windows_64 apigeectl

6. Passa alla directory apigeectl:

   cd ./apigeectl

   Questa directory è la home directory di apigeectl. È qui che si trova il comando eseguibile apigeectl.

7. Queste istruzioni utilizzano la variabile di ambiente $APIGEECTL_HOME per la directory nel file system in cui è installata l'utilità apigeectl. Se necessario, cambia directory nella directory apigeectl e definisci la variabile con il seguente comando:

   Linux

   export APIGEECTL_HOME=$PWD

   echo $APIGEECTL_HOME

   Mac OS

   export APIGEECTL_HOME=$PWD

   echo $APIGEECTL_HOME

   Windows

   set APIGEECTL_HOME=%CD%

   echo %APIGEECTL_HOME%

8. Verifica la versione di apigeectl con il comando version:

   ./apigeectl version

   Version: 1.8.8

9. Passa alla directory hybrid-base-directory/hybrid-files. La directory hybrid-files contiene i file di configurazione, ad esempio il file delle sostituzioni, i certificati e gli account di servizio. Ad esempio:

   cd $APIGEECTL_HOME/../hybrid-files

10. Verifica che kubectl sia impostato sul contesto corretto utilizzando il seguente comando. Il contesto corrente deve essere impostato sul cluster in cui stai eseguendo l'upgrade di Apigee hybrid.

    kubectl config get-contexts | grep \*

11. Nella directory hybrid-files:
    1. Aggiorna i seguenti link simbolici a $APIGEECTL_HOME. Questi link ti consentono di eseguire il comando apigeectl appena installato dall'interno della directory hybrid-files:

       ln -nfs $APIGEECTL_HOME/tools tools
       ln -nfs $APIGEECTL_HOME/config config
       ln -nfs $APIGEECTL_HOME/templates templates
       ln -nfs $APIGEECTL_HOME/plugins plugins

    2. Per verificare che i link simbolici siano stati creati correttamente, esegui il seguente comando e assicurati che i percorsi dei link rimandino alle posizioni corrette:

       ls -l | grep ^l

12. Esegui un'inizializzazione di prova per verificare la presenza di errori:

    ${APIGEECTL_HOME}/apigeectl init -f OVERRIDES_FILE --dry-run=client

    dove OVERRIDES_FILE è il nome del file delle sostituzioni, ad esempio ./overrides/overrides.yaml.

    Suggerimento: puoi sostituire OVERRIDES_FILE nel codice di esempio riportato sopra con il nome e il percorso del file di override e ogni istanza in questa pagina verrà sostituita.
13. Se non ci sono errori, inizializza la versione ibrida 1.8.8. Questo comando installa e configura anche il gateway di ingresso Apigee:

    $APIGEECTL_HOME/apigeectl init -f OVERRIDES_FILE

14. Controlla lo stato dell'inizializzazione:

    $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

    In caso di esito positivo, l'output è: All containers ready.

    Problema noto: dopo aver eseguito init e aver verificato che check-ready è andato a buon fine, se visualizzi i pod, potresti notare che la convalida dello schema Cassandra è in uno stato di errore. Questo stato è considerato un problema noto (#245664917) e non è dannoso. Puoi ignorare l'errore e passare al passaggio successivo: apigeectl apply.

    Come ulteriore controllo, puoi anche eseguire questo comando per controllare lo stato di ApigeeDataStore:

    kubectl describe apigeeds -n apigee

    Nell'output, cerca State: running.

15. Verifica la presenza di errori con una prova simulata del comando apply utilizzando il flag --dry-run:

    $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --dry-run=client

16. Se non sono presenti errori, applica le sostituzioni. Seleziona e segui le istruzioni per gli ambienti di produzione o per gli ambienti non di produzione, a seconda dell'installazione.
    Durante la procedura di upgrade, ogni componente eseguirà un riavvio graduale. Pertanto, per gli ambienti di produzione, è meglio applicare l'upgrade a un componente alla volta.

    Produzione

    Per gli ambienti di produzione, devi eseguire l'upgrade di ogni componente ibrida singolarmente e controllare lo stato del componente di cui è stato eseguito l'upgrade prima di procedere con il componente successivo.

    1. Assicurati di essere nella directory hybrid-files.
    2. Applica le sostituzioni per eseguire l'upgrade di Cassandra:

       $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --datastore

    3. Controlla il completamento:

       $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

       Suggerimento: se check-ready non va a buon fine, puoi ottenere maggiori informazioni sui pod con:

       kubectl -n NAMESPACE get pods

       dove NAMESPACE è il tuo spazio dei nomi Apigee hybrid.

       Vai al passaggio successivo solo quando i pod sono pronti.

    4. Applica le sostituzioni per eseguire l'upgrade dei componenti di Telemetria e controlla il completamento:

       $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --telemetry

       $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

    5. Avvia i componenti Redis:

       $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --redis

    6. Applica le sostituzioni per eseguire l'upgrade dei componenti a livello di organizzazione (MART, Watcher e Apigee Connect) e controlla il completamento:

       $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --org

       $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

    7. Applica le sostituzioni per eseguire l'upgrade degli ambienti. Hai due opzioni:
       • Per ambiente: applica le sostituzioni a un ambiente alla volta e controlla il completamento. Ripeti questo passaggio per ogni ambiente:

         $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --env ENV_NAME

         $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

         dove ENV_NAME è il nome dell'ambiente di cui stai eseguendo l'upgrade.

       • Tutti gli ambienti contemporaneamente: applica le sostituzioni a tutti gli ambienti contemporaneamente e controlla il completamento:

         $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --all-envs

         $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

    8. Applica le sostituzioni per eseguire l'upgrade dei componenti virtualhosts e controlla il completamento:

       $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --settings virtualhosts

       $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

    Non prod

    Nella maggior parte degli ambienti non di produzione, di prova o sperimentali, puoi applicare le sostituzioni a tutti i componenti contemporaneamente. Se il tuo ambiente non di produzione è di grandi dimensioni e complesso o se rispecchia molto da vicino un ambiente di produzione, ti consigliamo di utilizzare le istruzioni per l'upgrade degli ambienti di produzione.

    1. Assicurati di essere nella directory hybrid-files.
    2. $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE

    3. Controlla lo stato:

       $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

Esegui l'upgrade della versione di Kubernetes

Esegui l'upgrade della piattaforma Kubernetes alle versioni supportate da hybrid 1.8. Se hai bisogno di aiuto, consulta la documentazione della tua piattaforma.

Fai clic per espandere un elenco delle piattaforme supportate

	Versioni di Apigee hybrid
Piattaforme	1.6 ^(3)	1.7 ^(3)	1.8 ^(3)	1.9	1,10
Anthos (Google Cloud - GKE)	1.19.x 1.20.x 1.21.x	1.20.x 1.21.x 1.22.x ^(≥ 1.7.2) 1.23.x ^(≥ 1.7.2)	1.21.x ^(≤ 1.8.3) 1.22.x ^(≤ 1.8.3) 1.23.x ^(≤ 1.8.4) 1.24.x ^(≥ 1.8.4) 1.25.x ^(≥ 1.8.4)	1.23.x 1.24.x 1.25.x 1.26.x ^(≥ 1.9.2)	1.24.x 1.25.x 1.26.x
Anthos (AWS)	1.7.x 1.8.x 1.9.3+ 1.10.x	1.9.x 1.10.x 1.12.x ^(≥ 1.7.2)	1.10.x 1.11.x 1.12.x 1.13.x 1.25^(13)	1.12.x 1.13.x 1.25^(13)	1.13.x 1.25^(13) 1.26^(13)
Anthos (Azure)	1.8.x	1.9.x 1.10.x 1.12.x ^(≥ 1.7.2)	1.10.x 1.11.x 1.12.x 1.13.x 1.14.x	1.12.x 1.13.x 1.14.x	1.13.x 1.14.x 1.15.x
Anthos (on-premise - VMware)^(1)	1.7.x 1.8.x 1.9.3+ 1.10.x	1.9.x ^(4) 1.10.x ^(4) 1.11.x ^(4) ^(≥ 1.7.2) 1.12.x ^(4) ^(≥ 1.7.2)	1.10.x ^(4) 1.11.x ^(4) 1.12.x ^(4) ^(5) 1.13.x ^(5) 1.14.x ^(5) 1.15.x	1.12.x ^(4) 1.13.x 1.14.x 1.15.x	1.13.x 1.14.x 1.15.x 1.16.x
Anthos (bare metal)^(1)	1.7.x 1.8.2+ 1.9.3+ 1.10.x	1.9.x ^(4) 1.10.x ^(4) 1.11.x ^(4) ^(≥ 1.7.2) 1.12.x ^(4) ^(≥ 1.7.2)	1.10.x ^(4) 1.11.x ^(4) 1.12.x ^(4) ^(5) 1.13.x ^(5) 1.14.x ^(5) 1.15.x	1.12.x ^(4) 1.13.x 1.14.x 1.15.x	1.13.x 1.14.x 1.15.x 1.16.x
EKS^(7)	1.19.x 1.20.x 1.21.x	1.21.x 1.22.x ^(≥ 1.7.2) 1.23.x ^(≥ 1.7.2)	1.22.x ^(≤ 1.8.3) 1.23.x ^(≤ 1.8.4) 1.24.x ^(≥ 1.8.4) 1.25.x ^(≥ 1.8.4)	1.23.x 1.24.x 1.25.x 1.26.x ^(≥ 1.9.2)	1.24.x 1.25.x 1.26.x
AKS^(7)	1.19.x 1.20.x 1.21.x	1.21.x 1.22.x ^(≥ 1.7.2) 1.23.x ^(≥ 1.7.2)	1.22.x ^(≤ 1.8.3) 1.23.x ^(≤ 1.8.4) 1.24.x ^(≥ 1.8.4) 1.25.x ^(≥ 1.8.4)	1.23.x 1.24.x 1.25.x 1.26.x ^(≥ 1.9.2)	1.24.x 1.25.x 1.26.x
OpenShift^(7)	4.6 4.7 4.8	4.7 4.8	4.8 4.9 4.10	4.10 4.11	4.11 4.12
Rancher Kubernetes Engine (RKE)^(7)	N/D	N/A	N/D	1.3.8	v1.26.2+rke2r1
Componenti	1.6 ^(3)	1.7 ^(3)	1.8	1.9	1,10
Anthos Service Mesh (ASM)	1.9.x 1.10.x 1.12.x 1.13.x	1.10.x 1.11.x 1.12.x 1.13.x ^(≥ 1.7.2) 1.14.x 1.15.x ^(≥ 1.7.6)	1.11.x 1.12.x 1.13.x 1.14.x 1.15.x	1.17.x^(11)	1.17.x^(11)
JDK	JDK 11	JDK 11	JDK 11	JDK 11	JDK 11
cert-manager	1.5.4	1.7.x	1.7.x 1.8.x 1.9.x 1.10.x 1.11.x	1.10.x 1.11.x	1.10.x 1.11.x 1.12.x
Cassandra	3.11.10	3.11.10	3.11.10	3.11.10	3.11.10
^(1) Nelle versioni Anthos 1.8, 1.9 e 1.10, segui le istruzioni riportate in questi documenti per evitare conflitti con cert-manager: Anthos 1.8.2 e versioni successive: Con conflitto con cert-manager durante l'upgrade alla versione 1.8.2 o successive. Anthos 1.9: Con conflitto con cert-manager durante l'upgrade alla versione 1.9.0 o 1.9.1. Anthos 1.10 e versioni successive: Installazione di cert-manager in conflitto. ^(2) Assistenza disponibile con Apigee hybrid versione 1.7.2 e successive. ^(3) Le date ufficiali di ritiro delle versioni 1.8 e precedenti di Apigee hybrid sono state raggiunte. Le patch mensili regolari non sono più disponibili. Queste release non sono più supportate ufficialmente, ad eccezione dei clienti con eccezioni esplicite e ufficiali per il proseguimento del supporto. Gli altri clienti devono eseguire l'upgrade. ^(4)Le versioni 1.12 e precedenti di Anthos on bare metal e VMware non sono più supportate. Consulta le norme relative al supporto delle versioni di Anthos on bare metal e le Cluster Anthos su VMware VMware. ^(5)Anthos on Bare Metal e VMWare richiedono ASM 1.14 o versioni successive. Ti consigliamo di eseguire l'upgrade alla versione 1.8 ibrida e di passare al gateway di ingresso Apigee, che non richiede più l'installazione di ASM sul cluster ibrida. ^(6) Assistenza disponibile con Apigee hybrid versione 1.8.4 e successive. ^(7) I cluster collegati non sono obbligatori per Apigee hybrid 1.8 e versioni successive che utilizzano Apigee ingressgateway.. ^(8) Non supportato con Apigee hybrid versione 1.8.4 e successive. ^(9) Assistenza disponibile con Apigee hybrid versione 1.7.6 e successive. ^(10) Non supportato con Apigee hybrid versione 1.8.5 e successive. ^(11) ASM viene installato automaticamente con Apigee hybrid 1.9 e versioni successive. ^(12) Assistenza disponibile con Apigee hybrid versione 1.9.2 e successive. ^(13) I numeri di versione di Cluster Anthos on AWS (multi-cloud) ora rispecchiano le versioni di Kubernetes. Consulta la versione di Anthos e l'assistenza per l'upgrade per i dettagli delle versioni e le patch consigliate.

Informazioni sui cluster collegati

Per le versioni di Apigee hybrid 1.7.x e precedenti, devi utilizzare i cluster collegati Anthos se vuoi eseguire Apigee hybrid in un contesto multicloud su Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS) o un altro fornitore di servizi Kubernetes di terze parti supportato. L'attacco al cluster consente a Google di misurare l'utilizzo di Anthos Service Mesh (ASM). La registrazione del cluster di terze parti è facoltativa. Registrati solo se vuoi visualizzare il cluster collegato nella Google Cloud Console. Per ulteriori informazioni, consulta Collegare i cluster Kubernetes di terze parti a Google Cloud.

Per la versione ibrida di Apigee 1.8.x, i cluster collegati ad Anthos sono obbligatori se utilizzi Anthos Service Mesh per il gateway in entrata. Se utilizzi il gateway di ingresso Apigee, i cluster Anthos collegati sono facoltativi.

Nota: le installazioni ibride non sono attualmente supportate su GKE Autopilot.

Spostare il traffico da Anthos Service Mesh al gateway di ingresso Apigee

Per indirizzare il traffico al gateway di ingresso Apigee:

1. Esponi il gateway di ingresso Apigee. Segui le procedure descritte in Esporre il gateway di ingresso Apigee.
2. Testa il nuovo gateway di ingresso chiamando un proxy. Idealmente, testa tutti i proxy fondamentali attualmente implementati.
3. Per spostare il traffico, aggiorna i record DNS in modo che rimandino all'indirizzo IP del nuovo gateway di ingresso Apigee. A seconda del provider DNS, potresti essere in grado di spostare gradualmente il traffico sul nuovo endpoint. Suggerimento : puoi trovare l'indirizzo IP esterno del gateway di ingresso Apigee con il seguente comando:

   kubectl get svc -n apigee -l app=apigee-ingressgateway

   L'output dovrebbe avere il seguente aspetto:

   NAME                                        TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)                                      AGE
   apigee-ingressgateway-prod-hybrid-37a39bd   LoadBalancer   192.0.2.123   233.252.0.123   15021:32049/TCP,80:31624/TCP,443:30723/TCP   16h

4. Assicurati che tutto il traffico di runtime funzioni monitorando le dashboard. Vai al passaggio successivo solo se tutto funziona come previsto. Assicurati che non venga inviato traffico tramite il vecchio gateway di ingresso (Anthos Service Mesh), poiché la propagazione dell'aggiornamento DNS potrebbe essere lenta a causa della memorizzazione nella cache DNS.
5. Per impedire ad Apigee di fornire la configurazione ad Anthos Service Mesh, segui i passaggi descritti in Interrompere l'erogazione della configurazione ad ASM nella guida Gestione del gateway di ingresso Apigee.
6. Esegui nuovamente il test e monitora il traffico del proxy API.
7. Segui le istruzioni riportate nella documentazione di Anthos Service Mesh per disinstallare Anthos Service Mesh dal cluster.

Esegui l'upgrade di Anthos Service Mesh alla versione 1.15

Esegui questo passaggio solo se intendi continuare a utilizzare Anthos Service Mesh per il tuo gateway di ingresso anziché il gateway di ingresso Apigee.

Potresti riscontrare una breve interruzione del traffico in entrata (in genere meno di due secondi) durante l'upgrade di Anthos Service Mesh. Se esegui l'aggiornamento a una versione ibrida in due o più cluster, puoi evitare questa interruzione eseguendo l'upgrade di un cluster alla volta. Deviare tutto il traffico di produzione dal cluster di cui stai per eseguire l'upgrade, metterlo offline e procedere con la procedura di upgrade. Ripeti la procedura per ogni cluster.

Esegui le procedure utilizzando la documentazione di Anthos Service Mesh appropriata per la tua piattaforma:

Le istruzioni per installare e configurare Anthos Service Mesh sono diverse a seconda della piattaforma. Le piattaforme sono suddivise nelle seguenti categorie:

• GKE: cluster Google Kubernetes Engine in esecuzione su Google Cloud.
• Al di fuori di Google Cloud: cluster Anthos in esecuzione su:
  • Cluster Anthos su VMware (GKE on-prem)
  • Anthos on bare metal
  • Anthos clusters on AWS
  • Amazon EKS
• Altre piattaforme Kubernetes: cluster conformi creati ed eseguiti su:
  • AKS
  • EKS
  • OpenShift

GKE

La sequenza per eseguire l'upgrade alla versione 1.13.9 di Anthos Service Mesh per l'installazione ibrida è la seguente:

1. Preparati per l'upgrade.
2. Installa la nuova versione di Anthos Service Mesh.
3. Elimina i deployment, i servizi e gli webhook della versione precedente di Anthos Service Mesh dalla tua installazione attuale.
4. Esegui l'upgrade dei gateway e configura i nuovi webhook.

Preparati a eseguire l'upgrade di Anthos Service Mesh alla versione 1.13.9

Nota: puoi eseguire l'upgrade direttamente dalla versione 1.11 o superiore di Anthos Service Mesh alla versione 1.13.9di Anthos Service Mesh. Se utilizzi una versione di Anthos Service Mesh precedente alla 1.11, devi prima eseguire l'upgrade alla versione 1.11. Segui le istruzioni riportate in Upgrade da versioni precedenti

1. Esamina i requisiti in Eseguire l'upgrade di Anthos Service Mesh, ma non eseguire ancora l'upgrade.
2. Prima di installare la nuova versione, determina la revisione corrente. Ti serviranno queste informazioni per eliminare i deployment, i servizi e gli webhook della versione precedente di Anthos Service Mesh dalla tua installazione attuale. Utilizza il seguente comando per archiviare la revisione istiod corrente in una variabile di ambiente:

   export DELETE_REV=$(kubectl get deploy -n istio-system -l app=istiod -o jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}')
   echo $DELETE_REV

   L'output dovrebbe avere il seguente aspetto: 1.12.9-asm.2

   Nota: se il comando restituisce più valori, imposta il valore di DELETE_REV sulla versione più vecchia e segui la procedura per eliminarla, quindi ripeti la procedura fino a quando non avrai eliminato tutte le versioni.
3. Crea un nuovo file overlay.yaml o verifica che quello esistente overlay.yaml contenga i seguenti contenuti:

   apiVersion: install.istio.io/v1alpha1
   kind: IstioOperator
   spec:
     components:
       ingressGateways:
       - name: istio-ingressgateway
         enabled: true
         k8s:
           nodeSelector:
             # default node selector, if different or not using node selectors, change accordingly.
             cloud.google.com/gke-nodepool: apigee-runtime
           resources:
             requests:
               cpu: 1000m
           service:
             type: LoadBalancer
             loadBalancerIP: STATIC_IP # If you do not have a reserved static IP, leave this out.
             ports:
               - name: http-status-port
                 port: 15021
               - name: http2
                 port: 80
                 targetPort: 8080
               - name: https
                 port: 443
                 targetPort: 8443
     meshConfig:
       accessLogFormat:
         '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'

4. Segui le istruzioni riportate nelle seguenti sezioni della documentazione di Anthos Service Mesh:
   Importante: assicurati di seguire le istruzioni per eseguire l'upgrade di Anthos Service Mesh con le funzionalità facoltative e per includere il tuo overlay.yaml.
   1. Scarica asmcli
   2. Concedere le autorizzazioni di amministratore del cluster
   3. Convalida progetto e cluster
   4. Eseguire l'upgrade con funzionalità facoltative. Interrompi prima di iniziare la sezione "Eseguire l'upgrade dei gateway".
5. Passa al nuovo control plane:
   1. Recupera l'etichetta di revisione su istiod:

      kubectl get pod -n istio-system -L istio.io/rev

      L'output del comando è simile al seguente.

          NAME                                  READY  STATUS  RESTARTS   AGE  REV
          istiod-asm-1139-10-67998f4b55-lrzpz    1/1    Running  0         68m  asm-1129-0
          istiod-asm-1139-10-67998f4b55-r76kr    1/1    Running  0         68m  asm-1129-0
          istiod-1129-0-1-5cd96f88f6-n7tj9      1/1    Running  0         27s  asm-1139-10
          istiod-1129-0-1-5cd96f88f6-wm68b      1/1    Running  0         27s  asm-1139-10

   2. Assegna l'etichetta della revisione più recente a una variabile di ambiente.

      Nell'output, nella colonna REV, prendi nota del valore dell'etichetta della revisione per la nuova versione. In questo esempio, il valore è asm-1139-10

      export UPGRADE_REV="REVISION_LABEL"

   3. Aggiungi l'etichetta di revisione allo spazio dei nomi istio-system e rimuovi l'etichetta istio-injection (se esistente) con il seguente comando.

      kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV istio-injection- --overwrite

      Se nell'output viene visualizzato "istio-injection not found", puoi ignorarlo. Ciò significa che in precedenza lo spazio dei nomi non aveva l'etichetta istio-injection. Poiché l'iniezione automatica non riesce se un spazio dei nomi contiene sia l'etichetta istio-injection sia l'etichetta di revisione, tutti i comandi kubectl label nella documentazione di Anthos Service Mesh includono la rimozione dell'etichetta istio-injection.

   4. Riavvia i pod per attivare la re-iniezione.

      kubectl rollout restart deployment -n istio-system

   5. Testa l'applicazione per verificare che i carichi di lavoro funzionino correttamente.
   6. Se hai carichi di lavoro in altri spazi dei nomi, ripeti i passaggi per etichettare lo spazio dei nomi e riavviare i pod.
6. Elimina le versioni precedenti:
   1. Vai alla directory in cui hai installato asmcli.
   2. Memorizza la directory di output per l'installazione di Anthos Service Mesh nella variabile di ambiente DIR_PATH. Si tratta della stessa directory specificata nella procedura di upgrade con funzionalità facoltative.

      export DIR_PATH=OUTPUT_DIR

   3. Crea uno script shell contenente i seguenti comandi:

      #!/bin/bash
      
      set -ex
      
      if [[ "${DELETE_REV}" != "${UPGRADE_REV}" ]]; then
        kubectl apply -f ${DIR_PATH}/asm/istio/istiod-service.yaml
        kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete deploy -l app=istio-ingressgateway-connectors,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete ValidatingWebhookConfiguration -l app=istiod,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete MutatingWebhookConfiguration -l app=sidecar-injector,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete IstioOperator installed-state-${DELETE_REV} -n istio-system --ignore-not-found=true
      fi
      

   4. Esegui lo script per eliminare le versioni precedenti.

Al di fuori di Google Cloud

Queste istruzioni riguardano l'upgrade di Anthos Service Mesh su:

• Cluster Anthos su VMware (GKE on-prem)
• Anthos on bare metal
• Anthos clusters on AWS
• Amazon EKS

La sequenza per eseguire l'upgrade alla versione 1.13.9 di Anthos Service Mesh per l'installazione ibrida è la seguente:

1. Preparati per l'upgrade.
2. Installa la nuova versione di Anthos Service Mesh.
3. Elimina i deployment, i servizi e gli webhook della versione precedente di Anthos Service Mesh dalla tua installazione attuale.
4. Esegui l'upgrade dei gateway e configura i nuovi webhook.

Preparati a eseguire l'upgrade di Anthos Service Mesh alla versione 1.13.9

Nota: puoi eseguire l'upgrade direttamente dalla versione 1.11 o superiore di Anthos Service Mesh alla versione 1.13.9di Anthos Service Mesh. Se utilizzi una versione di Anthos Service Mesh precedente alla 1.11, devi prima eseguire l'upgrade alla versione 1.11. Segui le istruzioni riportate in Upgrade da versioni precedenti

1. Esamina i requisiti in Eseguire l'upgrade di Anthos Service Mesh, ma non eseguire ancora l'upgrade.
2. Prima di installare la nuova versione, determina la revisione corrente. Ti serviranno queste informazioni per eliminare i deployment, i servizi e gli webhook della versione precedente di Anthos Service Mesh dalla tua installazione attuale. Utilizza il seguente comando per archiviare la revisione istiod corrente in una variabile di ambiente:

   export DELETE_REV=$(kubectl get deploy -n istio-system -l app=istiod -o jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}')
   echo $DELETE_REV

   L'output dovrebbe avere il seguente aspetto: 1.12.9-asm.2

   Nota: se il comando restituisce più valori, imposta il valore di DELETE_REV sulla versione più vecchia e segui la procedura per eliminarla, quindi ripeti la procedura fino a quando non avrai eliminato tutte le versioni.
3. Crea un nuovo file overlay.yaml o verifica che quello esistente overlay.yaml contenga i seguenti contenuti:

   apiVersion: install.istio.io/v1alpha1
   kind: IstioOperator
   spec:  
     components:
       ingressGateways:
       - name: istio-ingressgateway
         enabled: true
         k8s:
           nodeSelector:
             # default node selector, if different or not using node selectors, change accordingly.
             cloud.google.com/gke-nodepool: apigee-runtime
           resources:
             requests:
               cpu: 1000m
           service:
             type: LoadBalancer
             loadBalancerIP: STATIC_IP # If you do not have a reserved static IP, leave this out.
             ports:
               - name: http-status-port
                 port: 15021
               - name: http2
                 port: 80
                 targetPort: 8080
               - name: https
                 port: 443
                 targetPort: 8443
     values:
       gateways:
         istio-ingressgateway:
           runAsRoot: true
   
     meshConfig:
       accessLogFormat:
         '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'

4. Segui le istruzioni riportate nelle seguenti sezioni della documentazione di Anthos Service Mesh:
   Importante: assicurati di seguire le istruzioni per eseguire l'upgrade di Anthos Service Mesh con le funzionalità facoltative e per includere il tuo overlay.yaml.
   1. Scarica asmcli
   2. Concedere le autorizzazioni di amministratore del cluster
   3. Convalida progetto e cluster
   4. Eseguire l'upgrade con funzionalità facoltative. Interrompi prima di iniziare la sezione "Eseguire l'upgrade dei gateway".
5. Passa al nuovo control plane:
   1. Recupera l'etichetta di revisione su istiod:

      kubectl get pod -n istio-system -L istio.io/rev

      L'output del comando è simile al seguente.

          NAME                                  READY  STATUS  RESTARTS   AGE  REV
          istiod-asm-1139-10-67998f4b55-lrzpz    1/1    Running  0         68m  asm-1129-0
          istiod-asm-1139-10-67998f4b55-r76kr    1/1    Running  0         68m  asm-1129-0
          istiod-1129-0-1-5cd96f88f6-n7tj9      1/1    Running  0         27s  asm-1139-10
          istiod-1129-0-1-5cd96f88f6-wm68b      1/1    Running  0         27s  asm-1139-10

   2. Assegna l'etichetta della revisione più recente a una variabile di ambiente.

      Nell'output, nella colonna REV, prendi nota del valore dell'etichetta della revisione per la nuova versione. In questo esempio, il valore è asm-1139-10

      export UPGRADE_REV="REVISION_LABEL"

   3. Aggiungi l'etichetta di revisione allo spazio dei nomi istio-system e rimuovi l'etichetta istio-injection (se esistente) con il seguente comando.

      kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV istio-injection- --overwrite

      Se nell'output viene visualizzato "istio-injection not found", puoi ignorarlo. Ciò significa che in precedenza lo spazio dei nomi non aveva l'etichetta istio-injection. Poiché l'iniezione automatica non riesce se un spazio dei nomi contiene sia l'etichetta istio-injection sia l'etichetta di revisione, tutti i comandi kubectl label nella documentazione di Anthos Service Mesh includono la rimozione dell'etichetta istio-injection.

   4. Riavvia i pod per attivare la re-iniezione.

      kubectl rollout restart deployment -n istio-system

   5. Testa l'applicazione per verificare che i carichi di lavoro funzionino correttamente.
   6. Se hai carichi di lavoro in altri spazi dei nomi, ripeti i passaggi per etichettare lo spazio dei nomi e riavviare i pod.
6. Elimina le versioni precedenti:
   1. Vai alla directory in cui hai installato asmcli.
   2. Memorizza la directory di output per l'installazione di Anthos Service Mesh nella variabile di ambiente DIR_PATH. Si tratta della stessa directory specificata nella procedura di upgrade con funzionalità facoltative.

      export DIR_PATH=OUTPUT_DIR

   3. Crea uno script shell contenente i seguenti comandi:

      #!/bin/bash
      
      set -ex
      
      if [[ "${DELETE_REV}" != "${UPGRADE_REV}" ]]; then
        kubectl apply -f ${DIR_PATH}/asm/istio/istiod-service.yaml
        kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete deploy -l app=istio-ingressgateway-connectors,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete ValidatingWebhookConfiguration -l app=istiod,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete MutatingWebhookConfiguration -l app=sidecar-injector,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete IstioOperator installed-state-${DELETE_REV} -n istio-system --ignore-not-found=true
      fi
      

   4. Esegui lo script per eliminare le versioni precedenti.

AKS / EKS

In queste istruzioni, la procedura di upgrade della versione istio-1.13.9-asm.10 di Anthos Service Mesh (Anthos Service Mesh) sui cluster Anthos collegati è la stessa di un'installazione da zero.

Preparazione all'installazione di Anthos Service Mesh

1. Prima di installare la nuova versione, determina la revisione corrente. Ti serviranno queste informazioni per eliminare il webhook di convalida e il webhook di mutazione dalla tua attuale installazione di Anthos Service Mesh. Utilizza il seguente comando per archiviare la revisione corrente istiod in una variabile di ambiente:

   export DELETE_REV=$(kubectl get deploy -n istio-system -l app=istiod -o jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}')
   echo $DELETE_REV

   L'output dovrebbe avere il seguente aspetto: 1.12.9-asm.2

   Nota: se il comando restituisce più valori, imposta il valore di DELETE_REV sulla versione più vecchia e segui la procedura per eliminarla, quindi ripeti la procedura fino a quando non avrai eliminato tutte le versioni.

Linux

Scarica il file di installazione di Anthos Service Mesh nella directory di lavoro corrente:

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-linux-amd64.tar.gz

Scarica il file della firma e utilizza OpenSSL per verificarla:

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-linux-amd64.tar.gz.1.sig

openssl dgst -verify /dev/stdin -signature istio-1.13.9-asm.10-linux-amd64.tar.gz.1.sig istio-1.13.9-asm.10.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

Estrai i contenuti del file in qualsiasi posizione del file system. Ad esempio, per estrarre i contenuti nella directory di lavoro corrente:

tar xzf istio-1.13.9-asm.10-linux-amd64.tar.gz

Il comando crea una directory di installazione nella directory di lavoro corrente denominata istio-1.13.9-asm.10 che contiene:

• Applicazioni di esempio nella directory samples.
• Lo strumento a riga di comando istioctl che utilizzi per installare Anthos Service Mesh si trova nella directory bin.
• I profili di configurazione di Anthos Service Mesh si trovano nella directory manifests/profiles.

Assicurati di essere nella directory principale dell'installazione di Anthos Service Mesh:

cd istio-1.13.9-asm.10

Per comodità, aggiungi gli strumenti nella directory /bin a PATH:

export PATH=$PWD/bin:$PATH

Mac OS

Scarica il file di installazione di Anthos Service Mesh nella directory di lavoro corrente:

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-osx.tar.gz

Scarica il file della firma e utilizza OpenSSL per verificarla:

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-osx.tar.gz.1.sig

openssl dgst -sha256 -verify /dev/stdin -signature istio-1.13.9-asm.10-osx.tar.gz.1.sig istio-1.13.9-asm.10.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

Estrai i contenuti del file in qualsiasi posizione del file system. Ad esempio, per estrarre i contenuti nella directory di lavoro corrente:

tar xzf istio-1.13.9-asm.10-osx.tar.gz

Il comando crea una directory di installazione nella directory di lavoro corrente denominata istio-1.13.9-asm.10 che contiene:

• Applicazioni di esempio nella directory samples.
• Lo strumento a riga di comando istioctl che utilizzi per installare Anthos Service Mesh si trova nella directory bin.
• I profili di configurazione di Anthos Service Mesh si trovano nella directory manifests/profiles.

Assicurati di essere nella directory principale dell'installazione di Anthos Service Mesh:

cd istio-1.13.9-asm.10

Per comodità, aggiungi gli strumenti nella directory /bin a PATH:

export PATH=$PWD/bin:$PATH

Windows

Scarica il file di installazione di Anthos Service Mesh nella directory di lavoro corrente:

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-win.zip

Scarica il file della firma e utilizza OpenSSL per verificarla:

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-win.zip.1.sig

openssl dgst -verify - -signature istio-1.13.9-asm.10-win.zip.1.sig istio-1.13.9-asm.10.win.zip <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

Estrai i contenuti del file in qualsiasi posizione del file system. Ad esempio, per estrarre i contenuti nella directory di lavoro corrente:

tar xzf istio-1.13.9-asm.10-win.zip

Il comando crea una directory di installazione nella directory di lavoro corrente denominata istio-1.13.9-asm.10 che contiene:

• Applicazioni di esempio nella directory samples.
• Lo strumento a riga di comando istioctl che utilizzi per installare Anthos Service Mesh si trova nella directory bin.
• I profili di configurazione di Anthos Service Mesh si trovano nella directory manifests\profiles.

Assicurati di essere nella directory principale dell'installazione di Anthos Service Mesh:

cd istio-1.13.9-asm.10

Per comodità, aggiungi gli strumenti nella directory \bin al tuo PATH:

set PATH=%CD%\bin:%PATH%

2. Ora che Anthos Service Mesh Istio è installato, controlla la versione di istioctl:

   istioctl version

3. Crea uno spazio dei nomi denominato istio-system per i componenti del piano di controllo:

   kubectl create namespace istio-system

Installazione di Anthos Service Mesh

1. Modifica il file overlay.yaml o creane uno nuovo con i seguenti contenuti:

   apiVersion: install.istio.io/v1alpha1
   kind: IstioOperator
   spec:
     meshConfig:
       accessLogFile: /dev/stdout
       enableTracing: true
       accessLogFormat:
         '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'
     components:
       ingressGateways:
       - name: istio-ingressgateway
         enabled: true
         k8s:
           service:
             type: LoadBalancer
             ports:
             - name: status-port
               port: 15021
               targetPort: 15021
             - name: http2
               port: 80
               targetPort: 8080
             - name: https
               port: 443
               targetPort: 8443
   

2. Installa Anthos Service Mesh con istioctl utilizzando il profilo asm-multicloud:

   istioctl install \
       --set profile=asm-multicloud \
       --set revision="asm-1139-10" \
       --filename overlay.yaml

   L'output dovrebbe avere il seguente aspetto:

   kubectl get pods -n istio-system
   NAME                                   READY   STATUS    RESTARTS   AGE
   istio-ingressgateway-88b6fd976-flgp2   1/1     Running   0          3m13s
   istio-ingressgateway-88b6fd976-p5dl9   1/1     Running   0          2m57s
   istiod-asm-1139-10-798ffb964-2ls88       1/1     Running   0          3m21s
   istiod-asm-1139-10-798ffb964-fnj8c       1/1     Running   1          3m21s

   L'argomento --set revision aggiunge un'etichetta di revisione nel formato istio.io/rev=asm-1139-10 a istiod. L'etichetta di revisione viene utilizzata dal webhook dell'iniettore di sidecar automatico per associare i sidecar iniettati a una determinata istiod revisione. Per attivare l'iniezione automatica di sidecar per uno spazio dei nomi, devi etichettarlo con una revisione corrispondente a quella dell'etichetta in istiod.

3. Verifica che l'installazione sia stata completata:

   kubectl get svc -n istio-system

   L'output dovrebbe avere il seguente aspetto:

   NAME                   TYPE           CLUSTER-IP       EXTERNAL-IP     PORT(S)                                                                      AGE
   istio-ingressgateway   LoadBalancer   172.200.48.52    34.74.177.168   15021:30479/TCP,80:30030/TCP,443:32200/TCP,15012:32297/TCP,15443:30244/TCP   3m35s
   istiod                 ClusterIP      172.200.18.133   <none>          15010/TCP,15012/TCP,443/TCP,15014/TCP                                        4m46s
   istiod-asm-1139-10       ClusterIP      172.200.63.220   <none>          15010/TCP,15012/TCP,443/TCP,15014/TCP                                        3m43s

4. Passa al nuovo control plane:
   1. Recupera l'etichetta di revisione su istiod:

      kubectl get pod -n istio-system -L istio.io/rev

      L'output del comando è simile al seguente.

          NAME                                  READY  STATUS  RESTARTS   AGE  REV
          istiod-asm-1139-10-67998f4b55-lrzpz    1/1    Running  0         68m  asm-1129-0
          istiod-asm-1139-10-67998f4b55-r76kr    1/1    Running  0         68m  asm-1129-0
          istiod-1129-0-1-5cd96f88f6-n7tj9      1/1    Running  0         27s  asm-1139-10
          istiod-1129-0-1-5cd96f88f6-wm68b      1/1    Running  0         27s  asm-1139-10

   2. Assegna l'etichetta della revisione più recente a una variabile di ambiente.

      Nell'output, nella colonna REV, prendi nota del valore dell'etichetta della revisione per la nuova versione. In questo esempio, il valore è asm-1139-10

      export UPGRADE_REV="REVISION_LABEL"

   3. Aggiungi l'etichetta di revisione allo spazio dei nomi istio-system e rimuovi l'etichetta istio-injection (se esistente) con il seguente comando.

      kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV istio-injection- --overwrite

      Se nell'output viene visualizzato "istio-injection not found", puoi ignorarlo. Ciò significa che in precedenza lo spazio dei nomi non aveva l'etichetta istio-injection. Poiché l'iniezione automatica non riesce se un spazio dei nomi contiene sia l'etichetta istio-injection sia l'etichetta di revisione, tutti i comandi kubectl label nella documentazione di Anthos Service Mesh includono la rimozione dell'etichetta istio-injection.

   4. Riavvia i pod per attivare la re-iniezione.

      kubectl rollout restart deployment -n istio-system

   5. Testa l'applicazione per verificare che i carichi di lavoro funzionino correttamente.
   6. Se hai carichi di lavoro in altri spazi dei nomi, ripeti i passaggi per etichettare lo spazio dei nomi e riavviare i pod.
5. Elimina le versioni precedenti:
   1. Vai alla directory in cui hai installato asmcli.
   2. Crea uno script shell contenente i seguenti comandi:

      #!/bin/bash
      
      set -ex
      
      if [[ "${DELETE_REV}" != "${UPGRADE_REV}" ]]; then
        kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete deploy -l app=istio-ingressgateway-connectors,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete ValidatingWebhookConfiguration -l app=istiod,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete MutatingWebhookConfiguration -l app=sidecar-injector,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete IstioOperator installed-state-${DELETE_REV} -n istio-system --ignore-not-found=true
      fi
      

   3. Esegui lo script per eliminare le versioni precedenti.

OpenShift

In queste istruzioni, la procedura di upgrade della versione istio-1.13.9-asm.10 di Anthos Service Mesh (Anthos Service Mesh) sui cluster Anthos collegati è la stessa di un'installazione da zero.

Preparazione all'installazione di Anthos Service Mesh

1. Prima di installare la nuova versione, determina la revisione corrente. Ti serviranno queste informazioni per eliminare il webhook di convalida e il webhook di mutazione dalla tua attuale installazione di Anthos Service Mesh. Utilizza il seguente comando per archiviare la revisione corrente istiod in una variabile di ambiente:

   export DELETE_REV=$(kubectl get deploy -n istio-system -l app=istiod -o jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}')
   echo $DELETE_REV

   L'output dovrebbe avere il seguente aspetto: 1.12.9-asm.2

   Nota: se il comando restituisce più valori, imposta il valore di DELETE_REV sulla versione più vecchia e segui la procedura per eliminarla, quindi ripeti la procedura fino a quando non avrai eliminato tutte le versioni.

Linux

Concedi la limitazione del contesto di sicurezza anyuid (SCC) a istio-system con il seguente comando OpenShift CLI (oc):

oc adm policy add-scc-to-group anyuid system:serviceaccounts:istio-system

Scarica il file di installazione di Anthos Service Mesh nella directory di lavoro corrente:

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-linux-amd64.tar.gz

Scarica il file della firma e utilizza OpenSSL per verificarla:

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-linux-amd64.tar.gz.1.sig

openssl dgst -verify /dev/stdin -signature istio-1.13.9-asm.10-linux-amd64.tar.gz.1.sig istio-1.13.9-asm.10.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

Estrai i contenuti del file in qualsiasi posizione del file system. Ad esempio, per estrarre i contenuti nella directory di lavoro corrente:

tar xzf istio-1.13.9-asm.10-linux-amd64.tar.gz

Il comando crea una directory di installazione nella directory di lavoro corrente denominata istio-1.13.9-asm.10 che contiene:

• Applicazioni di esempio nella directory samples.
• Lo strumento a riga di comando istioctl che utilizzi per installare Anthos Service Mesh si trova nella directory bin.
• I profili di configurazione di Anthos Service Mesh si trovano nella directory manifests/profiles.

Assicurati di essere nella directory principale dell'installazione di Anthos Service Mesh:

cd istio-1.13.9-asm.10

Per comodità, aggiungi gli strumenti nella directory /bin a PATH:

export PATH=$PWD/bin:$PATH

Mac OS

Concedi la limitazione del contesto di sicurezza anyuid (SCC) a istio-system con il seguente comando OpenShift CLI (oc):

oc adm policy add-scc-to-group anyuid system:serviceaccounts:istio-system

Scarica il file di installazione di Anthos Service Mesh nella directory di lavoro corrente:

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-osx.tar.gz

Scarica il file della firma e utilizza OpenSSL per verificarla:

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-osx.tar.gz.1.sig

openssl dgst -sha256 -verify /dev/stdin -signature istio-1.13.9-asm.10-osx.tar.gz.1.sig istio-1.13.9-asm.10.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

Estrai i contenuti del file in qualsiasi posizione del file system. Ad esempio, per estrarre i contenuti nella directory di lavoro corrente:

tar xzf istio-1.13.9-asm.10-osx.tar.gz

Il comando crea una directory di installazione nella directory di lavoro corrente denominata istio-1.13.9-asm.10 che contiene:

• Applicazioni di esempio nella directory samples.
• Lo strumento a riga di comando istioctl che utilizzi per installare Anthos Service Mesh si trova nella directory bin.
• I profili di configurazione di Anthos Service Mesh si trovano nella directory manifests/profiles.

Assicurati di essere nella directory principale dell'installazione di Anthos Service Mesh:

cd istio-1.13.9-asm.10

Per comodità, aggiungi gli strumenti nella directory /bin a PATH:

export PATH=$PWD/bin:$PATH

Windows

Concedi la limitazione del contesto di sicurezza anyuid (SCC) a istio-system con il seguente comando OpenShift CLI (oc):

oc adm policy add-scc-to-group anyuid system:serviceaccounts:istio-system

Scarica il file di installazione di Anthos Service Mesh nella directory di lavoro corrente:

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-win.zip

Scarica il file della firma e utilizza OpenSSL per verificarla:

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-win.zip.1.sig

openssl dgst -verify - -signature istio-1.13.9-asm.10-win.zip.1.sig istio-1.13.9-asm.10.win.zip <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

Estrai i contenuti del file in qualsiasi posizione del file system. Ad esempio, per estrarre i contenuti nella directory di lavoro corrente:

tar xzf istio-1.13.9-asm.10-win.zip

Il comando crea una directory di installazione nella directory di lavoro corrente denominata istio-1.13.9-asm.10 che contiene:

• Applicazioni di esempio nella directory samples.
• Lo strumento a riga di comando istioctl che utilizzi per installare Anthos Service Mesh si trova nella directory bin.
• I profili di configurazione di Anthos Service Mesh si trovano nella directory manifests\profiles.

Assicurati di essere nella directory principale dell'installazione di Anthos Service Mesh:

cd istio-1.13.9-asm.10

Per comodità, aggiungi gli strumenti nella directory \bin al tuo PATH:

set PATH=%CD%\bin:%PATH%

2. Ora che Anthos Service Mesh Istio è installato, controlla la versione di istioctl:

   istioctl version

3. Crea uno spazio dei nomi denominato istio-system per i componenti del piano di controllo:

   kubectl create namespace istio-system

Configura il webhook di convalida

Quando installi Anthos Service Mesh, imposti un'etichetta di revisione su istiod. Devi impostare la stessa revisione sul webhook di convalida.

1. Crea un file denominato istiod-service.yaml con i seguenti contenuti:

   apiVersion: v1
   kind: Service
   metadata:
     name: istiod
     namespace: istio-system
     labels:
       istio.io/rev: asm-1139-10
       app: istiod
       istio: pilot
       release: istio
   spec:
     ports:
       - port: 15010
         name: grpc-xds # plaintext
         protocol: TCP
       - port: 15012
         name: https-dns # mTLS with k8s-signed cert
         protocol: TCP
       - port: 443
         name: https-webhook # validation and injection
         targetPort: 15017
         protocol: TCP
       - port: 15014
         name: http-monitoring # prometheus stats
         protocol: TCP
     selector:
       app: istiod
       istio.io/rev: asm-1139-10
     meshConfig:
       accessLogFormat:
         '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'

2. Utilizza kubectl per applicare la configurazione dell'webhook di convalida:

   kubectl apply -f istiod-service.yaml

3. Verifica che la configurazione sia stata applicata:

   kubectl get svc -n istio-system

   La risposta dovrebbe essere simile alla seguente:

   NAME     TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                                 AGE
   istiod   ClusterIP   172.200.18.133   <none>        15010/TCP,15012/TCP,443/TCP,15014/TCP   22s

Installazione di Anthos Service Mesh

1. Modifica il file overlay.yaml o creane uno nuovo con i seguenti contenuti:

   apiVersion: install.istio.io/v1alpha1
   kind: IstioOperator
   spec:
     meshConfig:
       accessLogFile: /dev/stdout
       enableTracing: true
       accessLogFormat:
         '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'
     components:
       ingressGateways:
         - name: istio-ingressgateway
           enabled: true
           k8s:
             service:
               type: LoadBalancer
               ports:
               - name: status-port
                 port: 15021
                 targetPort: 15021
               - name: http2
                 port: 80
                 targetPort: 8080
               - name: https
                 port: 443
                 targetPort: 8443
   

2. Installa Anthos Service Mesh con istioctl utilizzando il profilo asm-multicloud:

   istioctl install \
       --set profile=asm-multicloud \
       --set revision="asm-1139-10" \
       --filename overlayfile.yaml

   L'output dovrebbe avere il seguente aspetto:

   kubectl get pods -n istio-system
   NAME                                   READY   STATUS    RESTARTS   AGE
   istio-ingressgateway-88b6fd976-flgp2   1/1     Running   0          3m13s
   istio-ingressgateway-88b6fd976-p5dl9   1/1     Running   0          2m57s
   istiod-asm-1139-10-798ffb964-2ls88       1/1     Running   0          3m21s
   istiod-asm-1139-10-798ffb964-fnj8c       1/1     Running   1          3m21s

   L'argomento --set revision aggiunge un'etichetta di revisione nel formato istio.io/rev=1.6.11-asm.1 a istiod. L'etichetta di revisione viene utilizzata dal webhook dell'iniettore di sidecar automatico per associare i sidecar iniettati a una determinata istiod revisione. Per attivare l'iniezione automatica di sidecar per uno spazio dei nomi, devi etichettarlo con una revisione corrispondente a quella dell'etichetta in istiod.

3. Verifica che l'installazione sia stata completata:

   kubectl get svc -n istio-system

   L'output dovrebbe avere il seguente aspetto:

   NAME                   TYPE           CLUSTER-IP       EXTERNAL-IP     PORT(S)                                                                      AGE
   istio-ingressgateway   LoadBalancer   172.200.48.52    34.74.177.168   15021:30479/TCP,80:30030/TCP,443:32200/TCP,15012:32297/TCP,15443:30244/TCP   3m35s
   istiod                 ClusterIP      172.200.18.133   <none>          15010/TCP,15012/TCP,443/TCP,15014/TCP                                        4m46s
   istiod-asm-1139-10       ClusterIP      172.200.63.220   <none>          15010/TCP,15012/TCP,443/TCP,15014/TCP                                        3m43s

4. Passa al nuovo control plane:
   1. Recupera l'etichetta di revisione su istiod:

      kubectl get pod -n istio-system -L istio.io/rev

      L'output del comando è simile al seguente.

          NAME                                  READY  STATUS  RESTARTS   AGE  REV
          istiod-asm-1139-10-67998f4b55-lrzpz    1/1    Running  0         68m  asm-1129-0
          istiod-asm-1139-10-67998f4b55-r76kr    1/1    Running  0         68m  asm-1129-0
          istiod-1129-0-1-5cd96f88f6-n7tj9      1/1    Running  0         27s  asm-1139-10
          istiod-1129-0-1-5cd96f88f6-wm68b      1/1    Running  0         27s  asm-1139-10

   2. Assegna l'etichetta della revisione più recente a una variabile di ambiente.

      Nell'output, nella colonna REV, prendi nota del valore dell'etichetta della revisione per la nuova versione. In questo esempio, il valore è asm-1139-10

      export UPGRADE_REV="REVISION_LABEL"

   3. Aggiungi l'etichetta di revisione allo spazio dei nomi istio-system e rimuovi l'etichetta istio-injection (se esistente) con il seguente comando.

      kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV istio-injection- --overwrite

      Se nell'output viene visualizzato "istio-injection not found", puoi ignorarlo. Ciò significa che in precedenza lo spazio dei nomi non aveva l'etichetta istio-injection. Poiché l'iniezione automatica non riesce se un spazio dei nomi contiene sia l'etichetta istio-injection sia l'etichetta di revisione, tutti i comandi kubectl label nella documentazione di Anthos Service Mesh includono la rimozione dell'etichetta istio-injection.

   4. Riavvia i pod per attivare la re-iniezione.

      kubectl rollout restart deployment -n istio-system

   5. Testa l'applicazione per verificare che i carichi di lavoro funzionino correttamente.
   6. Se hai carichi di lavoro in altri spazi dei nomi, ripeti i passaggi per etichettare lo spazio dei nomi e riavviare i pod.
5. Elimina le versioni precedenti:
   1. Vai alla directory in cui hai installato asmcli.
   2. Crea uno script shell contenente i seguenti comandi:

      #!/bin/bash
      
      set -ex
      
      if [[ "${DELETE_REV}" != "${UPGRADE_REV}" ]]; then
        kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete deploy -l app=istio-ingressgateway-connectors,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete ValidatingWebhookConfiguration -l app=istiod,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete MutatingWebhookConfiguration -l app=sidecar-injector,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete IstioOperator installed-state-${DELETE_REV} -n istio-system --ignore-not-found=true
      fi
      

   3. Esegui lo script per eliminare le versioni precedenti.

Congratulazioni! L'upgrade alla versione 1.8.8 di Apigee hybrid è andato a buon fine.

Rollback di un upgrade

Per eseguire il rollback di un upgrade precedente:

1. Ripulisci i job completati per lo spazio dei nomi dell'ambiente di runtime ibrido, dove NAMESPACE è lo spazio dei nomi specificato nel file degli override, se ne hai specificato uno. In caso contrario, lo spazio dei nomi predefinito è apigee:

   kubectl delete job -n NAMESPACE \
     $(kubectl get job -n NAMESPACE \
     -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')

2. Elimina i job completati per lo spazio dei nomi apigee-system:

   kubectl delete job -n apigee-system \
     $(kubectl get job -n apigee-system \
     -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')

3. Modifica la variabile APIGEECTL_HOME in modo che punti alla directory che contiene la versione precedente di apigeectl. Ad esempio:

   export APIGEECTL_HOME=PATH_TO_PREVIOUS_APIGEECTL_DIRECTORY

4. Annulla le modifiche apportate al file overrides:
   1. Rimuovi o inserisci un commento per ingressGateways e tutte le relative proprietà.
   2. Imposta il valore di virtualhosts.selector.app sul valore precedente, ad esempio:

      virtualhosts:
        - name: my-env-group
          selector:
            app: istio-ingressgateway

   3. Rimuovi o commenta ao.args.disableIstioConfigInAPIServer.
5. Nella directory principale dell'installazione a cui vuoi eseguire il rollback, esegui apigeectl apply, controlla lo stato dei pod e poi esegui apigeectl init. Assicurati di utilizzare il file delle sostituzioni originale per la versione di destinazione del rollback:
   1. Nella directory hybrid-files, esegui apigeectl apply:

      $APIGEECTL_HOME/apigeectl apply -f ORIGINAL_OVERRIDES_FILE

      dove ORIGINAL_OVERRIDES_FILE è il percorso relativo e il nome del file delle sostituzioni per l'installazione ibrida della versione precedente, ad esempio ./overrides/overrides1.7.yaml.

   2. Controlla lo stato dei pod:

      kubectl -n NAMESPACE get pods

      dove NAMESPACE è il tuo spazio dei nomi Apigee hybrid.

   3. Controlla lo stato di apigeeds:

      kubectl describe apigeeds -n apigee

      L'output dovrebbe avere il seguente aspetto:

      Status:
        Cassandra Data Replication:
        Cassandra Pod Ips:
          10.8.2.204
        Cassandra Ready Replicas:  1
        Components:
          Cassandra:
            Last Successfully Released Version:
              Revision:  v1-f8aa9a82b9f69613
              Version:   v1
            Replicas:
              Available:  1
              Ready:      1
              Total:      1
              Updated:    1
            State:        running
        Scaling:
          In Progress:         false
          Operation:
          Requested Replicas:  0
        State:                 running

      Vai al passaggio successivo solo quando il pod apigeeds è in esecuzione.

   4. Esegui il seguente comando per annotare i valori del nuovo conteggio delle repliche per il gestore dei messaggi dopo l'upgrade.Se questi valori non corrispondono a quelli impostati in precedenza, modifica i valori nel file delle sostituzioni in modo che corrispondano alla configurazione precedente.

      apigeectl apply -f ORIGINAL_OVERRIDES_FILE --dry-run=client --print-yaml --env ENV_NAME 2>/dev/null |grep "runtime:" -A 25 -B 1| grep "autoScaler" -A 2

      L'output dovrebbe avere il seguente aspetto:

            autoScaler:
              minReplicas: 2
              maxReplicas: 10

   5. Se esegui il rollback alla versione 1.8.4 o precedente di Hybrid, elimina il deployment del controller utilizzato dalla versione 1.8.5 e successive di Hybrid:

      kubectl -n apigee-system delete deploy apigee-controller-manager

   6. Esegui apigeectl init:

      $APIGEECTL_HOME/apigeectl init -f ORIGINAL_OVERRIDES_FILE

6. Elimina l'implementazione del gestore del gateway di ingresso Apigee. Questo componente è pertinente solo per le versioni di Apigee hybrid 1.8 e successive.

   kubectl delete deployment -n NAMESPACE apigee-ingress-gateway-manager

   dove NAMESPACE è il tuo spazio dei nomi Apigee hybrid.