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

Mettre à niveau Apigee hybrid vers la version 1.13

Cette procédure concerne la mise à niveau d'Apigee hybrid de la version 1.12.x vers la version 1.13.4 et depuis les versions précédentes d'Apigee hybrid de la version 1.13.x vers la version 1.13.4.

Utilisez les mêmes procédures pour les mises à niveau de versions mineures (par exemple, de la version 1.12 vers la version 1.13) et pour les mises à niveau de versions de correctifs (par exemple, de la version 1.13.0 vers la version 1.13.4).

Si vous effectuez une mise à niveau à partir de la version 1.11 d'Apigee hybrid ou d'une version antérieure, vous devez d'abord passer à la version 1.12 avant de migrer vers la version 1.13.4. Consultez les instructions de mise à niveau d'Apigee hybrid vers la version 1.12.

Modifications par rapport à Apigee hybrid v1.12

Notez les modifications suivantes :

apigee-operator dans l'espace de noms Apigee : à partir de la version 1.13, apigee-operator s'exécute dans le même espace de noms Kubernetes que les autres composants Apigee hybrid, apigee par défaut. Vous pouvez attribuer n'importe quel nom à l'espace de noms. Dans les versions précédentes, le apigee-operator devait s'exécuter dans son propre espace de noms, apigee-system.
Anthos (sur bare metal ou VMware) est désormais Google Distributed Cloud (pour bare metal ou VMware) : pour en savoir plus, consultez les présentations des produits Google Distributed Cloud pour bare metal et Google Distributed Cloud pour VMware.
Contrôles plus stricts de l'instanciation de classe : à partir de la version 1.13.3 d'Apigee hybrid, la règle JavaCallout inclut désormais une sécurité supplémentaire lors de l'instanciation de classe Java. Cette mesure de sécurité renforcée empêche le déploiement de stratégies qui tentent directement ou indirectement d'effectuer des actions nécessitant des autorisations non autorisées.
Dans la plupart des cas, les règles existantes continueront de fonctionner comme prévu, sans aucun problème. Toutefois, il est possible que les règles reposant sur des bibliothèques tierces ou celles comportant du code personnalisé qui déclenche indirectement des opérations nécessitant des autorisations élevées soient affectées.

Important : Pour tester votre installation, suivez la procédure décrite dans Valider les règles après la mise à niveau vers la version 1.13.3 ou ultérieure afin de valider le comportement des règles.

Prérequis

Avant de passer à la version 1.13 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.12, vous devez passer à la version 1.12 avant de passer à la version 1.13. Consultez la page Mettre à niveau Apigee hybrid vers la version 1.12.
Helm version 3.14.2 ou ultérieure.
kubectl : version compatible de kubectl adaptée à votre version de la plate-forme Kubernetes. Consultez la section 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.13 ci-dessous.

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

La mise à niveau vers la version 1.13 d'Apigee hybrid peut nécessiter un temps d'arrêt.

Lors de la mise à niveau du contrôleur Apigee vers la version 1.13.4, 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 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 aient été 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.12 ne peut pas être utilisée pour restaurer une instance Hybrid 1.13.

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.13.4 de l'environnement d'exécution hybride.

Préparer la mise à niveau vers la version 1.13

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

Si vous utilisez des fichiers de certificat de service (.json) dans vos remplacements pour authentifier les comptes de service, assurez-vous que vos fichiers de certificat de compte de service se trouvent dans le répertoire de chart Helm approprié. Les charts Helm ne peuvent pas lire les fichiers en dehors de chaque répertoire de chart.

Cette étape n'est pas obligatoire si vous utilisez des secrets Kubernetes ou Workload Identity pour authentifier des comptes de service.

Le tableau suivant indique la destination de chaque fichier de compte de service, en fonction de votre type d'installation :

Prod

Compte de service	Nom de fichier par défaut	Répertoire du chart Helm
`apigee-cassandra`	`PROJECT_ID-apigee-cassandra.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-datastore/`
`apigee-logger`	`PROJECT_ID-apigee-logger.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-telemetry/`
`apigee-mart`	`PROJECT_ID-apigee-mart.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-org/`
`apigee-metrics`	`PROJECT_ID-apigee-metrics.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-telemetry/`
`apigee-runtime`	`PROJECT_ID-apigee-runtime.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-env`
`apigee-synchronizer`	`PROJECT_ID-apigee-synchronizer.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-env/`
`apigee-udca`	`PROJECT_ID-apigee-udca.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-org/`
`apigee-watcher`	`PROJECT_ID-apigee-watcher.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-org/`

Hors production

Créez une copie du fichier de compte de service apigee-non-prod dans chacun des répertoires suivants :

Compte de service	Nom de fichier par défaut	Répertoires du chart Helm
`apigee-non-prod`	`PROJECT_ID-apigee-non-prod.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-datastore/` `$APIGEE_HELM_CHARTS_HOME/apigee-telemetry/` `$APIGEE_HELM_CHARTS_HOME/apigee-org/` `$APIGEE_HELM_CHARTS_HOME/apigee-env/`

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.12 et 1.13 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

	1.10 ⁽²⁾	1.11	1.12	1.13
GKE sur Google Cloud	1.24.x 1.25.x 1.26.x 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	1.25.x 1.26.x 1.27.x 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	1.26.x 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)}	1.27.x 1.28.x 1.29.x 1.30.x
GKE sur AWS	1.13.x (K8s v1.24.x) 1.14.x (K8s v1.25.x) 1.26.x⁽⁴⁾ 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	1.14.x (K8s v1.25.x) 1.26.x⁽⁴⁾ 1.27.x 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	1.26.x⁽⁴⁾ 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)}	1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)} 1.30.x
GKE sur Azure	1.13.x 1.14.x 1.26.x⁽⁴⁾ 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	1.14.x 1.26.x⁽⁴⁾ 1.27.x 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	1.26.x⁽⁴⁾ 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)}	1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)} 1.30.x
Google Distributed Cloud (logiciel uniquement) sur VMware ⁽⁵⁾	1.13.x ⁽¹⁾ 1.14.x 1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	1.14.x 1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x⁽⁴⁾ 1.29.x^{(≥ 1.12.1)}	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.13.x ⁽¹⁾ 1.14.x (K8s v1.25.x) 1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.27.x⁽⁴⁾^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	1.14.x 1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x⁽⁴⁾^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x⁽⁴⁾ 1.29.x^{(≥ 1.12.1)}	1.16.x (K8s v1.27.x) 1.28.x⁽⁴⁾ 1.29.x 1.30.x
EKS	1.24.x 1.25.x 1.26.x 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	1.25.x 1.26.x 1.27.x 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	1.26.x 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)}	1.26.x 1.27.x 1.28.x 1.29.x
AKS	1.24.x 1.25.x 1.26.x 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	1.25.x 1.26.x 1.27.x 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	1.26.x 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)}	1.26.x 1.27.x 1.28.x 1.29.x
OpenShift	4.11 4.12 4.14^{(≥ 1.10.5)} 4.15^{(≥ 1.10.5)}	4.12 4.13 4.14 4.15^{(≥ 1.11.2)} 4.16^{(≥ 1.11.2)}	4.12 4.13 4.14 4.15 4.16^{(≥ 1.12.1)}	4.12 4.13 4.14 4.15 4.16
Rancher Kubernetes Engine (RKE)	v1.26.2+rke2r1 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	v1.26.2+rke2r1 v1.27.x 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	v1.26.2+rke2r1 v1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)}	v1.26.2+rke2r1 v1.27.x 1.28.x 1.29.x 1.30.x
VMware Tanzu	N/A	N/A	v1.26.x	v1.26.x
Composants	1.10	1.11	1.12	1.13
Cloud Service Mesh	1.17.x⁽³⁾	1.17.x^{(v1.11.0 - v1.11.1)}⁽³⁾ 1.18.x^{(≥ 1.11.2)}⁽³⁾	1.18.x⁽³⁾	1.19.x⁽³⁾
JDK	JDK 11	JDK 11	JDK 11	JDK 11
cert-manager	1.10.x 1.11.x 1.12.x	1.11.x 1.12.x 1.13.x	1.11.x 1.12.x 1.13.x	1.13.x 1.14.x 1.15.x
Cassandra	3.11	3.11	4.0	4.0
Kubernetes	1.24.x 1.25.x 1.26.x	1.25.x 1.26.x 1.27.x	1.26.x 1.27.x 1.28.x 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.14.2+
Pilote CSI Secret Store		1.3.4	1.4.1	1.4.1
Vault		1.13.x	1.15.2	1.15.2
⁽¹⁾ Sur la version 1.13 d'Anthos sur site (Google Distributed Cloud), suivez ces instructions pour éviter tout conflit avec `cert-manager` : Installation de cert-manager en conflit ⁽²⁾ Les dates de fin de vie officielles des versions 1.10 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. ⁽⁴⁾ Les numéros de version de GKE sur AWS reflètent désormais les versions de Kubernetes. Consultez la page Compatibilité des versions et des mises à niveau de GKE Enterprise pour obtenir des informations sur les versions et les correctifs recommandés. ⁽⁵⁾ 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.

Installer l'environnement d'exécution hybride 1.13.4

Préparer la mise à niveau des charts Helm

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.13.4
helm pull $CHART_REPO/apigee-operator --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-datastore --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-env --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-ingress-manager --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-org --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-redis --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-telemetry --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-virtualhost --version $CHART_VERSION --untar

Mettez à niveau cert-manager si nécessaire.
Si vous devez mettre à niveau votre version de cert-manager, installez la nouvelle version à l'aide de la commande suivante :
```
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.15.5/cert-manager.yaml
```
Consultez la page Plates-formes et versions prises en charge : cert-manager pour obtenir la liste des versions prises en charge.

Remarque : Certaines versions de cert-manager présentent un problème qui peut empêcher le serveur TLS du webhook de renouveler automatiquement son certificat CA. Pour éviter cela, Apigee recommande d'utiliser cert-manager version 1.15.5 ou ultérieure.
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

Migrez apigee-operator de l'espace de noms apigee-system vers APIGEE_NAMESPACE.
Remarque : Cette étape n'est requise que pour les mises à niveau à partir de la version 1.12.x. Si vous effectuez une mise à niveau à partir d'une version antérieure de 1.13, vous pouvez ignorer cette étape.
1. Annoter le fichier clusterIssuer avec le nouvel espace de noms
```
kubectl annotate --overwrite clusterIssuer apigee-ca-issuer meta.helm.sh/release-namespace='APIGEE_NAMESPACE'
```
2. Si vous modifiez le nom de version pour apigee-operator, annotez clusterIssuer avec le nouveau nom de version.
```
kubectl annotate --overwrite clusterIssuer apigee-ca-issuer meta.helm.sh/release-name='APIGEE_OPERATOR_RELEASE_NAME'
```
3. Remplacez les instances répliquées de votre déploiement d'Apigee Operator existant dans l'espace de noms apigee-system par 0 (zéro) pour éviter que les deux contrôleurs ne mettent à jour les ressources personnalisées.
```
kubectl scale deployment apigee-controller-manager -n apigee-system --replicas=0
```
4. Supprimez apigee-mutating-webhook-configuration et apigee-validating-webhook-configuration.
```
kubectl delete mutatingwebhookconfiguration apigee-mutating-webhook-configuration
kubectl delete validatingwebhookconfiguration apigee-validating-webhook-configuration
```
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.

Installer les charts Helm Apigee hybrid

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

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-org1-xxxxx          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 que la mise à jour en cours se termine, 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 Three big concepts class="external" 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.13.4.
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-org1-dev-xxx            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 que la mise à jour en cours se termine, 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-xxxxxx                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.
Remarque : Cette étape n'est requise que pour les mises à niveau à partir de la version 1.12.x. Si vous effectuez une mise à niveau à partir d'une version antérieure de 1.13, vous pouvez ignorer cette étape.
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 :
Remarque : Cette étape n'est requise que pour les mises à niveau à partir de la version 1.12.x. Si vous effectuez une mise à niveau à partir d'une version antérieure de 1.13, vous pouvez ignorer cette étape.
```
helm upgrade operator apigee-operator/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f overrides.yaml
```

Valider les règles après la mise à niveau vers la version 1.13.3 ou ultérieure

Utilisez cette procédure pour valider le comportement de la règle JavaCallout après la mise à niveau de la version 1.13.2 ou antérieure vers la version 1.13.3 ou ultérieure.

Vérifiez si les fichiers JAR Java demandent des autorisations inutiles.
Une fois la règle déployée, vérifiez les journaux d'exécution pour voir si le message de journal suivant est présent : "Failed to load and initialize class ...". Si ce message s'affiche, cela signifie que le fichier JAR déployé a demandé des autorisations inutiles. Pour résoudre ce problème, examinez le code Java et mettez à jour le fichier JAR.
Examinez et mettez à jour le code Java.
Examinez tout code Java (y compris les dépendances) pour identifier la cause des opérations potentiellement non autorisées. Si vous en trouvez, modifiez le code source comme il se doit.
Testez les règles avec le contrôle de sécurité activé.
Dans un environnement non destiné à la production, activez l'indicateur de vérification de la sécurité et redéployez vos règles avec un fichier JAR mis à jour. Pour définir l'indicateur :
- Dans le fichier apigee-env/values.yaml, définissez conf_security-secure.constructor.only sur true sous runtime:cwcAppend:. Exemple :
```
# Apigee Runtime
runtime:
  cwcAppend:
    conf_security-secure.constructor.only: true
```
- Mettez à jour le chart apigee-env de l'environnement pour appliquer la modification. Exemple :
```
helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set env=ENV_NAME \
  -f OVERRIDES_FILE
```
Si le message de journal "Failed to load and initialize class ..." est toujours présent, continuez à modifier et à tester le fichier JAR jusqu'à ce qu'il ne s'affiche plus.
Activez le contrôle de sécurité dans l'environnement de production.
Après avoir testé et vérifié minutieusement le fichier JAR dans l'environnement hors production, activez le contrôle de sécurité dans votre environnement de production en définissant l'indicateur conf_security-secure.constructor.only sur true et en mettant à jour le graphique apigee-env pour l'environnement de production afin d'appliquer la modification.

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 restaurez les CRD.

En raison de la modification de l'espace de noms pour apigee-operator, vous devez effectuer des étapes supplémentaires pour supprimer les hooks d'admission de validation et de mutation. Ainsi, lorsque vous réinstallerez apigee-operator dans l'espace de noms apigee-system, ils seront recréés pour pointer vers le bon point de terminaison de l'opérateur Apigee.

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.

Remplacez les instances répliquées du déploiement d'Apigee Operator existant dans Apigee par 0 (zéro) pour éviter que les deux contrôleurs ne mettent à jour les ressources personnalisées et ne provoquent des conflits lors du rollback dans l'espace de noms apigee-system.

kubectl scale deployment apigee-controller-manager -n APIGEE_NAMESPACE --replicas=0

kubectl delete mutatingwebhookconfiguration \
  apigee-mutating-webhook-configuration-APIGEE_NAMESPACE

kubectl delete validatingwebhookconfiguration \
  apigee-validating-webhook-configuration-APIGEE_NAMESPACE

Rétablis tous les graphiques de apigee-virtualhost à apigee-datastore. Les commandes suivantes supposent que vous utilisez les graphiques de la version précédente (v1.12.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.12_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.12_OVERRIDES_FILE

Rétablissez les graphiques restants, à l'exception de apigee-operator.

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

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

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

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

helm upgrade datastore apigee-datastore/ \
  --install \
  --namespace apigee \
  --atomic \
  -f 1.12_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 la 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.12_OVERRIDES_FILE

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

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 rollback.
```
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.12_OVERRIDES_FILE
```

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

Modifications par rapport à Apigee hybrid v1.12

Prérequis

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

Préparer la mise à niveau vers la version 1.13

Sauvegarder votre installation hybrid

Linux

macOS

Windows

Prod

Hors production

Mettre à niveau votre version de Kubernetes

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

Composants

Installer l'environnement d'exécution hybride 1.13.4

Préparer la mise à niveau des charts Helm

Installer les charts Helm Apigee hybrid

Valider les règles après la mise à niveau vers la version 1.13.3 ou ultérieure

Effectuer un rollback vers la version précédente

Mettre à niveau Apigee hybrid vers la version 1.13