Upgrade di Apigee hybrid alla versione 1.8

Introduzione al gateway in entrata Apigee

A partire dalla versione 1.8, Apigee hybrid offre una nuova funzionalità per gestire il gateway in entrata per la tua installazione ibrida, il gateway Ingress Apigee. Anthos Service Mesh non è più un prerequisito per l'installazione ibrida. Con il gateway in entrata 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 in entrata Apigee prima di poter iniziare a utilizzare la funzionalità.

Apigee utilizza un piccolo sottoinsieme di funzionalità Anthos Service Mesh per il gateway in entrata. A partire dalla versione ibrida 1.8 Apigee hybrid include un gateway in entrata che viene installato e aggiornato nell'ambito degli upgrade ibridi di Apigee. Pertanto non è necessario acquisire esperienza su Anthos Service Mesh per installare, eseguire l'upgrade e gestire Apigee hybrid. I problemi relativi alle versioni dei gateway in entrata e alla compatibilità con le release ibride di Apigee vengono gestiti automaticamente.

Esistono due scenari per la migrazione:

  • Migrazione multi-cluster o più regioni (opzione consigliata):

    Prima di passare a una nuova risorsa Ingress per Apigee, svuota tutto il traffico verso un altro cluster o un'altra regione dal cluster di cui stai eseguendo la migrazione. In questo modo, potrai verificare se il nuovo gateway Ingress Apigee funziona come previsto. Poi riporta il traffico al cluster di cui è stato eseguito l'upgrade.

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

    Durante l'upgrade, Apigee attiverà il nuovo gateway in entrata con un indirizzo IP specificato da te. Puoi quindi verificare se il nuovo gateway in entrata Apigee funziona come previsto e quindi spostare il traffico al nuovo ingresso in entrata. Potrebbero verificarsi tempi di inattività durante l'upgrade.

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

Panoramica dell'upgrade alla versione 1.8.8

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

  1. Preparati per l'upgrade.
  2. Installa la versione del runtime ibrido 1.8.8.
  3. Per il gateway in entrata, scegli una delle seguenti opzioni:

Prerequisiti

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

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

Preparati per l'upgrade alla versione 1.8

  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 in Backup e ripristino 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 già eseguito questo passaggio sull'installazione di ibrida v1.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, di solito si tratta dell'account di servizio apigee-runtime. Per gli ambienti non di produzione, di solito si tratta dell'account di servizio apigee-non-prod.

Puoi aggiungere il ruolo nella UI Console Cloud > IAM e amministratore > Account di servizio o con i seguenti comandi:

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

    Produzione 

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

    Se corrisponde al pattern apigee-runtime@$ORG_NAME.iam.gserviceaccount.com, puoi utilizzare questo pattern nel passaggio successivo.

    Non di produzione 

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

    Se corrisponde al pattern apigee-non-prod@$ORG_NAME.iam.gserviceaccount.com, puoi utilizzare questo pattern 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 di produzione 

    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:apigee-runtime@hybrid-example-project.iam.gserviceaccount.com" \
    --role="roles/cloudtrace.agent"

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

Preparati a installare il gateway in entrata Apigee

a installare il gateway in entrata Apigee nell'ambito dell'upgrade. Devi aggiungere la seguente proprietà ingressGateways al file di override.

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 in entrata. Può essere qualsiasi nome che soddisfi i seguenti requisiti:
    • Hanno 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 alle proprietà di configurazione

  • REPLICAS_MIN e REPLICAS_MAX sono il numero minimo e massimo di repliche per il gateway in entrata Apigee nell'installazione. Per maggiori informazioni e impostazioni predefinite, consulta ingressGateways[].replicaCountMin e ingressGateways[].replicaCountMax nel riferimento alle proprietà di configurazione.
  • CPU_COUNT_REQ e MEMORY_REQ sono le richieste di CPU e memoria per ogni replica del gateway in entrata Apigee nella tua installazione.

    Per maggiori informazioni e impostazioni predefinite, consulta ingressGateways[].resources.requests.cpu e ingressGateways[].resources.requests.memory nel riferimento alle proprietà di configurazione.

  • CPU_COUNT_LIMIT e MEMORY_LIMIT I limiti massimi di CPU e memoria per ogni replica del gateway in entrata Apigee nell'installazione.

    Per maggiori informazioni e impostazioni predefinite, consulta ingressGateways[].resources.limits.cpu e ingressGateways[].resources.limits.memory nel riferimento alle proprietà di configurazione.

  • SVC_ANNOTATIONS_KEY e SVC_ANNOTATIONS_VALUE (facoltativo):

    Questa è una coppia chiave-valore che fornisce annotazioni per il servizio in entrata 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 obbligatorie e suggerite.

    Consulta ingressGateways[].svcAnnotations nel riferimento alle proprietà di configurazione.
  • SVC_LOAD_BALANCER_IP (Facoltativo) Consente di assegnare un indirizzo IP statico per il bilanciatore del carico. Sulle piattaforme che supportano la specifica 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 un indirizzo IP statico allocato per il bilanciatore del carico, escludi questa proprietà dal file di override.

    Consulta ingressGateways[].svcLoadBalancerIP nel riferimento alle proprietà di configurazione.

Apporta ulteriori modifiche al file di override per abilitare o disabilitare le funzionalità facoltative della versione 1.8

Aggiungi le seguenti proprietà al file overrides.yaml per abilitare le nuove funzionalità nella versione ibrida 1.8. Queste funzionalità sono facoltative.

  • La funzionalità UDCA basata sull'organizzazione è ora attiva per impostazione predefinita. L'utilizzo di un singolo deployment UDCA per gestire il traffico per tutti gli ambienti previene il sottoutilizzo dei pod UDCA e aumenta la disponibilità di risorse dei nodi per altri componenti Apigee. UDCA con ambito organizzazione utilizza un unico account di servizio per tutti gli ambienti, apigee-udca.

    Se utilizzi account di servizio diversi per UDCA in ambienti diversi, tieni presente che ora utilizzerà 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 v 1.8 supporta UDCA con ambito a livello di ambiente. Per mantenere la UDCA per ambiente, imposta orgScopedUDCA: false.

    Vedi orgScopedUDCA nel riferimento alle proprietà di configurazione.

  • Abilita validateOrg per richiedere una rigorosa convalida che l'organizzazione e l'ambiente Apigee siano attivi e funzionino con il progetto Google Cloud Platform specificato nel file overrides. 
    validateOrg: true

    Consulta validateOrg nel riferimento per le proprietà di configurazione.

installa il runtime ibrido 1.8.8

  1. Assicurati di essere nella directory di base ibrida (la directory padre della directory in cui si trova il file eseguibile apigeectl): 
    cd $APIGEECTL_HOME/..

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

    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 in un nome di 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 il contenuto del file gzip scaricato nella directory 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. I contenuti tar vengono, per impostazione predefinita, espansi in una directory che contiene 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 è la home directory 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 è la posizione dei file di configurazione, ad esempio il file di override, 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 attuale 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 comando seguente 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 di override, ad esempio ./overrides/overrides.yaml.

  13. Se non ci sono errori, inizializza l'ibrido 1.8.8. Inoltre questo comando installa e configura il gateway in entrata Apigee: 
    $APIGEECTL_HOME/apigeectl init -f OVERRIDES_FILE
  14. Controlla lo stato di inizializzazione: 
    $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

    Se l'operazione riesce, l'output dice: All containers ready.

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

    kubectl describe apigeeds -n apigee

    Cerca State: running nell'output.

  15. Verifica la presenza di errori con una prova 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 gli override. Seleziona e segui le istruzioni per gli ambienti di produzione o non di produzione, a seconda dell'installazione.

    Produzione

    Per gli ambienti di produzione, devi eseguire l'upgrade di ogni componente ibrido singolarmente e controllare lo stato del componente aggiornato prima di passare al componente successivo.

    1. Assicurati di essere nella directory hybrid-files.
    2. Applica gli override per eseguire l'upgrade di Cassandra: 
      $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --datastore
    3. Completamento del controllo: 
      $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

      Procedi al passaggio successivo solo quando i pod sono pronti.

    4. Applica gli override 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. Visualizza i componenti Redis: 
      $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --redis
    6. Applica gli override per eseguire l'upgrade dei componenti a livello di organizzazione (MART, Watcher e Apigee Connect) e verifica il completamento: 
      $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --org
      $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
    7. Applica gli override per eseguire l'upgrade dei tuoi ambienti. Hai due possibilità:
      • Ambiente per ambiente: applica gli override a un ambiente alla volta e verifica 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 gli override a tutti gli ambienti contemporaneamente e verifica il completamento: 
        $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --all-envs
        $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
    8. Applica gli override 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 di produzione

    Nella maggior parte degli ambienti non di produzione, demo o sperimentali, puoi applicare gli override a tutti i componenti contemporaneamente. Se il tuo ambiente non di produzione è di grandi dimensioni e complesso o riproduce da vicino un ambiente di produzione, puoi utilizzare le istruzioni per eseguire 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 tua piattaforma Kubernetes alle versioni supportate dall'ibrido 1.8. Se hai bisogno di assistenza, segui la documentazione della piattaforma.

Sposta il traffico da Anthos Service Mesh al gateway in entrata di Apigee

Per passare il traffico al gateway in entrata Apigee:

  1. Esporre il gateway in entrata Apigee. Segui le procedure descritte in Esponi il gateway in entrata di Apigee.
  2. Testa il nuovo gateway in entrata chiamando un proxy. Idealmente, testa tutti i proxy cruciali di cui hai eseguito il deployment.
  3. Per cambiare il traffico, aggiorna i record DNS in modo che puntino all'indirizzo IP del nuovo gateway in entrata Apigee. A seconda del tuo provider DNS, potresti essere in grado di spostare gradualmente il traffico al nuovo endpoint. Suggerimento : puoi trovare l'indirizzo IP esterno del gateway in entrata Apigee con il seguente comando: 
    kubectl get svc -n apigee -l app=apigee-ingressgateway

    L'output dovrebbe essere simile al seguente: 

    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. Monitora le dashboard per assicurarti che tutto il traffico di runtime funzioni. Procedi al passaggio successivo solo se tutto funziona come previsto. Assicurati che nessun traffico passi attraverso il tuo vecchio gateway in entrata (Anthos Service Mesh), poiché l'aggiornamento del DNS potrebbe essere lento a propagarsi a causa della memorizzazione nella cache del DNS.
  5. Per impedire ad Apigee di fornire la configurazione ad Anthos Service Mesh, segui i passaggi descritti in Interrompere l'invio della configurazione ad ASM nella guida per la gestione del gateway in entrata di Apigee.
  6. Ripeti il test e monitora il traffico del proxy API.
  7. Segui le istruzioni 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 le procedure utilizzando la documentazione di Anthos Service Mesh appropriata per la tua piattaforma:

Le istruzioni per installare e configurare Anthos Service Mesh variano a seconda della piattaforma. Le piattaforme si dividono nelle seguenti categorie:

  • GKE: cluster Google Kubernetes Engine in esecuzione su Google Cloud.
  • All'esterno di Google Cloud: cluster Anthos in esecuzione su:
    • Cluster Anthos su VMware (GKE on-prem)
    • Anthos su Bare Metal
    • Cluster Anthos su AWS
    • Amazon EKS
  • Altre piattaforme Kubernetes: cluster conformi creati e in esecuzione su:
    • AKS
    • EKS
    • OpenShift

GKE

La sequenza per l'upgrade alla versione di Anthos Service Mesh 1.13.9 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 i webhook della versione precedente di Anthos Service Mesh dall'installazione attuale.
  4. Esegui l'upgrade dei gateway e configura i nuovi webhook.

Prepara l'upgrade di Anthos Service Mesh alla versione 1.13.9

  1. Esamina i requisiti in Esegui l'upgrade di Anthos Service Mesh, ma non eseguirlo ancora.
  2. Prima di installare la nuova versione, determina la revisione corrente. Avrai bisogno di queste informazioni per eliminare i deployment, i servizi e i webhook della versione precedente di Anthos Service Mesh dall'installazione attuale. Utilizza il comando seguente per archiviare la revisione istiod attuale 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 essere simile a 1.12.9-asm.2.

  3. Crea un nuovo file overlay.yaml o verifica che il file overlay.yaml esistente includa 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 nelle sezioni seguenti della documentazione di Anthos Service Mesh:
    1. Scarica asmcli
    2. Concedi le autorizzazioni di amministratore del cluster
    3. Convalida progetto e cluster
    4. Esegui l'upgrade con funzionalità facoltative. Interrompi prima di avviare la sezione "Esegui l'upgrade dei gateway".
  5. Passa al nuovo piano di controllo:
    1. Ottieni l'etichetta della 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 di revisione più recente a una variabile di ambiente.

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

      export UPGRADE_REV="REVISION_LABEL"
    3. Aggiungi l'etichetta della 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 vedi "istio-injection not found" nell'output, puoi ignorarlo. Ciò significa che in precedenza lo spazio dei nomi non aveva l'etichetta istio-injection. Poiché l'inserimento automatico non va a buon fine se uno 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 reiniezione. 
      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. Archivia 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 Esegui l'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 su Bare Metal
  • Cluster Anthos su AWS
  • Amazon EKS

La sequenza per l'upgrade alla versione di Anthos Service Mesh 1.13.9 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 i webhook della versione precedente di Anthos Service Mesh dall'installazione attuale.
  4. Esegui l'upgrade dei gateway e configura i nuovi webhook.

Prepara l'upgrade di Anthos Service Mesh alla versione 1.13.9

  1. Esamina i requisiti in Esegui l'upgrade di Anthos Service Mesh, ma non eseguirlo ancora.
  2. Prima di installare la nuova versione, determina la revisione corrente. Avrai bisogno di queste informazioni per eliminare i deployment, i servizi e i webhook della versione precedente di Anthos Service Mesh dall'installazione attuale. Utilizza il comando seguente per archiviare la revisione istiod attuale 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 essere simile a 1.12.9-asm.2.

  3. Crea un nuovo file overlay.yaml o verifica che il file overlay.yaml esistente includa 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 nelle sezioni seguenti della documentazione di Anthos Service Mesh:
    1. Scarica asmcli
    2. Concedi le autorizzazioni di amministratore del cluster
    3. Convalida progetto e cluster
    4. Esegui l'upgrade con funzionalità facoltative. Interrompi prima di avviare la sezione "Esegui l'upgrade dei gateway".
  5. Passa al nuovo piano di controllo:
    1. Ottieni l'etichetta della 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 di revisione più recente a una variabile di ambiente.

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

      export UPGRADE_REV="REVISION_LABEL"
    3. Aggiungi l'etichetta della 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 vedi "istio-injection not found" nell'output, puoi ignorarlo. Ciò significa che in precedenza lo spazio dei nomi non aveva l'etichetta istio-injection. Poiché l'inserimento automatico non va a buon fine se uno 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 reiniezione. 
      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. Archivia 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 Esegui l'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, il processo di upgrade della versione istio-1.13.9-asm.10 di Anthos Service Mesh (Anthos Service Mesh) sui cluster collegati ad Anthos equivale a eseguire una nuova installazione.

Preparazione dell'installazione di Anthos Service Mesh

  1. Prima di installare la nuova versione, determina la revisione corrente. Queste informazioni saranno necessarie per eliminare il webhook di convalida e il web di mutazione dall'installazione attuale di Anthos Service Mesh. Utilizza il comando seguente 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 essere simile a 1.12.9-asm.2.

    2. Linux

  2. Scarica il file di installazione di Anthos Service Mesh nella tua directory di lavoro attuale: 
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-linux-amd64.tar.gz
  3. Scarica il file della firma e utilizza OpenSSL per verificare la firma: 
    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
  4. Estrai i contenuti del file in qualsiasi posizione nel file system. Ad esempio, per estrarre i contenuti nella directory di lavoro attuale: 
    tar xzf istio-1.13.9-asm.10-linux-amd64.tar.gz

    Il comando crea una directory di installazione nella directory di lavoro attuale 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.
  5. Assicurati di essere nella directory root dell'installazione di Anthos Service Mesh: 
    cd istio-1.13.9-asm.10
  6. Per praticità, aggiungi gli strumenti nella directory /bin a PATH: 
    export PATH=$PWD/bin:$PATH

    7. Mac OS

  7. Scarica il file di installazione di Anthos Service Mesh nella tua directory di lavoro attuale: 
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-osx.tar.gz
  8. Scarica il file della firma e utilizza OpenSSL per verificare la firma: 
    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
  9. Estrai i contenuti del file in qualsiasi posizione nel file system. Ad esempio, per estrarre i contenuti nella directory di lavoro attuale: 
    tar xzf istio-1.13.9-asm.10-osx.tar.gz

    Il comando crea una directory di installazione nella directory di lavoro attuale 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.
  10. Assicurati di essere nella directory root dell'installazione di Anthos Service Mesh: 
    cd istio-1.13.9-asm.10
  11. Per praticità, aggiungi gli strumenti nella directory /bin a PATH: 
    export PATH=$PWD/bin:$PATH

    12. Windows

  12. Scarica il file di installazione di Anthos Service Mesh nella tua directory di lavoro attuale: 
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-win.zip
  13. Scarica il file della firma e utilizza OpenSSL per verificare la firma: 
    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
  14. Estrai i contenuti del file in qualsiasi posizione nel file system. Ad esempio, per estrarre i contenuti nella directory di lavoro attuale: 
    tar xzf istio-1.13.9-asm.10-win.zip

    Il comando crea una directory di installazione nella directory di lavoro attuale 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.
  15. Assicurati di essere nella directory root dell'installazione di Anthos Service Mesh: 
    cd istio-1.13.9-asm.10
  16. Per praticità, aggiungi gli strumenti nella directory \bin al tuo PERCORSO: 
    set PATH=%CD%\bin:%PATH%
    17.
  17. Ora che Anthos Service Mesh Istio è installato, controlla la versione di istioctl: 
    istioctl version
  18. 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 tuo file overlay.yaml o creane uno nuovo con il seguente contenuto: 
    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 essere simile al seguente: 

    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 della revisione viene utilizzata dal webhook automatico dell'iniettore collaterale per associare i file collaterali inseriti a una determinata revisione istiod. Per abilitare l'inserimento automatico collaterale per uno spazio dei nomi, devi etichettarlo con una revisione che corrisponda all'etichetta su istiod.

  3. Verifica che l'installazione sia stata completata: 
    kubectl get svc -n istio-system

    L'output dovrebbe essere simile al seguente: 

    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 piano di controllo:
    1. Ottieni l'etichetta della 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 di revisione più recente a una variabile di ambiente.

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

      export UPGRADE_REV="REVISION_LABEL"
    3. Aggiungi l'etichetta della 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 vedi "istio-injection not found" nell'output, puoi ignorarlo. Ciò significa che in precedenza lo spazio dei nomi non aveva l'etichetta istio-injection. Poiché l'inserimento automatico non va a buon fine se uno 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 reiniezione. 
      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, il processo di upgrade della versione istio-1.13.9-asm.10 di Anthos Service Mesh (Anthos Service Mesh) sui cluster collegati ad Anthos equivale a eseguire una nuova installazione.

Preparazione dell'installazione di Anthos Service Mesh

  1. Prima di installare la nuova versione, determina la revisione corrente. Queste informazioni saranno necessarie per eliminare il webhook di convalida e il web di mutazione dall'installazione attuale di Anthos Service Mesh. Utilizza il comando seguente 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 essere simile a 1.12.9-asm.2.

    2. Linux

  2. Concedi il vincolo del contesto di sicurezza (SCC) anyuid a istio-system con il seguente comando dell'interfaccia a riga di comando di OpenShift (oc): 
    oc adm policy add-scc-to-group anyuid system:serviceaccounts:istio-system
  3. Scarica il file di installazione di Anthos Service Mesh nella tua directory di lavoro attuale: 
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-linux-amd64.tar.gz
  4. Scarica il file della firma e utilizza OpenSSL per verificare la firma: 
    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
  5. Estrai i contenuti del file in qualsiasi posizione nel file system. Ad esempio, per estrarre i contenuti nella directory di lavoro attuale: 
    tar xzf istio-1.13.9-asm.10-linux-amd64.tar.gz

    Il comando crea una directory di installazione nella directory di lavoro attuale 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.
  6. Assicurati di essere nella directory root dell'installazione di Anthos Service Mesh: 
    cd istio-1.13.9-asm.10
  7. Per praticità, aggiungi gli strumenti nella directory /bin a PATH: 
    export PATH=$PWD/bin:$PATH

    8. Mac OS

  8. Concedi il vincolo del contesto di sicurezza (SCC) anyuid a istio-system con il seguente comando dell'interfaccia a riga di comando di OpenShift (oc): 
    oc adm policy add-scc-to-group anyuid system:serviceaccounts:istio-system
  9. Scarica il file di installazione di Anthos Service Mesh nella tua directory di lavoro attuale: 
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-osx.tar.gz
  10. Scarica il file della firma e utilizza OpenSSL per verificare la firma: 
    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
  11. Estrai i contenuti del file in qualsiasi posizione nel file system. Ad esempio, per estrarre i contenuti nella directory di lavoro attuale: 
    tar xzf istio-1.13.9-asm.10-osx.tar.gz

    Il comando crea una directory di installazione nella directory di lavoro attuale 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.
  12. Assicurati di essere nella directory root dell'installazione di Anthos Service Mesh: 
    cd istio-1.13.9-asm.10
  13. Per praticità, aggiungi gli strumenti nella directory /bin a PATH: 
    export PATH=$PWD/bin:$PATH

    14. Windows

  14. Concedi il vincolo del contesto di sicurezza (SCC) anyuid a istio-system con il seguente comando dell'interfaccia a riga di comando di OpenShift (oc): 
    oc adm policy add-scc-to-group anyuid system:serviceaccounts:istio-system
  15. Scarica il file di installazione di Anthos Service Mesh nella tua directory di lavoro attuale: 
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-win.zip
  16. Scarica il file della firma e utilizza OpenSSL per verificare la firma: 
    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
  17. Estrai i contenuti del file in qualsiasi posizione nel file system. Ad esempio, per estrarre i contenuti nella directory di lavoro attuale: 
    tar xzf istio-1.13.9-asm.10-win.zip

    Il comando crea una directory di installazione nella directory di lavoro attuale 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.
  18. Assicurati di essere nella directory root dell'installazione di Anthos Service Mesh: 
    cd istio-1.13.9-asm.10
  19. Per praticità, aggiungi gli strumenti nella directory \bin al tuo PERCORSO: 
    set PATH=%CD%\bin:%PATH%
    20.
  20. Ora che Anthos Service Mesh Istio è installato, controlla la versione di istioctl: 
    istioctl version
  21. 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 del 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 a: 

    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 tuo file overlay.yaml o creane uno nuovo con il seguente contenuto: 
    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 essere simile al seguente: 

    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 della revisione viene utilizzata dal webhook automatico dell'iniettore collaterale per associare i file collaterali inseriti a una determinata revisione istiod. Per abilitare l'inserimento automatico collaterale per uno spazio dei nomi, devi etichettarlo con una revisione che corrisponda all'etichetta su istiod.

  3. Verifica che l'installazione sia stata completata: 
    kubectl get svc -n istio-system

    L'output dovrebbe essere simile al seguente: 

    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 piano di controllo:
    1. Ottieni l'etichetta della 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 di revisione più recente a una variabile di ambiente.

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

      export UPGRADE_REV="REVISION_LABEL"
    3. Aggiungi l'etichetta della 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 vedi "istio-injection not found" nell'output, puoi ignorarlo. Ciò significa che in precedenza lo spazio dei nomi non aveva l'etichetta istio-injection. Poiché l'inserimento automatico non va a buon fine se uno 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 reiniezione. 
      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.

Rollback di un upgrade

Per eseguire il rollback di un upgrade precedente, segui questi passaggi:

  1. Esegui la pulizia dei job completati per lo spazio dei nomi del runtime ibrido, dove NAMESPACE è lo spazio dei nomi specificato nel file di override, se hai specificato uno spazio dei nomi. 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. Pulisci 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 al file overrides:
    1. Rimuovi o commenta 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 root dell'installazione di cui vuoi eseguire il rollback, esegui apigeectl apply, controlla lo stato dei pod, quindi esegui apigeectl init. Assicurati di utilizzare il file di override originale per la versione a cui vuoi eseguire il rollback:
    1. Nella directory dei file ibridi, esegui apigeectl apply: 
      $APIGEECTL_HOME/apigeectl apply -f ORIGINAL_OVERRIDES_FILE

      Dove ORIGINAL_OVERRIDES_FILE è il percorso e il nome file relativi del file di override 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 è lo spazio dei nomi ibrido di Apigee.

    3. Controlla lo stato di apigeeds: 
      kubectl describe apigeeds -n apigee

      L'output dovrebbe essere simile al seguente: 

      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

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

    4. Esegui questo comando per prendere nota dei nuovi valori di conteggio delle repliche per il processore di messaggi dopo l'upgrade.Se questi valori non corrispondono a quelli che hai impostato in precedenza, modifica i valori nel file di override 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 essere simile al seguente: 

            autoScaler:
        minReplicas: 2
        maxReplicas: 10
    5. Se esegui il rollback alla versione ibrida 1.8.4 o precedente, elimina il deployment del controller utilizzato dalla versione ibrida v1.8.5 e successive: 
      kubectl -n apigee-system delete deploy apigee-controller-manager
    6. Esecuzione apigeectl init: 
      $APIGEECTL_HOME/apigeectl init -f ORIGINAL_OVERRIDES_FILE
  6. Elimina il deployment del gestore gateway in entrata di Apigee. Questo componente è pertinente solo per le versioni ibride di Apigee 1.8 e successive. 
    kubectl delete deployment -n NAMESPACE apigee-ingress-gateway-manager

    Dove NAMESPACE è lo spazio dei nomi ibrido di Apigee.