Cette page a été traduite par l'API Cloud Translation.

Mettre à niveau Apigee hybrid vers la version 1.16

Cette procédure concerne la mise à niveau d'Apigee hybrid de la version 1.15.x vers la version 1.16.0.

Modifications par rapport à Apigee hybrid v1.15

Notez les modifications suivantes :

Profils Seccomp : à partir de la version 1.16, Apigee hybrid offre désormais la possibilité d'appliquer des profils Seccomp à vos composants d'exécution, ce qui améliore considérablement la sécurité de votre déploiement. Cette fonctionnalité permet aux administrateurs Apigee et aux équipes de sécurité de limiter les appels système qu'un processus conteneurisé peut effectuer sur le noyau de l'hôte. En limitant un conteneur aux appels système nécessaires, vous pouvez :
- Renforcez la sécurité : limitez le risque d'évasion de conteneur et d'élévation des privilèges.
- Appliquez le principe du moindre privilège : assurez-vous que les composants n'ont accès qu'aux appels système exacts nécessaires à leur fonctionnement.
- Conformité Meet : fournit un contrôle essentiel pour répondre aux exigences strictes de conformité en matière de sécurité.
Pour en savoir plus, consultez Configurer des profils Seccomp pour la sécurité des pods.
Suppression de l'UDCA dans Apigee hybrid : dans Apigee hybrid version 1.16, le composant Unified Data Collection Agent (UDCA) a été supprimé. Les responsabilités liées à l'envoi de données d'analyse, de trace et d'état de déploiement au plan de contrôle Apigee sont désormais gérées à l'aide d'un pipeline de données basé sur Google Cloud Pub/Sub. Le pipeline de données basé sur Pub/Sub est le mécanisme de collecte de données par défaut depuis la version 1.14.0 d'Apigee hybrid.
Compte de service apigee-guardrails : dans la version 1.16.0, Apigee Hybrid introduit un compte de service Google IAM apigee-guardrails. Il est utilisé par le graphique apigee-operator lors de l'installation pour vérifier que toutes les API nécessaires sont activées dans votre projet.
Consultez les pages suivantes :
Compatibilité avec les versions 1.18 et 1.19 de cert-manager : Apigee hybrid v1.16 est compatible avec cert-manager version 1.18 et cert-manager version 1.19. Dans la version 1.18 de cert-manager, la valeur par défaut de Certificate.Spec.PrivateKey.rotationPolicy a été modifiée, ce qui peut avoir un impact sur le trafic. Si vous effectuez une mise à niveau à partir d'une version antérieure d'Apigee hybrid et que vous passez à la version 1.18 ou ultérieure de cert-manager, suivez la procédure Mettre à niveau cert-manager de ce guide.

Remarque : Cela n'affecte pas les nouvelles installations d'Apigee hybrid v1.6.

Pour en savoir plus sur les fonctionnalités de la version 1.16 d'Hybrid, consultez les notes de version d'Apigee hybrid v1.16.0.

Prérequis

Avant de passer à la version 1.16 d'Apigee hybrid, assurez-vous que votre installation remplit les conditions suivantes :

Si votre installation hybride exécute une version antérieure à la version 1.15, vous devez passer à la version 1.15 avant de passer à la version 1.16. Consultez Mettre à niveau Apigee hybrid vers la version 1.15.
Helm version 3.14.2 ou ultérieure.
kubectl : version compatible de kubectl adaptée à votre version de la plate-forme Kubernetes. Consultez Plates-formes et versions compatibles : kubectl.
cert-manager : version compatible de cert-manager. Consultez la section Plates-formes et versions compatibles : cert-manager. Si nécessaire, vous mettrez à niveau cert-manager dans la section Préparer la mise à niveau vers la version 1.16 ci-dessous.

Avant de passer à la version 1.16.0 : limites et remarques importantes

Apigee hybrid 1.16.0 introduit une nouvelle limite de proxy améliorée par environnement, qui vous permet de déployer davantage de proxys et de flux partagés dans un même environnement. Consultez Limites : proxys d'API pour comprendre les limites concernant le nombre de proxys et de flux partagés que vous pouvez déployer par environnement. Cette fonctionnalité n'est disponible que pour les organisations hybrides nouvellement créées et ne peut pas être appliquée aux organisations mises à niveau. Pour utiliser cette fonctionnalité, effectuez une nouvelle installation d'Apigee hybrid 1.16.0 et créez une organisation.

Cette fonctionnalité est disponible exclusivement dans le forfait d'abonnement 2024 et est soumise aux droits accordés dans le cadre de cet abonnement. Pour en savoir plus sur cette fonctionnalité, consultez Limites de proxy améliorées par environnement.
La mise à niveau vers la version 1.16 d'Apigee hybrid peut nécessiter un temps d'arrêt.

Lors de la mise à niveau du contrôleur Apigee vers la version 1.16.0, tous les déploiements Apigee font l'objet d'un redémarrage progressif. Pour minimiser les temps d'arrêt dans les environnements hybrides de production lors d'un redémarrage progressif, assurez-vous d'exécuter au moins deux clusters (dans la même région ou dans un centre de données différent). Dirigez l'ensemble du trafic de production vers un seul cluster et sélectionnez le cluster que vous êtes sur le point de mettre à niveau hors connexion, puis poursuivez le processus de mise à niveau. Répétez cette procédure pour chaque cluster.

Apigee vous recommande de mettre à niveau tous les clusters dès que possible afin de réduire les risques d'impact sur la production. Après la mise à niveau du premier cluster, il n'y a pas de date limite pour procéder à la mise à niveau de l'ensemble des clusters restants. Toutefois, jusqu'à ce que tous les clusters restants soient mis à niveau, la sauvegarde et la restauration de bases de données Cassandra ne peuvent pas fonctionner avec les versions mixtes. Par exemple, une sauvegarde Hybrid 1.15 ne peut pas être utilisée pour restaurer une instance Hybrid 1.16.
Les modifications du plan de gestion n'ont pas besoin d'être entièrement suspendues lors d'une mise à niveau. Les suspensions temporaires requises pour les modifications du plan de gestion sont indiquées dans les instructions de mise à niveau ci-dessous.

Présentation de la mise à niveau vers la version 1.16.0

Les procédures de mise à niveau d'Apigee hybrid sont organisées dans les sections suivantes :

Préparez la mise à niveau.
Installez la version 1.16.0 de l'environnement d'exécution hybride.

Préparer la mise à niveau vers la version 1.16

Sauvegarder votre installation hybrid

Ces instructions utilisent la variable d'environnement APIGEE_HELM_CHARTS_HOME pour le répertoire de votre système de fichiers dans lequel vous avez installé les charts Helm. Si nécessaire, accédez au répertoire et définissez la variable en utilisant la commande suivante :
Linux
```
export APIGEE_HELM_CHARTS_HOME=$PWD
echo $APIGEE_HELM_CHARTS_HOME
```
macOS
```
export APIGEE_HELM_CHARTS_HOME=$PWD
echo $APIGEE_HELM_CHARTS_HOME
```
Windows
```
set APIGEE_HELM_CHARTS_HOME=%CD%
echo %APIGEE_HELM_CHARTS_HOME%
```
Créez une copie de sauvegarde de votre répertoire $APIGEE_HELM_CHARTS_HOME/ version 1.15. Vous pouvez utiliser n'importe quel processus de sauvegarde. Par exemple, vous pouvez créer un fichier tar contenant l'intégralité de votre répertoire à l'aide de la commande suivante :
```
tar -czvf $APIGEE_HELM_CHARTS_HOME/../apigee-helm-charts-v1.15-backup.tar.gz $APIGEE_HELM_CHARTS_HOME
```
Sauvegardez votre base de données Cassandra en suivant les instructions figurant sur la page Sauvegarde et récupération de Cassandra.
Assurez-vous que votre certificat TLS et vos fichiers de clé (.crt, .key et/ou .pem) se trouvent dans le répertoire $APIGEE_HELM_CHARTS_HOME/apigee-virtualhost/.

Mettre à niveau votre version de Kubernetes

Vérifiez la version de votre plate-forme Kubernetes et, si nécessaire, mettez à niveau votre plate-forme Kubernetes vers une version compatible avec les versions 1.15 et 1.16 d'Apigee hybrid. Si vous avez besoin d'aide, consultez la documentation de votre plate-forme.

Cliquer pour développer la liste des plates-formes compatibles

Versions compatibles

	1,14	1.15	1.16
GKE sur 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 sur 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 sur 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 (logiciel uniquement) sur 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 (logiciel uniquement) sur solution 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
Composants	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 à 3.x.x	3.14.2 à 3.x.x	3.17.0 à 3.x.x
Pilote CSI Secret Store	1.4.6+	1.4.6+	1.4.6+
Vault	1.17.2	1.17.2	1.17.2
⁽¹⁾ Les dates de fin de vie officielles des versions 1.13 et antérieures d'Apigee hybrid ont été atteintes. Les correctifs mensuels standards ne sont plus disponibles. Ces versions ne sont plus officiellement compatibles, sauf pour les clients bénéficiant d'exceptions explicites et officielles. Les autres clients doivent effectuer une mise à niveau. ⁽²⁾ Cloud Service Mesh est automatiquement installé avec Apigee hybrid 1.9 et les versions ultérieures. ⁽³⁾ Vault n'est pas certifié sur Google Distributed Cloud pour VMware. ⁽⁴⁾ Compatibilité avec Apigee hybrid version 1.10.5 et ultérieure. ⁽⁵⁾ Compatibilité avec Apigee hybrid version 1.11.2 et ultérieure. ⁽⁶⁾ Compatibilité avec Apigee hybrid version 1.12.1 et ultérieure. ⁽⁷⁾ Apigee hybrid est testé et certifié sur OpenShift à l'aide de la version de Kubernetes fournie avec chaque version OCP spécifique. ⁽⁸⁾ Dans certaines versions de cert-manager, le serveur TLS du webhook peut ne pas renouveler automatiquement son certificat CA. Pour éviter cela, Apigee recommande d'utiliser : Hybrid v1.13 : utilisez cert-manager version 1.15.5 ou ultérieure. Hybrid v1.14 : utilisez cert-manager version 1.15.5 ou 1.16.3. Hybrid v1.15 : utilisez cert-manager version 1.16.3+ ou 1.17.2+. Hybrid v1.16 : utilisez les versions 1.16.3+, 1.17.2+, 1.18.0+ ou 1.19.0+ de cert-manager. Consultez le problème connu 465834046 pour les versions 1.18 et 1.19 de cert-manager. ⁽⁹⁾ La version 1.18 de cert-manager introduit une modification de la règle de rotation des clés privées par défaut, ce qui peut entraîner des interruptions de trafic. Consultez le problème connu 465834046 pour trouver une solution.

Versions non compatibles

	1.6 ⁽¹⁾	1.7 ⁽¹⁾	1.8 ⁽¹⁾	1.9 ⁽¹⁾	1.10 ⁽¹⁾	1.11 ⁽¹⁾	1.12 ⁽¹⁾	1.13 ⁽¹⁾
GKE sur 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 sur 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 sur 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 (logiciel uniquement) sur 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 (logiciel uniquement) sur solution 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/A	N/A	N/A	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/A	N/A	N/A	N/A	N/A	N/A	v1.26.x	v1.26.x
Composants	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 à 3.x.x	3.14.2 à 3.x.x
Pilote CSI Secret Store						1.3.4+	1.4.1+	1.4.6+
Vault						1.13.x	1.15.2	1.15.2
⁽¹⁾ Les dates de fin de vie officielles des versions 1.13 et antérieures d'Apigee hybrid ont été atteintes. Les correctifs mensuels standards ne sont plus disponibles. Ces versions ne sont plus officiellement compatibles, sauf pour les clients bénéficiant d'exceptions explicites et officielles. Les autres clients doivent effectuer une mise à niveau. ⁽²⁾ Cloud Service Mesh est automatiquement installé avec Apigee hybrid 1.9 et les versions ultérieures. ⁽³⁾ Vault n'est pas certifié sur Google Distributed Cloud pour VMware. ⁽⁴⁾ Compatibilité avec Apigee hybrid version 1.10.5 et ultérieure. ⁽⁵⁾ Compatibilité avec Apigee hybrid version 1.11.2 et ultérieure. ⁽⁶⁾ Compatibilité avec Apigee hybrid version 1.12.1 et ultérieure. ⁽⁷⁾ Apigee hybrid est testé et certifié sur OpenShift à l'aide de la version de Kubernetes fournie avec chaque version OCP spécifique. ⁽⁸⁾ Dans certaines versions de cert-manager, le serveur TLS du webhook peut ne pas renouveler automatiquement son certificat CA. Pour éviter cela, Apigee recommande d'utiliser : Hybrid v1.13 : utilisez cert-manager version 1.15.5 ou ultérieure. Hybrid v1.14 : utilisez cert-manager version 1.15.5 ou 1.16.3. Hybrid v1.15 : utilisez cert-manager version 1.16.3+ ou 1.17.2+. Hybrid v1.16 : utilisez les versions 1.16.3+, 1.17.2+, 1.18.0+ ou 1.19.0+ de cert-manager. Consultez le problème connu 465834046 pour les versions 1.18 et 1.19 de cert-manager. ⁽⁹⁾ La version 1.18 de cert-manager introduit une modification de la règle de rotation des clés privées par défaut, ce qui peut entraîner des interruptions de trafic. Consultez le problème connu 465834046 pour trouver une solution.

Extrayez les graphiques Helm Apigee.

Les charts Apigee hybrid sont hébergés dans Google Artifact Registry :

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

À l'aide de la commande pull, copiez tous les charts Helm Apigee hybrid sur votre espace de stockage local à l'aide de la commande suivante :

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

Modifier `kustomization.yaml` pour un espace de noms Apigee personnalisé

Si votre espace de noms Apigee n'est pas apigee, modifiez le fichier apigee-operator/etc/crds/default/kustomization.yaml et remplacez la valeur namespace par votre espace de noms Apigee.

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

namespace: APIGEE_NAMESPACE

Si vous utilisez apigee comme espace de noms, vous n'avez pas besoin de modifier le fichier.

Installez les CRD Apigee mises à jour :

Remarque : Il s'agit de la seule méthode compatible pour installer des CRD Apigee. N'utilisez pas kubectl apply sans -k. N'omettez pas --server-side.

Utilisez la fonctionnalité de simulation kubectl en exécutant la commande suivante :

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

Après avoir validé la commande avec la simulation, exécutez la commande suivante :

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

Validez l'installation à l'aide de la commande kubectl get crds :

kubectl get crds | grep apigee

Le résultat doit se présenter sous la forme suivante :

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

Vérifiez les libellés sur les nœuds de cluster. Par défaut, Apigee planifie les pods de données sur les nœuds portant le libellé cloud.google.com/gke-nodepool=apigee-data et les pods d'exécution sont programmés sur les nœuds portant le libellé cloud.google.com/gke-nodepool=apigee-runtime. Vous pouvez personnaliser les libellés de votre pool de nœuds dans le fichier overrides.yaml.

Pour en savoir plus, consultez la page Configurer des pools de nœuds dédiés.

Configurer le compte de service `apigee-guardrails`

À partir de hybrid v1.16, le compte de service apigee-guardrails est requis pour mettre à niveau le graphique apigee-operator.

Dans la procédure suivante, sélectionnez le type d'authentification de compte de service que vous utilisez.

Vérifiez que vous pouvez exécuter create-service-account. Si vous venez de télécharger les graphiques, il est possible que le fichier create-service-account ne soit pas en mode exécutable. Exécutez la commande suivante dans votre répertoire APIGEE_HELM_CHARTS_HOME :
```
./apigee-operator/etc/tools/create-service-account --help
```
Si le résultat indique permission denied, vous devez rendre le fichier exécutable, par exemple avec chmod sous Linux, MacOS ou UNIX, ou dans l'explorateur Windows, ou à l'aide de la commande icacls dans Windows. Exemple :
```
chmod +x ./apigee-operator/etc/tools/create-service-account
```
Créez le compte de service apigee-guardrails :
Secrets Kubernetes
```
./apigee-operator/etc/tools/create-service-account \
  --env prod \
  --profile apigee-guardrails \
  --dir service-accounts
```
Cette commande crée le compte de service apigee-guardrails et télécharge la clé dans le répertoire service-accounts/.
Fichiers JSON
```
./apigee-operator/etc/tools/create-service-account \
  --env prod \
  --profile apigee-guardrails \
  --dir ./apigee-operator/
```
Cette commande crée le compte de service apigee-guardrails et télécharge la clé dans le répertoire du graphique apigee-operator/.
Vault
```
./apigee-operator/etc/tools/create-service-account \
  --env prod \
  --profile apigee-guardrails \
  --dir service-accounts
```
Cette commande crée le compte de service apigee-guardrails et télécharge la clé dans le répertoire service-accounts/.
WIF pour GKE
```
./apigee-operator/etc/tools/create-service-account \
  --env prod \
  --profile apigee-guardrails \
  --dir service-accounts
```
Cette commande crée le compte de service apigee-guardrails et télécharge la clé dans le répertoire apigee-operator/etc/tools/service-accounts/. Vous n'avez pas besoin du fichier clé téléchargé et vous pouvez le supprimer.
WIF sur d'autres plates-formes
```
./apigee-operator/etc/tools/create-service-account \
  --env prod \
  --profile apigee-guardrails \
  --dir service-accounts
```
Cette commande crée le compte de service apigee-guardrails et télécharge la clé dans le répertoire service-accounts/.

Configurez l'authentification pour le compte de service apigee-guardrails :

Secrets Kubernetes

Créez le secret Kubernetes à l'aide du fichier de clé de compte de service apigee-guardrails dans le répertoire 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

Ajoutez le code ci-dessous à votre fichier overrides.yaml :

guardrails:
  serviceAccountRef: apigee-guardrails-svc-account

Fichiers JSON

Ajoutez les éléments suivants à votre fichier overrides.yaml, en utilisant le chemin d'accès au fichier de clé du compte de service apigee-guardrails dans le répertoire apigee-operator/ :

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

Vault

Mettez à jour le secret Vault secret/data/apigee/orgsakeys pour ajouter une entrée guardrails avec le contenu du fichier de clé de compte de service apigee-guardrails.
```
vault kv patch secret/apigee/orgsakeys guardrails="$(cat ./service-accounts/hybrid115-apigee-guardrails.json)"
```

Le compte de service Kubernetes (KSA) pour les garde-fous est nommé apigee-operator-guardrails-sa. Ajoutez le KSA Guardrails aux comptes de service spécifiques à l'organisation associés au rôle apigee-orgsakeys dans Vault.

Obtenez la liste actuelle des liaisons KSA :

vault read auth/kubernetes/role/apigee-orgsakeys

Le résultat doit être au format suivant :

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

Dans le résultat, BOUND_SERVICE_ACCOUNT_NAMES est une liste de noms de comptes de service séparés par une virgule. Ajoutez apigee-operator-guardrails-sa à la liste des noms, par exemple (sans les sauts de ligne ajoutés pour la lisibilité) :

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

Mettez à jour les liaisons au rôle apigee-orgsakeys avec la liste mise à jour des noms de comptes de service :

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

Ajouter des "garde-fous" à SecretProviderClass
1. Modifiez votre fichier spc-org.yaml.
  Conseil : Si vous devez le recréer, utilisez le modèle dans Stocker des clés de compte de service dans HashiCorp Vault : créer des objets SecretProviderClass.
2. Sous spec.parameters.objects, ajoutez une entrée de garde-corps :
```
      - objectName: "guardrails"
        secretPath: ""
        secretKey: ""
```
  Conseil : Pour les environnements scriptés ou pour automatiser cette modification, vous pouvez utiliser le processeur YAML en ligne de commande yq.
  Commande : pour ajouter l'entrée "guardrails" à spc-org.yaml sur place, utilisez la commande suivante :
```
yq -i '.spec.parameters.objects |= (
    from_yaml + [
        {
            "objectName": "guardrails",
            "secretPath": "",
            "secretKey": ""
        }
    ] | to_yaml
)' spc-org.yaml
```
  Cette commande analyse la chaîne YAML intégrée dans le champ objects, ajoute le nouvel élément à la liste, puis réécrit le résultat.
3. Mettez à jour votre SecretProviderClass :
```
kubectl -n APIGEE_NAMESPACE apply -f spc-org.yaml
```

WIF pour GKE

Le compte de service Kubernetes (KSA) pour les garde-fous est nommé apigee-operator-guardrails-sa. Créez l'association pour le compte de service Google Cloud apigee-guardrails à l'aide de la commande suivante :

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

Ajoutez le code ci-dessous à votre fichier overrides.yaml :

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

WIF sur d'autres plates-formes

Le compte de service Kubernetes (KSA) pour les garde-fous est nommé apigee-operator-guardrails-sa. Vous devez accorder au KSA des garde-fous l'accès à l'emprunt d'identité du compte de service Google apigee-guardrails (GSA) et configurer vos remplacements pour qu'ils utilisent un fichier de configuration des identifiants.

Accordez au KSA l'accès pour emprunter l'identité du GSA avec la commande suivante :

Modèle

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

Exemple

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

Où :

PROJECT_ID : ID de votre projet Google Cloud.
PROJECT_NUMBER : numéro de projet du projet dans lequel vous avez créé le pool d'identités de charge de travail.
POOL_ID : ID du pool d'identités de charge de travail.
APIGEE_NAMESPACE : espace de noms dans lequel Apigee hybrid est installé.

Créez un fichier de configuration des identifiants pour le compte de service 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

où WORKLOAD_PROVIDER_ID correspond à l'ID de votre fournisseur de pool d'identités de charge de travail.

Configurez apigee-guardrails pour utiliser la fédération d'identité de charge de travail avec l'une des méthodes suivantes :
WIF : secrets
1. Créez un secret Kubernetes en utilisant le fichier source des identifiants pour chaque fichier de configuration des identifiants.
  kubectl create secret -n APIGEE_NAMESPACE generic guardrails-workload-identity-secret --from-file="client_secret.json=./apigee-guardrails-credential-configuration.json"
2. Remplacez la valeur de serviceAccountRef par le nouveau secret :
  guardrails: serviceAccountRef: guardrails-workload-identity-secret
WIF : fichiers

Déplacez le fichier apigee-guardrails-credential-configuration.json généré vers le répertoire de graphiques apigee-operator/.

Ajoutez le code ci-dessous à votre fichier overrides.yaml :
```
guardrails:
  serviceAccountPath: apigee-guardrails-credential-configuration.json
```
WIF: Vault

Mettez à jour la clé de compte de service pour guardrails dans Vault avec le fichier de source des identifiants correspondant :
```
SAKEY=$(cat .apigee-guardrails-credential-configuration.json); kubectl -n APIGEE_NAMESPACE exec vault-0 -- vault kv patch secret/apigee/orgsakeys guardrails="$SAKEY"
```
Pour en savoir plus, consultez la page Storing service account keys in Hashicorp Vault.

Mettre à niveau cert-manager

Apigee hybrid v1.16 est compatible avec les versions 1.16 à 1.19 de cert-manager. Une modification apportée à cert-manager 1.18 peut entraîner un problème avec votre trafic. Dans la version 1.18 de cert-manager, la valeur par défaut de Certificate.Spec.PrivateKey.rotationPolicy est passée de Never à Always. Pour les installations Apigee hybrid mises à niveau, cela peut entraîner un problème avec votre trafic. Lorsque vous passez à la version 1.16 d'hybrid à partir d'une version antérieure, vous devez modifier votre certificat apigee-ca pour compenser ce changement ou conserver votre version de cert-manager à la version 1.17.x ou antérieure.

Avant de mettre à niveau cert-manager vers la version 1.18 ou 1.19, suivez la procédure ci-dessous pour modifier votre certificat apigee-ca et définir la valeur de Certificate.Spec.PrivateKey.rotationPolicy sur Never.

Vérifiez le contenu de votre certificat apigee-ca pour voir si rotationPolicy est défini :

Conseil : Si vous utilisez un espace de noms cert-manager personnalisé, remplacez cert-manager par l'espace de noms approprié dans les commandes suivantes.

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

Recherchez les valeurs sous spec.privateKey dans le résultat :

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

Si rotationPolicy n'est pas défini ou s'il est défini sur Always, modifiez le certificat apigee-ca pour définir la valeur de rotationPolicy sur Never :

Effectuez d'abord une simulation :

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

Corrigez le certificat :

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

Vérifiez que la valeur de rotationPolicy est désormais définie sur Never :

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

Le résultat doit ressembler à ce qui suit :

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

Mettez à niveau cert-manager. La commande suivante permet de télécharger et d'installer cert-manager v1.19.2 :
```
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.19.2/cert-manager.yaml
```
Consultez la page Plates-formes et versions prises en charge : cert-manager pour obtenir la liste des versions prises en charge.

Consultez les pages suivantes :

Installer l'environnement d'exécution hybride 1.16.0

Remarque : Avant d'exécuter des commandes de mise à niveau ou d'installation Helm, utilisez la fonctionnalité de simulation de Helm en ajoutant --dry-run à la fin de la commande. Consultez helm -h pour répertorier les commandes, les options et l'utilisation compatibles.

Si ce n'est pas le cas, accédez à votre répertoire APIGEE_HELM_CHARTS_HOME. Exécutez les commandes suivantes à partir de ce répertoire.

Mettez à niveau l'opérateur ou le contrôleur Apigee :

Remarque : Cette étape nécessite des autorisations de cluster élevées. Exécutez helm -h ou helm upgrade -h pour en savoir plus

Effectuez un dry run :

helm upgrade operator apigee-operator/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run=server

Mettez à niveau le graphique :

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

Vérifiez l'installation de l'opérateur 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

Vérifiez qu'il est opérationnel en vérifiant sa 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

Mettez à niveau le datastore Apigee :

Simulation :

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

Mettez à niveau le graphique :

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

Vérifiez que apigeedatastore est opérationnel en vérifiant son état :

kubectl -n APIGEE_NAMESPACE get apigeedatastore default

NAME      STATE       AGE
default   running    2d

Mettez à niveau la télémétrie Apigee :

Simulation :

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

Mettez à niveau le graphique :

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

Vérifiez qu'elle est opérationnelle en vérifiant son état :

kubectl -n APIGEE_NAMESPACE get apigeetelemetry apigee-telemetry

NAME               STATE     AGE
apigee-telemetry   running   2d

Mettez à niveau Apigee Redis :

Simulation :

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

Mettez à niveau le graphique :

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

Vérifiez qu'elle est opérationnelle en vérifiant son état :

kubectl -n APIGEE_NAMESPACE get apigeeredis default

NAME      STATE     AGE
default   running   2d

Mettez à niveau le gestionnaire d'entrée Apigee :

Simulation :

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

Mettez à niveau le graphique :

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

Vérifiez qu'il est opérationnel en vérifiant sa 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

Mettez à niveau l'organisation Apigee :
Simulation :
```
helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run=server
```
Mettez à niveau le graphique :
```
helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE
```
Vérifiez qu'elle est opérationnelle en vérifiant l'état de l'organisation correspondante :
```
kubectl -n APIGEE_NAMESPACE get apigeeorg
```
```
NAME                      STATE     AGE
apigee-my-org-my-env      running   2d
```
Remarque : Si la commande de mise à niveau échoue avec l'erreur Forbidden: state: releasing, les composants existants sont toujours en cours de publication. Vous pouvez attendre la fin de la mise à jour en cours, puis réessayer. Vérifiez l'état de la version à l'aide de la commande suivante :
```
kubectl get org -n APIGEE_NAMESPACE
```
Mettez à niveau l'environnement.
Vous devez installer un environnement à la fois. Spécifiez l'environnement avec --set env=ENV_NAME.

Effectuez un dry run :
```
helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set env=ENV_NAME \
  -f OVERRIDES_FILE \
  --dry-run=server
```
- ENV_RELEASE_NAME est un nom utilisé pour suivre l'installation et les mises à niveau du graphique apigee-env. Ce nom doit être unique par rapport aux autres noms de version Helm de votre installation. Il s'agit généralement de la même valeur que ENV_NAME. Toutefois, si votre environnement porte le même nom que votre groupe d'environnements, vous devez utiliser des noms de version différents pour l'environnement et le groupe d'environnements (par exemple, dev-env-release et dev-envgroup-release). Pour en savoir plus sur les versions dans Helm, consultez Trois concepts importants dans la documentation Helm.
- ENV_NAME est le nom de l'environnement que vous mettez à niveau.
- OVERRIDES_FILE est votre nouveau fichier de remplacement pour la version 1.16.0.
Mettez à niveau le graphique :
```
helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set env=ENV_NAME \
  -f OVERRIDES_FILE
```
Vérifiez qu'il est opérationnel en vérifiant l'état de l'environnement correspondant :
```
kubectl -n APIGEE_NAMESPACE get apigeeenv
```
```
NAME                          STATE       AGE   GATEWAYTYPE
apigee-my-org-my-env          running     2d
```

Remarque : Si la commande de mise à niveau échoue avec l'erreur Forbidden: state: releasing, les composants existants sont toujours en cours de publication. Vous pouvez attendre la fin de la mise à jour en cours, puis réessayer. Vérifiez l'état de la version à l'aide de la commande suivante :

kubectl get env -n APIGEE_NAMESPACE

Mettez à jour les groupes d'environnement (virtualhosts).
1. Vous devez installer un groupe d'environnements (hôte virtuel) à la fois. Spécifiez le groupe d'environnement avec --set envgroup=ENV_GROUP_NAME. Répétez les commandes suivantes pour chaque groupe d'environnements mentionné dans le fichier overrides.yaml :
  Effectuez un dry run :
```
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 est le nom avec lequel vous avez déjà installé le graphique apigee-virtualhost. Il s'agit généralement de ENV_GROUP_NAME.
  
  Mettez à niveau le graphique :
```
helm upgrade ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set envgroup=ENV_GROUP_NAME \
  -f OVERRIDES_FILE
```
  Remarque : ENV_GROUP_RELEASE_NAME doit être unique dans l'espace de noms apigee.
  Par exemple, si vous avez un environnement nommé prod et un groupe d'environnements nommé prod, définissez la valeur de ENV_GROUP_RELEASE_NAME sur une valeur unique, comme prod-envgroup.
2. Vérifiez l'état de la ressource ApigeeRoute (AR).
  L'installation de virtualhosts crée ApigeeRouteConfig (ARC) qui crée ApigeeRoute en interne une fois que l'observateur Apigee extrait les détails liés au groupe d'environnement du plan de contrôle. Par conséquent, vérifiez que l'état d'AR correspondant est en cours d'exécution :
```
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
```
Une fois que vous avez vérifié que toutes les installations ont été mises à niveau, supprimez l'ancienne version de apigee-operator de l'espace de noms apigee-system.
1. Désinstallez l'ancienne version de operator :
```
helm delete operator -n apigee-system
```
2. Supprimez l'espace de noms apigee-system :
```
kubectl delete namespace apigee-system
```
Mettez à niveau operator à nouveau dans votre espace de noms Apigee pour réinstaller les ressources supprimées à l'échelle du cluster :
```
helm upgrade operator apigee-operator/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f overrides.yaml
```

Effectuer un rollback vers la version précédente

Pour revenir à la version précédente, utilisez l'ancienne version du graphique pour annuler le processus de mise à niveau dans l'ordre inverse. Commencez par apigee-virtualhost, puis revenez à apigee-operator et rétablissez les CRD.

Conseil : Si vous connaissez la dernière version, vous pouvez utiliser la commande helm rollback au lieu de la commande helm upgrade décrite ci-dessous.

Rétablissez tous les graphiques de apigee-virtualhost à apigee-datastore. Les commandes suivantes supposent que vous utilisez les graphiques de la version précédente (v1.15.x).

Exécutez la commande suivante pour chaque groupe d'environnements :

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

Exécutez la commande suivante pour chaque environnement :

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

Rétablissez les graphiques restants, à l'exception de 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

Créez l'espace de noms apigee-system.
```
kubectl create namespace apigee-system
```

Corrigez l'annotation de la ressource dans l'espace de noms apigee-system.

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

Si vous avez également modifié le nom de la version, mettez à jour l'annotation avec le nom de version operator.
```
kubectl annotate --overwrite clusterIssuer apigee-ca-issuer meta.helm.sh/release-name='operator'
```

Installez apigee-operator dans l'espace de noms apigee-system.

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

Rétablissez les CRD en réinstallant les anciens.

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

Nettoyez la version apigee-operator de l'espace de noms APIGEE_NAMESPACE pour terminer le processus de rétablissement.
```
helm uninstall operator -n APIGEE_NAMESPACE
```
Certaines ressources à l'échelle du cluster, telles que clusterIssuer, sont supprimées lorsque operator est désinstallé. Réinstallez-les à l'aide de la commande suivante :
```
helm upgrade operator apigee-operator/ \
  --install \
  --namespace apigee-system \
  --atomic \
  -f 1.15_OVERRIDES_FILE
```

Mettre à niveau Apigee hybrid vers la version 1.16 Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Modifications par rapport à Apigee hybrid v1.15

Prérequis

Avant de passer à la version 1.16.0 : limites et remarques importantes

Présentation de la mise à niveau vers la version 1.16.0

Préparer la mise à niveau vers la version 1.16

Sauvegarder votre installation hybrid

Linux

macOS

Windows

Mettre à niveau votre version de Kubernetes

Cliquer pour développer la liste des plates-formes compatibles

Versions compatibles

Composants

Versions non compatibles

Composants

Extrayez les graphiques Helm Apigee.

Modifier kustomization.yaml pour un espace de noms Apigee personnalisé

Configurer le compte de service apigee-guardrails

Secrets Kubernetes

Fichiers JSON

Vault

WIF pour GKE

WIF sur d'autres plates-formes

Secrets Kubernetes

Fichiers JSON

Vault

WIF pour GKE

WIF sur d'autres plates-formes

Modèle

Exemple

WIF : secrets

WIF : fichiers

WIF: Vault

Mettre à niveau cert-manager

Installer l'environnement d'exécution hybride 1.16.0

Effectuer un rollback vers la version précédente

Mettre à niveau Apigee hybrid vers la version 1.16

Modifier `kustomization.yaml` pour un espace de noms Apigee personnalisé

Configurer le compte de service `apigee-guardrails`