Upgrade di Apigee hybrid alla versione 1.10

Al momento stai visualizzando la versione 1.10 della documentazione di Apigee hybrid. Per ulteriori informazioni, consulta Versioni supportate.

Version 1.10 

   Versioni supportate:

• v1.14 (ultima versione)                        
• v1.13                         
• 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                                         

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

Utilizza le stesse procedure per gli upgrade delle versioni minori (ad esempio dalla versione 1.9 alla 1.10) e per gli upgrade delle release delle patch (ad esempio dalla 1.10.0 alla 1.10.5).

Panoramica dell'upgrade alla versione 1.10.5

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

Quando esegui l'upgrade del controller Apigee alla versione 1.10.5, 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/nello stesso 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.9 non può essere utilizzato per ripristinare un'istanza Hybrid 1.10.
• 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.

Nota: le modifiche al piano di gestione non devono essere sospese durante un upgrade. Eventuali sospensioni necessarie per le modifiche al piano di gestione sono incluse nelle istruzioni di upgrade.

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

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

Prerequisiti

Queste istruzioni per l'upgrade presuppongono che tu abbia installato la versione 1.9.x di Apigee hybrid e che tu voglia eseguire l'upgrade alla versione 1.10.5. Se stai eseguendo l'aggiornamento da una versione precedente, consulta le istruzioni per eseguire l'upgrade di Apigee hybrid alla versione 1.9.

Prepararsi all'upgrade alla versione 1.10

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 Mac OS Windows
   export APIGEECTL_HOME=$PWD
   echo $APIGEECTL_HOME

   export APIGEECTL_HOME=$PWD
   echo $APIGEECTL_HOME

   set APIGEECTL_HOME=%CD%
   echo %APIGEECTL_HOME%

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

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

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

Esegui l'upgrade della versione di Kubernetes

Controlla la versione della piattaforma Kubernetes e, se necessario, esegui l'upgrade a una versione supportata sia da hybrid 1.9 sia da hybrid 1.10. Se hai bisogno di aiuto, consulta la documentazione della tua piattaforma.

Fai clic per espandere un elenco delle piattaforme supportate

	1.10 ^(3)	1,11	1,12
GKE su Google Cloud	1.24.x 1.25.x 1.26.x 1.27.x^(≥ 1.10.5) 1.28.x^(≥ 1.10.5)	1.25.x 1.26.x 1.27.x 1.28.x^(≥ 1.11.2) 1.29.x^(≥ 1.11.2)	1.26.x 1.27.x 1.28.x 1.29.x^(≥ 1.12.1)
GKE su AWS	1.13.x (K8s v1.24.x) 1.14.x (K8s v1.25.x) 1.26.x^(12) 1.27.x^(≥ 1.10.5) 1.28.x^(≥ 1.10.5)	1.14.x (K8s v1.25.x) 1.26.x^(12) 1.27.x 1.28.x^(≥ 1.11.2) 1.29.x^(≥ 1.11.2)	1.26.x^(12) 1.27.x 1.28.x 1.29.x^(≥ 1.12.1)
GKE su Azure	1.13.x 1.14.x 1.26.x^(12) 1.27.x^(≥ 1.10.5) 1.28.x^(≥ 1.10.5)	1.14.x 1.26.x^(12) 1.27.x 1.28.x^(≥ 1.11.2) 1.29.x^(≥ 1.11.2)	1.26.x^(12) 1.27.x 1.28.x 1.29.x^(≥ 1.12.1)
Google Distributed Cloud (solo software) su VMware ^(1) ^(13)	1.13.x 1.14.x 1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.27.x^(≥ 1.10.5) 1.28.x^(≥ 1.10.5)	1.14.x 1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x^(≥ 1.11.2) 1.29.x^(≥ 1.11.2)	1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x^(12) 1.29.x^(≥ 1.12.1)
Google Distributed Cloud (solo software) su bare metal ^(1)	1.13.x 1.14.x (K8s v1.25.x) 1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.27.x^(12)^(≥ 1.10.5) 1.28.x^(≥ 1.10.5)	1.14.x 1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x^(12)^(≥ 1.11.2) 1.29.x^(≥ 1.11.2)	1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x^(12) 1.29.x^(≥ 1.12.1)
EKS^(7)	1.24.x 1.25.x 1.26.x 1.27.x^(≥ 1.10.5) 1.28.x^(≥ 1.10.5)	1.25.x 1.26.x 1.27.x 1.28.x^(≥ 1.11.2) 1.29.x^(≥ 1.11.2)	1.26.x 1.27.x 1.28.x 1.29.x^(≥ 1.12.1)
AKS^(7)	1.24.x 1.25.x 1.26.x 1.27.x^(≥ 1.10.5) 1.28.x^(≥ 1.10.5)	1.25.x 1.26.x 1.27.x 1.28.x^(≥ 1.11.2) 1.29.x^(≥ 1.11.2)	1.26.x 1.27.x 1.28.x 1.29.x^(≥ 1.12.1)
OpenShift^(7)	4.11 4.12 4.14^(≥ 1.10.5) 4.15^(≥ 1.10.5)	4.12 4.13 4.14 4.15^(≥ 1.11.2) 4.16^(≥ 1.11.2)	4.12 4.13 4.14 4.15 4.16^(≥ 1.12.1)
Rancher Kubernetes Engine (RKE)	v1.26.2+rke2r1 1.27.x^(≥ 1.10.5) 1.28.x^(≥ 1.10.5)	v1.26.2+rke2r1 v1.27.x 1.28.x^(≥ 1.11.2) 1.29.x^(≥ 1.11.2)	v1.26.2+rke2r1 v1.27.x 1.28.x 1.29.x^(≥ 1.12.1)
VMware Tanzu	N/D	N/D	v1.26.x
Componenti	1,10	1,11	1,12
Anthos Service Mesh	1.17.x^(10)	1.18.x^(10)	1.19.x^(10)
JDK	JDK 11	JDK 11	JDK 11
cert-manager	1.10.x 1.11.x 1.12.x	1.11.x 1.12.x 1.13.x	1.11.x 1.12.x 1.13.x
Cassandra	3.11	3.11	4.0
Kubernetes	1.24.x 1.25.x 1.26.x	1.25.x 1.26.x 1.27.x	1.26.x 1.27.x 1.28.x
kubectl			1.27.x 1.28.x 1.29.x
Helm	3,10 e oltre	3,10 e oltre	3.14.2 e versioni successive
Driver CSI Secret Store		1.3.4	1.4.1
Vault		1.13.x	1.15.2
^(1) In Anthos on-premise (Google Distributed Cloud) versione 1.13, segui queste istruzioni per evitare conflitti con cert-manager: 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.10 e precedenti di Apigee Hybrid sono state raggiunte. Le patch mensili regolari non sono più disponibili. Queste release non sono più ufficialmente supportate, ad eccezione dei clienti con eccezioni esplicite e ufficiali per il supporto continuo. Gli altri clienti devono eseguire l'upgrade. ^(4)Le versioni 1.12 e precedenti di Anthos on-premise (Google Distributed Cloud) non sono più supportate. Consulta i Criteri di supporto delle versioni di Distributed Cloud on bare metal e l'elenco delle versioni supportate di Distributed Cloud on VMware. ^(5)Google Distributed Cloud on bare metal o VMware richiede Anthos Service Mesh 1.14 o versioni successive. Ti consigliamo di eseguire l'upgrade alla versione ibrida 1.8 e di passare al gateway di ingresso Apigee, che non richiede più l'installazione di Anthos Service Mesh nel cluster ibrido. ^(6) Assistenza disponibile con Apigee hybrid versione 1.8.4 e successive. ^(7) Non supportato con Apigee hybrid versione 1.8.4 e successive. ^(8) Assistenza disponibile con Apigee hybrid versione 1.7.6 e successive. ^(9) Non supportato con Apigee hybrid versione 1.8.5 e successive. ^(10) Anthos Service Mesh viene installato automaticamente con Apigee Hybrid 1.9 e versioni successive. ^(11) Assistenza disponibile con Apigee hybrid versione 1.9.2 e successive. ^(12) I numeri di versione di GKE su AWS ora rispecchiano le versioni di Kubernetes. Consulta la sezione Versione di GKE Enterprise e assistenza per l'upgrade per i dettagli sulle versioni e le patch consigliate. ^(13) Vault non è certificato su Google Distributed Cloud per VMware. ^(14) Assistenza disponibile con la versione 1.10.5 e successive di Apigee hybrid. ^(15) Assistenza disponibile con Apigee hybrid versione 1.11.2 e successive. ^(16) Assistenza disponibile con Apigee hybrid versione 1.12.1 e successive.

Informazioni sui cluster collegati

Per le versioni di Apigee hybrid 1.7.x e precedenti, devi utilizzare cluster collegati a GKE se vuoi eseguire Apigee hybrid in un contesto multi-cloud 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.

Per la versione ibrida di Apigee 1.8.x, sono necessari i cluster collegati a GKE se utilizzi Anthos Service Mesh per il gateway di ingresso. Se utilizzi il gateway di ingresso Apigee, i cluster collegati sono facoltativi.

Nota: le installazioni ibride non sono attualmente supportate nei cluster Autopilot.

Installa il runtime di hybrid 1.10.5

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 Mac OS Windows

   Linux a 64 bit:

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

   Mac 64 bit:

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

   Windows a 64 bit:

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

3. Rinomina la directory apigeectl/ attuale con il nome di una directory di backup. Ad esempio:
   Linux Mac OS Windows
   mv $APIGEECTL_HOME/ $APIGEECTL_HOME-v1.9/

   mv $APIGEECTL_HOME/ $APIGEECTL_HOME-v1.9/ 

   rename %APIGEECTL_HOME% %APIGEECTL_HOME%-v1.9 

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.9 rinominata:

   Linux Mac OS Windows
   tar xvzf filename.tar.gz -C ./

   tar xvzf filename.tar.gz -C ./

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

   Linux Mac OS Windows
   mv apigeectl_1.10.5-xxxxxxx_linux_64 apigeectl

   mv apigeectl_1.10.5-xxxxxxx_mac_64 apigeectl

   rename apigeectl_1.10.5-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 Mac OS Windows
   export APIGEECTL_HOME=$PWD

   echo $APIGEECTL_HOME

   export APIGEECTL_HOME=$PWD

   echo $APIGEECTL_HOME

   set APIGEECTL_HOME=%CD%

   echo %APIGEECTL_HOME%

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

   ./apigeectl version

   Version: 1.10.5

9. Crea una directory hybrid-base-directory/hybrid-files, quindi spostati al suo interno. La directory hybrid-filesè il luogo in cui si trovano i file di configurazione, come il file delle sostituzioni, i certificati e gli account di servizio. Ad esempio:
   Linux Mac OS Windows
   mkdir $APIGEECTL_HOME/../hybrid-files

   cd $APIGEECTL_HOME/../hybrid-files

   mkdir $APIGEECTL_HOME/../hybrid-files

   cd $APIGEECTL_HOME/../hybrid-files

   mkdir %APIGEECTL_HOME%/../hybrid-files

   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. Apporta la seguente modifica al file overrides.yaml per attivare il grafico apigee-operator o utilizzare il tag corretto 1.10.5-hotfix.1:

      ao:
        image:
          url: "gcr.io/apigee-release/hybrid/apigee-operators"
          tag: "1.10.5-hotfix.1"
      

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

    $APIGEECTL_HOME/apigeectl init -f OVERRIDES_FILE

    Nota: apigeectl installa e configura il gateway di ingresso Apigee quando esegui apigeectl init.
15. 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.

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

17. 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.
    ProduzioneNon prod

    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 trovarti 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

    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 trovarti nella directory hybrid-files.
    2. $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE

    3. Controlla lo stato:

       $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

Congratulazioni! Hai eseguito l'upgrade alla versione 1.10.5 di Apigee hybrid. Per testare l'upgrade, chiama un proxy per la nuova installazione. Per un esempio, consulta Passaggio 10: esegui il deployment di un proxy API nella guida all'installazione di Apigee hybrid 1.10.

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