Questa procedura riguarda l'upgrade da Apigee hybrid dalla versione 1.8.x alla versione ibrida di Apigee 1.9.4 e dalle release precedenti dell'ibrido 1.9.x alla versione 1.9.4.
Utilizza le stesse procedure per gli upgrade della versione secondaria (ad esempio versione 1.8) alla versione 1.9) e per gli upgrade delle release delle patch (ad esempio da 1.9.0 a 1.9.4).
Se esegui l'upgrade da Apigee hybrid versione 1.7 o precedente, devi prima eseguire l'upgrade ad versione ibrida 1.8 prima di eseguire l'upgrade alla versione 1.9.4. Consulta le istruzioni per l'upgrade Apigee hybrid alla versione 1.8.
A partire dalla versione 1.9.0, Apigee hybrid supporta solo il gateway Apigee in entrata come traffico in entrata livello di sicurezza.
Panoramica dell'aggiornamento alla versione 1.9.4
.Le procedure per l'upgrade di Apigee hybrid sono organizzate nelle seguenti sezioni:
Prerequisiti
- Queste istruzioni per l'upgrade presuppongono che la versione ibrida di Apigee sia 1.8.x installato e desiderano aggiornarlo alla versione 1.9.4. Se esegui l'aggiornamento da di una versione precedente, consulta le istruzioni per Upgrade di Apigee hybrid alla versione 1.8.
- Nella versione ibrida di Apigee 1.8, abbiamo introdotto il gateway Apigee in entrata come livello alternativo in entrata
ad Anthos Service Mesh. A partire dalla versione 1.9.0, Apigee hybrid richiede l'uso di
il gateway Apigee in entrata e non supporta più l'utilizzo di Anthos Service Mesh per il traffico in entrata. Se l'installazione
stai eseguendo l'upgrade da Anthos Service Mesh, devi prima eseguire la migrazione all'utilizzo del gateway in entrata Apigee prima
aggiornamento 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à sono gestiti automaticamente da Apigee hybrid. Pertanto non è necessaria alcuna esperienza con Anthos Service Mesh per installare, eseguire l'upgrade e gestire Gateway ibrido Apigee in entrata.
Consulta Migrazione al gateway in entrata Apigee nella documentazione della versione ibrida v1.8 per ulteriori istruzioni.
Prepara l'upgrade alla versione 1.9
Esegui il backup dell'installazione ibrida (opzione consigliata)
- 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 directoryapigeectl
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%
- Crea una copia di backup della directory della versione 1.8
$APIGEECTL_HOME/
. Ad esempio:tar -czvf $APIGEECTL_HOME/../apigeectl-v1.8-backup.tar.gz $APIGEECTL_HOME
- Esegui il backup del tuo 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
ha già aggiunto il ruolo Cloud Trace Agent
al tuo modello ibrido
l'installazione della versione 1.8,
Assicurati che il tuo account di servizio per i servizi di runtime Apigee disponga dell'agente Cloud Trace
Ruolo Google Cloud IAM (roles/cloudtrace.agent
).
Per gli ambienti di produzione, l'account di servizio di runtime è apigee-runtime
. Per
ambienti non di produzione, l'account di servizio di runtime è apigee-non-prod
.
Puoi aggiungere il ruolo nel Console Cloud > IAM & Amministratore > UI account di servizio o con i seguenti comandi:
- Recupera 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 al pattern
apigee-runtime@$ORG_NAME.iam.gserviceaccount.com
, puoi usare questo pattern nel passaggio successivo.Non prod
gcloud iam service-accounts list --filter "apigee-non-prod"
Se corrisponde al pattern
apigee-non-prod@$ORG_NAME.iam.gserviceaccount.com
, puoi usare questo pattern nel passaggio successivo. - 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.
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 il traffico in entrata. Se la tua installazione ibrida utilizza Anthos Service Mesh, devi eseguire la migrazione dell'attuale installazione nel gateway in entrata Apigee prima di installare la versione ibrida 1,9
-
Aggiungi la
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 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 "."
- Inizia con un carattere alfanumerico
- Termina con un carattere alfanumerico
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 nella tua installazione. Per ulteriori informazioni e impostazioni predefinite, vedi
ingressGateways[].replicaCountMin
eingressGateways[].replicaCountMax
nel riferimento della proprietà di configurazione. - CPU_COUNT_REQ e MEMORY_REQ sono le richieste di CPU e memoria per ogni
del gateway Apigee in entrata nella tua installazione.
Per ulteriori informazioni e impostazioni predefinite, vedi
ingressGateways[].resources.requests.cpu
eingressGateways[].resources.requests.memory
nel riferimento della proprietà di configurazione. - CPU_COUNT_LIMIT e MEMORY_LIMIT sono i limiti massimi di CPU e memoria per
ogni replica del gateway Apigee in entrata nella tua installazione.
Per ulteriori informazioni e impostazioni predefinite, vedi
ingressGateways[].resources.limits.cpu
eingressGateways[].resources.limits.memory
nel riferimento della proprietà di configurazione. - SVC_ANNOTATIONS_KEY SVC_ANNOTATIONS_VALUE (facoltativo):
Si tratta di una coppia chiave-valore che fornisce annotazioni per il servizio in entrata predefinito. Le annotazioni vengono utilizzate dalla piattaforma cloud per aiutare a configurare l'installazione ibrida, ad esempio impostando il tipo di bilanciatore del carico su interni o esterni. Ad esempio:
ingressGateways: svcAnnotations: networking.gke.io/load-balancer-type: "Internal"
Le annotazioni variano da piattaforma a piattaforma. Fai riferimento alla tua piattaforma documentazione per le annotazioni obbligatorie e suggerite.
di Gemini Advanced. ConsultaingressGateways[].svcAnnotations
nella documentazione di riferimento delle proprietà di configurazione. - SVC_LOAD_BALANCER_IP (facoltativo) ti consente di assegnare un indirizzo IP statico per il tuo
con il bilanciatore del carico di rete
passthrough esterno regionale. Sulle piattaforme che supportano la specifica dell'indirizzo IP del bilanciatore del carico,
verrà creato con questo indirizzo IP. Sulle piattaforme che non consentono di specificare
indirizzo IP del bilanciatore del carico, questa proprietà viene ignorata.
Se non hai un indirizzo IP statico allocato per il bilanciatore del carico, esci da questa proprietà dal file di override.
di Gemini Advanced. ConsultaingressGateways[].svcLoadBalancerIP
nel riferimento per le proprietà di configurazione.
- INGRESS_NAME è il nome del deployment di Ingress. Può essere qualsiasi nome
che soddisfi i seguenti requisiti:
- Applica le modifiche per installare il gateway in entrata Apigee con i seguenti comandi:
$APIGEECTL_HOME/apigeectl apply -f overrides/overrides.yaml
- Esporre il gateway in entrata Apigee. Segui le procedure in Esponi il gateway in entrata Apigee.
- Testa il nuovo gateway in entrata chiamando un proxy. Idealmente, testa tutti i proxy cruciali di cui hai eseguito il deployment.
- Per spostare il traffico, aggiorna i record DNS in modo che rimandino all'indirizzo IP del nuovo gateway di ingresso Apigee.
A seconda del tuo provider DNS, potresti essere in grado di spostare gradualmente il traffico sul nuovo endpoint.
Suggerimento : puoi trovare l'indirizzo IP esterno del gateway Apigee in entrata 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
- Assicurati che tutto il traffico del runtime funzioni monitorando le tue dashboard. Procedi solo con la successiva passaggio se tutto funziona come previsto. Assicurati che non ci sia traffico lungo il vecchio gateway in entrata (Anthos Service Mesh), poiché l'aggiornamento del DNS può essere lento a propagarsi a causa della memorizzazione nella cache del DNS.
- Per interrompere la fornitura della configurazione ad Anthos Service Mesh da parte di Apigee, segui i passaggi descritti in Interrompi l'invio della configurazione ad ASM in la guida alla gestione del gateway in entrata Apigee.
- Ripeti il test e monitora il traffico del proxy API.
- Segui le istruzioni nella documentazione di Anthos Service Mesh per Disinstalla Anthos Service Mesh da nel cluster.
Installazione del runtime ibrido 1.9.4
- Assicurati di trovarti nella directory di base ibrida (l'elemento padre della directory in cui
dove si trova il file eseguibile
apigeectl
):cd $APIGEECTL_HOME/..
-
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.9.4/apigeectl_linux_64.tar.gz
Mac OS
Mac a 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
- Rinomina la directory
apigeectl/
corrente 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
-
Estrai i contenuti del file gzip scaricato nella directory di base ibrida. La directory di base ibrida è la directory in cui è stato rinominato La directory
apigeectl-v1.8
si trova:Linux
tar xvzf filename.tar.gz -C ./
Mac OS
tar xvzf filename.tar.gz -C ./
Windows
tar xvzf filename.zip -C ./
-
Per impostazione predefinita, i contenuti tar vengono espansi in una directory con la versione e la piattaforma in il nome. Ad esempio:
./apigeectl_1.9.4-xxxxxxx_linux_64
. Rinomina la directory aapigeectl
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
-
Passa alla directory
apigeectl
:cd ./apigeectl
Questa directory è la home directory di
apigeectl
. È dove dove si trova il comando eseguibileapigeectl
. - 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 directoryapigeectl
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%
- Verifica la versione di
apigeectl
con il comandoversion
:./apigeectl version
Version: 1.9.4
- Passa alla directory
hybrid-base-directory/hybrid-files
.hybrid-files
è la directory in cui i file di configurazione, come file di override, certificati e account di servizio, in cui si trovano. Ad esempio:cd $APIGEECTL_HOME/../hybrid-files
- 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 \*
- Nella directory
hybrid-files
:-
Aggiorna i seguenti link simbolici a
$APIGEECTL_HOME
. Questi link ti consentono di eseguire il comandoapigeectl
appena installato dall'interno della directoryhybrid-files
:ln -nfs
$APIGEECTL_HOME
/tools toolsln -nfs
$APIGEECTL_HOME
/config configln -nfs
$APIGEECTL_HOME
/templates templatesln -nfs
$APIGEECTL_HOME
/plugins plugins -
Per verificare che i collegamenti simbolici siano stati creati correttamente, esegui questo comando e rendi
assicurati che i percorsi dei link indirizzino alle posizioni corrette:
ls -l | grep ^l
-
Aggiorna i seguenti link simbolici a
- Esegui un'inizializzazione dry run 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
. - Se non ci sono errori, inizializzare ibrido 1.9.4:
$APIGEECTL_HOME/apigeectl init -f OVERRIDES_FILE
- Controlla lo stato di 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
. - Verifica la presenza di errori con una prova del comando
apply
utilizzando--dry-run
Segnala:$APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --dry-run=client
- Se non sono presenti errori, applica gli override. Seleziona e segui le istruzioni per gli ambienti di produzione oppure
ambienti non di produzione, a seconda dell'installazione.
Produzione
Per gli ambienti di produzione, eseguire l'upgrade di ogni componente ibrido individualmente, e controlla lo stato del componente di cui è stato eseguito l'upgrade prima di passare al componente successivo.
- Assicurati di essere nella directory
hybrid-files
. - Applica gli override per eseguire l'upgrade di Cassandra:
$APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --datastore
- Verifica di completamento:
$APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
Procedi al passaggio successivo solo quando i pod sono pronti.
- Applica gli override per eseguire l'upgrade dei componenti di telemetria e verificare il completamento:
$APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --telemetry
$APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
- Visualizza i componenti Redis:
$APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --redis
- Applica gli override per eseguire l'upgrade dei componenti a livello di organizzazione (MART, Watcher e Apigee)
connettiti) e verifica il completamento:
$APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --org
$APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
- Applica gli override per eseguire l'upgrade degli ambienti. Hai a disposizione due opzioni:
- Ambiente per ambiente: applica gli override 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 esegui 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
- Ambiente per ambiente: applica gli override a un ambiente alla volta e controlla il completamento. Ripeti
questo passaggio per ogni ambiente:
- Applica gli override per eseguire l'upgrade dei componenti
virtualhosts
e verificare 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 è grande e complesso che imitano da vicino un ambiente di produzione, ti consigliamo di utilizzare le istruzioni per l'upgrade degli ambienti di produzione.
- Assicurati di essere nella directory
hybrid-files
. $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE
- Controlla lo stato:
$APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
- Assicurati di essere nella directory
Installa 1.9.4-hotfix.1
Segui questi passaggi per installare la release di aggiornamento rapido 1.9.4-hotfix.1
:
- Prima di svolgere questi passaggi, devi utilizzare la versione ibrida di Apigee 1.9.4 o successive. Se non sono sulla versione 1.9.4 o successiva, esegui un upgrade alla versione 1.9.4 prima di procedere.
- Apri il file
overrides.yaml
. - Nella stanza
istiod
, modifica la versione del tag immagine (se presente). alla versione1.17.7
. Ad esempio:istiod: image: url: "gcr.io/apigee-release/hybrid/apigee-asm-istiod" tag: "1.17.7-asm.0-distroless"
- A seconda di come hai scelto di installare Apigee hybrid, potresti avere una stanza
ingressGateway
oingressGateways
. Individua la stanza visualizzata nel file di override e modifica la versione del tag immagine (se presente). alla versione1.17.7
. Ad esempio, se hai una stanzaingressGateway
:ingressGateway: image: url: "gcr.io/apigee-release/hybrid/apigee-asm-ingress" tag: "1.17.7-asm.0-distroless"
oppure, se hai una strofa
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" ...
- Salva il file.
- Esegui il seguente comando per inizializzare il componente
istiod
:$APIGEECTL_HOME/apigeectl init -f OVERRIDES_FILE
$APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
- Esegui questo comando per applicare le modifiche ai componenti Apigee in entrata. Se disponi
per più organizzazioni, ripeti questo comando per ciascuna:
$APIGEECTL_HOME/apigeectl apply --org -f OVERRIDES_FILE
$APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
- Verifica lo stato dei tuoi pod:
kubectl get pods -n YOUR_APIGEE_NAMESPACE
Esegui l'upgrade della versione di Kubernetes
Esegui l'upgrade della tua piattaforma Kubernetes alle versioni supportate da hybrid 1.9. Se hai bisogno di assistenza, segui la documentazione della piattaforma.
.Rollback di un upgrade in corso...
Per eseguire il rollback di un upgrade precedente:
- Esegui la pulizia dei job completati per lo spazio dei nomi del runtime ibrido, dove NAMESPACE è
specificato nel file degli 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}')
- Esegui la pulizia dei 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}')
- Modifica la variabile
APIGEECTL_HOME
in modo che punti alla directory che contiene la precedente diapigeectl
. Ad esempio:export APIGEECTL_HOME=PATH_TO_PREVIOUS_APIGEECTL_DIRECTORY
- Nella directory root dell'installazione di cui vuoi eseguire il rollback,
apigeectl apply
, controlla lo stato dei pod ed eseguiapigeectl init
. Assicurati di utilizzare il file di override originale per la versione vuoi eseguire il rollback a:- Nella directory hybrid-files, esegui
apigeectl apply
:$APIGEECTL_HOME
/apigeectl apply -f ORIGINAL_OVERRIDES_FILEDove ORIGINAL_OVERRIDES_FILE è il percorso relativo e il nome file degli override per l'installazione ibrida precedente, ad esempio:
./overrides/overrides1.8.yaml
. - Controlla lo stato dei pod:
kubectl -n NAMESPACE get pods
dove NAMESPACE è il tuo spazio dei nomi Apigee hybrid.
- 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. - Esegui questo comando per prendere nota dei nuovi valori del conteggio delle repliche
al processore di messaggi dopo l'upgrade. Se questi valori non corrispondono a quanto impostato
in precedenza, modifica i valori nel file delle sostituzioni affinché corrispondano ai valori
configurazione.
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
- Corsa di
apigeectl init
:$APIGEECTL_HOME
/apigeectl init -f ORIGINAL_OVERRIDES_FILE
- Nella directory hybrid-files, esegui