Questa pagina è stata tradotta dall'API Cloud Translation.

Eseguire l'upgrade di Apigee hybrid alla versione 1.12

Questa procedura riguarda l'upgrade da Apigee hybrid versione 1.11.x ad Apigee hybrid versione 1.12.4 e dalle versioni precedenti di hybrid 1.12.x alla versione 1.12.4.

Utilizza le stesse procedure per gli upgrade delle versioni secondarie (ad esempio dalla versione 1.11 alla 1.12) e per gli upgrade delle release di patch (ad esempio dalla versione 1.12.0 alla 1.12.4).

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

Modifiche rispetto ad Apigee hybrid v1.11

La versione 1.12 di Apigee hybrid introduce le seguenti modifiche che influiscono sul processo di upgrade. Per un elenco completo delle funzionalità della versione 1.12, consulta le note di rilascio della versione 1.12.0 di Hybrid.

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

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

Per continuare a emettere metriche per le risorse monitorate ProxyV2 e TargetV2, imposta metrics.disablePrometheusPipeline su true in overrides.yaml.
Se hai configurato avvisi basati sulle metriche, verifica l'utilizzo delle metriche corrette per l'installazione ibrida. Per saperne di più, consulta Avvisi basati su metriche.
Controlli più rigorosi per l'istanza della classe: a partire dalla versione 1.12.4 di Apigee Hybrid, il JavaCallout policy ora include una sicurezza aggiuntiva durante l'istanza della classe Java. La misura di sicurezza avanzata impedisce l'implementazione di criteri che tentano direttamente o indirettamente azioni che richiedono autorizzazioni non consentite.
Nella maggior parte dei casi, le norme esistenti continueranno a funzionare come previsto senza problemi. Tuttavia, è possibile che le norme che si basano su librerie di terze parti o quelle con codice personalizzato che attiva indirettamente operazioni che richiedono autorizzazioni elevate possano essere interessate.

Importante:per testare l'installazione, segui la procedura descritta in Convalida delle norme dopo l'upgrade alla versione 1.12.4 per convalidare il comportamento delle norme.

Considerazioni da tenere presenti prima di iniziare un upgrade alla versione 1.12

Considerazioni su Cassandra

L'upgrade dalla versione 1.11 alla versione 1.12 di Apigee hybrid include un upgrade del database Cassandra dalla versione 3.11.x alla versione 4.x. Sebbene l'upgrade di Cassandra venga gestito nell'ambito della procedura di upgrade di Apigee hybrid, pianifica quanto segue:

L'upgrade della versione di Cassandra verrà eseguito in background e avrà luogo su un pod (o nodo Cassandra) alla volta, quindi pianifica una capacità del database ridotta durante l'upgrade.
Aumenta la 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 della versione 1.11 prima di iniziare l'upgrade e convalida i backup.
L'upgrade di apigee-datastore comporterà un aumento temporaneo del consumo di CPU a causa delle attività post-upgrade eseguite da Cassandra
Una volta eseguito l'upgrade del componente apigee-datastore (Cassandra), non puoi eseguire il rollback di questo componente alla versione precedente. Esistono due scenari per il rollback di un upgrade a hybrid v1.12 dopo l'upgrade del componente apigee-datastore:
- Se il componente apigee-datastore è in buono stato, ma altri componenti richiedono un rollback, puoi eseguire il rollback di questi altri componenti singolarmente.
  Nota:non potrai aggiungere regioni o scalare i nodi Cassandra durante l'esecuzione di componenti di versioni ibride diverse.
- Se il componente apigee-datastore è in uno stato non valido, devi eseguire il ripristino da un backup v1.11 in un'installazione v1.11.
  Nota:non puoi combinare le versioni durante il ripristino. Devi ripristinare un backup eseguito in un'installazione v1.11 in un'installazione v1.11.

Considerazioni preliminari all'upgrade di un'installazione a una sola regione

Se devi eseguire il rollback a una versione precedente di Apigee Hybrid, la procedura potrebbe richiedere tempi di inattività. Pertanto, se stai eseguendo l'upgrade di un'installazione a livello di regione singola, ti consigliamo di creare una seconda regione ed eseguire l'upgrade di una sola regione alla volta nella seguente sequenza:

Aggiungi una seconda regione all'installazione esistente utilizzando la stessa versione ibrida. Consulta la sezione Deployment multiregionale nella documentazione della versione 1.11.
Esegui il backup e convalida i dati della prima regione prima di iniziare un upgrade. Consulta la panoramica del backup di Cassandra nella documentazione della versione 1.11.
Esegui l'upgrade della regione appena aggiunta a hybrid 1.12.
Sposta il traffico nella nuova regione e convalidalo.
Una volta convalidata, esegui l'upgrade della regione precedente con la versione ibrida 1.12.
Sposta tutto il traffico nella regione precedente e convalidalo.
Ritira la nuova regione.

Considerazioni preliminari all'upgrade di un'installazione multiregionale

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

Esegui il backup e convalida i dati di ogni regione prima di iniziare l'upgrade.
Esegui l'upgrade della versione ibrida in una regione e assicurati che tutti i pod siano in stato di esecuzione per convalidare l'upgrade.
Convalida il traffico nella regione appena aggiornata.
Esegui l'upgrade di ogni regione successiva solo dopo aver convalidato il traffico nella regione precedente.
In caso di potenziale necessità di eseguire il rollback di un upgrade in un deployment multiregionale, preparati a spostare il traffico dalle regioni in cui si è verificato l'errore e valuta la possibilità di aggiungere capacità sufficiente nella regione in cui il traffico verrà dirottato per gestire il traffico di entrambe le regioni.

Prerequisiti

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

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

Limitazioni

Tieni presente le seguenti limitazioni quando pianifichi l'upgrade da Apigee hybrid versione 1.11 alla versione 1.12. La pianificazione può contribuire a ridurre la necessità di tempi di inattività se devi eseguire il rollback o il ripristino dopo l'upgrade.

I backup di Hybrid 1.12 non possono essere ripristinati in Hybrid 1.11 e viceversa a causa dell'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 singola regione, non puoi eseguire il rollback del componente datastore una volta terminato il processo di upgrade del datastore. Non puoi eseguire il rollback di un datastore Cassandra 4.x a un datastore Cassandra 3.x. Per farlo, dovrai eseguire il ripristino dall'ultimo backup dei dati di Cassandra 3.x (dall'installazione della versione ibrida 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'upgrade alla versione 1.12.4

L'upgrade alla versione 1.12 di Apigee hybrid potrebbe richiedere tempi di inattività.

Quando esegui l'upgrade del controller Apigee alla versione 1.12.4, tutti i deployment Apigee vengono riavviati in sequenza. Per ridurre al minimo i tempi di inattività negli ambienti ibridi di produzione durante un riavvio graduale, assicurati di eseguire almeno due cluster (nello stesso o in un data center/regione diverso). Devia tutto il traffico di produzione a un singolo cluster, metti offline il cluster di cui stai per eseguire l'upgrade e procedi con la procedura di upgrade. Ripeti la procedura per ogni cluster.

Apigee consiglia di eseguire l'upgrade di tutti i cluster il prima possibile per ridurre le possibilità di impatto sulla produzione. Non è previsto un limite di tempo per l'upgrade di tutti i cluster rimanenti dopo l'upgrade del primo. Tuttavia, fino a quando non verrà eseguito l'upgrade di tutti i cluster rimanenti, le seguenti operazioni saranno interessate:

Il backup e il ripristino di Cassandra non possono funzionare con versioni miste. Ad esempio, un backup di Hybrid 1.11 non può essere utilizzato per ripristinare un'istanza Hybrid 1.12.
Lo streaming dei dati di Cassandra non funzionerà tra versioni ibride miste. Pertanto, i tuoi cluster Cassandra non possono essere scalati orizzontalmente.
L'espansione e il ritiro delle regioni saranno interessati, perché queste operazioni dipendono dallo streaming dei dati di Cassandra.

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

Preparati all'upgrade.
- Backup di Cassandra.
- Esegui il backup delle directory di installazione ibrida.
Installa la versione 1.12.4 del runtime di hybrid.

Prepararsi all'upgrade alla versione 1.12

Backup di Cassandra

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

Riavvia tutti i pod Cassandra nel cluster prima di iniziare la procedura di upgrade, in modo che eventuali problemi persistenti possano emergere.

Per riavviare e testare i pod Cassandra, elimina ogni pod singolarmente, uno alla volta, quindi verifica che torni allo stato di esecuzione e che il probe di disponibilità venga superato:

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

. . .

Eliminare 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 siano state apportate modifiche, in modo da poter utilizzare la stessa configurazione per eseguire l'upgrade alla versione ibrida 1.12.

Assicurati che tutti i nodi Cassandra in tutte le regioni siano nello stato UN (Up / Normal). Se un nodo Cassandra si trova in uno stato diverso, risolvi il problema 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 il comando 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, passa a 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 directory $APIGEE_HELM_CHARTS_HOME/ della versione 1.11. Puoi utilizzare qualsiasi procedura 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 database Cassandra seguendo le istruzioni riportate in Backup e ripristino di Cassandra.

Se utilizzi file di certificati di servizio (.json) negli override per autenticare i service account, assicurati che i file di certificati del account di servizio si trovino nella directory del grafico Helm corretta. I grafici Helm non possono leggere file al di fuori di ogni directory del grafico.

Questo passaggio non è necessario se utilizzi i secret Kubernetes o Workload Identity per autenticare i service account.

La tabella seguente mostra la destinazione di ogni file del service account, a seconda del tipo di installazione:

Prod

Service account	Nome file predefinito	Directory del grafico 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 del account di servizio apigee-non-prod in ciascuna delle seguenti directory:

Service account	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 i file del certificato e della chiave TLS (.crt, .key e/o .pem) si trovino nella directory $APIGEE_HELM_CHARTS_HOME/apigee-virtualhost/.

Esegui l'upgrade della versione di Kubernetes

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

Fai clic per espandere l'elenco delle piattaforme supportate

	1,10 ⁽³⁾	1,11	1,12
GKE su Google Cloud	1.24.x 1.25.x 1.26.x 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	1.25.x 1.26.x 1.27.x 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	1.26.x 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)}
GKE su AWS	1.13.x (K8s v1.24.x) 1.14.x (K8s v1.25.x) 1.26.x⁽¹²⁾ 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)}
GKE su Azure	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)}
Google Distributed Cloud (solo software) su VMware ⁽¹⁾ ⁽¹³⁾	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)}
Google Distributed Cloud (solo software) su bare metal ⁽¹⁾	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.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.24.x 1.25.x 1.26.x 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	1.25.x 1.26.x 1.27.x 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	1.26.x 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)}
OpenShift⁽⁷⁾	4.11 4.12 4.14^{(≥ 1.10.5)} 4.15^{(≥ 1.10.5)}	4.12 4.13 4.14 4.15^{(≥ 1.11.2)} 4.16^{(≥ 1.11.2)}	4.12 4.13 4.14 4.15 4.16^{(≥ 1.12.1)}
Rancher Kubernetes Engine (RKE)	v1.26.2+rke2r1 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	v1.26.2+rke2r1 v1.27.x 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	v1.26.2+rke2r1 v1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)}
VMware Tanzu	N/D	N/D	v1.26.x
Componenti	1,10	1,11	1,12
Cloud Service Mesh	1.17.x⁽¹⁰⁾	1.18.x⁽¹⁰⁾	1.19.x⁽¹⁰⁾
JDK	JDK 11	JDK 11	JDK 11
cert-manager	1.10.x 1.11.x 1.12.x	1.11.x 1.12.x 1.13.x	1.11.x 1.12.x 1.13.x
Cassandra	3.11	3.11	4.0
Kubernetes	1.24.x 1.25.x 1.26.x	1.25.x 1.26.x 1.27.x	1.26.x 1.27.x 1.28.x
kubectl			1.27.x 1.28.x 1.29.x
Helm	3.10+	3.10+	3.14.2+
Driver CSI Secret Store		1.3.4	1.4.1
Vault		1.13.x	1.15.2
⁽¹⁾ In Anthos on-premises (Google Distributed Cloud) versione 1.13, segui queste istruzioni per evitare conflitti con `cert-manager`: Installazione di cert-manager in conflitto ⁽²⁾ Supporto disponibile con Apigee hybrid versione 1.7.2 e successive. ⁽³⁾ Sono state raggiunte le date EOL ufficiali per le versioni 1.10 e precedenti di Apigee hybrid. Le patch mensili regolari non sono più disponibili. Queste release non sono più supportate ufficialmente, ad eccezione dei clienti con eccezioni esplicite e ufficiali per il supporto continuo. Altri clienti devono eseguire l'upgrade. ⁽⁴⁾Le versioni 1.12 e precedenti di Anthos on-premise (Google Distributed Cloud) non sono più supportate. Consulta i criteri di supporto delle versioni di Distributed Cloud su bare metal e l'elenco delle versioni supportate di Distributed Cloud su VMware. ⁽⁵⁾Google Distributed Cloud su bare metal o VMware richiede Cloud Service Mesh 1.14 o versioni successive. Ti consigliamo di eseguire l'upgrade a hybrid v1.8 e passare al gateway in entrata Apigee, che non richiede più l'installazione di Cloud Service Mesh sul cluster ibrido. ⁽⁶⁾ Supporto disponibile con Apigee hybrid versione 1.8.4 e successive. ⁽⁷⁾ Non supportato con Apigee Hybrid versione 1.8.4 e successive. ⁽⁸⁾ Supporto disponibile con Apigee hybrid versione 1.7.6 e successive. ⁽⁹⁾ Non supportato con Apigee hybrid versione 1.8.5 e successive. ⁽¹⁰⁾ Cloud Service Mesh viene installato automaticamente con Apigee hybrid 1.9 e versioni successive. ⁽¹¹⁾ Supporto disponibile con Apigee hybrid versione 1.9.2 e successive. ⁽¹²⁾ I numeri di versione di GKE su AWS ora riflettono le versioni di Kubernetes. Consulta Versione di GKE Enterprise e assistenza per l'upgrade per i dettagli della versione e le patch consigliate. ⁽¹³⁾ Vault non è certificato su Google Distributed Cloud per VMware. ⁽¹⁴⁾ Assistenza disponibile con Apigee hybrid versione 1.10.5 e successive. ⁽¹⁵⁾ Supporto disponibile con Apigee hybrid versione 1.11.2 e successive. ⁽¹⁶⁾ Supporto disponibile con Apigee hybrid versione 1.12.1 e successive.

Informazioni sui cluster collegati

Per Apigee hybrid versioni 1.7.x e precedenti, devi utilizzare cluster GKE allegati se vuoi eseguire Apigee hybrid in un contesto multicloud su Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS) o un altro provider di servizi Kubernetes di terze parti supportato. Il collegamento del cluster consente a Google di misurare l'utilizzo di Cloud Service Mesh.

Per Apigee Hybrid versione 1.8.x, i cluster GKE collegati sono necessari se utilizzi Cloud Service Mesh per il gateway in entrata. Se utilizzi il gateway Ingress Apigee, i cluster collegati sono facoltativi.

Installa il runtime di hybrid 1.12.4

Preparati all'upgrade dei grafici Helm

Estrai i grafici Helm di Apigee.

I grafici di Apigee hybrid sono ospitati in Google Artifact Registry:

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

Utilizzando il comando pull, copia tutti i grafici Helm di Apigee Hybrid 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.4
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

Esegui l'upgrade di cert-manager, se necessario.
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 le CRD Apigee aggiornate:

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

Utilizza la funzionalità dry run kubectl eseguendo questo comando:

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

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

L'output dovrebbe essere 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 i pod di runtime vengono pianificati sui nodi con l'etichetta cloud.google.com/gke-nodepool=apigee-runtime. Puoi personalizzare le etichette del pool di nodi nel file overrides.yaml.

Per saperne di più, consulta Configurazione dei pool di nodi dedicati.

Installa i grafici Helm di Apigee hybrid

Nota: prima di eseguire uno qualsiasi dei comandi di upgrade/installazione di Helm, utilizza la funzionalità di prova di Helm aggiungendo --dry-run alla fine del comando. Consulta helm -h per elencare comandi, opzioni e utilizzo supportati.

In caso contrario, vai alla directory APIGEE_HELM_CHARTS_HOME. Esegui i seguenti comandi da questa directory.

Esegui l'upgrade dell'operatore/controller Apigee:

Nota:questo passaggio richiede autorizzazioni del cluster elevate. Esegui helm -h o helm upgrade -h per maggiori 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 di cui è stata eseguita la migrazione da apigeectl a Helm, 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.4   1.12.4

Verifica che sia attivo e funzionante controllando la sua 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 di cui è stata eseguita la migrazione da apigeectl a Helm, 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 di cui è stata eseguita la migrazione da apigeectl a Helm, 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 di cui è stata eseguita la migrazione da apigeectl a Helm, 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 di Apigee Ingress Manager:

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 di cui è stata eseguita la migrazione da apigeectl a Helm, utilizza:

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

Verifica che sia attivo e funzionante controllando la sua 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 di cui è stata eseguita la migrazione da apigeectl a Helm, 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 il grafico apigee-env. Nella versione ibrida 1.10, di solito è apigee-env-ENV_NAME. In Hybrid v1.11 e versioni successive, in genere è ENV_NAME.
- ENV_NAME è il nome dell'ambiente che stai eseguendo l'upgrade.
- OVERRIDES_FILE è il nuovo file di override per la versione 1.12.4
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 di cui è stata eseguita la migrazione da apigeectl a Helm, 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 in esecuzione controllando lo stato dell'ambiente corrispondente:
```
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 il gruppo di ambienti con --set envgroup=ENV_GROUP_NAME. Ripeti i seguenti comandi per ogni gruppo di ambiente menzionato nel file overrides.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 il grafico apigee-virtualhost. Nella versione ibrida 1.10, di solito è 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 di cui è stata eseguita la migrazione da apigeectl a Helm, 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_RELEASE_NAME deve essere univoco all'interno dello spazio dei nomi apigee.
  Ad esempio, se hai un ambiente denominato prod e un gruppo di ambienti denominato prod, imposta il valore di ENV_GROUP_RELEASE_NAME su un valore univoco, ad esempio prod-envgroup.
2. Controlla lo stato di ApigeeRoute (AR).
  L'installazione di virtualhosts crea ApigeeRouteConfig (ARC) che crea internamente ApigeeRoute (AR) una volta che il watcher Apigee estrae i dettagli relativi al gruppo di ambienti dal control plane. Pertanto, verifica che lo stato del rispettivo AR sia 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
```

Convalida dei criteri dopo l'upgrade alla versione 1.12.4

Utilizza questa procedura per convalidare il comportamento del criterio JavaCallout dopo l'upgrade dalla versione 1.12.3 o precedente alla versione 1.12.4 o successiva.

Verifica se i file JAR Java richiedono autorizzazioni non necessarie.
Dopo il deployment della policy, controlla i log di runtime per verificare la presenza del seguente messaggio di log: "Failed to load and initialize class ...". Se visualizzi questo messaggio, significa che il file JAR di cui è stato eseguito il deployment ha richiesto autorizzazioni non necessarie. Per risolvere il problema, analizza il codice Java e aggiorna il file JAR.
Esamina e aggiorna il codice Java.
Esamina il codice Java (incluse le dipendenze) per identificare la causa di operazioni potenzialmente non consentite. Se lo trovi, modifica il codice sorgente come richiesto.
Testa i criteri con il controllo di sicurezza abilitato.
In un ambiente non di produzione, attiva il flag di controllo di sicurezza e esegui nuovamente il deployment dei criteri con un file JAR aggiornato. Per impostare il flag:
- Nel file apigee-env/values.yaml, imposta conf_security-secure.constructor.only su true in runtime:cwcAppend:. Ad esempio:
```
# Apigee Runtime
runtime:
  cwcAppend:
    conf_security-secure.constructor.only: true
```
- Aggiorna il grafico apigee-env per l'ambiente per applicare la modifica. Ad esempio:
```
helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set env=ENV_NAME \
  -f OVERRIDES_FILE
```
Se il messaggio di log "Failed to load and initialize class ..." è ancora presente, continua a modificare e testare il file JAR finché il messaggio di log non viene più visualizzato.
Attiva il controllo di sicurezza nell'ambiente di produzione.
Dopo aver testato e verificato a fondo il file JAR nell'ambiente non di produzione, attiva il controllo di sicurezza nell'ambiente di produzione impostando il flag conf_security-secure.constructor.only su true e aggiornando il grafico apigee-env per l'ambiente di produzione in modo da applicare la modifica.

Eseguire il rollback a una versione precedente

Questa sezione è suddivisa in sezioni a seconda dello stato del componente apigee-datastore dopo l'upgrade alla versione ibrida 1.12 di Apigee. Esistono procedure per il rollback di una singola regione o di più regioni con il componente apigee-datastore in buono stato e procedure per il ripristino da un backup quando apigee-datastore è in cattivo stato.

Rollback e ripristino di una singola regione

Eseguire il rollback quando `apigee-datastore` è in buono stato

Questa procedura spiega come eseguire il rollback di ogni componente di Apigee hybrid dalla versione 1.12 alla versione 1.11 tranne apigee-datastore. Il componente v1.12 apigee-datastore è compatibile con le versioni precedenti dei componenti di hybrid 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 di una singola regione alla versione 1.11:

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

Convalida il rilascio 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 i seguenti comandi:

Crea la seguente variabile di ambiente:
- PREVIOUS_HELM_CHARTS_HOME: la directory in cui sono installati i grafici Helm di Apigee hybrid precedenti. Questa è la versione a cui stai eseguendo il rollback.
Esegui il rollback degli host virtuali. Ripeti il seguente comando per ogni gruppo di ambienti menzionato nel file di sostituzioni.
```
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 il grafico apigee-virtualhost. Nella versione ibrida 1.10, di solito è apigee-virtualhost-ENV_GROUP_NAME. In Hybrid v1.11 e versioni successive, di solito è ENV_GROUP_NAME.
Esegui il rollback degli ambienti. Ripeti il seguente comando per ogni ambiente menzionato nel file di sostituzioni.
```
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 il grafico apigee-env. Nella versione ibrida 1.10, di solito è apigee-env-ENV_NAME. In Hybrid v1.11 e versioni successive, di solito è ENV_NAME.

Verifica che sia attivo e in esecuzione controllando lo stato dell'ambiente corrispondente:
```
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 controllando la sua 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 di Apigee Telemetry:

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

Verifica che sia attivo e funzionante controllando la sua 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 di Apigee hybrid:

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 il rilascio di tutti i componenti. Tutti i componenti devono essere nella versione precedente, tranne il 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 buone condizioni

Se l'upgrade del componente apigee-datastore non è andato a buon fine, non puoi eseguire il rollback di apigee-datastore dalla versione 1.12 alla versione 1.11. Devi invece eseguire il ripristino da un backup di un'installazione della versione 1.11. Utilizza la seguente sequenza per ripristinare la versione precedente.

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

Rollback e ripristino multiregionale

Eseguire il rollback quando `apigee-datastore` è in buono stato

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

Assicurati che tutti i nodi Cassandra in tutte le regioni siano nello stato UN (Up / Normal). Se un nodo Cassandra si trova in uno stato diverso, risolvi il problema prima di iniziare la procedura di 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 il comando 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 riportate in Rimuovi i nodi DOWN dal cluster Cassandra.

Vai alla directory in cui sono installati i grafici Helm di Apigee hybrid precedenti
Cambia il contesto nella regione in 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

Utilizza il comando helm per assicurarti che tutti i rilasci siano stati eseguiti l'upgrade alla versione 1.12 di Hybrid:

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 i seguenti comandi:

Crea la seguente variabile di ambiente:
- PREVIOUS_HELM_CHARTS_HOME: la directory in cui sono installati i grafici Helm di Apigee hybrid precedenti. Questa è la versione a cui stai eseguendo il rollback.
Esegui il rollback degli host virtuali. Ripeti il seguente comando per ogni gruppo di ambienti menzionato nel file di sostituzioni.
```
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 il grafico apigee-virtualhost. Nella versione ibrida 1.10, di solito è apigee-virtualhost-ENV_GROUP_NAME. In Hybrid v1.11 e versioni successive, di solito è ENV_GROUP_NAME.
Esegui il rollback degli ambienti. Ripeti il seguente comando per ogni ambiente menzionato nel file di sostituzioni.
```
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 il grafico apigee-env. Nella versione ibrida 1.10, di solito è apigee-env-ENV_NAME. In Hybrid v1.11 e versioni successive, di solito è ENV_NAME.

Verifica che ogni ambiente sia attivo e funzionante controllando lo stato dell'ambiente corrispondente:
```
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 controllando la sua 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 di Apigee Telemetry:

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

Verifica che sia attivo e funzionante controllando la sua 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 di Apigee hybrid:

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

Convalida il rilascio 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.

Recupero di un'installazione multiregionale a una versione precedente

Recupera la regione in cui l'upgrade non è riuscito in un upgrade multiregionale rimuovendo i riferimenti a questa regione dalle installazioni multiregionali. Questo metodo è possibile solo se è presente almeno una regione live su Hybrid 1.11. Il datastore v1.12 è compatibile con i componenti v1.11.

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

Reindirizza il traffico API dalle regioni interessate alla regione funzionante. Pianifica la capacità di conseguenza per supportare il traffico dirottato dalle regioni non riuscite.
Ritira la regione interessata. Per ogni regione interessata, segui i passaggi descritti in Dismissione di una regione ibrida. Attendi il completamento del ritiro prima di procedere con il passaggio successivo.
Pulisci la regione non riuscita seguendo le istruzioni riportate in Recuperare una regione da un upgrade non riuscito.
Recupera la regione interessata. Per il ripristino, crea una nuova regione, come descritto in Deployment in più regioni 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. Devi invece eseguire il ripristino da un backup di un'installazione della versione 1.11. Utilizza la seguente sequenza per ripristinare la versione precedente.

Se non hai un'installazione attiva della versione ibrida di Apigee 1.11 (ad esempio in un'altra regione), crea una nuova installazione della versione 1.11 utilizzando i file di grafici e override di cui hai eseguito il backup. Consulta le istruzioni di installazione di Apigee hybrid versione 1.11.
Ripristina la regione v1.11 (o la nuova installazione) dal backup seguendo le istruzioni riportate in:
- Backup dell'interfaccia Container Storage Interface (CSI):backup e ripristino CSI di Cassandra.
- Backup non CSI: Ripristino in più regioni.
Verifica il traffico verso l'installazione ripristinata
Per le installazioni multiregionali, ricompila 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 riportate in Disinstallazione del runtime di hybrid.

APPENDICE: Recuperare una regione da un upgrade non riuscito

Rimuovi un data center se l'upgrade da 1.11 a 1.12 non va a buon fine.

Convalida lo stato del cluster Cassandra da una regione attiva:

Passa al contesto kubectl della 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 l'accesso a 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 di visualizzare solo gli indirizzi IP dei pod Cassandra della regione live e che tutti abbiano la 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]

Pulisci la replica dello spazio delle chiavi Cassandra:

Recupera il job user-setup ed eliminalo. Verrà creato immediatamente un nuovo job user-setup.

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 l'avvio del nuovo job:

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 contenitore client seguendo le istruzioni riportate in Crea il contenitore client.

Ottieni tutti gli spazi chiave. Esegui l'accesso al 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

Ottieni gli spazi chiave:

select * from system_schema.keyspaces;

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

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 generare errori e la convalida non va a buon fine, utilizza i seguenti comandi per correggere la replica negli spazi chiave.

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

Ottieni gli spazi chiave:

select * from system_schema.keyspaces;

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

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 chiave vengano replicati nella regione corretta 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)

A questo punto, hai rimosso completamente tutti i riferimenti al controller di dominio non funzionante dal cluster Cassandra.

APPENDICE: Rimuovi i nodi DOWN dal cluster Cassandra

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

Esegui l'accesso a 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). Accedi al pod Cassandra in una regione in cui il pod Cassandra non è in grado di avviarsi.

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 down (DN). Dall'esempio precedente, rimuoveremo il riferimento all'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. Il nuovo pod Cassandra dovrebbe essere visualizzato e unirsi al cluster.
```
kubectl delete pod -n POD_NAME
```

Verifica che il nuovo pod Cassandra sia stato aggiunto 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 di blocco dopo il rollback

Utilizza questa procedura quando hai eseguito il rollback di apigee-datastore alla versione ibrida 1.11 dopo l'upgrade e si trova in uno stato bloccato.

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

Convalida utilizzando il comando Helm che il rollback del datastore è stato eseguito:

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

Recupera lo stato dei pod di 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 nello 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 è nello stato DN, ovvero il nodo 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

Esegui 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 Hybrid 1.12, che verranno visualizzati 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.

Convalida di nuovo tutti i pod 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

Convalida lo stato 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 e dovrebbe essere nello stato running.

Eseguire l'upgrade di Apigee hybrid alla versione 1.12 Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Modifiche rispetto ad Apigee hybrid v1.11

Considerazioni da tenere presenti prima di iniziare un upgrade alla versione 1.12

Considerazioni su Cassandra

Considerazioni preliminari all'upgrade di un'installazione a una sola regione

Considerazioni preliminari all'upgrade di un'installazione multiregionale

Prerequisiti

Limitazioni

Panoramica dell'upgrade alla versione 1.12.4

Prepararsi all'upgrade alla versione 1.12

Backup di Cassandra

Esegui il backup delle directory di installazione ibrida

Linux

Mac OS

Windows

Prod

Non di produzione

Esegui l'upgrade della versione di Kubernetes

Fai clic per espandere l'elenco delle piattaforme supportate

Componenti

Informazioni sui cluster collegati

Installa il runtime di hybrid 1.12.4

Preparati all'upgrade dei grafici Helm

Installa i grafici Helm di Apigee hybrid

Convalida dei criteri dopo l'upgrade alla versione 1.12.4

Eseguire il rollback a una versione precedente

Rollback e ripristino di una singola regione

Eseguire il rollback quando apigee-datastore è in buono stato

Ripristino quando apigee-datastore non è in buone condizioni

Rollback e ripristino multiregionale

Eseguire il rollback quando apigee-datastore è in buono stato

Recupero di un'installazione multiregionale a una versione precedente

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

APPENDICE: Recuperare una regione da un upgrade non riuscito

APPENDICE: Rimuovi i nodi DOWN dal cluster Cassandra

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

Eseguire l'upgrade di Apigee hybrid alla versione 1.12

Eseguire il rollback quando `apigee-datastore` è in buono stato

Ripristino quando `apigee-datastore` non è in buone condizioni

Eseguire il rollback quando `apigee-datastore` è in buono stato

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

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