Upgrade di Apigee hybrid alla versione 1.11 in corso...

Stai visualizzando la versione 1.11 di Documentazione di Apigee hybrid. Per ulteriori informazioni, vedi Versioni supportate.

Version 1.11 

Versioni supportate:

• v1.12 (più recente)                        
• v1.11                         
• v1.10                                        
• Elenco delle versioni supportate

Versioni non supportate:

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

Questa procedura riguarda l'upgrade da Apigee hybrid dalla versione 1.10.x alla versione ibrida di Apigee 1.11.2 e dalle release precedenti dell'ibrido 1.11.x alla versione 1.11.2.

Utilizza le stesse procedure per gli upgrade della versione secondaria (ad esempio versione 1.10 alla versione 1.11) e per gli upgrade delle release delle patch (ad esempio da 1.11.0 a 1.11.2).

Se esegui l'upgrade da Apigee hybrid versione 1.9 o precedente, devi prima eseguire l'upgrade ad versione ibrida 1.10 prima di eseguire l'upgrade alla versione 1.11.2. Consulta le istruzioni per l'upgrade Apigee hybrid alla versione 1.10.

Panoramica dell'aggiornamento alla versione 1.11.2

L'upgrade ad Apigee hybrid versione 1.11 potrebbe richiedere o un tempo di inattività.

Con l'upgrade del controller Apigee alla versione 1.11.2, tutte le istanze vengono sottoposti a un riavvio in sequenza. Per ridurre al minimo i tempi di inattività negli ambienti ibridi di produzione durante un riavvio in sequenza, assicurati di eseguire almeno due cluster (nello stesso in una regione/un data center differente). Deviare tutto il traffico di produzione in un unico cluster e utilizzare cluster di cui stai per eseguire l'upgrade offline, quindi procedi con il processo di upgrade. Ripeti il processo per ogni cluster.

Apigee consiglia di eseguire l'upgrade di tutti i cluster il prima possibile per ridurre le probabilità dell'impatto sulla produzione. Non è previsto alcun limite di tempo per il quale deve essere eseguito l'upgrade di tutti i cluster rimanenti dopo l'upgrade della prima. Tuttavia, fino a quando non sarà stato eseguito l'upgrade di tutti i cluster rimanenti, operazioni successive saranno interessate:

• Il backup e il ripristino di Cassandra non funzionano con le versioni miste. Ad esempio, un backup da Hybrid 1.10 non può essere utilizzato per ripristinare un ambiente 1.11.
• I flussi di dati Cassandra non funzionano tra versioni ibride miste. Pertanto, I cluster Cassandra non possono scalare orizzontalmente.
• Saranno interessate l'espansione e il ritiro delle regioni, in quanto queste operazioni dipendono Flusso di dati di Cassandra.

.

Nota: le modifiche al piano di gestione non devono essere sospese durante upgrade. Qualsiasi sospensione necessaria per le modifiche al piano di gestione è inclusa nell'upgrade istruzioni.

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

1. Prepara l'upgrade.
2. Installa il runtime ibrido versione 1.11.2.

Prerequisiti

Queste istruzioni per l'upgrade presuppongono che tu abbia Apigee hybrid versione 1.10.x installato e desidera aggiornarlo alla versione 1.11.2. Se esegui l'aggiornamento da di una versione precedente, consulta le istruzioni per Upgrade di Apigee hybrid alla versione 1.10.

Grafici Helm e apigeectl

Nella versione 1.11 puoi scegliere di installare e gestire Apigee hybrid con i grafici Helm o apigeectl. Apigee consiglia di utilizzare Helm per gestire l'installazione.

Migrazione alla v1.11 con Helm dalla v1.10 con apigeectl

Per eseguire l'upgrade ad Apigee hybrid v1.11 gestito da Helm da un ambiente ibrido Installazione della versione 1.10 gestita con apigeectl:

1. Innanzitutto, esegui la migrazione di Helm dell'installazione v1.10 seguendo il istruzioni in Eseguire la migrazione dei grafici Apigee da apigeectl a Helm da apigeectl.
2. Segui le istruzioni per i grafici Helm riportate di seguito per eseguire l'upgrade della tua installazione.
   Nota: quando esegui l'upgrade di un'installazione migrata, devi inserire un flag --force nei comandi helm upgrade.

Prepara l'upgrade alla versione 1.11

Esegui il backup dell'installazione ibrida (opzione consigliata)

Helm

1. Queste istruzioni utilizzano la variabile di ambiente APIGEE_HELM_CHARTS_HOME per la directory nel file system in cui hai installato i grafici Helm. Se necessario, cambia directory in questa directory e definisci la variabile con il seguente comando:

   Linux

   export APIGEE_HELM_CHARTS_HOME=$PWD
   echo $APIGEE_HELM_CHARTS_HOME

   Mac OS

   export APIGEE_HELM_CHARTS_HOME=$PWD
   echo $APIGEE_HELM_CHARTS_HOME

   Windows

   set APIGEE_HELM_CHARTS_HOME=%CD%
   echo %APIGEE_HELM_CHARTS_HOME%

2. Crea una copia di backup della versione 1.10 Directory $APIGEE_HELM_CHARTS_HOME/. Puoi utilizzare qualsiasi processo di backup. Ad esempio: puoi creare un file tar dell'intera directory con:

   tar -czvf $APIGEE_HELM_CHARTS_HOME/../apigee-helm-charts-v1.10-backup.tar.gz $APIGEE_HELM_CHARTS_HOME

3. Esegui il backup del tuo database Cassandra seguendo le istruzioni in Backup e ripristino di Cassandra.
4. Se utilizzi i file di certificato di servizio (.json) in per autenticare gli account di servizio, assicurati che i file del certificato degli account di servizio la directory corretta del grafico Helm. I grafici Helm non possono leggere file esterni a ciascuna directory del grafico.

   Questo passaggio non è necessario se utilizzi secret di Kubernetes o Workload Identity per di autenticare gli account di servizio.

   La tabella seguente mostra la destinazione di ciascun servizio dell'account di servizio, a seconda del tipo di installazione:

   Produzione

   Account di servizio	Nome file predefinito	Directory dei grafici Helm
   apigee-cassandra	PROJECT_ID-apigee-cassandra.json	$APIGEE_HELM_CHARTS_HOME/apigee-datastore/
   apigee-logger	PROJECT_ID-apigee-logger.json	$APIGEE_HELM_CHARTS_HOME/apigee-telemetry/
   apigee-mart	PROJECT_ID-apigee-mart.json	$APIGEE_HELM_CHARTS_HOME/apigee-org/
   apigee-metrics	PROJECT_ID-apigee-metrics.json	$APIGEE_HELM_CHARTS_HOME/apigee-telemetry/
   apigee-runtime	PROJECT_ID-apigee-runtime.json	$APIGEE_HELM_CHARTS_HOME/apigee-env
   apigee-synchronizer	PROJECT_ID-apigee-synchronizer.json	$APIGEE_HELM_CHARTS_HOME/apigee-env/
   apigee-udca	PROJECT_ID-apigee-udca.json	$APIGEE_HELM_CHARTS_HOME/apigee-org/
   apigee-watcher	PROJECT_ID-apigee-watcher.json	$APIGEE_HELM_CHARTS_HOME/apigee-org/

   Non di produzione

   Crea una copia del file dell'account di servizio apigee-non-prod in ciascuno dei seguenti directory:

   Account di servizio	Nome file predefinito	Directory dei grafici Helm
   apigee-non-prod	PROJECT_ID-apigee-non-prod.json	$APIGEE_HELM_CHARTS_HOME/apigee-datastore/ $APIGEE_HELM_CHARTS_HOME/apigee-telemetry/ $APIGEE_HELM_CHARTS_HOME/apigee-org/ $APIGEE_HELM_CHARTS_HOME/apigee-env/

5. Assicurati che il certificato TLS e i file delle chiavi (.crt, .key e/o .pem) risiedono nel $APIGEE_HELM_CHARTS_HOME/apigee-virtualhost/ .

apigeectl

Gli esempi in queste istruzioni utilizzano la seguente struttura di directory. La tua installazione potrebbero essere diverse. Modifica le istruzioni in base alla struttura della tua installazione.

hybrid-v1.11-root-directory/
└── apigeectl/
    └── config/
    └── plugins/
    └── templates/
    └── tools/
└── hybrid-files/
    └── overrides/
    └── service-accounts/
    └── certs/
hybrid-v1.10-root-directory/

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 della versione 1.10 $APIGEECTL_HOME/. Ad esempio:

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

3. Esegui il backup del tuo database Cassandra seguendo le istruzioni in Backup e ripristino di Cassandra.

Esegui l'upgrade della versione di Kubernetes

Controlla la versione della tua piattaforma Kubernetes e, se necessario, esegui l'upgrade della piattaforma Kubernetes a un supportata sia dalla versione ibrida 1.10 che da quella ibrida 1/11 Se hai bisogno di assistenza, segui la documentazione della piattaforma.

Fai clic per espandere un elenco di piattaforme supportate

	1,8 ^(3)	1,9 ^(3)	1,10	1,11	1,12
Anthos (Google Cloud - GKE)	1,21,x ^(≤ 1,8,3) 1,22.x ^(≤ 1,8,3) 1.23.x ^(≤ 1.8.4) 1.24.x ^(≥ 1.8.4) 1.25.x ^(≥ 1.8.4)	1,23,x 1,24,x 1,25,x 1,26.x ^(≥ 1.9.2)	1,24,x 1,25,x 1,26,x 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)
Anthos (AWS)	1,10,x 1,11,x 1.12.x (K8s v1.23.x) 1.13.x (K8s v1.24.x) 1.14.x (K8s v1.25.x)	1,12,x 1.13.x (K8s v1.24.x) 1.14.x (K8s v1.25.x)	1.13.x (K8s v1.24.x) 1.14.x (K8s v1.25.x) 1,26 x^(13) 1.27.x^(≥ 1.10.5) 1.28.x^(≥ 1.10.5)	1.14.x (K8s v1.25.x) 1,26 x^(13) 1,27,x 1.28.x^(≥ 1.11.2) 1.29.x^(≥ 1.11.2)	1,26 x^(13) 1,27,x 1,28,x 1.29.x^(≥ 1.12.1)
Anthos (Azure)	1,10,x 1,11,x 1,12,x 1,13,x 1,14,x	1,12,x 1,13,x 1,14,x	1,13,x 1,14,x 1,26 x^(13) 1.27.x^(≥ 1.10.5) 1.28.x^(≥ 1.10.5)	1,14,x 1,26 x^(13) 1,27,x 1.28.x^(≥ 1.11.2) 1.29.x^(≥ 1.11.2)	1,26 x^(13) 1,27,x 1,28,x 1.29.x^(≥ 1.12.1)
Anthos (on-premise - VMware) ^(1) ^(14)	1.10.x ^(4) 1.11.x ^(4) 1.12.x ^(4) ^(5) 1.13.x ^(5) 1.14.x ^(5) 1.15.x (K8s v1.26.x)	1.12.x ^(4) 1,13.x 1,14.x 1.15.x (K8s v1.26.x)	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^(13) 1,29.x^(≥ 1.12.1)
Anthos (bare metal)^(1)	1.10.x ^(4) 1.11.x ^(4) 1.12.x ^(4) ^(5) 1.13.x ^(5) 1.14.x ^(5) 1,15.x	1.12.x ^(4) 1,13.x 1,14.x 1,15.x	1,13,x 1.14.x (K8s v1.25.x) 1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.27.x^(13)^(≥ 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^(13)^(≥ 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^(13) 1,29.x^(≥ 1.12.1)
EKS^(7)	1,22,x ^(≤ 1,8,3) 1,23.x ^(≤ 1.8.4) 1.24.x ^(≥ 1.8.4) 1.25.x ^(≥ 1.8.4)	1,23,x 1,24,x 1,25,x 1,26,x	1,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,22,x ^(≤ 1,8,3) 1,23.x ^(≤ 1.8.4) 1.24.x ^(≥ 1.8.4) 1.25.x ^(≥ 1.8.4)	1,23,x 1,24,x 1,25,x 1.26.x^(≥ 1.9.2)	1,24,x 1,25,x 1,26,x 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)
ApriMaiusc^(7)	4,8 4,9 4,10	4,10 4,11	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)^(7)	N/D	1.3.8	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/A	N/A	N/D	v1.26.x
Componenti	1,8 ^(3)	1,9 ^(3)	1,10	1,11	1,12
Anthos Service Mesh (ASM)	1,11,x 1,12.x 1,13,x 1,14x 1,15,x	1,17.x^(11)	1,17.x^(11)	1,18,x^(11)	1,19,x^(11)
JDK	JDK 11	JDK 11	JDK 11	JDK 11	JDK 11
gestore-certificati	1,7.x 1,8,x 1,9,x 1,10,x 1,11,x	1,10,x 1,11,x	1,10,x 1,11,x 1,12,x	1,11,x 1,12,x 1,13,x	1,11,x 1,12,x 1,13,x
Cassandra	3,11	3,11	3,11	3,11	4.0
Kubernetes		1,23,x 1,24,x 1,25,x	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+
Driver CSI Secret Store				1.3.4	1.4.1
Vault				1,13,x	1.15.2
^(1) Su Anthos versioni 1.8, 1.9 e 1.10, segui le istruzioni contenute in questi documenti per evitare conflitti con cert-manager: Anthos 1.8.2+: conflitto con cert-manager durante l'upgrade alla versione 1.8.2 o successiva. Anthos 1.9: Conflitto con cert-manager durante l'upgrade alla versione 1.9.0 o 1.9.1. Anthos 1.10+: installazione in conflitto di cert-manager. ^(2) Assistenza disponibile con Apigee ibrida versione 1.7.2 e successive. ^(3) Sono state raggiunte le date EOL ufficiali per le versioni ibride di Apigee 1.8 e precedenti. Le normali patch mensili non sono più disponibili. Queste release non sono più supportate ufficialmente, ad eccezione dei clienti con eccezioni esplicite e ufficiali per poter continuare a ricevere assistenza. Gli altri clienti devono eseguire l'upgrade. ^(4)Le versioni 1.12 e precedenti di Anthos on Bare Metal e VMWare non sono più supportate. Consulta il criterio di assistenza della versione Anthos on Bare Metal e le Cluster Anthos su VMware VMware. ^(5)Anthos su Bare Metal e VMWare richiede ASM 1.14 o versioni successive. Ti consigliamo di eseguire l'upgrade alla versione ibrida v1.8 e di passare al gateway in entrata Apigee, che non richiede più l'installazione di ASM sul cluster ibrido. ^(6) Assistenza disponibile con Apigee hybrid versione 1.8.4 e successive. ^(7) I cluster collegati non sono necessari per Apigee hybrid v1.8 e versioni successive che utilizzano Ingressgateway Apigee.. ^(8) Non supportato con Apigee hybrid versione 1.8.4 e successive. ^(9) Assistenza disponibile con Apigee ibrido versione 1.7.6 e successive. ^(10) Non supportato con Apigee hybrid versione 1.8.5 e successive. ^(11) ASM viene installato automaticamente con Apigee hybrid 1.9 e versioni successive. ^(12) Assistenza disponibile con Apigee hybrid versione 1.9.2 e successive. ^(13) Numeri di versione di Cluster Anthos on AWS (multi-cloud) ora tutte le versioni di Kubernetes. Consulta Anthos il supporto della versione e dell'upgrade per i dettagli della versione e le patch consigliate. ^(14) Vault non è certificato su Anthos (on-premise - VMware). ^(15) Assistenza disponibile con Apigee hybrid versione 1.10.5 e successive. ^(16) Assistenza disponibile con Apigee hybrid versione 1.11.2 e successive. ^(17) Assistenza disponibile con Apigee hybrid versione 1.12.1 e successive.

Informazioni sui cluster collegati

Per le versioni ibride di Apigee 1.7.x e precedenti, devi utilizzare Anthos allegato se vuoi eseguire Apigee hybrid in un contesto multi-cloud su Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS) o un altro servizio Kubernetes di terze parti supportato un fornitore di servizi per le aziende. Il collegamento al cluster consente a Google di misurare l'utilizzo di Anthos Service Mesh (ASM). Registrazione il cluster di terze parti è facoltativo. Registrati solo se vuoi visualizzare il cluster collegato nell' Google Cloud Console. Per ulteriori informazioni, vedi Allega terze parti cluster Kubernetes a Google Cloud.

Per Apigee hybrid versione 1.8.x, sono necessari i cluster collegati ad Anthos se utilizzi Anthos Service Mesh per il gateway in entrata. Se utilizzi il gateway in entrata Apigee, Anthos collegato sono facoltativi.

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

Installa il runtime ibrido 1.11.2

Attenzione : non creare nuovi ambienti durante il processo di upgrade.

Helm

Prepararsi per l'upgrade dei grafici Helm

Questa procedura di upgrade presuppone che tu stia utilizzando lo stesso spazio dei nomi e lo stesso servizio per l'installazione aggiornata. Se apporti modifiche alla configurazione, assicurati di per riflettere queste modifiche nel file degli override prima di installare i grafici Helm.

1. Apporta la seguente modifica al file overrides.yaml per attivare il grafico apigee-operator per utilizzare il tag corretto (1.11.2-hotfix.1):

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

2. Eseguire il pull dei grafici Apigee Helm.

   I grafici ibridi Apigee sono ospitati in Google Artifact Registry:

   oci://us-docker.pkg.dev/apigee-release/apigee-hybrid-helm-charts

   Con il comando pull, copia tutti i pod ibridi di Apigee nello spazio di archiviazione locale con il seguente comando:

   export CHART_REPO=oci://us-docker.pkg.dev/apigee-release/apigee-hybrid-helm-charts
   export CHART_VERSION=1.11.2
   helm pull $CHART_REPO/apigee-operator --version $CHART_VERSION --untar
   helm pull $CHART_REPO/apigee-datastore --version $CHART_VERSION --untar
   helm pull $CHART_REPO/apigee-env --version $CHART_VERSION --untar
   helm pull $CHART_REPO/apigee-ingress-manager --version $CHART_VERSION --untar
   helm pull $CHART_REPO/apigee-org --version $CHART_VERSION --untar
   helm pull $CHART_REPO/apigee-redis --version $CHART_VERSION --untar
   helm pull $CHART_REPO/apigee-telemetry --version $CHART_VERSION --untar
   helm pull $CHART_REPO/apigee-virtualhost --version $CHART_VERSION --untar
   

3. Installa cert-manager, se necessario.

   Se devi eseguire l'upgrade della versione di Gestione certificati, installa con il comando seguente:

   kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.11.1/cert-manager.yaml
   

4. Installa i CRD di Apigee aggiornati:
   Nota: da questo passaggio in poi, tutti i comandi devono essere eseguiti nella directory radice dei repository dei grafici.
   Nota: questo è l'unico metodo supportato per installare i CRD Apigee. Non utilizzare kubectl apply senza -k, non omettere --server-side.
   Nota:questo passaggio richiede autorizzazioni cluster elevate.

   1. Utilizza la funzionalità di prova di kubectl eseguendo il seguente comando:

      kubectl apply -k  apigee-operator/etc/crds/default/ --server-side --force-conflicts --validate=false --dry-run=server
      

   2. Dopo la convalida con il comando dry-run, esegui questo comando:

      kubectl apply -k  apigee-operator/etc/crds/default/ --server-side --force-conflicts --validate=false
      

   3. Convalida l'installazione con il comando kubectl get crds:

      kubectl get crds | grep apigee

      Dovresti vedere un output simile al seguente:

      apigeedatastores.apigee.cloud.google.com                    2023-10-09T14:48:30Z
      apigeedeployments.apigee.cloud.google.com                   2023-10-09T14:48:30Z
      apigeeenvironments.apigee.cloud.google.com                  2023-10-09T14:48:31Z
      apigeeissues.apigee.cloud.google.com                        2023-10-09T14:48:31Z
      apigeeorganizations.apigee.cloud.google.com                 2023-10-09T14:48:32Z
      apigeeredis.apigee.cloud.google.com                         2023-10-09T14:48:33Z
      apigeerouteconfigs.apigee.cloud.google.com                  2023-10-09T14:48:33Z
      apigeeroutes.apigee.cloud.google.com                        2023-10-09T14:48:33Z
      apigeetelemetries.apigee.cloud.google.com                   2023-10-09T14:48:34Z
      cassandradatareplications.apigee.cloud.google.com           2023-10-09T14:48:35Z
      

5. Controlla le etichette sui nodi del cluster. Per impostazione predefinita, Apigee pianifica i pod di dati sui nodi con l'etichetta cloud.google.com/gke-nodepool=apigee-data e pod di runtime sono pianificati su nodi con l'etichetta cloud.google.com/gke-nodepool=apigee-runtime. Puoi personalizza le etichette del pool di nodi nel file overrides.yaml.

   Per ulteriori informazioni, vedi Configurazione di pool di nodi dedicati.

Installa i grafici Helm ibridi Apigee

Nota: prima di eseguire qualsiasi comando di upgrade/installazione di Helm, usa la funzionalità di prova di Helm aggiungendo --dry-run alla fine il comando. Consulta la sezione helm -h per elencare i comandi, le opzioni e i comandi supportati e sull'utilizzo.

1. In caso contrario, passa alla directory APIGEE_HELM_CHARTS_HOME. Esegui l' i seguenti comandi da quella directory.
2. Esegui l'upgrade dell'operatore/del controller Apigee:
   Nota: questo passaggio richiede autorizzazioni cluster elevate. Esegui helm -h o helm upgrade -h per i dettagli

   Prova:

   helm upgrade operator apigee-operator/ \
     --install \
     --create-namespace \
     --namespace apigee-system \
     -f OVERRIDES_FILE \
     --dry-run
   

   Esegui l'upgrade del grafico:

   helm upgrade operator apigee-operator/ \
     --install \
     --create-namespace \
     --namespace apigee-system \
     -f OVERRIDES_FILE
   

   Nota:per le installazioni migrate, utilizza:

   helm upgrade operator apigee-operator/ \
     --install \
     --create-namespace \
     --namespace apigee-system \
     --force \
     -f OVERRIDES_FILE
   

   Verifica l'installazione dell'operatore Apigee:

   helm ls -n apigee-system
   

   NAME           NAMESPACE       REVISION        UPDATED                                 STATUS          CHART                   APP VERSION
   operator    apigee-system   3               2023-06-26 00:42:44.492009 -0800 PST    deployed        apigee-operator-1.11.2   1.11.2
   

   Verifica che sia attivo e funzionante controllandone la disponibilità:

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

   NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
   apigee-controller-manager   1/1     1            1           7d20h
   

3. Esegui l'upgrade del datastore Apigee:

   Prova:

   helm upgrade datastore apigee-datastore/ \
     --install \
     --namespace apigee \
     -f OVERRIDES_FILE \
     --dry-run
   

   Esegui l'upgrade del grafico:

   helm upgrade datastore apigee-datastore/ \
     --install \
     --namespace apigee \
     -f OVERRIDES_FILE
   

   Nota:per le installazioni migrate, utilizza:

   helm upgrade datastore apigee-datastore/ \
     --install \
     --namespace apigee \
     --force \
     -f OVERRIDES_FILE
   

   Verifica che apigeedatastore sia attivo e funzionante controllandone lo stato:

   kubectl -n apigee get apigeedatastore default
   

   NAME      STATE       AGE
   default   running    2d
   

4. Esegui l'upgrade della telemetria Apigee:

   Prova:

   helm upgrade telemetry apigee-telemetry/ \
     --install \
     --namespace apigee \
     -f OVERRIDES_FILE \
     --dry-run
   

   Esegui l'upgrade del grafico:

   helm upgrade telemetry apigee-telemetry/ \
     --install \
     --namespace apigee \
     -f OVERRIDES_FILE
   

   Nota:per le installazioni migrate, utilizza:

   helm upgrade telemetry apigee-telemetry/ \
     --install \
     --namespace apigee \
     --force \
     -f OVERRIDES_FILE
   

   Verifica che sia attivo e funzionante controllandone lo stato:

   kubectl -n apigee get apigeetelemetry apigee-telemetry
   

   NAME               STATE     AGE
   apigee-telemetry   running   2d
   

5. Esegui l'upgrade di Apigee Redis:

   Prova:

   helm upgrade redis apigee-redis/ \
     --install \
     --namespace apigee \
     -f OVERRIDES_FILE \
     --dry-run
   

   Esegui l'upgrade del grafico:

   helm upgrade redis apigee-redis/ \
     --install \
     --namespace apigee \
     -f OVERRIDES_FILE
   

   Nota:per le installazioni migrate, utilizza:

   helm upgrade redis apigee-redis/ \
     --install \
     --namespace apigee \
     --force \
     -f OVERRIDES_FILE
   

   Verifica che sia attivo e funzionante controllandone lo stato:

   kubectl -n apigee get apigeeredis default
   

   NAME      STATE     AGE
   default   running   2d
   

6. Esegui l'upgrade del gestore in entrata Apigee:

   Prova:

   helm upgrade ingress-manager apigee-ingress-manager/ \
     --install \
     --namespace apigee \
     -f OVERRIDES_FILE \
     --dry-run
   

   Esegui l'upgrade del grafico:

   helm upgrade ingress-manager apigee-ingress-manager/ \
     --install \
     --namespace apigee \
     -f OVERRIDES_FILE
   

   Nota:per le installazioni migrate, utilizza:

   helm upgrade ingress-manager apigee-ingress-manager/ \
     --install \
     --namespace apigee \
     --force \
     -f OVERRIDES_FILE
   

   Verifica che sia attivo e funzionante controllandone la disponibilità:

   kubectl -n apigee get deployment apigee-ingressgateway-manager
   

   NAME                            READY   UP-TO-DATE   AVAILABLE   AGE
   apigee-ingressgateway-manager   2/2     2            2           2d
   

7. Esegui l'upgrade dell'organizzazione Apigee:

   Prova:

   helm upgrade ORG_NAME apigee-org/ \
     --install \
     --namespace apigee \
     -f OVERRIDES_FILE \
     --dry-run
   

   Esegui l'upgrade del grafico:

   helm upgrade ORG_NAME apigee-org/ \
     --install \
     --namespace apigee \
     -f OVERRIDES_FILE
   

   Nota:per le installazioni migrate, utilizza:

   helm upgrade ORG_NAME apigee-org/ \
     --install \
     --namespace apigee \
     --force \
     -f OVERRIDES_FILE
   

   Verifica che sia attivo e funzionante controllando lo stato dell'organizzazione corrispondente:

   kubectl -n apigee get apigeeorg
   

   NAME                      STATE     AGE
   apigee-org1-xxxxx          running   2d
   

8. Esegui l'upgrade dell'ambiente.

   Devi installare un ambiente alla volta. Specifica l'ambiente con --set env=ENV_NAME:

   Prova:

   helm upgrade ENV_RELEASE_NAME apigee-env/ \
     --install \
     --namespace apigee \
     --set env=ENV_NAME \
     -f OVERRIDES_FILE \
     --dry-run
   

   • ENV_RELEASE_NAME è il nome con cui hai installato in precedenza la Grafico apigee-env. Nella versione ibrida v1.10, di solito viene apigee-env-ENV_NAME. Nella versione ibrida v1.11 e successive in genere è ENV_NAME.
   • ENV_NAME è il nome dell'ambiente di cui esegui l'upgrade.
   • OVERRIDES_FILE è il tuo nuovo file di override per la versione 1.11.2

   Esegui l'upgrade del grafico:

   helm upgrade ENV_RELEASE_NAME apigee-env/ \
     --install \
     --namespace apigee \
     --set env=ENV_NAME \
     -f OVERRIDES_FILE
   

   Nota:per le installazioni migrate, utilizza:

   helm upgrade ENV_RELEASE_NAME apigee-env/ \
     --install \
     --namespace apigee \
     --set env=ENV_NAME \
     --force \
     -f OVERRIDES_FILE
   

   Verifica che sia attivo e funzionante controllando lo stato del rispettivo ambiente:

   kubectl -n apigee get apigeeenv
   

   NAME                          STATE       AGE   GATEWAYTYPE
   apigee-org1-dev-xxx            running     2d
   

9. Esegui l'upgrade dei gruppi di ambienti (virtualhosts).
   1. Devi eseguire l'upgrade di un gruppo di ambienti (virtualhost) alla volta. Specifica l'ambiente gruppo con --set envgroup=ENV_GROUP_NAME. Ripeti quanto segue per ciascun gruppo env menzionato nel file override.yaml:

      Prova:

      helm upgrade ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
        --install \
        --namespace apigee \
        --set envgroup=ENV_GROUP_NAME \
        -f OVERRIDES_FILE \
        --dry-run
      

      ENV_GROUP_RELEASE_NAME è il nome con cui hai installato in precedenza la Grafico apigee-virtualhost. Nella versione ibrida v1.10, di solito viene apigee-virtualhost-ENV_GROUP_NAME. In Hybrid v1.11 e versioni successive, di solito ENV_GROUP_NAME.

      Esegui l'upgrade del grafico:

      helm upgrade ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
        --install \
        --namespace apigee \
        --set envgroup=ENV_GROUP_NAME \
        -f OVERRIDES_FILE
      

      Nota:per le installazioni migrate, utilizza:

      helm upgrade ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
        --install \
        --namespace apigee \
        --set envgroup=ENV_GROUP_NAME \
        --force \
        -f OVERRIDES_FILE
      

      Nota: ENV_GROUP_NAME deve essere univoco all'interno del dello spazio dei nomi apigee. Ad esempio, se disponi di un ambiente prod envgroup, devi impostare questo nome su prod-envgroup. Il gruppo di ambienti successivi deve essere comunque prod.
   2. Controlla lo stato di ApigeeRoute (AR).

      Installazione di virtualhosts crea ApigeeRouteConfig (ARC), che crea internamente ApigeeRoute (AR) dopo che l'osservatore Apigee ha eseguito il pull del gruppo env correlato i dettagli dal piano di controllo. Pertanto, verifica che i valori corrispondenti Lo stato dell'AR è in esecuzione:

      kubectl -n apigee get arc
      

      NAME                                STATE   AGE
      apigee-org1-dev-egroup                       2d
      

      kubectl -n apigee get ar
      

      NAME                                        STATE     AGE
      apigee-org1-dev-egroup-xxxxxx                running   2d
      

apigeectl

1. Archivia il numero della versione più recente in una variabile utilizzando il seguente comando:

   Linux

   export VERSION=$(curl -s \
     https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/current-version.txt?ignoreCache=1)

   Mac OS

   export VERSION=$(curl -s \
     https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/current-version.txt)

   Windows

   for /f "tokens=*" %a in ('curl -s ^
     https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/current-version.txt') ^
   do set VERSION=%a

2. Verifica che la variabile sia stata compilata con un numero di versione utilizzando il seguente comando. Se Se vuoi usare una versione diversa, puoi salvarla in una variabile di ambiente.

   echo $VERSION

   Dovresti vedere l'ultima versione ibrida di Apigee:

     1.11.2

3. 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/..

4. Scarica il pacchetto di 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/$VERSION/apigeectl_linux_64.tar.gz

   Mac OS

   Mac a 64 bit:

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

   Windows

   Windows a 64 bit:

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

5. Rinomina la directory apigeectl/ attuale con il nome della directory di backup. Ad esempio:

   Linux

   mv $APIGEECTL_HOME/ $APIGEECTL_HOME-v1.10/

   Mac OS

   mv $APIGEECTL_HOME/ $APIGEECTL_HOME-v1.10/ 

   Windows

   rename %APIGEECTL_HOME% %APIGEECTL_HOME%-v1.10 

6. Estrai il contenuto del file gzip scaricato nella directory base ibrida. La directory di base ibrida è la directory in cui è stato rinominato La directory apigeectl-v1.10 si trova:

   Linux

   tar xvzf filename.tar.gz -C ./

   Mac OS

   tar xvzf filename.tar.gz -C ./

   Windows

   tar xvzf filename.zip -C ./

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

   Linux

   mv apigeectl_1.11.2-xxxxxxx_linux_64 apigeectl

   Mac OS

   mv apigeectl_1.11.2-xxxxxxx_mac_64 apigeectl

   Windows

   rename apigeectl_1.11.2-xxxxxxx_windows_64 apigeectl

8. Passa alla directory apigeectl:

   cd ./apigeectl

   Questa è la home directory apigeectl. È dove dove si trova il comando eseguibile apigeectl.

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

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

    ./apigeectl version

    Version: 1.11.2

11. Crea una directory hybrid-base-directory/hybrid-files, quindi sposta al suo interno. La directory hybrid-files è il punto in cui vengono inseriti i file di configurazione file di override, certificati e account di servizio. Ad esempio:

    Linux

    mkdir $APIGEECTL_HOME/../hybrid-files

    cd $APIGEECTL_HOME/../hybrid-files

    Mac OS

    mkdir $APIGEECTL_HOME/../hybrid-files

    cd $APIGEECTL_HOME/../hybrid-files

    Windows

    mkdir %APIGEECTL_HOME%/../hybrid-files

    cd %APIGEECTL_HOME%/../hybrid-files

12. 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 \*

13. 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 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 collegamenti simbolici siano stati creati correttamente, esegui questo comando ed esegui assicurati che i percorsi dei link indirizzino alle posizioni corrette:

       ls -l | grep ^l

14. Apporta la seguente modifica al file overrides.yaml per attivare il grafico apigee-operator per utilizzare il tag corretto (1.11.2-hotfix.1):

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

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

    Suggerimento: puoi sostituire OVERRIDES_FILE nel codice precedente con il nome e il percorso del file degli override e di ogni istanza in questa pagina verrà sostituito.
16. Se non ci sono errori, inizializzare ibrido 1.11.2:

    $APIGEECTL_HOME/apigeectl init -f OVERRIDES_FILE

    Nota: apigeectl installa e configura Gateway in entrata Apigee quando esegui apigeectl init.
17. Controlla lo stato di inizializzazione:

    $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

    Se l'esito è positivo, l'output dice: All containers ready.

    kubectl describe apigeeds -n apigee

    Nell'output, cerca State: running.

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

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

    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. Verifica di completamento:

       $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

       Suggerimento: se check-ready non va a buon fine, puoi ricevere più informazioni sui tuoi pod con:

       kubectl -n NAMESPACE get pods

       Dove NAMESPACE è il tuo spazio dei nomi ibrido Apigee.

       Procedi al passaggio successivo solo quando i pod sono pronti.

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

    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) connettiti) 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 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

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

    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

.

Complimenti! Hai eseguito l'upgrade ad Apigee hybrid versione 1.11.2. per testare l'upgrade, chiama un proxy per la nuova installazione. Per un esempio, vedi Passaggio 10: esegui il deployment di un proxy API in Apigee hybrid Guida all'installazione 1.11.

Rollback di un upgrade in corso...

Per eseguire il rollback di un upgrade precedente:

Helm

Per tornare alla versione precedente, utilizza i grafici e il file degli override dal dell'installazione precedente.

1. Crea la seguente variabile di ambiente:
   • PREVIOUS_HELM_CHARTS_HOME: la directory in cui si trovava la versione ibrida di Apigee precedente I grafici Helm sono installati. Questa è la versione a cui stai eseguendo il rollback.
2. Esegui il rollback dei virtualhost. Ripeti il comando seguente per ogni gruppo di ambienti indicate nel file di override.

   helm upgrade ENV_GROUP_RELEASE_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-virtualhost/ \
     --namespace apigee \
     --atomic \
     --set envgroup=ENV_GROUP_NAME \
     -f PREVIOUS_OVERRIDES_FILE
   

   ENV_GROUP_RELEASE_NAME è il nome con cui hai installato in precedenza la Grafico apigee-virtualhost. Nella versione ibrida v1.10, di solito viene apigee-virtualhost-ENV_GROUP_NAME. In Hybrid v1.11 e versioni successive, di solito ENV_GROUP_NAME.

3. Esegui il rollback degli ambienti. Ripeti il comando seguente per ciascun ambiente menzionato nel file degli override.

   helm upgrade apigee-env-ENV_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-env/ \
     --install \
     --namespace apigee \
     --atomic \
     --set env=ENV_NAME \
     -f PREVIOUS_OVERRIDES_FILE
   

   ENV_RELEASE_NAME è il nome con cui hai installato in precedenza la Grafico apigee-env. Nella versione ibrida v1.10, di solito viene apigee-env-ENV_NAME. In Hybrid v1.11 e versioni successive, di solito ENV_NAME.

4. Esegui il rollback dell'organizzazione:

   helm upgrade ORG_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-org/ \
     --install \
     --namespace apigee \
     --atomic \
     -f PREVIOUS_OVERRIDES_FILE
   

5. Esegui il rollback di Ingress Manager:

   helm upgrade ingress-manager $PREVIOUS_HELM_CHARTS_HOME/apigee-ingress-manager/ \
     --install \
     --namespace apigee \
     --atomic \
     -f PREVIOUS_OVERRIDES_FILE
   

6. Esegui il rollback di Redis:

   helm upgrade redis $PREVIOUS_HELM_CHARTS_HOME/apigee-redis/ \
     --install \
     --namespace apigee \
     --atomic \
     -f PREVIOUS_OVERRIDES_FILE
   

7. Esegui il rollback della telemetria Apigee:

   helm upgrade telemetry $PREVIOUS_HELM_CHARTS_HOME/apigee-telemetry/ \
     --install \
     --namespace apigee \
     --atomic \
     -f PREVIOUS_OVERRIDES_FILE
   

8. Esegui il rollback di Apigee Datastore (il componente di database Cassandra):

   helm upgrade datastore $PREVIOUS_HELM_CHARTS_HOME/apigee-datastore/ \
     --install \
     --namespace apigee \
     --atomic \
     -f PREVIOUS_OVERRIDES_FILE
   

9. Esegui il rollback del controller Apigee:

   helm upgrade operator $PREVIOUS_HELM_CHARTS_HOME/apigee-operator/ \
     --install \
     --namespace apigee-system \
     --atomic \
     -f PREVIOUS_OVERRIDES_FILE
   

10. Esegui il rollback dei CRD ibridi di Apigee:

      kubectl apply -k  $PREVIOUS_HELM_CHARTS_HOME/apigee-operator/etc/crds/default/ --server-side --force-conflicts --validate=false
    

apigeectl

1. 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}')

2. 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}')

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

   export APIGEECTL_HOME=PATH_TO_PREVIOUS_APIGEECTL_DIRECTORY

4. Esegui i comandi seguenti nella directory radice dell'installazione di cui vuoi eseguire il rollback. Assicurati di utilizzare il file di override originale per la versione a cui vuoi eseguire il rollback:
   1. Nella directory hybrid-files, esegui apigeectl apply:

      $APIGEECTL_HOME/apigeectl apply -f ORIGINAL_OVERRIDES_FILE

      Dove ORIGINAL_OVERRIDES_FILE è il percorso relativo e il nome file degli override per l'installazione ibrida precedente, ad esempio: ./overrides/overrides1.10.yaml.

   2. Controlla lo stato dei tuoi pod:

      kubectl -n NAMESPACE get pods

      Dove NAMESPACE è il tuo spazio dei nomi ibrido 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 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

   5. Corsa di apigeectl init:

      $APIGEECTL_HOME/apigeectl init -f ORIGINAL_OVERRIDES_FILE