Questa pagina è stata tradotta dall'API Cloud Translation.

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

Questa procedura riguarda l'upgrade da Apigee hybrid dalla versione 1.11.x alla versione ibrida di Apigee 1.12.1.

Modifiche rispetto alla versione 1.11 di Apigee hybrid

La versione ibrida di Apigee 1.12 introduce le seguenti modifiche che influiscono durante il processo di upgrade. Per un elenco completo delle funzionalità della versione 1.12 vedi il Note di rilascio ibrida v1.12.0.

Cassandra 4.x: a partire dalla versione 1.12, Apigee hybrid utilizza Cassandra versione 4 e successive.
Importante: a causa della modifica del database, non puoi eseguire il rollback il componente apigee-datastore con upgrade eseguito. Pertanto, è fondamentale riportare il database Cassandra e l'installazione ibrida prima di eseguire l'upgrade. Se devi spostare l'upgrade, considera i seguenti scenari:
- Non è ancora stato eseguito l'upgrade di Cassandra: puoi eseguire il rollback di tutte le modifiche.
- È stato eseguito l'upgrade di Cassandra e tutti i pod di Cassandra sono in stato integro: puoi eseguire il rollback delle modifiche a tutti i componenti, ad eccezione di apigee-datastore. L'installazione v1.11.x continuerà a funzionare con un'istanza v1.12 di apigee-datastore che esegue Cassandra v4.
- È stato eseguito l'upgrade di Cassandra e i pod di Cassandra sono in uno stato non integro:devi disinstallare la versione ibrida 1.12 e ripristinare l'installazione della versione 11 da un backup.
Ritiro di apigeectl: a partire dalla versione 1.12, solo Apigee hybrid supporta Helm per l'installazione e la gestione dell'installazione ibrida.
Attenzione: il valore di apigeectl è ritirato a partire dal 17 aprile 2024. Lo strumento apigeectl non è supportato per Apigee hybrid v1.12. Il supporto di apigeectl per Apigee hybrid v1.10 e v1.11 terminerà il 17 aprile 2025. Per ulteriori informazioni, consulta Ritiro di Apigeectl.

Importante: se gestisci la versione 1.11 con apigeectl, devi prima eseguire la migrazione dell'installazione v1.11 per utilizzare Helm prima upgrade alla versione 1.12. Segui le istruzioni in Esegui la migrazione di Apigee hybrid ai grafici Helm da apigeectl.
È ora disponibile una nuova suite di metriche per il monitoraggio dei proxy e degli endpoint di destinazione Apigee. Per la versione ibrida v1.12, le risorse monitorate di ProxyV2 e TargetV2 non saranno più in uso per impostazione predefinita. Tutte le metriche del proxy e di destinazione verranno pubblicate in Proxy e Target risorse monitorate.

Per continuare a inviare metriche su ProxyV2 e TargetV2 risorse monitorate, imposta metrics.disablePrometheusPipeline su true in overrides.yaml.
Se hai configurato avvisi basati sulle metriche, conferma l'utilizzo delle metriche corrette per la tua installazione ibrida. Per ulteriori informazioni, consulta Avvisi basati sulle metriche.

Considerazioni da fare prima di avviare un upgrade alla versione 1.12

L'upgrade da Apigee ibrido dalla versione 1.11 alla versione 1.12 include un upgrade di Cassandra dalla versione 3.11.x alla versione 4.x. L'upgrade di Cassandra è gestito nell'ambito La procedura di upgrade ibrido di Apigee, prepara le seguenti considerazioni:

L'upgrade della versione di Cassandra verrà eseguito in background e avverrà su 1 pod (oppure nodo Cassandra) in un'unica soluzione, quindi è importante pianificare una riduzione della capacità del database durante l'upgrade.
Scala la tua capacità di Cassandra e assicurati che l'utilizzo del disco sia vicino o inferiore al 50% prima di iniziare l'upgrade.
Convalida e testa le procedure di backup e ripristino di Cassandra.
Esegui il backup dei dati di Cassandra nell'installazione ibrida 1.11 prima di eseguire l'upgrade e convalidare i backup.
L'upgrade di apigee-datastore comporterà un aumento temporaneo del consumo della CPU dovuto a: attività successive all'upgrade eseguite da Cassandra
Una volta eseguito l'upgrade del componente apigee-datastore (Cassandra), non potrai eseguire il rollback del componente alla versione precedente. Esistono due scenari per il rollback di una eseguire l'upgrade alla versione 1.12 ibrida dopo l'upgrade Componente apigee-datastore:
- Se il componente apigee-datastore è in buono stato, ma gli altri componenti non è necessario eseguire il rollback, puoi eseguirne il rollback singolarmente agli altri componenti.
  Nota: non potrai aggiungere regioni o scalare Cassandra nodi durante l'esecuzione di componenti di versioni ibride diverse.
- Se il componente apigee-datastore non è valido, devi eseguire il ripristino da una Backup della versione 1.11 in un'installazione della versione 1.11.
  Nota: non puoi combinare le versioni durante il ripristino. Devi ripristinare un backup eseguito in un'installazione v1.11 in un versione 1.11.

Considerazioni da fare prima di eseguire l'upgrade di un'installazione in una singola regione

Se devi eseguire il rollback a una versione precedente di Apigee hybrid, il processo potrebbe richiedere tempi di inattività. Pertanto, se esegui l'upgrade di una singola regione potrebbe essere utile creare una seconda regione ed eseguire l'upgrade di una sola regione alla volta la seguente sequenza:

Aggiungi una seconda regione all'installazione esistente utilizzando la stessa versione ibrida. Consulta Più regioni deployment nella documentazione della versione 1.11.
Prima di iniziare un upgrade, esegui il backup e convalida i dati della prima regione. Consulta Cassandra Panoramica del backup nella documentazione della versione 1.11.
Esegui l'upgrade della regione appena aggiunta alla versione ibrida 1.12.
Sposta il traffico alla nuova regione e convalida il traffico.
Al termine della convalida, esegui l'upgrade della regione precedente con la versione ibrida 1.12.
Ripristina tutto il traffico alla regione precedente e convalida il traffico.
Rimuovi la nuova regione.

Considerazioni da fare prima di eseguire l'upgrade di un'installazione multiregionale

Apigee consiglia la seguente sequenza per l'upgrade di un'installazione multiregionale:

Prima di iniziare l'upgrade, esegui il backup e convalida i dati di ogni regione.
Esegui l'upgrade della versione ibrida in una regione e assicurati che tutti i pod siano in esecuzione per convalidare l'upgrade.
Convalida il traffico nella regione di cui è stato appena eseguito l'upgrade.
Esegui l'upgrade di ogni regione successiva solo dopo aver convalidato il traffico nella regione precedente.
Se c'è la necessità di eseguire il rollback di un upgrade in un deployment multiregionale, per allontanare il traffico dalle regioni con errori, valuta la possibilità di aggiungere capacità sufficiente nella regione in cui il traffico verrà per gestire il traffico in entrambe le regioni.

Prerequisiti

Prima di eseguire l'upgrade alla versione ibrida 1.12, assicurati che l'installazione soddisfi i seguenti requisiti:

Un'installazione Apigee ibrida della versione 1.11 gestita con Helm.
- Se gestisci la tua installazione ibrida con apigeectl, devi prima di eseguire la migrazione dei cluster alla gestione Helm. Consulta Esegui la migrazione di Apigee hybrid a Helm da apigeectl nella documentazione ibrida v1.11.
- Se la tua installazione ibrida esegue una versione precedente alla v1.11, deve eseguire l'upgrade alla versione 1.11 prima di eseguire l'upgrade alla v1.12. consulta Upgrade di Apigee hybrid alla versione 1.11.
Helm versione 3.10+.
kubectl versione 1.27, 1.28 o 1.29 (consigliata).
cert-manager versione v1.13.0. Se necessario, eseguirai l'upgrade di cert-manager nella sezione Preparare l'upgrade alla versione di seguito.

Limitazioni

Tieni presente le seguenti limitazioni quando pianifichi l'upgrade dalla versione ibrida di Apigee Dalla versione 1.11 alla versione 1.12. La pianificazione può aiutare a ridurre la necessità di tempi di inattività nel caso in cui sia necessario eseguire il rollback ripristinare il deployment dopo l'upgrade.

Impossibile ripristinare i backup dalla versione ibrida 1.12 nella versione ibrida 1.11 e viceversa a causa incompatibilità tra le due versioni.
Non puoi scalare i pod del datastore durante l'upgrade alla versione 1.12. Soddisfa le tue esigenze di scalabilità in tutte le regioni prima di iniziare l'upgrade dell'installazione ibrida.
In un'installazione ibrida a regione singola, non puoi eseguire il rollback del componente Datastore una volta Il processo di upgrade del datastore è terminato. Non puoi eseguire il rollback di un datastore Cassandra 4.x a un Datastore Cassandra 3.x. Sarà necessario ripristinare il backup più recente del Dati di Cassandra 3.x (dall'installazione ibrida della versione 1.11).
L'eliminazione o l'aggiunta di una regione non è supportata durante l'upgrade. In un upgrade multiregionale, devi completare l'upgrade di tutte le regioni prima di poter aggiungere o eliminare regioni.

Panoramica dell'aggiornamento alla versione 1.12.1

L'upgrade ad Apigee versione ibrida 1.12 potrebbe richiedere o un tempo di inattività.

Con l'upgrade del controller Apigee alla versione 1.12.1, 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, interessate le seguenti operazioni:

Il backup e il ripristino di Cassandra non funzionano con le versioni miste. Ad esempio, un backup dalla versione ibrida 1.11 non può essere utilizzata per ripristinare 1.12.
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.

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

Prepara l'upgrade.
- Backup di Cassandra.
- Esegui il backup delle directory di installazione ibrida.
Installa il runtime ibrido versione 1.12.1.

Prepara l'upgrade alla versione 1.12

Cassandra di backup

Esegui il backup del tuo database Cassandra in tutte le regioni applicabili e convalida i dati dell'installazione ibrida della versione 1.11 prima di iniziare l'upgrade. Consulta Monitora i backup nella documentazione della versione 1.11.

Riavvia tutti i pod Cassandra nel cluster prima di avviare il processo di upgrade, per evitare che vengano riscontrati problemi persistenti.

Per riavviare e testare i pod Cassandra, elimina ogni pod singolarmente, un pod alla volta, quindi verifica che sia nuovamente in esecuzione e che il probe di idoneità superi l'esito:

Elenca i pod Cassandra:

kubectl get pods -n APIGEE_NAMESPACE -l app=apigee-cassandra

Ad esempio:

kubectl get pods -n apigee -l app=apigee-cassandra
NAME                         READY   STATUS    RESTARTS   AGE
apigee-cassandra-default-0   1/1     Running   0          2h
apigee-cassandra-default-1   1/1     Running   0          2h
apigee-cassandra-default-2   1/1     Running   0          2h

. . .

Elimina un pod:

kubectl delete pod -n APIGEE_NAMESPACE CASSANDRA_POD_NAME

Ad esempio:

kubectl delete pod -n apigee apigee-cassandra-default-0

Controlla lo stato elencando di nuovo i pod Cassandra:

kubectl get pods -n APIGEE_NAMESPACE -l app=apigee-cassandra

Ad esempio:

kubectl get pods -n apigee -l app=apigee-cassandra
NAME                         READY   STATUS    RESTARTS   AGE
apigee-cassandra-default-0   1/1     Running   0          16s
apigee-cassandra-default-1   1/1     Running   0          2h
apigee-cassandra-default-2   1/1     Running   0          2h

. . .

Applica di nuovo l'ultimo file di override noto per assicurarti che non abbia apportato modifiche. puoi utilizzare la stessa configurazione per eseguire l'upgrade alla versione ibrida 1.12.

Assicurati che tutti i nodi Cassandra in tutte le regioni si trovino nella zona UN (Up / Normal). Se un nodo Cassandra si trova in uno stato diverso, devi prima indirizzarlo prima di iniziare l'upgrade.

Puoi convalidare lo stato dei nodi Cassandra con i seguenti comandi:

Elenca i pod Cassandra:

kubectl get pods -n APIGEE_NAMESPACE -l app=apigee-cassandra

Ad esempio:

kubectl get pods -n apigee -l app=apigee-cassandra
NAME                         READY   STATUS    RESTARTS   AGE
apigee-cassandra-default-0   1/1     Running   0          2h
apigee-cassandra-default-1   1/1     Running   0          2h
apigee-cassandra-default-2   1/1     Running   0          2h
apigee-cassandra-default-3   1/1     Running   0          16m
apigee-cassandra-default-4   1/1     Running   0          14m
apigee-cassandra-default-5   1/1     Running   0          13m
apigee-cassandra-default-6   1/1     Running   0          9m
apigee-cassandra-default-7   1/1     Running   0          9m
apigee-cassandra-default-8   1/1     Running   0          8m

Controlla lo stato dei nodi per ogni pod Cassandra con kubectl nodetool status :

kubectl -n APIGEE_NAMESPACE exec -it CASSANDRA_POD_NAME nodetool status

Ad esempio:

kubectl -n apigee exec -it apigee-cassandra-default-0 nodetool status
Datacenter: us-east1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load        Tokens       Owns (effective)  Host ID                               Rack
UN  10.16.2.6    690.17 KiB  256          48.8%             b02089d1-0521-42e1-bbed-900656a58b68  ra-1
UN  10.16.4.6    705.55 KiB  256          51.6%             dc6b7faf-6866-4044-9ac9-1269ebd85dab  ra-1
UN  10.16.11.11  674.36 KiB  256          48.3%             c7906366-6c98-4ff6-a4fd-17c596c33cf7  ra-1
UN  10.16.1.11   697.03 KiB  256          49.8%             ddf221aa-80aa-497d-b73f-67e576ff1a23  ra-1
UN  10.16.5.13   703.64 KiB  256          50.9%             2f01ac42-4b6a-4f9e-a4eb-4734c24def95  ra-1
UN  10.16.8.15   700.42 KiB  256          50.6%             a27f93af-f8a0-4c88-839f-2d653596efc2  ra-1
UN  10.16.11.3   697.03 KiB  256          49.8%             dad221ff-dad1-de33-2cd3-f1.672367e6f  ra-1
UN  10.16.14.16  704.04 KiB  256          50.9%             1feed042-a4b6-24ab-49a1-24d4cef95473  ra-1
UN  10.16.16.1   699.82 KiB  256          50.6%             beef93af-fee0-8e9d-8bbf-efc22d653596  ra-1

Esegui il backup delle directory di installazione ibrida

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%
```
Crea una copia di backup della versione 1.11 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.11-backup.tar.gz $APIGEE_HELM_CHARTS_HOME
```
Esegui il backup del tuo database Cassandra seguendo le istruzioni in Backup e ripristino di Cassandra.

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 è obbligatorio 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/`

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

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.11 sia da quella ibrida 1,12. Se hai bisogno di assistenza, segui la documentazione della piattaforma.

Fai clic per espandere un elenco di piattaforme supportate

	1,9 ⁽³⁾	1,10	1,11	1,12
Anthos (Google Cloud - GKE)	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,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⁽¹³⁾ 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	1.14.x (K8s v1.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 (Azure)	1,12,x 1,13,x 1,14,x	1,13,x 1,14,x 1,26 x⁽¹³⁾ 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	1,14,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 (on-premise - VMware) ⁽¹⁾ ⁽¹⁴⁾	1.12.x ⁽⁴⁾ 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⁽¹³⁾ 1,29.x^{(≥ 1.12.1)}
Anthos (bare metal)⁽¹⁾	1.12.x ⁽⁴⁾ 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⁽¹³⁾^{(≥ 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⁽¹³⁾ 1,29.x^{(≥ 1.12.1)}
EKS⁽⁷⁾	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⁽⁷⁾	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⁽⁷⁾	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)⁽⁷⁾	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/D	v1.26.x
Componenti	1,9 ⁽³⁾	1,10	1,11	1,12
Anthos Service Mesh (ASM)	1,17.x⁽¹¹⁾	1,17.x⁽¹¹⁾	1,18,x⁽¹¹⁾	1,19,x⁽¹¹⁾
JDK	JDK 11	JDK 11	JDK 11	JDK 11
gestore-certificati	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	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
⁽¹⁾ 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`. ⁽²⁾ Assistenza disponibile con Apigee ibrida versione 1.7.2 e successive. ⁽³⁾ 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. ⁽⁴⁾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. ⁽⁵⁾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. ⁽⁶⁾ Assistenza disponibile con Apigee hybrid versione 1.8.4 e successive. ⁽⁷⁾ I cluster collegati non sono necessari per Apigee hybrid v1.8 e versioni successive che utilizzano Ingressgateway Apigee.. ⁽⁸⁾ Non supportato con Apigee hybrid versione 1.8.4 e successive. ⁽⁹⁾ Assistenza disponibile con Apigee ibrido versione 1.7.6 e successive. ⁽¹⁰⁾ Non supportato con Apigee hybrid versione 1.8.5 e successive. ⁽¹¹⁾ ASM viene installato automaticamente con Apigee hybrid 1.9 e versioni successive. ⁽¹²⁾ Assistenza disponibile con Apigee hybrid versione 1.9.2 e successive. ⁽¹³⁾ 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. ⁽¹⁴⁾ Vault non è certificato su Anthos (on-premise - VMware). ⁽¹⁵⁾ Assistenza disponibile con Apigee hybrid versione 1.10.5 e successive. ⁽¹⁶⁾ Assistenza disponibile con Apigee hybrid versione 1.11.2 e successive. ⁽¹⁷⁾ 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.

Installazione del runtime ibrido 1.12.1

Prepararsi per l'upgrade dei grafici Helm

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

Se necessario, esegui l'upgrade di cert-manager.
Se devi eseguire l'upgrade della versione di cert-manager, installa la nuova versione con il seguente comando:
```
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.13.0/cert-manager.yaml
```

Installa i CRD di Apigee aggiornati:

Nota: questo è l'unico metodo supportato per installare i CRD Apigee. Non utilizzare kubectl apply senza -k, non omettere --server-side.

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

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

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

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.

In caso contrario, passa alla directory APIGEE_HELM_CHARTS_HOME. Esegui l' i seguenti comandi da quella directory.

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.12.1   1.12.1

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

Esegui l'upgrade del datastore Apigee:

Prova:

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

Esegui l'upgrade del grafico:

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

Nota:per le installazioni migrate, utilizza:

helm upgrade datastore apigee-datastore/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --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

Esegui l'upgrade della telemetria Apigee:

Prova:

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

Esegui l'upgrade del grafico:

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

Nota:per le installazioni migrate, utilizza:

helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --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

Esegui l'upgrade di Apigee Redis:

Prova:

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

Esegui l'upgrade del grafico:

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

Nota:per le installazioni migrate, utilizza:

helm upgrade redis apigee-redis/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --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

Esegui l'upgrade del gestore in entrata Apigee:

Prova:

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

Esegui l'upgrade del grafico:

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

Nota:per le installazioni migrate, utilizza:

helm upgrade ingress-manager apigee-ingress-manager/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --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

Esegui l'upgrade dell'organizzazione Apigee:

Prova:

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

Esegui l'upgrade del grafico:

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

Nota:per le installazioni migrate, utilizza:

helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --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

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_NAMESPACE \
  --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.12.1
Esegui l'upgrade del grafico:
```
helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set env=ENV_NAME \
  -f OVERRIDES_FILE
```
Nota:per le installazioni migrate, utilizza:
```
helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --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
```
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_NAMESPACE \
  --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_NAMESPACE \
  --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_NAMESPACE \
  --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
```

Rollback a una versione precedente in corso

Questa sezione è divisa in sezioni in base allo stato del tuo apigee-datastore componente dopo l'upgrade alla versione ibrida di Apigee 1,12. Esistono procedure per il rollback a una o più regioni con il componente apigee-datastore è in buono stato e le procedure per il ripristino o il ripristino da un backup quando apigee-datastore è in uno stato non valido.

Rollback e recupero di una singola regione

Rollback in corso quando `apigee-datastore` è in stato buono

Questa procedura spiega come eseguire il rollback di ogni componente ibrido Apigee dalla versione 1.12 alla versione 1.12 v1.11 tranne apigee-datastore. La versione 1.12 di apigee-datastore è compatibile con le versioni precedenti dei componenti ibridi v1.11.

Avviso: non è possibile eseguire il rollback di apigee-datastore. L'incompatibilità dei dati tra le diverse versioni del database Cassandra impedisce il rollback alla versione precedente.

Per eseguire il rollback dell'installazione in una singola regione alla versione 1.11:

Prima di avviare il rollback, verifica che tutti i pod siano in esecuzione:
```
kubectl get pods -n APIGEE_NAMESPACE
```
```
kubectl get pods -n apigee-system
```

Convalida la release dei componenti utilizzando Helm:

helm -n APIGEE_NAMESPACE list

helm -n apigee-system list

Ad esempio:

helm -n apigee list
NAME              NAMESPACE   REVISION   UPDATED                                   STATUS     CHART                           APP VERSION
datastore         apigee      2          2024-03-29 17:08:07.917848253 +0000 UTC   deployed   apigee-datastore-1.12.0         1.12.0
ingress-manager   apigee      2          2024-03-29 17:21:02.917333616 +0000 UTC   deployed   apigee-ingress-manager-1.12.0   1.12.0
redis             apigee      2          2024-03-29 17:19:51.143728084 +0000 UTC   deployed   apigee-redis-1.12.0             1.12.0
telemetry         apigee      2          2024-03-29 17:16:09.883885403 +0000 UTC   deployed   apigee-telemetry-1.12.0         1.12.0
myhybridorg       apigee      2          2024-03-29 17:21:50.899855344 +0000 UTC   deployed   apigee-org-1.12.0               1.12.0

Esegui il rollback di ogni componente tranne apigee-datastore con quanto segue :

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.
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_NAMESPACE \
  --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.
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_NAMESPACE \
  --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.

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

Esegui il rollback dell'organizzazione:

helm upgrade ORG_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-org/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f PREVIOUS_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

Esegui il rollback di Ingress Manager:

helm upgrade ingress-manager $PREVIOUS_HELM_CHARTS_HOME/apigee-ingress-manager/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f PREVIOUS_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

Esegui il rollback di Redis:

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

Verifica che sia attivo e funzionante controllandone lo stato:

kubectl -n apigee get apigeeredis default

NAME      STATE     AGE
default   running   2d

Esegui il rollback della telemetria Apigee:

helm upgrade telemetry $PREVIOUS_HELM_CHARTS_HOME/apigee-telemetry/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f PREVIOUS_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

Esegui il rollback del controller Apigee:

helm upgrade operator $PREVIOUS_HELM_CHARTS_HOME/apigee-operator/ \
  --install \
  --namespace apigee-system \
  --atomic \
  -f PREVIOUS_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.12.1   1.12.1

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

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

Verifica che tutti i pod siano in esecuzione o completati:

kubectl get pods -n APIGEE_NAMESPACE

kubectl get pods -n apigee-system

Convalida la release di tutti i componenti. Tutti i componenti devono essere nella versione precedente tranne datastore:

helm -n APIGEE_NAMESPACE list

helm -n apigee-system list

Ad esempio:

helm -n apigee  list
NAME              NAMESPACE  REVISION  UPDATED                                  STATUS    CHART                          APP VERSION
datastore         apigee     2         2024-03-29 18:47:55.979671057 +0000 UTC  deployed  apigee-datastore-1.12.0        1.12.0
ingress-manager   apigee     3         2024-03-14 19:14:57.905700154 +0000 UTC  deployed  apigee-ingress-manager-1.11.0  1.11.0
redis             apigee     3         2024-03-14 19:15:49.406917944 +0000 UTC  deployed  apigee-redis-1.11.0            1.11.0
telemetry         apigee     3         2024-03-14 19:17:04.803421424 +0000 UTC  deployed  apigee-telemetry-1.11.0        1.11.0
myhybridorg       apigee     3         2024-03-14 19:13:17.807673713 +0000 UTC  deployed  apigee-org-1.11.0              1.11.0

Ripristino quando `apigee-datastore` non è in uno stato buono

Se l'upgrade del componente apigee-datastore non è andato a buon fine, non puoi eseguire il rollback apigee-datastore dalla versione 1.12 alla versione 1.11. Invece, deve eseguire il ripristino da un backup effettuato da un'installazione v1.11. Utilizza quanto segue per ripristinare la versione precedente.

Se non hai un'installazione attiva di Apigee versione ibrida 1.11 (ad esempio in un'altra regione), crea una nuova installazione v1.11 utilizzando i grafici di cui hai eseguito il backup e i file di override. Consulta le Versione ibrida Apigee 1.11 Istruzioni per l'installazione.
Ripristina la regione v1.11 (o la nuova installazione) dal backup seguendo le istruzioni in:
- Backup di Cloud Storage Interface (CSI): Cassandra Backup e ripristino CSI.
- Backup non CSI: Ripristino all'interno di un'unica regione.
Verifica il traffico verso l'installazione ripristinata
(Facoltativo) Rimuovi l'installazione della versione 1.12 seguendo le istruzioni riportate in Disinstalla il runtime ibrido.

Rollback e ripristino multiregionale

Rollback in corso quando `apigee-datastore` è in stato buono

Prima di avviare il rollback, verifica che tutti i pod siano in esecuzione:
```
kubectl get pods -n APIGEE_NAMESPACE
```
```
kubectl get pods -n apigee-system
```

Puoi convalidare lo stato dei nodi Cassandra con i seguenti comandi:

Elenca i pod Cassandra:

kubectl get pods -n APIGEE_NAMESPACE -l app=apigee-cassandra

Ad esempio:

kubectl get pods -n apigee -l app=apigee-cassandra
NAME                         READY   STATUS    RESTARTS   AGE
apigee-cassandra-default-0   1/1     Running   0          2h
apigee-cassandra-default-1   1/1     Running   0          2h
apigee-cassandra-default-2   1/1     Running   0          2h
apigee-cassandra-default-3   1/1     Running   0          16m
apigee-cassandra-default-4   1/1     Running   0          14m
apigee-cassandra-default-5   1/1     Running   0          13m
apigee-cassandra-default-6   1/1     Running   0          9m
apigee-cassandra-default-7   1/1     Running   0          9m
apigee-cassandra-default-8   1/1     Running   0          8m

Controlla lo stato dei nodi per ogni pod Cassandra con kubectl nodetool status :

kubectl -n APIGEE_NAMESPACE exec -it CASSANDRA_POD_NAME -- nodetool -u JMX_USER -pw JMX_PASSWORD

Ad esempio:

kubectl -n apigee exec -it apigee-cassandra-default-0 -- nodetool -u jmxuser -pw JMX_PASSWORD status
Datacenter: us-east1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load        Tokens   Owns (effective)   Host ID                                Rack
UN  10.16.2.6    690.17 KiB  256      48.8%              b02089d1-0521-42e1-bbed-900656a58b68   ra-1
UN  10.16.4.6    705.55 KiB  256      51.6%              dc6b7faf-6866-4044-9ac9-1269ebd85dab   ra-1
UN  10.16.11.11  674.36 KiB  256      48.3%              c7906366-6c98-4ff6-a4fd-17c596c33cf7   ra-1
UN  10.16.1.11   697.03 KiB  256      49.8%              ddf221aa-80aa-497d-b73f-67e576ff1a23   ra-1
UN  10.16.5.13   703.64 KiB  256      50.9%              2f01ac42-4b6a-4f9e-a4eb-4734c24def95   ra-1
UN  10.16.8.15   700.42 KiB  256      50.6%              a27f93af-f8a0-4c88-839f-2d653596efc2   ra-1
UN  10.16.11.3   697.03 KiB  256      49.8%              dad221ff-dad1-de33-2cd3-f1.672367e6f   ra-1
UN  10.16.14.16  704.04 KiB  256      50.9%              1feed042-a4b6-24ab-49a1-24d4cef95473   ra-1
UN  10.16.16.1   699.82 KiB  256      50.6%              beef93af-fee0-8e9d-8bbf-efc22d653596   ra-1

Se non tutti i pod Cassandra sono in stato UN, segui le istruzioni in Rimuovi i nodi IN DOWN dal cluster Cassandra.

Vai alla directory in cui sono installati i precedenti grafici Helm ibridi Apigee
Cambia il contesto nella regione di cui è stato eseguito l'upgrade
```
kubectl config use-context UPGRADED_REGION_CONTEXT
    
```

Verifica che tutti i pod siano in esecuzione:

kubectl get pods -n APIGEE_NAMESPACE

kubectl get pods -n apigee-system

Usa il comando helm per assicurarti che sia stato eseguito l'upgrade di tutte le release alla versione ibrida 1.12:

helm -n APIGEE_NAMESPACE list

helm -n apigee-system list

Ad esempio:

helm -n apigee list
NAME             NAMESPACE  REVISION  UPDATED                                  STATUS    CHART                          APP VERSION
datastore        apigee     2         2024-03-29 17:08:07.917848253 +0000 UTC  deployed  apigee-datastore-1.12.0        1.12.0
ingress-manager  apigee     2         2024-03-29 17:21:02.917333616 +0000 UTC  deployed  apigee-ingress-manager-1.12.0  1.12.0
redis            apigee     2         2024-03-29 17:19:51.143728084 +0000 UTC  deployed  apigee-redis-1.12.0            1.12.0
telemetry        apigee     2         2024-03-29 17:16:09.883885403 +0000 UTC  deployed  apigee-telemetry-1.12.0        1.12.0
myhybridorg      apigee     2         2024-03-29 17:21:50.899855344 +0000 UTC  deployed  apigee-org-1.12.0              1.12.0

Esegui il rollback di ogni componente tranne apigee-datastore con quanto segue :

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.
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_NAMESPACE \
  --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.
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_NAMESPACE \
  --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.

Verifica che ogni ambiente sia attivo e in esecuzione controllando lo stato del rispettivo ambiente:
```
kubectl -n apigee get apigeeenv
```
```
NAME                  STATE     AGE   GATEWAYTYPE
apigee-org1-dev-xxx   running   2d
```

Esegui il rollback dell'organizzazione:

helm upgrade ORG_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-org/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f PREVIOUS_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

Esegui il rollback di Ingress Manager:

helm upgrade ingress-manager $PREVIOUS_HELM_CHARTS_HOME/apigee-ingress-manager/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f PREVIOUS_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

Esegui il rollback di Redis:

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

Verifica che sia attivo e funzionante controllandone lo stato:

kubectl -n apigee get apigeeredis default

NAME      STATE     AGE
default   running   2d

Esegui il rollback della telemetria Apigee:

helm upgrade telemetry $PREVIOUS_HELM_CHARTS_HOME/apigee-telemetry/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f PREVIOUS_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

Esegui il rollback del controller Apigee:

helm upgrade operator $PREVIOUS_HELM_CHARTS_HOME/apigee-operator/ \
  --install \
  --namespace apigee-system \
  --atomic \
  -f PREVIOUS_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.12.1   1.12.1

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

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

Convalida la release di tutti i componenti. Tutti i componenti devono essere nella versione precedente tranne datastore:

helm -n APIGEE_NAMESPACE list

helm -n apigee-system list

Ad esempio:

helm -n apigee  list
NAME              NAMESPACE  REVISION  UPDATED                                  STATUS    CHART                          APP VERSION
datastore         apigee     2         2024-03-29 18:47:55.979671057 +0000 UTC  deployed  apigee-datastore-1.12.0        1.12.0
ingress-manager   apigee     3         2024-03-14 19:14:57.905700154 +0000 UTC  deployed  apigee-ingress-manager-1.11.0  1.11.0
redis             apigee     3         2024-03-14 19:15:49.406917944 +0000 UTC  deployed  apigee-redis-1.11.0            1.11.0
telemetry         apigee     3         2024-03-14 19:17:04.803421424 +0000 UTC  deployed  apigee-telemetry-1.11.0        1.11.0
myhybridorg       apigee     3         2024-03-14 19:13:17.807673713 +0000 UTC  deployed  apigee-org-1.11.0              1.11.0

A questo punto è stato eseguito il rollback di tutte le release tranne datastore alla versione precedente.

Ripristino di un'installazione multiregionale in una versione precedente

Recupera la regione in cui l'upgrade non è riuscito in un upgrade in più regioni rimuovendo i riferimenti a quest'ultima da installazioni di più regioni. Questo metodo è possibile solo se esiste almeno una regione attiva nell'ambiente ibrido 1.11. Il datastore v1.12 è compatibile con i componenti v 1.11.

Per recuperare le regioni non riuscite da una regione integra, segui questi passaggi:

Reindirizza il traffico API dalle regioni interessate alla regione funzionante. Piano la capacità di supportare di conseguenza il traffico deviato dalle regioni in errore.
Rimuovi la regione interessata. Per ogni regione interessata, segui i passaggi descritti in Rimuovere una regione ibrida. Attendi il completamento del ritiro prima di procedere con lo spostamento al passaggio successivo.
Esegui la pulizia della regione in errore seguendo le istruzioni in Recuperare una regione da un upgrade non riuscito.
Recupera la regione interessata. Per eseguire il ripristino, crea una nuova regione, come descritto in Deployment multiregionale su GKE, GKE On-Prem e AKS.

Ripristino di un'installazione multiregionale da un backup con `apigee-datastore` in stato non valido

Se l'upgrade del componente apigee-datastore non è andato a buon fine, non puoi eseguire il rollback dalla versione 1.12 alla versione 1.11. Invece, deve eseguire il ripristino da un backup effettuato da un'installazione v1.11. Utilizza quanto segue per ripristinare la versione precedente.

Se non hai un'installazione attiva di Apigee versione ibrida 1.11 (ad esempio in un'altra regione), crea una nuova installazione v1.11 utilizzando i grafici di cui hai eseguito il backup e i file di override. Consulta le Versione ibrida Apigee 1.11 Istruzioni per l'installazione.
Ripristina la regione v1.11 (o la nuova installazione) dal backup seguendo le istruzioni in:
- Backup di Cloud Storage Interface (CSI): Cassandra Backup e ripristino CSI.
- Backup non CSI: Ripristino in più regioni.
Verifica il traffico verso l'installazione ripristinata
Per le installazioni in più regioni, ricrea e ripristina la regione successiva. Consulta le istruzioni in Ripristino da un backup in Ripristino in più regioni.
Rimuovi l'installazione della versione 1.12 seguendo le istruzioni in Disinstalla il runtime ibrido.

APPENDICE: Ripristino di una regione da un upgrade non riuscito

Rimuovere un data center se l'aggiornamento non riesce dalla versione 1.11 alla versione 1.12.

Convalida lo stato del cluster Cassandra da una regione attiva:

Cambia il contesto kubectl con la regione da rimuovere:
```
kubectl config use-context CONTEXT_OF_LIVE_REGION
```

Elenca i pod Cassandra:

kubectl get pods -n APIGEE_NAMESPACE -l app=apigee-cassandra

Ad esempio:

kubectl get pods -n apigee -l app=apigee-cassandra
NAME                 READY   STATUS    RESTARTS   AGE
apigee-cassandra-default-0   1/1     Running   0          2h
apigee-cassandra-default-1   1/1     Running   0          2h
apigee-cassandra-default-2   1/1     Running   0          2h

Esegui in uno dei pod Cassandra:

kubectl exec -it -n CASSANDRA_POD_NAME -- /bin/bash

Controlla lo stato del cluster Cassandra:

nodetool -u JMX_USER -pw JMX_PASSWORD status

L'output dovrebbe essere simile al seguente:

Datacenter: dc-1
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load        Tokens       Owns (effective)  Host ID                               Rack
UN  10.48.12.16  813.84 KiB  256          100.0%            a6340ad9-37ba-4ec8-a8c2-f7b7ac931807  ra-1
UN  10.48.14.16  859.89 KiB  256          100.0%            39f03c51-e387-4dac-8360-6d8732e690a7  ra-1
UN  10.48.0.18   888.95 KiB  256          100.0%            0d57df49-52e4-4c01-832d-d9df845ab732  ra-1

Descrivi il cluster per verificare che vengano visualizzati solo gli IP dei pod Cassandra della regione attiva e tutti nella stessa versione dello schema:

nodetool -u JMX_USER -pw JMX_PASSWORD describecluster

L'output dovrebbe essere simile al seguente:

nodetool -u JMX_USER -pw JMX_PASSWORD describecluster

Schema versions:
    4bebf2de-0582-31b4-9c5f-e36f60127e1b: [10.48.14.16, 10.48.12.16, 10.48.0.18]

Esegui la pulizia della replica dello spazio delle chiavi Cassandra:

Ottieni il job user-setup ed eliminalo. Verrà eseguito un nuovo job user-setup possono essere create immediatamente.

kubectl get jobs -n APIGEE_NAMESPACE

Ad esempio:

kubectl get jobs -n apigee
  NAME                                                           COMPLETIONS   DURATION   AGE
  apigee-cassandra-schema-setup-myhybridorg-8b3e61d          1/1           6m35s      3h5m
  apigee-cassandra-schema-val-myhybridorg-8b3e61d-28499150   1/1           10s        9m22s
 apigee-cassandra-user-setup-myhybridorg-8b3e61d            0/1           21s        21s

kubectl delete jobs USER_SETUP_JOB_NAME -n APIGEE_NAMESPACE

L'output dovrebbe mostrare il nuovo job che inizia:

kubectl delete jobs apigee-cassandra-user-setup-myhybridorg-8b3e61d -n apigee

  apigee-cassandra-user-setup-myhybridorg-8b3e61d-wl92b         0/1     Init:0/1    0               1s

Convalida le impostazioni di replica dello spazio delle chiavi Cassandra creando un container client dopo in Creare il container client.

Recupera tutti gli spazi delle chiavi. Esegui in un pod cassandra-client e avvia un client cqlsh:

kubectl exec -it -n APIGEE_NAMESPACE cassandra-client -- /bin/bash

Connettiti al server Cassandra con ddl user, in quanto dispone delle autorizzazioni necessarie per eseguire i seguenti comandi:

cqlsh apigee-cassandra-default.apigee.svc.cluster.local -u DDL_USER -p DDL_PASSWORD --ssl

Recupera gli spazi delle chiavi:

select * from system_schema.keyspaces;

L'output dovrebbe essere simile al seguente, dove dc-1 è il DC live:

select * from system_schema.keyspaces;

 keyspace_name            | durable_writes | replication
--------------------------+----------------+--------------------------------------------------------------------------------
   kvm_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
              system_auth |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
            system_schema |           True |                        {'class': 'org.apache.cassandra.locator.LocalStrategy'}
 quota_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
 cache_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
   rtc_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
       system_distributed |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
                   system |           True |                        {'class': 'org.apache.cassandra.locator.LocalStrategy'}
                   perses |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
            system_traces |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
   kms_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}

(11 rows)

Se per qualche motivo il job user-setup continua a restituire un errore e la convalida non va a buon fine, utilizza i comandi seguenti per correggere la replica negli spazi delle chiavi.

kubectl exec -it -n APIGEE_NAMESPACE cassandra-client -- /bin/bash

Connettiti al server Cassandra con ddl user, in quanto dispone delle autorizzazioni necessarie per eseguire i seguenti comandi:

cqlsh apigee-cassandra-default.apigee.svc.cluster.local -u DDL_USER -p DDL_PASSWORD --ssl

Recupera gli spazi delle chiavi:

select * from system_schema.keyspaces;

Utilizza i nomi degli spazi delle chiavi del comando precedente e sostituiscili nei seguenti esempi

alter keyspace quota_myhybridorg_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
alter keyspace kms_myhybridorg_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
alter keyspace kvm_myhybridorg_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
alter keyspace cache_myhybridorg_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
alter keyspace perses_myhybridorg_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
alter keyspace rtc_myhybridorg_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
alter keyspace system_auth WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
alter keyspace system_distributed WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
alter keyspace system_traces WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};

Verifica che tutti gli spazi delle chiavi siano replicati nella regione giusta con il seguente comando cqlsh:

select * from system_schema.keyspaces;

Ad esempio:

select * from system_schema.keyspaces;

 keyspace_name           | durable_writes | replication
-------------------------+----------------+--------------------------------------------------------------------------------
kvm_myhybridorg_hybrid   |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
          system_auth    |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
        system_schema    |           True |                        {'class': 'org.apache.cassandra.locator.LocalStrategy'}
quota_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
cache_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
rtc_myhybridorg_hybrid   |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
   system_distributed    |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
               system    |           True |                        {'class': 'org.apache.cassandra.locator.LocalStrategy'}
               perses    |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
        system_traces    |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
kms_myhybridorg_hybrid   |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}

(11 rows)

In questa fase hai rimosso completamente tutti i riferimenti per il controller di dominio non attivo dal cluster Cassandra.

APPENDICE: Rimuovi nodi DOWN dal cluster Cassandra

Utilizza questa procedura quando esegui il rollback di un'installazione multiregionale e non tutti i pod Cassandra sono in stato attivo / normale (UN).

Esegui in uno dei pod Cassandra:

kubectl exec -it -n CASSANDRA_POD_NAME -- /bin/bash

Controlla lo stato del cluster Cassandra:

nodetool -u JMX_USER -pw JMX_PASSWORD status

Verifica che il nodo sia effettivamente inattivo (DN). Esegui l'esecuzione in un pod Cassandra in una regione in cui non è possibile visualizzare il pod Cassandra.

Datacenter: dc-1
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load        Tokens  Owns (effective)  Host ID                               Rack
UN  10.48.12.16  1.15 MiB    256     100.0%            a6340ad9-37ba-4ec8-a8c2-f7b7ac931807  ra-1
UN  10.48.0.18   1.21 MiB    256     100.0%            0d57df49-52e4-4c01-832d-d9df845ab732  ra-1
UN  10.48.14.16  1.18 MiB    256     100.0%            39f03c51-e387-4dac-8360-6d8732e690a7  ra-1

Datacenter: us-west1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load        Tokens  Owns (effective)  Host ID                               Rack
DN  10.8.4.4     432.42 KiB  256     100.0%            cd672398-5c45-4c88-a424-86d757951e53  rc-1
UN  10.8.19.6    5.8 MiB     256     100.0%            84f771f3-3632-4155-b27f-a67125d73bc5  rc-1
UN  10.8.21.5    5.74 MiB    256     100.0%            f6f21b70-348d-482d-89fa-14b7147a5042  rc-1

Rimuovi il riferimento al nodo verso il basso (DN). Dall'esempio precedente rimuoveremo il riferimento per l'host 10.8.4.4

kubectl exec -it -n apigee apigee-cassandra-default-2 -- /bin/bash
 nodetool -u JMX_USER -pw JMX_PASSWORD removenode HOST_ID

Dopo aver rimosso il riferimento, termina il pod. Dovrebbe apparire il nuovo pod Cassandra e unirsi al cluster
```
kubectl delete pod -n POD_NAME
```

Verifica che il nuovo pod Cassandra sia stato unito al cluster.

Datacenter: dc-1
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load        Tokens  Owns (effective)  Host ID                               Rack
UN  10.48.12.16  1.16 MiB    256     100.0%            a6340ad9-37ba-4ec8-a8c2-f7b7ac931807  ra-1
UN  10.48.0.18   1.22 MiB    256     100.0%            0d57df49-52e4-4c01-832d-d9df845ab732  ra-1
UN  10.48.14.16  1.19 MiB    256     100.0%            39f03c51-e387-4dac-8360-6d8732e690a7  ra-1

Datacenter: us-west1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load        Tokens  Owns (effective)  Host ID                               Rack
UN  10.8.19.6    5.77 MiB    256     100.0%            84f771f3-3632-4155-b27f-a67125d73bc5  rc-1
UN  10.8.4.5     246.99 KiB  256     100.0%            0182e675-eec8-4d68-a465-69211b621601  rc-1
UN  10.8.21.5    5.69 MiB    256     100.0%            f6f21b70-348d-482d-89fa-14b7147a5042  rc-1

A questo punto puoi procedere con l'upgrade o il rollback delle regioni rimanenti del cluster.

APPENDICE: Risoluzione dei problemi: `apigee-datastore` in stato bloccato dopo il rollback

Utilizza questa procedura se hai eseguito il rollback di apigee-datastore all'ibrido 1.11 dopo l'upgrade e il dispositivo è bloccato.

Prima di correggere nuovamente lo stato del controller del datastore, verifica che sia in stato releasing e che i pod non vengano visualizzati insieme allo stato del cluster Cassandra.

Verifica mediante il comando Helm il rollback del datastore:

helm -n APIGEE_NAMESPACE list

Ad esempio:

helm -n apigee list
NAME              NAMESPACE  REVISION  UPDATED                                   STATUS    CHART                              APP VERSION
datastore         apigee     3         2024-04-04 22:15:08.792539892 +0000 UTC   deployed   apigee-datastore-1.11.0           1.11.0
ingress-manager   apigee     1         2024-04-02 22:24:27.564184968 +0000 UTC   deployed   apigee-ingress-manager-1.12.0     1.12.0
redis             apigee     1         2024-04-02 22:23:59.938637491 +0000 UTC   deployed   apigee-redis-1.12.0               1.12.0
telemetry         apigee     1         2024-04-02 22:23:39.458134303 +0000 UTC   deployed   apigee-telemetry-1.12             1.12.0
myhybridorg       apigee     1         2024-04-02 23:36:32.614927914 +0000 UTC   deployed   apigee-org-1.12.0                 1.12.0

Ottieni lo stato dei pod Cassandra:

kubectl get pods -n APIGEE_NAMESPACE

Ad esempio:

kubectl get pods -n apigee
NAME                         READY   STATUS             RESTARTS      AGE
apigee-cassandra-default-0   1/1     Running            0             2h
apigee-cassandra-default-1   1/1     Running            0             2h
apigee-cassandra-default-2   0/1     CrashLoopBackOff   4 (13s ago)   2m13s

Verifica che il controller apigeeds sia bloccato in stato di rilascio:

kubectl get apigeeds -n APIGEE_NAMESPACE

Ad esempio:

kubectl get apigeeds -n apigee
NAME      STATE       AGE
default   releasing   46h

Convalida lo stato dei nodi Cassandra (nota che un nodo è in stato DN, ovvero è bloccato nello stato CrashLoopBackOff):

kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  -- nodetool -u JMX_USER -pw JMX_PASSWORD status

Ad esempio:

kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u jmxuser -pw JMX_PASSWORD status
Defaulted container "apigee-cassandra" out of: apigee-cassandra, apigee-cassandra-ulimit-init (init)
Datacenter: us-west1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--   Address       Load       Tokens   Owns (effective)   Host ID                               Rack
UN   10.68.7.28    2.12 MiB   256      100.0%             4de9df37-3997-43e7-8b5b-632d1feb14d3  rc-1
UN   10.68.10.29   2.14 MiB   256      100.0%             a54e673b-ec63-4c08-af32-ea6c00194452  rc-1
DN   10.68.6.26    5.77 MiB   256      100.0%             0fe8c2f4-40bf-4ba8-887b-9462159cac45   rc-1

Eseguire l'upgrade del datastore utilizzando i grafici 1.12.
Nota: il controller tornerà allo stato releasing, ma questa volta creerà pod con le immagini per l'ibrido 1.12 che verrà visualizzato e Cassandra si unirà al cluster e diventerà UN (UP/NORMAL).
```
helm upgrade datastore APIGEE_HELM_1.12.0_HOME/apigee-datastore/   --install   --namespace APIGEE_NAMESPACE   -f overrides.yaml
```

Verifica che tutti i pod siano Running e che il cluster Cassandra sia di nuovo integro.

Verifica che tutti i pod siano di nuovo READY:

kubectl get pods -n APIGEE_NAMESPACE

Ad esempio:

kubectl get pods -n apigee
NAME                         READY   STATUS    RESTARTS   AGE
apigee-cassandra-default-0   1/1     Running   0          29h
apigee-cassandra-default-1   1/1     Running   0          29h
apigee-cassandra-default-2   1/1     Running   0          60m

Convalida lo stato del cluster Cassandra:

kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  -- nodetool -u JMX_USER -pw JMX_PASSWORD status

Ad esempio:

kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u jmxuser -pw JMX_PASSWORD status
Datacenter: us-west1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--   Address       Load      Tokens   Owns (effective)   Host ID                                Rack
UN   10.68.4.15    2.05 MiB  256      100.0%             0fe8c2f4-40bf-4ba8-887b-9462159cac45   rc-1
UN   10.68.7.28    3.84 MiB  256      100.0%             4de9df37-3997-43e7-8b5b-632d1feb14d3   rc-1
UN   10.68.10.29   3.91 MiB  256      100.0%             a54e673b-ec63-4c08-af32-ea6c00194452   rc-1

Stato della convalida del controller apigeeds:

kubectl get apigeeds -n APIGEE_NAMESPACE

Ad esempio:

kubectl get apigeeds -n apigee
NAME      STATE     AGE
default   running   2d1h

A questo punto hai corretto il datastore che dovrebbe essere nello stato running.

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

Modifiche rispetto alla versione 1.11 di Apigee hybrid

Considerazioni da fare prima di avviare un upgrade alla versione 1.12

Considerazioni da fare prima di eseguire l'upgrade di un'installazione in una singola regione

Considerazioni da fare prima di eseguire l'upgrade di un'installazione multiregionale

Prerequisiti

Limitazioni

Panoramica dell'aggiornamento alla versione 1.12.1

Prepara l'upgrade alla versione 1.12

Cassandra di backup

Esegui il backup delle directory di installazione ibrida

Linux

Mac OS

Windows

Produzione

Non di produzione

Esegui l'upgrade della versione di Kubernetes

Fai clic per espandere un elenco di piattaforme supportate

Componenti

Informazioni sui cluster collegati

Installazione del runtime ibrido 1.12.1

Prepararsi per l'upgrade dei grafici Helm

Installa i grafici Helm ibridi Apigee

Rollback a una versione precedente in corso

Rollback e recupero di una singola regione

Rollback in corso quando apigee-datastore è in stato buono

Ripristino quando apigee-datastore non è in uno stato buono

Rollback e ripristino multiregionale

Rollback in corso quando apigee-datastore è in stato buono

Ripristino di un'installazione multiregionale in una versione precedente

Ripristino di un'installazione multiregionale da un backup con apigee-datastore in stato non valido

APPENDICE: Ripristino di una regione da un upgrade non riuscito

APPENDICE: Rimuovi nodi DOWN dal cluster Cassandra

APPENDICE: Risoluzione dei problemi: apigee-datastore in stato bloccato dopo il rollback

Rollback in corso quando `apigee-datastore` è in stato buono

Ripristino quando `apigee-datastore` non è in uno stato buono

Rollback in corso quando `apigee-datastore` è in stato buono

Ripristino di un'installazione multiregionale da un backup con `apigee-datastore` in stato non valido

APPENDICE: Risoluzione dei problemi: `apigee-datastore` in stato bloccato dopo il rollback