Questa pagina è stata tradotta dall'API Cloud Translation.

Upgrade di Apigee hybrid alla versione 1.16

Questa procedura riguarda l'upgrade da Apigee hybrid versione 1.15.x ad Apigee hybrid versione 1.16.0.

Modifiche rispetto ad Apigee hybrid v1.15

Tieni presente le seguenti modifiche:

Profili Seccomp: A partire dalla versione 1.16, Apigee hybrid ora offre la possibilità di applicare profili Seccomp ai componenti di runtime, migliorando significativamente la postura di sicurezza della tua implementazione. Questa funzionalità consente agli amministratori e ai team di sicurezza di Apigee di limitare le chiamate di sistema che un processo in container può effettuare al kernel dell'host. Se limiti un container alle sole chiamate di sistema necessarie, puoi:
- Migliora la sicurezza: riduci il rischio di attacchi container breakout e di escalation dei privilegi.
- Applica il principio del privilegio minimo: assicurati che i componenti abbiano accesso solo alle chiamate di sistema esatte necessarie per il loro funzionamento.
- Meet Compliance: fornisci un controllo fondamentale per soddisfare i rigorosi requisiti di conformità alla sicurezza.
Per saperne di più, consulta Configurare i profili Seccomp per la sicurezza dei pod.
Rimozione di UDCA in Apigee hybrid: In Apigee hybrid versione 1.16, il componente Unified Data Collection Agent (UDCA) è stato rimosso. Le responsabilità di invio dei dati di analisi, tracciamento e stato del deployment al control plane Apigee vengono ora gestite utilizzando una pipeline di dati basata su Google Cloud Pub/Sub. L'utilizzo della pipeline di dati basata su Pub/Sub è il meccanismo di raccolta dati predefinito a partire da Apigee Hybrid versione 1.14.0.
Service account apigee-guardrails: Nella versione 1.16.0, Apigee Hybrid introduce un account di servizio Google IAM apigee-guardrails. Viene utilizzato dal grafico apigee-operator durante l'installazione per verificare che tutte le API necessarie siano abilitate nel tuo progetto.
Vedi:
Supporto delle versioni 1.18 e 1.19 di cert-manager: Apigee hybrid v1.16 supporta le versioni 1.18 e 1.19 di cert-manager. Nella release 1.18 di cert-manager, è stata apportata una modifica al valore predefinito di Certificate.Spec.PrivateKey.rotationPolicy che può influire sul traffico. Se esegui l'upgrade da una versione precedente di Apigee Hybrid e l'upgrade alla versione 1.18 o successive di cert-manager, segui la procedura Esegui l'upgrade di cert-manager in questa guida.

Nota:questo non influisce sulle nuove installazioni di Apigee hybrid v1.6.

Per ulteriori informazioni sulle funzionalità della versione 1.16 di Hybrid, consulta le note di rilascio di Apigee hybrid v1.16.0.

Prerequisiti

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

Se la tua installazione ibrida esegue una versione precedente alla v1.15, devi eseguire l'upgrade alla versione 1.15 prima di eseguire l'upgrade alla v1.16. Consulta la sezione Eseguire l'upgrade di Apigee Hybrid alla versione 1.15.
Helm versione v3.14.2+.
kubectl: una versione supportata di kubectl adatta alla versione della tua piattaforma Kubernetes. Consulta Piattaforme e versioni supportate: kubectl.
cert-manager: una versione supportata di cert-manager. Consulta Piattaforme e versioni supportate: cert-manager. Se necessario, esegui l'upgrade di cert-manager nella sezione Preparati all'upgrade alla versione 1.16 di seguito.

Prima di eseguire l'upgrade alla versione 1.16.0: limitazioni e note importanti

Apigee hybrid 1.16.0 introduce un nuovo limite avanzato per ambiente per i proxy che ti consente di eseguire il deployment di più proxy e flussi condivisi in un unico ambiente. Consulta la sezione Limiti: proxy API per comprendere i limiti al numero di proxy e flussi condivisi che puoi eseguire il deployment per ambiente. Questa funzionalità è disponibile solo per le organizzazioni ibride appena create e non può essere applicata alle organizzazioni di cui è stato eseguito l'upgrade. Per utilizzare questa funzionalità, esegui una nuova installazione di hybrid 1.16.0 e crea una nuova organizzazione.

Questa funzionalità è disponibile esclusivamente nell'ambito del piano di abbonamento 2024 ed è soggetta ai diritti concessi nell'ambito di questo abbonamento. Consulta Limiti proxy avanzati per ambiente per saperne di più su questa funzionalità.
L'upgrade alla versione 1.16 di Apigee hybrid potrebbe richiedere tempi di inattività.

Quando esegui l'upgrade del controller Apigee alla versione 1.16.0, tutti i deployment Apigee vengono riavviati 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 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 probabilità di impatto sulla produzione. Non è previsto un limite di tempo per l'upgrade di tutti i cluster rimanenti dopo l'upgrade del primo. Tuttavia, finché non viene eseguito l'upgrade di tutti i cluster rimanenti, il backup e il ripristino di Cassandra non possono funzionare con versioni miste. Ad esempio, un backup di Hybrid 1.15 non può essere utilizzato per ripristinare un'istanza Hybrid 1.16.
Le modifiche al piano di gestione non devono essere sospese completamente durante un upgrade. Eventuali sospensioni temporanee richieste per le modifiche al piano di gestione sono indicate nelle istruzioni di upgrade riportate di seguito.

Panoramica dell'upgrade alla versione 1.16.0

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

Preparati all'upgrade.
Installa la versione 1.16.0 del runtime di hybrid.

Prepararsi all'upgrade alla versione 1.16

Esegui il backup dell'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.15. 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.15-backup.tar.gz $APIGEE_HELM_CHARTS_HOME
```
Esegui il backup del database Cassandra seguendo le istruzioni riportate in Backup e ripristino di Cassandra.
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.15 sia da hybrid 1.16. Se hai bisogno di aiuto, consulta la documentazione della tua piattaforma.

Fai clic per espandere l'elenco delle piattaforme supportate

Versioni supportate

	1,14	1,15	1,16
GKE su Google Cloud	1.28.x 1.29.x 1.30.x 1.31.x	1.29.x 1.30.x 1.31.x 1.32.x 1.33.x	1.31.x 1.32.x 1.33.x
GKE su AWS	1.28.x 1.29.x^{(≥ 1.12.1)(8)} 1.30.x 1.31.x	1.29.x^{(≥ 1.12.1)(8)} 1.30.x 1.31.x 1.32.x	1.31.x 1.32.x 1.33.x
GKE su Azure	1.28.x 1.29.x^{(≥ 1.12.1)(8)} 1.30.x 1.31.x	1.29.x^{(≥ 1.12.1)(8)} 1.30.x 1.31.x 1.32.x	1.31.x 1.32.x 1.33.x
Google Distributed Cloud (solo software) su VMware ⁽³⁾	1.28.x 1.29.x 1.30.x 1.31.x	1.29.x 1.30.x 1.31.x 1.32.x 1.33.x	1.31.x 1.32.x 1.33.x
Google Distributed Cloud (solo software) su bare metal	1.28.x 1.29.x 1.30.x 1.31.x	1.29.x 1.30.x 1.31.x 1.32.x 1.33.x	1.31.x 1.32.x 1.33.x
EKS	1.28.x 1.29.x 1.30.x 1.31.x 1.32.x	1.29.x 1.30.x 1.31.x 1.32.x 1.33.x	1.31.x 1.32.x 1.33.x
AKS	1.28.x 1.29.x 1.30.x 1.31.x	1.29.x 1.30.x 1.31.x 1.32.x 1.33.x	1.31.x 1.32.x 1.33.x
OpenShift⁽⁷⁾	4.13 4.14 4.15 4.16 4.17	4.16 4.17 4.18	4.18 4.19 4.20
Rancher Kubernetes Engine (RKE)	v1.27.x 1.28.x 1.29.x 1.30.x 1.31.x	v1.28.x 1.29.x 1.30.x 1.31.x 1.32.x 1.33.x	1.31.x 1.32.x 1.33.x
VMware Tanzu	v1.26.x	v1.26.x	v1.26.x
Componenti	1,14	1,15	1,16
Cloud Service Mesh	1.22.x⁽²⁾	1.22.x⁽²⁾	1.22.x⁽²⁾
JDK	JDK 11	JDK 11	JDK 11
cert-manager	1.15.x⁽⁸⁾ 1.16.x⁽⁸⁾ 1.17.x⁽⁸⁾	1.16.x⁽⁸⁾ 1.17.x⁽⁸⁾	1.16.x⁽⁸⁾ 1.17.x⁽⁸⁾ 1.18.x⁽⁹⁾ 1.19.x⁽⁹⁾
Cassandra	4.0	4.0	4.0
Kubernetes	1.28.x 1.29.x 1.30.x 1.31.x 1.32.x	1.29.x 1.30.x 1.31.x 1.32.x 1.33.x	1.30.x 1.31.x 1.32.x 1.33.x
kubectl	1.28.x 1.29.x 1.30.x 1.31.x 1.32.x	1.29.x 1.30.x 1.31.x 1.32.x 1.33.x	1.30.x 1.31.x 1.32.x 1.33.x
Helm	3.14.2 fino a 3.x.x	3.14.2 fino a 3.x.x	3.17.0 fino alla versione 3.x.x
Driver CSI Secret Store	1.4.6+	1.4.6+	1.4.6+
Vault	1.17.2	1.17.2	1.17.2
⁽¹⁾ Sono state raggiunte le date EOL ufficiali per le versioni 1.13 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. ⁽²⁾ Cloud Service Mesh viene installato automaticamente con Apigee Hybrid 1.9 e versioni successive. ⁽³⁾ 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. ⁽⁷⁾ Apigee hybrid è testato e certificato su OpenShift utilizzando la versione di Kubernetes inclusa in ogni versione specifica di OCP. ⁽⁸⁾ Alcune versioni di cert-manager presentano un problema per cui il server TLS webhook potrebbe non riuscire a rinnovare automaticamente il certificato CA. Per evitare questo problema, Apigee consiglia di utilizzare: Hybrid v1.13: utilizza cert-manager versione 1.15.5 o successive. Hybrid v1.14: utilizza le versioni di cert-manager 1.15.5+ o 1.16.3+. Ibrido v1.15: utilizza cert-manager versione 1.16.3+ o 1.17.2+. Hybrid v1.16: utilizza le versioni di cert-manager 1.16.3+, 1.17.2+, 1.18.0+ o 1.19.0+. Consulta il problema noto 465834046 per le release 1.18 e 1.19 di cert-manager. ⁽⁹⁾ La release 1.18 di cert-manager introduce una modifica alle norme di rotazione predefinite delle chiavi private che potrebbe causare interruzioni del traffico. Per una soluzione alternativa, consulta il problema noto 465834046.

Versioni non supportate

	1.6 ⁽¹⁾	1.7 ⁽¹⁾	1,8 ⁽¹⁾	1.9 ⁽¹⁾	1.10 ⁽¹⁾	1,11 ⁽¹⁾	1,12 ⁽¹⁾	1.13 ⁽¹⁾
GKE su Google Cloud	1.19.x 1.20.x 1.21.x	1.20.x 1.21.x 1.22.x ^{(≥ 1.7.2) 1.23.x ^{(≥ 1.7.2)}}	1.21.x ^{(≤ 1.8.3)} 1.22.x ^{(≤ 1.8.3)} 1.23.x ^{(≤ 1.8.4)} 1.24.x ^{(≥ 1.8.4)} 1.25.x ^{(≥ 1.8.4)}	1.23.x 1.24.x 1.25.x 1.26.x ^{(≥ 1.9.2)}	1.24.x 1.25.x 1.26.x 1.27.x^{(≥ 1.10.5)(6)} 1.28.x^{(≥ 1.10.5)(6)}	1.25.x 1.26.x 1.27.x 1.28.x^{(≥ 1.11.2)(7)} 1.29.x^{(≥ 1.11.2)(7)}	1.26.x 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)(8)}	1.27.x 1.28.x 1.29.x 1.30.x
GKE su AWS	1.7.x 1.8.x 1.9.3+ 1.10.x	1.9.x 1.10.x 1.12.x ^{(≥ 1.7.2)}	1.10.x 1.11.x 1.12.x (K8s v1.23.x) 1.13.x (K8s v1.24.x) 1.14.x (K8s v1.25.x)	1.12.x 1.13.x (K8s v1.24.x) 1.14.x (K8s v1.25.x)	1.13.x (K8s v1.24.x) 1.14.x (K8s v1.25.x) 1.26.x⁽³⁾ 1.27.x^{(≥ 1.10.5)(6)} 1.28.x^{(≥ 1.10.5)(6)}	1.14.x (K8s v1.25.x) 1.26.x⁽³⁾ 1.27.x 1.28.x^{(≥ 1.11.2)(7)} 1.29.x^{(≥ 1.11.2)(7)}	1.26.x⁽³⁾ 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)(8)}	1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)(8)} 1.30.x
GKE su Azure	1.8.x	1.9.x 1.10.x 1.12.x ^{(≥ 1.7.2)}	1.10.x 1.11.x 1.12.x 1.13.x 1.14.x	1.12.x 1.13.x 1.14.x	1.13.x 1.14.x 1.26.x⁽³⁾ 1.27.x^{(≥ 1.10.5)(6)} 1.28.x^{(≥ 1.10.5)(6)}	1.14.x 1.26.x⁽³⁾ 1.27.x 1.28.x^{(≥ 1.11.2)(7)} 1.29.x^{(≥ 1.11.2)(7)}	1.26.x⁽³⁾ 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)(8)}	1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)(8)} 1.30.x
Google Distributed Cloud (solo software) su VMware ⁽³⁾	1.7.x 1.8.x 1.9.3+ 1.10.x	1.9.x 1.10.x 1.11.x ⁽³⁾ ^{(≥ 1.7.2) 1.12.x ^{(≥ 1.7.2)}}	1.10.x 1.11.x 1.12.x 1.13.x 1.14.x 1.15.x (K8s v1.26.x)	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)(6)} 1.28.x^{(≥ 1.10.5)(6)}	1.14.x 1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x^{(≥ 1.11.2)(7)} 1.29.x^{(≥ 1.11.2)(7)}	1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x 1.29.x^{(≥ 1.12.1)(8)}	1.16.x (K8s v1.27.x) 1.28.x 1.29.x 1.30.x
Google Distributed Cloud (solo software) su bare metal	1.7.x 1.8.2+ 1.9.3+ 1.10.x	1.9.x 1.10.x 1.11.x ^{(≥ 1.7.2) 1.12.x ^{(≥ 1.7.2)}}	1.10.x 1.11.x 1.12.x 1.13.x 1.14.x 1.15.x	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)(6)} 1.28.x^{(≥ 1.10.5)(6)}	1.14.x 1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x^{(≥ 1.11.2)(7)} 1.29.x^{(≥ 1.11.2)(7)}	1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x 1.29.x^{(≥ 1.12.1)(8)}	1.16.x (K8s v1.27.x) 1.28.x 1.29.x 1.30.x
EKS	1.19.x 1.20.x 1.21.x	1.21.x 1.22.x ^{(≥ 1.7.2) 1.23.x ^{(≥ 1.7.2)}}	1.22.x ^{(≤ 1.8.3)} 1.23.x ^{(≤ 1.8.4)} 1.24.x ^{(≥ 1.8.4)} 1.25.x ^{(≥ 1.8.4)}	1.23.x 1.24.x 1.25.x 1.26.x	1.24.x 1.25.x 1.26.x 1.27.x^{(≥ 1.10.5)(6)} 1.28.x^{(≥ 1.10.5)(6)}	1.25.x 1.26.x 1.27.x 1.28.x^{(≥ 1.11.2)(7)} 1.29.x^{(≥ 1.11.2)(7)}	1.26.x 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)(8)}	1.27.x 1.28.x 1.29.x 1.30.x
AKS	1.19.x 1.20.x 1.21.x	1.21.x 1.22.x ^{(≥ 1.7.2) 1.23.x ^{(≥ 1.7.2)}}	1.22.x ^{(≤ 1.8.3)} 1.23.x ^{(≤ 1.8.4)} 1.24.x ^{(≥ 1.8.4)} 1.25.x ^{(≥ 1.8.4)}	1.23.x 1.24.x 1.25.x 1.26.x^{(≥ 1.9.2)}	1.24.x 1.25.x 1.26.x 1.27.x^{(≥ 1.10.5)(6)} 1.28.x^{(≥ 1.10.5)(6)}	1.25.x 1.26.x 1.27.x 1.28.x^{(≥ 1.11.2)(7)} 1.29.x^{(≥ 1.11.2)(7)}	1.26.x 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)(8)}	1.27.x 1.28.x 1.29.x 1.30.x
OpenShift⁽⁷⁾	4.6 4.7 4.8	4.7 4.8	4.8 4.9 4.10	4.10 4.11	4.11 4.12 4.14^{(≥ 1.10.5)(6)} 4.15^{(≥ 1.10.5)(6)}	4.12 4.13 4.14 4.15^{(≥ 1.11.2)(7)} 4.16^{(≥ 1.11.2)(7)}	4.12 4.13 4.14 4.15 4.16^{(≥ 1.12.1)(8)}	4.12 4.13 4.14 4.15 4.16
Rancher Kubernetes Engine (RKE)	N/D	N/D	N/D	1.3.8	v1.26.2+rke2r1 1.27.x^{(≥ 1.10.5)(6)} 1.28.x^{(≥ 1.10.5)(6)}	v1.26.2+rke2r1 v1.27.x 1.28.x^{(≥ 1.11.2)(7)} 1.29.x^{(≥ 1.11.2)(7)}	v1.26.2+rke2r1 v1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)(8)}	v1.26.2+rke2r1 v1.27.x 1.28.x 1.29.x 1.30.x
VMware Tanzu	N/D	N/D	N/D	N/D	N/D	N/D	v1.26.x	v1.26.x
Componenti	1.6 ⁽¹⁾	1.7 ⁽¹⁾	1,8 ⁽¹⁾	1.9 ⁽¹⁾	1.10 ⁽¹⁾	1,11 ⁽¹⁾	1,12 ⁽¹⁾	1.13 ⁽¹⁾
Cloud Service Mesh	1.9.x 1.10.x 1.12.x 1.13.x	1.10.x 1.11.x 1.12.x 1.13.x ^{(≥ 1.7.2) 1.14.x 1.15.x ^{(≥ 1.7.6)}}	1.11.x 1.12.x 1.13.x 1.14.x 1.15.x	1.17.x⁽²⁾	1.17.x⁽²⁾	1.17.x^{(v1.11.0 - v1.11.1)}⁽²⁾ 1.18.x^{(≥ 1.11.2)(7)}⁽²⁾	1.18.x⁽²⁾	1.19.x⁽²⁾
JDK	JDK 11	JDK 11	JDK 11	JDK 11	JDK 11	JDK 11	JDK 11	JDK 11
cert-manager	1.5.4	1.7.x	1.7.x 1.8.x 1.9.x 1.10.x 1.11.x	1.10.x 1.11.x	1.10.x 1.11.x 1.12.x	1.11.x 1.12.x 1.13.x	1.11.x 1.12.x 1.13.x	1.15.x⁽⁸⁾ 1.16.x⁽⁸⁾ 1.17.x⁽⁸⁾
Cassandra	3.11	3.11	3.11	3.11	3.11	3.11	4.0	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 1.29.x	1.27.x 1.28.x 1.29.x 1.30.x
kubectl					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 1.29.x	1.27.x 1.28.x 1.29.x 1.30.x
Helm					3.10+	3.10+	3.14.2 fino a 3.x.x	3.14.2 fino a 3.x.x
Driver CSI Secret Store						1.3.4+	1.4.1+	1.4.6+
Vault						1.13.x	1.15.2	1.15.2
⁽¹⁾ Sono state raggiunte le date EOL ufficiali per le versioni 1.13 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. ⁽²⁾ Cloud Service Mesh viene installato automaticamente con Apigee Hybrid 1.9 e versioni successive. ⁽³⁾ 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. ⁽⁷⁾ Apigee hybrid è testato e certificato su OpenShift utilizzando la versione di Kubernetes inclusa in ogni versione specifica di OCP. ⁽⁸⁾ Alcune versioni di cert-manager presentano un problema per cui il server TLS webhook potrebbe non riuscire a rinnovare automaticamente il certificato CA. Per evitare questo problema, Apigee consiglia di utilizzare: Hybrid v1.13: utilizza cert-manager versione 1.15.5 o successive. Hybrid v1.14: utilizza le versioni di cert-manager 1.15.5+ o 1.16.3+. Ibrido v1.15: utilizza cert-manager versione 1.16.3+ o 1.17.2+. Hybrid v1.16: utilizza le versioni di cert-manager 1.16.3+, 1.17.2+, 1.18.0+ o 1.19.0+. Consulta il problema noto 465834046 per le release 1.18 e 1.19 di cert-manager. ⁽⁹⁾ La release 1.18 di cert-manager introduce una modifica alle norme di rotazione predefinite delle chiavi private che potrebbe causare interruzioni del traffico. Per una soluzione alternativa, consulta il problema noto 465834046.

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

Modifica `kustomization.yaml` per uno spazio dei nomi Apigee personalizzato

Se il tuo spazio dei nomi Apigee non è apigee, modifica il file apigee-operator/etc/crds/default/kustomization.yaml e sostituisci il valore namespace con il tuo spazio dei nomi Apigee.

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

namespace: APIGEE_NAMESPACE

Se utilizzi apigee come spazio dei nomi, non devi modificare il file.

Installa le CRD Apigee aggiornate:

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

Utilizza la funzionalità dry run 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

L'output dovrebbe essere simile al seguente:

apigeedatastores.apigee.cloud.google.com                    2024-08-21T14:48:30Z
apigeedeployments.apigee.cloud.google.com                   2024-08-21T14:48:30Z
apigeeenvironments.apigee.cloud.google.com                  2024-08-21T14:48:31Z
apigeeissues.apigee.cloud.google.com                        2024-08-21T14:48:31Z
apigeeorganizations.apigee.cloud.google.com                 2024-08-21T14:48:32Z
apigeeredis.apigee.cloud.google.com                         2024-08-21T14:48:33Z
apigeerouteconfigs.apigee.cloud.google.com                  2024-08-21T14:48:33Z
apigeeroutes.apigee.cloud.google.com                        2024-08-21T14:48:33Z
apigeetelemetries.apigee.cloud.google.com                   2024-08-21T14:48:34Z
cassandradatareplications.apigee.cloud.google.com           2024-08-21T14: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 la sezione Configurazione dei pool di nodi dedicati.

Configurare il account di servizio `apigee-guardrails`

A partire dalla versione 1.16 di hybrid, il account di servizio apigee-guardrails è necessario per eseguire l'upgrade del grafico apigee-operator.

Nella procedura seguente, seleziona il tipo di autenticazione del account di servizio che stai utilizzando.

Verifica di poter eseguire create-service-account. Se hai appena scaricato i grafici, il file create-service-account potrebbe non essere in modalità eseguibile. Nella directory APIGEE_HELM_CHARTS_HOME esegui questo comando:
```
./apigee-operator/etc/tools/create-service-account --help
```
Se l'output indica permission denied, devi rendere eseguibile il file, ad esempio con chmod in Linux, macOS o UNIX o in Esplora risorse di Windows o con il comando icacls in Windows. Ad esempio:
```
chmod +x ./apigee-operator/etc/tools/create-service-account
```
Crea il account di servizio apigee-guardrails:
Secret Kubernetes
```
./apigee-operator/etc/tools/create-service-account \
  --env prod \
  --profile apigee-guardrails \
  --dir service-accounts
```
Questo comando crea il account di servizio apigee-guardrails e scarica la chiave nella directory service-accounts/.
File JSON
```
./apigee-operator/etc/tools/create-service-account \
  --env prod \
  --profile apigee-guardrails \
  --dir ./apigee-operator/
```
Questo comando crea il account di servizio apigee-guardrails e scarica la chiave nella directory del grafico apigee-operator/.
Vault
```
./apigee-operator/etc/tools/create-service-account \
  --env prod \
  --profile apigee-guardrails \
  --dir service-accounts
```
Questo comando crea il account di servizio apigee-guardrails e scarica la chiave nella directory service-accounts/.
WIF per GKE
```
./apigee-operator/etc/tools/create-service-account \
  --env prod \
  --profile apigee-guardrails \
  --dir service-accounts
```
Questo comando crea il account di servizio apigee-guardrails e scarica la chiave nella directory apigee-operator/etc/tools/service-accounts/. Non hai bisogno del file di chiave scaricato e puoi eliminarlo.
WIF su altre piattaforme
```
./apigee-operator/etc/tools/create-service-account \
  --env prod \
  --profile apigee-guardrails \
  --dir service-accounts
```
Questo comando crea il account di servizio apigee-guardrails e scarica la chiave nella directory service-accounts/.

Configura l'autenticazione per il account di servizio apigee-guardrails:

Secret Kubernetes

Crea il secret Kubernetes utilizzando il file della chiave del account di servizio apigee-guardrails nella directory service-accounts/:

kubectl create secret generic apigee-guardrails-svc-account \
    --from-file="client_secret.json=$APIGEE_HELM_CHARTS_HOME/service-accounts/$PROJECT_ID-apigee-guardrails.json" \
    -n $APIGEE_NAMESPACE

Aggiungi quanto segue al tuo file overrides.yaml:

guardrails:
  serviceAccountRef: apigee-guardrails-svc-account

File JSON

Aggiungi quanto segue al file overrides.yaml, utilizzando il percorso del file della chiave del account di servizio apigee-guardrails nella directory apigee-operator/:

guardrails:
  serviceAccountPath: $PROJECT_ID-apigee-guardrails.json

Vault

Aggiorna il secret Vault secret/data/apigee/orgsakeys per aggiungere una voce guardrails con i contenuti del file della chiave del account di servizio apigee-guardrails.
```
vault kv patch secret/apigee/orgsakeys guardrails="$(cat ./service-accounts/hybrid115-apigee-guardrails.json)"
```

Il account di servizio Kubernetes (KSA) per i guardrail si chiama apigee-operator-guardrails-sa. Aggiungi l'asset di sicurezza e conformità Guardrails agli account di servizio specifici dell'organizzazione associati al ruolo apigee-orgsakeys in Vault.

Recupera l'elenco attuale delle associazioni KSA:

vault read auth/kubernetes/role/apigee-orgsakeys

L'output dovrebbe avere il seguente formato:

Key                                         Value
---                                         -----
alias_name_source                           serviceaccount_uid
bound_service_account_names                 BOUND_SERVICE_ACCOUNT_NAMES
bound_service_account_namespace_selector    n/a
bound_service_account_namespaces            APIGEE_NAMESPACE

Nell'output, BOUND_SERVICE_ACCOUNT_NAMES è un elenco di nomi di account di servizio separati da virgole. Aggiungi apigee-operator-guardrails-sa all'elenco dei nomi. Ad esempio (senza i ritorni a capo aggiunti per la leggibilità):

apigee-manager,apigee-cassandra-default,apigee-cassandra-backup-sa,
apigee-cassandra-restore-sa,apigee-cassandra-schema-setup-myhybrido
rg-5b044c1,apigee-cassandra-schema-val-myhybridorg-5b044c1,apigee-c
assandra-user-setup-myhybridorg-5b044c1,apigee-mart-myhybridorg-5b0
44c1,apigee-mint-task-scheduler-myhybridorg-5b044c1,apigee-connect-
agent-myhybridorg-5b044c1,apigee-watcher-myhybridorg-5b044c1,apigee
-metrics-apigee-telemetry,apigee-open-telemetry,apigee-synchronizer
-myhybridorg-dev-ee52aca,apigee-runtime-telemetry-collector-apigee-
telemetry,apigee-logger-apigee-e-myhybrridorg-dev-ee52aca,apigee-sy
nchronizer-myhybridog-prod-2d0221c,apigee-runtime-myhybridorg-prod-
2d0221c,apigee-operator-guardrails-sa

Aggiorna le associazioni al ruolo apigee-orgsakeys con l'elenco aggiornato dei nomi dei account di servizio:

vault write auth/kubernetes/role/apigee-orgsakeys \
  bound_service_account_names=UPDATED_BOUND_SERVICE_ACCOUNT_NAMES \
  bound_service_account_namespaces=APIGEE_NAMESPACE \
  policies=apigee-orgsakeys-auth \
  ttl=1m

Aggiungi "guardrail" a SecretProviderClass
1. Modifica il file spc-org.yaml.
  Suggerimento:se devi ricrearlo, utilizza il modello in Memorizzare le chiavi del account di servizio in Hashicorp Vault: crea oggetti SecretProviderClass.
2. In spec.parameters.objects, aggiungi una voce di contromisure:
```
      - objectName: "guardrails"
        secretPath: ""
        secretKey: ""
```
  Suggerimento:per gli ambienti basati su script o per automatizzare questa modifica, puoi utilizzare il processore YAML della riga di comando yq.
  Comando:per aggiungere la voce "guardrail" a spc-org.yaml in loco, utilizza questo comando:
```
yq -i '.spec.parameters.objects |= (
    from_yaml + [
        {
            "objectName": "guardrails",
            "secretPath": "",
            "secretKey": ""
        }
    ] | to_yaml
)' spc-org.yaml
```
  Questo comando analizza la stringa YAML incorporata nel campo objects, aggiunge il nuovo elemento all'elenco e poi riscrive il risultato.
3. Aggiorna il tuo SecretProviderClass:
```
kubectl -n APIGEE_NAMESPACE apply -f spc-org.yaml
```

WIF per GKE

Il account di servizio Kubernetes (KSA) per i guardrail si chiama apigee-operator-guardrails-sa. Crea l'associazione per il account di servizio Google (GSA) apigee-guardrails con il seguente comando:

gcloud iam service-accounts add-iam-policy-binding apigee-guardrails@$PROJECT_ID.iam.gserviceaccount.com \
    --role roles/iam.workloadIdentityUser \
    --member "serviceAccount:$PROJECT_ID.svc.id.goog[$APIGEE_NAMESPACE/apigee-operator-guardrails-sa]" \
    --project $PROJECT_ID

Aggiungi quanto segue al tuo file overrides.yaml:

guardrails:
  gsa: apigee-guardrails@$PROJECT_ID.iam.gserviceaccount.com

WIF su altre piattaforme

Il account di servizio Kubernetes (KSA) per i guardrail si chiama apigee-operator-guardrails-sa. Devi concedere all'KSA delle misure di protezione l'accesso per simulare l'identità dell'account di servizio Google (GSA) apigee-guardrails e configurare gli override in modo che utilizzino un file di configurazione delle credenziali.

Concedi all'account di servizio Kubernetes l'accesso per rappresentare l'account di servizio Google con il seguente comando:

Modello

gcloud iam service-accounts add-iam-policy-binding \
  apigee-guardrails@$PROJECT_ID.iam.gserviceaccount.com \
  --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/system:serviceaccount:APIGEE_NAMESPACE:apigee-operator-guardrails-sa" \
  --role=roles/iam.workloadIdentityUser

Esempio

gcloud iam service-accounts add-iam-policy-binding \
  apigee-guardrails@my-project.iam.gserviceaccount.com \
  --member="principal://iam.googleapis.com/projects/1234567890/locations/global/workloadIdentityPools/my-pool/subject/system:serviceaccount:apigee:apigee-operator-guardrails-sa" \
  --role=roles/iam.workloadIdentityUser

Dove:

PROJECT_ID: l'ID del tuo progetto Google Cloud.
PROJECT_NUMBER: il numero di progetto del progetto in cui hai creato il pool di identità del workload.
POOL_ID: l'ID del pool di identità del workload.
APIGEE_NAMESPACE: lo spazio dei nomi in cui è installato Apigee hybrid.

Crea un file di configurazione delle credenziali per il account di servizio apigee-guardrails:

gcloud iam workload-identity-pools create-cred-config \
  projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/WORKLOAD_PROVIDER_ID \
  --service-account=apigee-guardrails@$PROJECT_ID.iam.gserviceaccount.com \
  --credential-source-file=/var/run/service-account/token \
  --credential-source-type=text \
  --output-file=apigee-guardrails-credential-configuration.json

dove WORKLOAD_PROVIDER_ID è l'ID del provider di pool di identità del workload.

Configura apigee-guardrails in modo che utilizzi la federazione delle identità per i workload con uno dei seguenti metodi:
WIF: secrets
1. Crea un nuovo secret Kubernetes utilizzando il file di origine delle credenziali per ogni file di configurazione delle credenziali.
  kubectl create secret -n APIGEE_NAMESPACE generic guardrails-workload-identity-secret --from-file="client_secret.json=./apigee-guardrails-credential-configuration.json"
2. Sostituisci il valore di serviceAccountRef con il nuovo secret:
  guardrails: serviceAccountRef: guardrails-workload-identity-secret
WIF: file

Sposta il file apigee-guardrails-credential-configuration.json generato nella directory dei grafici apigee-operator/.

Aggiungi quanto segue al tuo file overrides.yaml:
```
guardrails:
  serviceAccountPath: apigee-guardrails-credential-configuration.json
```
WIF: Vault

Aggiorna la chiave del account di servizio per guardrails in Vault con il file di origine delle credenziali corrispondente:
```
SAKEY=$(cat .apigee-guardrails-credential-configuration.json); kubectl -n APIGEE_NAMESPACE exec vault-0 -- vault kv patch secret/apigee/orgsakeys guardrails="$SAKEY"
```
Per saperne di più, consulta Storing service account keys in Hashicorp Vault.

Esegui l'upgrade di cert-manager

Apigee hybrid v1.16 supporta le versioni di cert-manager dalla 1.16 alla 1.19. In cert-manager 1.18 è stata apportata una modifica che può causare un problema con il traffico. Nella release 1.18 di cert-manager, il valore predefinito di Certificate.Spec.PrivateKey.rotationPolicy è stato modificato da Never a Always. Per le installazioni ibride di Apigee aggiornate, questo può causare un problema con il traffico. Quando esegui l'upgrade a ibrido v1.16 da una versione precedente, devi modificare il certificato apigee-ca per compensare questa modifica o mantenere la versione di cert-manager alla release 1.17.x o precedente.

Prima di eseguire l'upgrade di cert-manager alla versione 1.18 o 1.19, utilizza la seguente procedura per modificare il certificato apigee-ca in modo da impostare il valore di Certificate.Spec.PrivateKey.rotationPolicy su Never.

Controlla i contenuti del certificato apigee-ca per vedere se rotationPolicy è impostato:

Suggerimento: se utilizzi uno spazio dei nomi cert-manager personalizzato, sostituisci cert-manager con lo spazio dei nomi corretto nei seguenti comandi.

kubectl get certificate apigee-ca -n cert-manager -o yaml

Cerca i valori in spec.privateKey nell'output:

...
spec:
  commonName: apigee-hybrid
  duration: 87600h
  isCA: true
  issuerRef:
    group: cert-manager.io
    kind: ClusterIssuer
    name: apigee-root-certificate-issuer
  privateKey:
    algorithm: ECDSA
    # Note: rotationPolicy would appear here if it is set.
    size: 256
  secretName: apigee-ca
...

Se rotationPolicy non è impostato o se è impostato su Always, modifica il certificato apigee-ca per impostare il valore di rotationPolicy su Never:

Esegui prima un dry run:

kubectl patch Certificate \
  --dry-run=server \
  -n cert-manager \
  --type=json \
  -p='[{"op": "replace", "path": "/spec/privateKey/rotationPolicy", "value": "Never"}]' \
  -o=yaml \
  apigee-ca

Applica la patch al certificato:

kubectl patch Certificate \
  -n cert-manager \
  --type=json \
  -p='[{"op": "replace", "path": "/spec/privateKey/rotationPolicy", "value": "Never"}]' \
  -o=yaml \
  apigee-ca

Verifica che il valore di rotationPolicy sia ora impostato su Never:

kubectl get certificate apigee-ca -n cert-manager -o yaml

L'output dovrebbe essere simile al seguente:

...
spec:
  commonName: apigee-hybrid
  duration: 87600h
  isCA: true
  issuerRef:
    group: cert-manager.io
    kind: ClusterIssuer
    name: apigee-root-certificate-issuer
  privateKey:
    algorithm: ECDSA
    rotationPolicy: Never
    size: 256
  secretName: apigee-ca
...

Esegui l'upgrade di cert-manager. Il seguente comando scaricherà e installerà cert-manager v1.19.2:
```
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.19.2/cert-manager.yaml
```
Consulta l'articolo Piattaforme e versioni supportate: cert-manager per un elenco delle versioni supportate.

Vedi:

Installa il runtime di hybrid 1.16.0

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 \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run=server

Esegui l'upgrade del grafico:

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

Verifica l'installazione dell'operatore Apigee:

helm ls -n APIGEE_NAMESPACE

NAME       NAMESPACE       REVISION   UPDATED                                STATUS     CHART                   APP VERSION
operator   apigee   3          2024-08-21 00:42:44.492009 -0800 PST   deployed   apigee-operator-1.16.0   1.16.0

Verifica che sia in funzione controllando la sua disponibilità:

kubectl -n APIGEE_NAMESPACE 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=server

Esegui l'upgrade del grafico:

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

Verifica che apigeedatastore sia attivo e funzionante controllandone lo stato:

kubectl -n APIGEE_NAMESPACE 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=server

Esegui l'upgrade del grafico:

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

Verifica che sia attivo e funzionante controllandone lo stato:

kubectl -n APIGEE_NAMESPACE 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=server

Esegui l'upgrade del grafico:

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

Verifica che sia attivo e funzionante controllandone lo stato:

kubectl -n APIGEE_NAMESPACE 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=server

Esegui l'upgrade del grafico:

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

Verifica che sia in funzione controllando la sua disponibilità:

kubectl -n APIGEE_NAMESPACE 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=server
```
Esegui l'upgrade del grafico:
```
helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE
```
Verifica che sia attivo e funzionante controllando lo stato dell'organizzazione corrispondente:
```
kubectl -n APIGEE_NAMESPACE get apigeeorg
```
```
NAME                      STATE     AGE
apigee-my-org-my-env      running   2d
```
Nota: se il comando di upgrade non va a buon fine e viene visualizzato l'errore Forbidden: state: releasing, i componenti esistenti sono ancora in stato di rilascio. Puoi attendere il completamento dell'aggiornamento corrente e poi riprovare. Controlla lo stato della release con il seguente comando:
```
kubectl get org -n APIGEE_NAMESPACE
```
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=server
```
- ENV_RELEASE_NAME è un nome utilizzato per tenere traccia dell'installazione e degli upgrade del grafico apigee-env. Questo nome deve essere univoco rispetto agli altri nomi delle release Helm nell'installazione. Di solito è uguale a ENV_NAME. Tuttavia, se il tuo ambiente ha lo stesso nome del tuo gruppo di ambienti, devi utilizzare nomi di release diversi per l'ambiente e il gruppo di ambienti, ad esempio dev-env-release e dev-envgroup-release. Per ulteriori informazioni sulle release in Helm, consulta Tre concetti importanti nella documentazione di Helm.
- ENV_NAME è il nome dell'ambiente che stai eseguendo l'upgrade.
- OVERRIDES_FILE è il nuovo file di override per la versione 1.16.0
Esegui l'upgrade del grafico:
```
helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set env=ENV_NAME \
  -f OVERRIDES_FILE
```
Verifica che sia attivo e in esecuzione controllando lo stato dell'ambiente corrispondente:
```
kubectl -n APIGEE_NAMESPACE get apigeeenv
```
```
NAME                          STATE       AGE   GATEWAYTYPE
apigee-my-org-my-env          running     2d
```

Nota: se il comando di upgrade non va a buon fine e viene visualizzato l'errore Forbidden: state: releasing, i componenti esistenti sono ancora in stato di rilascio. Puoi attendere il completamento dell'aggiornamento corrente e poi riprovare. Controlla lo stato della release con il seguente comando:

kubectl get env -n APIGEE_NAMESPACE

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 ambienti 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=server
```
  ENV_GROUP_RELEASE_NAME è il nome con cui hai installato in precedenza il grafico apigee-virtualhost. 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: 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 AR corrispondente sia in esecuzione:
```
kubectl -n APIGEE_NAMESPACE get arc
```
```
NAME                                STATE   AGE
apigee-org1-dev-egroup                       2d
```
```
kubectl -n APIGEE_NAMESPACE get ar
```
```
NAME                                        STATE     AGE
apigee-org1-dev-egroup-123abc               running   2d
```
Dopo aver verificato che tutti gli upgrade sono stati eseguiti correttamente, elimina la versione apigee-operator precedente dallo spazio dei nomi apigee-system.
1. Disinstalla la vecchia versione di operator:
```
helm delete operator -n apigee-system
```
2. Elimina lo spazio dei nomi apigee-system:
```
kubectl delete namespace apigee-system
```

Esegui di nuovo l'upgrade di operator nello spazio dei nomi Apigee per reinstallare le risorse con ambito cluster eliminate:

helm upgrade operator apigee-operator/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f overrides.yaml

Eseguire il rollback a una versione precedente

Per eseguire il rollback alla versione precedente, utilizza la versione precedente del grafico per eseguire il rollback della procedura di upgrade in ordine inverso. Inizia con apigee-virtualhost e torna indietro fino a apigee-operator, poi ripristina i CRD.

Suggerimento:se conosci l'ultima versione, puoi utilizzare il comando helm rollback anziché il comando helm upgrade descritto di seguito.

Ripristina tutte le classifiche dal apigee-virtualhost al apigee-datastore. I seguenti comandi presuppongono che tu stia utilizzando i grafici della versione precedente (v1.15.x).

Esegui questo comando per ogni gruppo di ambienti:

helm upgrade ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
  --install \
  --namespace apigee \
  --atomic \
  --set envgroup=ENV_GROUP_NAME \
  -f 1.15_OVERRIDES_FILE

Esegui questo comando per ogni ambiente:

helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace apigee \
  --atomic \
  --set env=ENV_NAME \
  -f 1.15_OVERRIDES_FILE

Ripristina i grafici rimanenti, tranne apigee-operator.

helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace apigee \
  --atomic \
  -f 1.15_OVERRIDES_FILE

helm upgrade ingress-manager apigee-ingress-manager/ \
  --install \
  --namespace apigee \
  --atomic \
  -f 1.15_OVERRIDES_FILE

helm upgrade redis apigee-redis/ \
  --install \
  --namespace apigee \
  --atomic \
  -f 1.15_OVERRIDES_FILE

helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace apigee \
  --atomic \
  -f 1.15_OVERRIDES_FILE

helm upgrade datastore apigee-datastore/ \
  --install \
  --namespace apigee \
  --atomic \
  -f 1.15_OVERRIDES_FILE

Crea lo spazio dei nomi apigee-system.
```
kubectl create namespace apigee-system
```

Applica la patch all'annotazione della risorsa nello spazio dei nomi apigee-system.

kubectl annotate --overwrite clusterIssuer apigee-ca-issuer meta.helm.sh/release-namespace='apigee-system'

Se hai modificato anche il nome della release, aggiorna l'annotazione con il nome della release operator.
```
kubectl annotate --overwrite clusterIssuer apigee-ca-issuer meta.helm.sh/release-name='operator'
```

Installa apigee-operator nello spazio dei nomi apigee-system.

helm upgrade operator apigee-operator/ \
  --install \
  --namespace apigee-system \
  --atomic \
  -f 1.15_OVERRIDES_FILE

Ripristina i CRD reinstallando quelli precedenti.

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

Pulisci la release apigee-operator dallo spazio dei nomi APIGEE_NAMESPACE per completare la procedura di rollback.
```
helm uninstall operator -n APIGEE_NAMESPACE
```
Alcune risorse con ambito cluster, come clusterIssuer, vengono eliminate quando operator viene disinstallato. Reinstallali con il seguente comando:
```
helm upgrade operator apigee-operator/ \
  --install \
  --namespace apigee-system \
  --atomic \
  -f 1.15_OVERRIDES_FILE
```

Upgrade di Apigee hybrid alla versione 1.16 Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Modifiche rispetto ad Apigee hybrid v1.15

Prerequisiti

Prima di eseguire l'upgrade alla versione 1.16.0: limitazioni e note importanti

Panoramica dell'upgrade alla versione 1.16.0

Prepararsi all'upgrade alla versione 1.16

Esegui il backup dell'installazione ibrida

Linux

Mac OS

Windows

Esegui l'upgrade della versione di Kubernetes

Fai clic per espandere l'elenco delle piattaforme supportate

Versioni supportate

Componenti

Versioni non supportate

Componenti

Estrai i grafici Helm di Apigee.

Modifica kustomization.yaml per uno spazio dei nomi Apigee personalizzato

Configurare il account di servizio apigee-guardrails

Secret Kubernetes

File JSON

Vault

WIF per GKE

WIF su altre piattaforme

Secret Kubernetes

File JSON

Vault

WIF per GKE

WIF su altre piattaforme

Modello

Esempio

WIF: secrets

WIF: file

WIF: Vault

Esegui l'upgrade di cert-manager

Installa il runtime di hybrid 1.16.0

Eseguire il rollback a una versione precedente

Upgrade di Apigee hybrid alla versione 1.16

Modifica `kustomization.yaml` per uno spazio dei nomi Apigee personalizzato

Configurare il account di servizio `apigee-guardrails`