Upgrade di Apigee hybrid alla versione 1.9

Questa procedura riguarda l'upgrade dalla versione 1.8.x di Apigee hybrid alla versione 1.9.4 di Apigee hybrid e dalle release precedenti di hybrid 1.9.x alla versione 1.9.4.

Utilizza le stesse procedure per gli upgrade delle versioni minori (ad esempio dalla versione 1.8 alla 1.9) e per gli upgrade delle release delle patch (ad esempio dalla 1.9.0 alla 1.9.4).

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

A partire dalla versione 1.9.0, Apigee Hybrid supporta solo il gateway di ingresso Apigee come livello di ingresso.

Panoramica dell'upgrade alla versione 1.9.4

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

  1. Preparati all'upgrade.
  2. Installa la versione 1.9.4 del runtime di hybrid.

Prerequisiti

  • Queste istruzioni per l'upgrade presuppongono che tu abbia installato la versione 1.8.x di Apigee hybrid e voglia eseguirne l'upgrade alla versione 1.9.4. Se esegui l'aggiornamento da una versione precedente, consulta le istruzioni per l'upgrade di Apigee hybrid alla versione 1.8.
  • Nella versione 1.8 di Apigee hybrid, abbiamo introdotto il gateway di ingresso Apigee come livello di ingresso alternativo ad Anthos Service Mesh. A partire dalla versione 1.9.0, Apigee Hybrid richiede l'utilizzo del gateway di ingresso Apigee e non supporta più l'utilizzo di Anthos Service Mesh per l'ingresso. Se l'installazione da cui stai eseguendo l'upgrade utilizza Anthos Service Mesh, devi prima eseguire la migrazione all'utilizzo di Apigee Ingress Gateway prima di eseguire l'upgrade alla versione 1.9.4.

    Il gateway di ingresso Apigee utilizza un piccolo sottoinsieme di funzionalità di Anthos Service Mesh per il gateway di ingresso. La gestione e l'upgrade di queste funzionalità vengono gestite automaticamente da Apigee hybrid. Di conseguenza, non è necessaria esperienza con Anthos Service Mesh per installare, eseguire l'upgrade e gestire il gateway di ingresso ibrido Apigee.

    Per istruzioni, consulta la sezione Eseguire la migrazione al gateway di ingresso Apigee nella documentazione di hybrid v1.8.

Prepararsi all'upgrade alla versione 1.9

  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.8. Ad esempio: 
    tar -czvf $APIGEECTL_HOME/../apigeectl-v1.8-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 aggiunto il ruolo Cloud Trace Agent alla tua installazione ibrida v1.8, assicurati che l'account di servizio per i servizi di runtime Apigee abbia il ruolo IAM di Google Cloud Agente Cloud Trace (roles/cloudtrace.agent).

Per gli ambienti di produzione, l'account di servizio di runtime è apigee-runtime. Per gli ambienti non di produzione, l'account di servizio di runtime è 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 l'indirizzo email 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: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.

Installa il gateway di ingresso Apigee se la tua installazione utilizza Anthos Service Mesh

A partire dalla versione 1.9, Apigee Hybrid non supporta più l'utilizzo di Anthos Service Mesh per l'ingresso. Se la tua installazione ibrida utilizza Anthos Service Mesh, devi eseguire la migrazione dell'installazione attuale al gateway di ingresso Apigee prima di installare la versione ibrida 1.9.

  1. Aggiungi la 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
    svcAnnotations:  # optional. See Known issue 243599452.
      networking.gke.io/load-balancer-type: "Internal"
    svcLoadBalancerIP: 198.252.0.123
    • 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 il gateway di ingresso Apigee nella tua installazione. Per ulteriori informazioni e impostazioni predefinite, consulta ingressGateways[].replicaCountMin e ingressGateways[].replicaCountMax nel riferimento alla 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.

      Per ulteriori informazioni e impostazioni predefinite, consulta ingressGateways[].resources.requests.cpu e ingressGateways[].resources.requests.memory nella pagina di riferimento della proprietà Configuration.

    • CPU_COUNT_LIMIT e MEMORY_LIMIT sono i limiti massimi di CPU e memoria per ogni replica del gateway di ingresso Apigee nella tua installazione.

      Per ulteriori informazioni e impostazioni predefinite, consulta ingressGateways[].resources.limits.cpu e ingressGateways[].resources.limits.memory nella pagina di riferimento della proprietà Configuration.

    • SVC_ANNOTATIONS_KEY SVC_ANNOTATIONS_VALUE (facoltativo):

      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.

      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 la specifica dell'indirizzo IP del bilanciatore del carico, il bilanciatore del carico verrà creato con questo indirizzo IP. Su 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.

      Consulta ingressGateways[].svcLoadBalancerIP nel riferimento per le proprietà di configurazione.
  2. Applica le modifiche per installare il gateway di ingresso Apigee con i seguenti comandi: 
    $APIGEECTL_HOME/apigeectl apply -f overrides/overrides.yaml
  3. Esponi il gateway di ingresso Apigee. Segui le procedure descritte in Esporre il gateway di ingresso Apigee.
  4. Testa il nuovo gateway di ingresso chiamando un proxy. Idealmente, testa tutti i proxy fondamentali attualmente implementati.
  5. 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
  6. 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.
  7. 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.
  8. Esegui nuovamente il test e monitora il traffico del proxy API.
  9. Segui le istruzioni riportate nella documentazione di Anthos Service Mesh per disinstallare Anthos Service Mesh dal cluster.

Installa il runtime di hybrid 1.9.4

  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.9.4/apigeectl_linux_64.tar.gz

    Mac OS

    Mac 64 bit:

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

    Windows

    Windows a 64 bit:

    curl -LO ^
  https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.9.4/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.8/

    Mac OS 

    mv $APIGEECTL_HOME/ $APIGEECTL_HOME-v1.8/

    Windows 

    rename %APIGEECTL_HOME% %APIGEECTL_HOME%-v1.8

  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.8 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.9.4-xxxxxxx_linux_64. Rinomina la directory in apigeectl utilizzando il seguente comando:

    Linux 

    mv apigeectl_1.9.4-xxxxxxx_linux_64 apigeectl

    Mac OS 

    mv apigeectl_1.9.4-xxxxxxx_mac_64 apigeectl

    Windows 

    rename apigeectl_1.9.4-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.9.4
  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.

  13. Se non ci sono errori, inizializza la versione ibrida 1.9.4: 
    $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. 

    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.

    Produzione

    Per gli ambienti di produzione, esegui l'upgrade di ciascun componente ibrida singolarmente e controlla lo stato del componente di cui è stato eseguito l'upgrade prima di passare al 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

      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

Installa 1.9.4-hotfix.1

Per installare la release del hotfix 1.9.4-hotfix.1:

  1. Prima di svolgere questi passaggi, devi utilizzare la versione ibrida di Apigee 1.9.4 o successive. Se non utilizzi la versione 1.9.4 o successive, esegui l'upgrade alla versione 1.9.4 prima di procedere.
  2. Apri il file overrides.yaml.
  3. Nella stanza istiod, modifica la versione del tag immagine (se presente) in 1.17.7. Ad esempio: 
    istiod:
  image:
    url: "gcr.io/apigee-release/hybrid/apigee-asm-istiod"
    tag: "1.17.7-asm.0-distroless"
  4. A seconda di come hai scelto di installare Apigee hybrid, potresti avere una stanza ingressGateway o ingressGateways. Individua la stanza visualizzata nel file delle sostituzioni e modifica la versione del tag immagine (se presente) in 1.17.7. Ad esempio, se hai una stanza ingressGateway: 
    ingressGateway:
  image:
    url: "gcr.io/apigee-release/hybrid/apigee-asm-ingress"
    tag: "1.17.7-asm.0-distroless"

    oppure, se hai una stanza ingressGateways:

    ingressGateways:
  - name: gateway1
    image:
      url: "gcr.io/apigee-release/hybrid/apigee-asm-ingress"
      tag: "1.17.7-asm.0-distroless"
    ...
  - name: gateway2
    image:
      url: "gcr.io/apigee-release/hybrid/apigee-asm-ingress"
      tag: "1.17.7-asm.0-distroless"
    ...
  5. Salva il file.
  6. Esegui il seguente comando per inizializzare il componente istiod: 
    $APIGEECTL_HOME/apigeectl init -f OVERRIDES_FILE
     
    $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
  7. Esegui il seguente comando per applicare le modifiche ai componenti di ingresso Apigee. Se hai più di un'organizzazione, ripeti questo comando per ognuna: 
    $APIGEECTL_HOME/apigeectl apply --org -f OVERRIDES_FILE
     
    $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
  8. Verifica lo stato dei pod: 
    kubectl get pods -n YOUR_APIGEE_NAMESPACE

Esegui l'upgrade della versione di Kubernetes

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

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. 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 e il nome del file delle sostituzioni per l'installazione ibrida della versione precedente, ad esempio ./overrides/overrides1.8.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. Esegui apigeectl init: 
      $APIGEECTL_HOME/apigeectl init -f ORIGINAL_OVERRIDES_FILE