Mettre à niveau Apigee hybrid vers la version 1.12

Version 1.12 (latest)

   Versions compatibles :

• v1.12 (la plus récente)                        
• v1.11                         
• v1.10                                        
• Liste des versions compatibles

   Versions non compatibles :

• v1.9                                         
• v1.8                                         
• v1.7                                         
• v1.6                                         
• v1.5                                         
• v1.4                                         
• v1.3                                         
• v1.2                                         
• v1.1                                         

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

Modifications par rapport à Apigee hybrid v1.11

La version 1.12 d'Apigee hybrid introduit les modifications suivantes qui ont une incidence sur le processus de mise à niveau. Pour obtenir la liste complète des fonctionnalités de la version 1.12, consultez les notes de version d'Apigee hybrid v1.12.0.

• Cassandra 4.x : à partir de la version 1.12, Apigee hybrid utilise Cassandra version 4 ou ultérieure.
  Important : En raison de la modification de la base de données, vous ne pouvez pas effectuer de rollback du composant apigee-datastore mis à niveau. Par conséquent, il est essentiel de sauvegarder votre base de données Cassandra et votre installation hybride avant de procéder à la mise à niveau. Si vous devez effectuer un rollback de la mise à niveau, envisagez les scénarios suivants :

  • Cassandra n'a pas encore été mis à jour : vous pouvez effectuer un rollback de toutes les modifications.
  • Cassandra a été mis à niveau et tous les pods Cassandra sont opérationnels : vous pouvez effectuer un rollback des modifications sur tous les composants, à l'exception de apigee-datastore. Votre installation v1.11.x continuera de fonctionner avec une instance v1.12 de votre apigee-datastore qui exécute Cassandra v4.
  • Cassandra mis à niveau et les pods Cassandra ne sont pas opérationnels : vous devez désinstaller la version hybride 1.12 et restaurer l'installation de la version 11 à partir d'une sauvegarde.
• Abandon de apigeectl : À partir de la version 1.12, Apigee hybrid n'est compatible qu'avec Helm pour l'installation et la gestion de votre installation hybride.
  Attention : apigeectl est obsolète depuis le 17 avril 2024. L'outil apigeectl n'est pas compatible avec Apigee hybrid v1.12. Apigee hybrid v1.10 et v1.11 ne sera plus compatible avec apigeectl à partir du 17 avril 2025. Pour en savoir plus, consultez la page Abandon d'apigeectl.
  Important : Si vous gérez la version 1.11 avec apigeectl, vous devez d'abord migrer votre installation de la version 1.11 pour utiliser Helm avant de passer à la version 1.12. Suivez les instructions de la section Migrer des graphiques Apigee hybrid vers Helm depuis apigeectl.

• Une nouvelle suite de métriques pour surveiller les proxys Apigee et les points de terminaison cibles est désormais disponible. Pour Apigee hybrid v1.12, les ressources surveillées ProxyV2 et TargetV2 ne seront plus utilisées par défaut. Toutes les métriques de proxy et de cible seront publiées dans les ressources surveillées Proxy et Target.

  Pour continuer à émettre des métriques vers les ressources surveillées ProxyV2 et TargetV2, définissez metrics.disablePrometheusPipeline sur true dans overrides.yaml.

  Si vous avez configuré des alertes basées sur les métriques, vérifiez l'utilisation des métriques appropriées pour votre installation hybride. Pour en savoir plus, consultez la page Alertes basées sur des métriques.

Éléments à prendre en compte avant de lancer une mise à niveau vers la version 1.12

La mise à niveau de la version 1.11 d'Apigee hybrid vers la version 1.12 inclut une mise à niveau de la base de données Cassandra de la version 3.11.x vers la version 4.x. Bien que la mise à niveau de Cassandra soit gérée dans le cadre de la procédure de mise à niveau d'Apigee hybrid, veuillez prendre en compte les éléments suivants :

• La mise à niveau de la version Cassandra s'effectue en arrière-plan et se déroule sur un pod (ou un nœud Cassandra) à la fois. Il est donc recommandé de réduire la capacité de la base de données pendant la mise à niveau.
• Effectuez le scaling de votre capacité Cassandra et assurez-vous que l'utilisation du disque est proche ou inférieure à 50 % avant de commencer la mise à niveau.
• Validez et testez vos procédures de sauvegarde et de restauration Cassandra.
• Sauvegardez les données Cassandra dans votre installation d'Apigee hybrid version 1.11 avant de commencer la mise à niveau et la validation de vos sauvegardes.
• La mise à niveau de apigee-datastore entraînera une augmentation temporaire de la consommation du processeur en raison des tâches post-mise à niveau effectuées par Cassandra.
• Une fois que vous avez mis à niveau le composant apigee-datastore (Cassandra), vous ne pouvez pas revenir à la version précédente. Il existe deux scénarios pour effectuer un rollback d'une mise à niveau vers la version 1.12 hybride après la mise à niveau du composant apigee-datastore :
  • Si le composant apigee-datastore est dans un bon état, mais que d'autres composants nécessitent un rollback, vous pouvez effectuer un rollback de ces autres composants individuellement.
    Remarque : Vous ne pourrez pas ajouter de régions ni effectuer le scaling des nœuds Cassandra lors de l'exécution de composants de différentes versions hybrides.
  • Si l'état du composant apigee-datastore est incorrect, vous devez effectuer une restauration à partir d'une sauvegarde v1.11 vers une installation v1.11.
    Remarque : Vous ne pouvez pas combiner les versions lors de la restauration. Vous devez restaurer une sauvegarde d'une installation v1.11 dans une installation v1.11.

Éléments à prendre en compte avant de mettre à niveau une installation régionale

Si vous devez effectuer un rollback vers une version précédente d'Apigee hybrid, le processus peut nécessiter un temps d'arrêt. Par conséquent, si vous mettez à niveau une installation régionale, vous pouvez créer une deuxième région, puis ne mettre à niveau qu'une seule région à la fois dans l'ordre suivant :

1. Ajoutez une deuxième région à votre installation existante en utilisant la même version hybride. Consultez la page Déploiement multirégional dans la documentation de la version 1.11.
2. Sauvegardez et validez les données de la première région avant de lancer une mise à niveau. Consultez la page Présentation de la sauvegarde Cassandra dans la documentation de la version 1.11.
3. Mettez à niveau la région nouvellement ajoutée vers Apigee hybrid 1.12.
4. Basculez le trafic vers la nouvelle région et validez le trafic.
5. Une fois validé, mettez à niveau l'ancienne région vers Apigee hybrid 1.12.
6. Basculez tout le trafic vers l'ancienne région et validez le trafic.
7. Désactivez la nouvelle région.

Éléments à prendre en compte avant de mettre à niveau une installation multirégionale

Apigee recommande la séquence suivante pour mettre à niveau une installation multirégionale :

1. Sauvegardez et validez les données de chaque région avant de commencer la mise à niveau.
2. Mettez à niveau la version hybride dans une région et assurez-vous que tous les pods sont en cours d'exécution pour valider la mise à niveau.
3. Validez le trafic dans la région qui vient d'être mise à jour.
4. Mettez à niveau chaque région suivante, uniquement après avoir validé le trafic sur la région précédente.
5. Dans le cas où vous auriez besoin d'effectuer un rollback d'une mise à niveau dans un déploiement multirégional, préparez-vous à transférer le trafic hors des régions défaillantes, envisagez d'ajouter suffisamment de capacité dans la région où le trafic sera redirigé pour gérer le trafic des deux régions.

Prérequis

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

• Une installation Apigee hybrid version 1.11 gérée avec Helm.
  • Si vous gérez votre installation hybride avec apigeectl, vous devez d'abord migrer vos clusters vers la gestion Helm. Consultez la page Migrer Apigee hybrid vers Helm depuis apigeectl dans la documentation d'Apigee hybrid v1.11.
  • Si votre installation hybride exécute une version antérieure à la version 1.11, vous devez passer à la version 1.11 avant de passer à la version 1.12. Consultez la page Mettre à niveau Apigee hybrid vers la version 1.11.
• Helm version 3.10 ou ultérieure.
• kubectl version 1.27, 1.28 ou 1.29 (recommandée).
• Cert-manager version 1.13.0. Si nécessaire, vous mettrez à niveau cert-manager dans la section Préparer la mise à niveau vers la version ci-dessous.

Limites

Tenez compte des limites suivantes lorsque vous planifiez votre mise à niveau d'Apigee hybrid de la version 1.11 vers la version 1.12. La planification peut vous aider à réduire le besoin de temps d'arrêt si vous devez effectuer un rollback ou effectuer une restauration après la mise à niveau.

• Les sauvegardes d'Apigee hybrid 1.12 ne peuvent pas être restaurées dans la version 1.11 et inversement, en raison d'une incompatibilité entre les deux versions.
• Vous ne pouvez pas effectuer de scaling des pods du datastore pendant la mise à niveau vers la version 1.12. Répondez à vos besoins de scaling dans toutes les régions avant de commencer à mettre à niveau votre installation hybride.
• Dans une installation hybride à une seule région, vous ne pouvez pas effectuer de rollback du composant du datastore une fois le processus de mise à niveau du datastore terminé. Vous ne pouvez pas effectuer de rollback d'un datastore Cassandra 4.x vers un datastore Cassandra 3.x. Pour cela, vous devrez effectuer une restauration à partir de votre sauvegarde la plus récente des données Cassandra 3.x (depuis votre installation d'Apigee hybrid version 1.11).
• Il n'est pas possible de supprimer ou d'ajouter une région pendant la mise à niveau. Dans une mise à niveau multirégionale, vous devez effectuer la mise à niveau de toutes les régions avant de pouvoir ajouter ou supprimer des régions.

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

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

Lors de la mise à niveau du contrôleur Apigee vers la version 1.12.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 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. Les opérations suivantes seront toutefois affectées, 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.11 ne peut pas être utilisée pour restaurer une instance Hybrid 1.12.
• Le flux de données Cassandra ne fonctionnera pas entre les versions hybrides mixtes. Par conséquent, vos clusters Cassandra ne peuvent pas subir de scaling horizontal.
• L'extension de région et la mise hors service seront affectées, car ces opérations dépendent du flux de données Cassandra.

Remarque : Les modifications du plan de gestion n'ont pas besoin d'être suspendues lors d'une mise à niveau. Les suspensions requises pour les modifications du plan de gestion sont incluses dans les instructions de mise à niveau.

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

1. Préparez la mise à niveau.
   • Créez une sauvegarde Cassandra.
   • Créez une sauvegarde de vos répertoires d'installation Hybrid.
2. Installez la version 1.12.0 de l'environnement d'exécution Hybrid.

Préparer la mise à niveau vers la version 1.12

Créer une sauvegarde de Cassandra

• Sauvegardez votre base de données Cassandra dans toutes les régions applicables et validez les données de votre installation d'Apigee hybrid version 1.11 avant de commencer la mise à niveau. Consultez la page Surveiller les sauvegardes dans la documentation de la version 1.11.
• Redémarrez tous les pods Cassandra du cluster avant de lancer le processus de mise à niveau, afin que tout problème persistant puisse se manifester.

  Pour redémarrer et tester les pods Cassandra, supprimez chaque pod individuellement, un pod à la fois, puis vérifiez qu'il est à nouveau en cours d'exécution et que la vérification d'aptitude réussit :

  1. Répertoriez les pods Cassandra :

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

     Par exemple :

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

  2. Supprimez un pod :

     kubectl delete pod -n APIGEE_NAMESPACE CASSANDRA_POD_NAME

     Par exemple :

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

  3. Vérifiez l'état en répertoriant à nouveau les pods Cassandra :

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

     Par exemple :

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

• Appliquez à nouveau le dernier fichier de remplacement connu pour vous assurer qu'aucune modification n'y a été apportée afin de pouvoir utiliser la même configuration pour passer à la version 1.12 d'Apigee hybrid.
• Assurez-vous que tous les nœuds Cassandra de toutes les régions sont à l'état UN (Up/Normal). Si un nœud Cassandra est dans un état différent, solutionnez le problème avant de commencer la mise à niveau.

  Vous pouvez valider l'état de vos nœuds Cassandra à l'aide des commandes suivantes :

  1. Répertoriez les pods Cassandra :

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

     Par exemple :

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

  2. Vérifiez l'état des nœuds de chaque pod Cassandra à l'aide de la commande kubectl nodetool status :

     kubectl -n APIGEE_NAMESPACE exec -it CASSANDRA_POD_NAME nodetool status

     Par exemple :

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

Sauvegarder vos répertoires d'installation hybrides

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

2. Créez une copie de sauvegarde de votre répertoire $APIGEE_HELM_CHARTS_HOME/ version 1.11. 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.11-backup.tar.gz $APIGEE_HELM_CHARTS_HOME

3. Sauvegardez votre base de données Cassandra en suivant les instructions figurant sur la page Sauvegarde et récupération de Cassandra.
4. 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/

5. 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.11 et 1.12 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.9 ^(3)	1.10	1.11	1.12
Anthos (Google Cloud – GKE)	1.23.x 1.24.x 1.25.x 1.26.x ^(≥ 1.9.2)	1.24.x 1.25.x 1.26.x	1.25.x 1.26.x 1.27.x	1.26.x 1.27.x 1.28.x
Anthos (AWS)	1.12.x 1.13.x (K8s v1.24.x) 1.14.x (K8s v1.25.x)	1.13.x (K8s v1.24.x) 1.14.x (K8s v1.25.x) 1.26.x^(13)	1.14.x (K8s v1.25.x) 1.26.x^(13) 1.27.x	1.26.x^(13) 1.27.x 1.28.x
Anthos (Azure)	1.12.x 1.13.x 1.14.x	1.13.x 1.14.x 1.26.x^(13)	1.14.x 1.26.x^(13) 1.27.x	1.26.x^(13) 1.27.x 1.28.x
Anthos (sur site - VMware) ^(1) ^(14)	1.12.x ^(4) 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.14.x 1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x)	1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x^(13)
Anthos (Bare Metal)^(1)	1.12.x ^(4) 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.14.x 1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x)	1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x^(13)
EKS^(7)	1.23.x 1.24.x 1.25.x 1.26.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
AKS^(7)	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.25.x 1.26.x 1.27.x	1.26.x 1.27.x 1.28.x
OpenShift^(7)	4.10 4.11	4.11 4.12	4.12 4.13 4.14	4.12 4.13 4.14 4.15
Rancher Kubernetes Engine (RKE)^(7)	1.3.8	v1.26.2+rke2r1	v1.26.2+rke2r1 v1.27.x	v1.26.2+rke2r1 v1.27.x v1.28.x
Composants	1.9 ^(3)	1.10	1.11	1.12
Anthos Service Mesh (ASM)	1.17.x^(11)	1.17.x^(11)	1.18.x^(11)	1.19.x^(11)
JDK	JDK 11	JDK 11	JDK 11	JDK 11
cert-manager	1.10.x 1.11.x	1.10.x 1.11.x 1.12.x	1.11.x 1.12.x 1.13.x	1.11.x 1.12.x 1.13.x
Cassandra	3.11	3.11	3.11	4.0
Kubernetes	1.23.x 1.24.x 1.25.x	1.24.x 1.25.x 1.26.x	1.25.x 1.26.x 1.27.x	1.26.x 1.27.x 1.28.x
kubectl				1.27.x 1.28.x 1.29.x
Helm		3.10+	3.10+	3.14.2+
Pilote CSI Secret Store			1.3.4	1.4.1
Vault			1.13.x	1.15.2
^(1) Sur les versions Anthos 1.8, 1.9 et 1.10, suivez les instructions de ces documents pour éviter tout conflit avec cert-manager : Anthos 1.8.2+ : conflit avec cert-manager lors de la mise à niveau vers la version 1.8.2 ou ultérieure. Anthos 1.9 : conflit avec cert-manager lors de la mise à niveau vers la version 1.9.0 ou 1.9.1. Anthos 1.10+ : installation de cert-manager en conflit. ^(2) Compatibilité avec Apigee hybrid version 1.7.2 et ultérieure. ^(3) Les dates de fin de vie officielles des versions 1.8 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. ^(4) Anthos sur bare metal et VMWare versions 1.12 et antérieures ne sont plus compatibles. Consultez les règles de compatibilité des versions d'Anthos sur bare metal et les versions des clusters Anthos sur VMware. ^(5) Anthos sur bare metal et VMWare nécessitent ASM 1.14 ou une version ultérieure. Nous vous recommandons de passer à la version 1.8 d'Apigee hybrid et de passer à la passerelle d'entrée Apigee, qui ne vous oblige plus à installer ASM sur votre cluster hybride. ^(6) Compatibilité avec Apigee hybrid version 1.8.4 et ultérieure. ^(7) Les clusters associés ne sont pas requis pour Apigee hybrid versions 1.8 et ultérieures utilisant la passerelle d'entrée Apigee. ^(8) Non compatible avec Apigee hybrid 1.8.4 et versions ultérieures. ^(9) Compatibilité avec Apigee hybrid version 1.7.6 et ultérieure. ^(10) Non compatible avec Apigee hybrid 1.8.5 et versions ultérieures. ^(11) ASM est automatiquement installé avec Apigee hybrid 1.9 et les versions ultérieures. ^(12) Compatibilité avec Apigee hybrid version 1.9.2 et ultérieure. ^(13) Les numéros de version des clusters Anthos sur AWS (multicloud) reflètent désormais les versions de Kubernetes. Consultez la page Compatibilité des versions et des mises à niveau d'Anthos pour obtenir des informations sur les versions et les correctifs recommandés. ^(14) Vault n'est pas certifié sur Anthos (sur site – VMware).

À propos des clusters associés

Pour les versions 1.7.x et antérieures d'Apigee hybrid, vous devez utiliser des clusters associés à Anthos si vous souhaitez exécuter Apigee hybrid dans un contexte multicloud sur Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS) ou un autre fournisseur de services Kubernetes tiers compatible. Le rattachement de cluster permet à Google de mesurer l'utilisation d'Anthos Service Mesh (ASM). L'enregistrement du cluster tiers est facultatif. Vous ne devez procéder à l'enregistrement que si vous souhaitez afficher le cluster associé dans la console Google Cloud. Pour plus d'informations, consultez la section Associer des clusters Kubernetes tiers à Google Cloud.

Pour les versions 1.8.x d'Apigee hybrid, les clusters associés à Anthos sont requis si vous utilisez Anthos Service Mesh pour votre passerelle d'entrée. Si vous utilisez une passerelle d'entrée Apigee, les clusters associés à Anthos sont facultatifs.

Remarque : Les installations hybrides ne sont actuellement pas compatibles avec GKE Autopilot.

Installer l'environnement d'exécution hybride 1.12.0

Attention : Ne créez pas d'environnements pendant le processus de mise à niveau.

Préparer la mise à niveau des charts Helm

Cette procédure de mise à niveau suppose que vous utilisez le même espace de noms et les mêmes comptes de service pour l'installation mise à niveau. Si vous apportez des modifications de configuration, veillez à refléter ces modifications dans votre fichier de remplacement avant d'installer les charts Helm.

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

2. 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.13.0/cert-manager.yaml
   

3. Installez les CRD Apigee mises à jour :
   Remarque : À partir de cette étape, toutes les commandes doivent être exécutées dans le répertoire racine du dépôt de graphique.
   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.
   Remarque : Cette étape nécessite des autorisations de cluster élevées.

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

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

   3. 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                    2023-10-09T14:48:30Z
      apigeedeployments.apigee.cloud.google.com                   2023-10-09T14:48:30Z
      apigeeenvironments.apigee.cloud.google.com                  2023-10-09T14:48:31Z
      apigeeissues.apigee.cloud.google.com                        2023-10-09T14:48:31Z
      apigeeorganizations.apigee.cloud.google.com                 2023-10-09T14:48:32Z
      apigeeredis.apigee.cloud.google.com                         2023-10-09T14:48:33Z
      apigeerouteconfigs.apigee.cloud.google.com                  2023-10-09T14:48:33Z
      apigeeroutes.apigee.cloud.google.com                        2023-10-09T14:48:33Z
      apigeetelemetries.apigee.cloud.google.com                   2023-10-09T14:48:34Z
      cassandradatareplications.apigee.cloud.google.com           2023-10-09T14:48:35Z
      

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

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

   Simulation :

   helm upgrade operator apigee-operator/ \
     --install \
     --create-namespace \
     --namespace apigee-system \
     -f OVERRIDES_FILE \
     --dry-run
   

   Mettez à niveau le graphique :

   helm upgrade operator apigee-operator/ \
     --install \
     --create-namespace \
     --namespace apigee-system \
     -f OVERRIDES_FILE
   

   Remarque : Pour les installations migrées, utilisez :

   helm upgrade operator apigee-operator/ \
     --install \
     --create-namespace \
     --namespace apigee-system \
     --force \
     -f OVERRIDES_FILE
   

   Vérifiez l'installation de l'opérateur Apigee :

   helm ls -n apigee-system
   

   NAME       NAMESPACE       REVISION   UPDATED                                STATUS     CHART                   APP VERSION
   operator   apigee-system   3          2023-06-26 00:42:44.492009 -0800 PST   deployed   apigee-operator-1.12.0   1.12.0
   

   Vérifiez qu'il est opérationnel en vérifiant sa disponibilité :

   kubectl -n apigee-system get deploy apigee-controller-manager
   

   NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
   apigee-controller-manager   1/1     1            1           7d20h
   

3. Mettez à niveau le datastore Apigee :

   Simulation :

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

   Mettez à niveau le graphique :

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

   Remarque : Pour les installations migrées, utilisez :

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

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

   kubectl -n apigee get apigeedatastore default
   

   NAME      STATE       AGE
   default   running    2d
   

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

   Simulation :

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

   Mettez à niveau le graphique :

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

   Remarque : Pour les installations migrées, utilisez :

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

   Vérifiez qu'il est opérationnel en vérifiant son état :

   kubectl -n apigee get apigeetelemetry apigee-telemetry
   

   NAME               STATE     AGE
   apigee-telemetry   running   2d
   

5. Mettez à niveau Apigee Redis :

   Simulation :

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

   Mettez à niveau le graphique :

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

   Remarque : Pour les installations migrées, utilisez :

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

   Vérifiez qu'il est opérationnel en vérifiant son état :

   kubectl -n apigee get apigeeredis default
   

   NAME      STATE     AGE
   default   running   2d
   

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

   Mettez à niveau le graphique :

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

   Remarque : Pour les installations migrées, utilisez :

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

   Vérifiez qu'il est opérationnel en vérifiant sa disponibilité :

   kubectl -n apigee get deployment apigee-ingressgateway-manager
   

   NAME                            READY   UP-TO-DATE   AVAILABLE   AGE
   apigee-ingressgateway-manager   2/2     2            2           2d
   

7. Mettez à niveau l'organisation Apigee :

   Simulation :

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

   Mettez à niveau le graphique :

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

   Remarque : Pour les installations migrées, utilisez :

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

   Vérifiez qu'elle est opérationnelle en vérifiant l'état de l'organisation correspondante :

   kubectl -n apigee get apigeeorg
   

   NAME                      STATE     AGE
   apigee-org1-xxxxx          running   2d
   

8. Mettez à niveau l'environnement.

   Vous devez installer un environnement à la fois. Spécifiez l'environnement avec --set env=ENV_NAME :

   Simulation :

   helm upgrade ENV_RELEASE_NAME apigee-env/ \
     --install \
     --namespace APIGEE_NAMESPACE \
     --set env=ENV_NAME \
     -f OVERRIDES_FILE \
     --dry-run
   

   • ENV_RELEASE_NAME est le nom avec lequel vous avez déjà installé le graphique apigee-env. Dans la version 1.10 d'Apigee hybrid, il s'agit généralement de apigee-env-ENV_NAME. Dans Apigee hybrid v1.11 et versions ultérieures, il s'agit généralement de ENV_NAME.
   • ENV_NAME est le nom de l'environnement que vous mettez à niveau.
   • OVERRIDES_FILE est votre nouveau fichier de remplacement pour la version 1.12.0.

   Mettez à niveau le graphique :

   helm upgrade ENV_RELEASE_NAME apigee-env/ \
     --install \
     --namespace APIGEE_NAMESPACE \
     --set env=ENV_NAME \
     -f OVERRIDES_FILE
   

   Remarque : Pour les installations migrées, utilisez :

   helm upgrade ENV_RELEASE_NAME apigee-env/ \
     --install \
     --namespace APIGEE_NAMESPACE \
     --set env=ENV_NAME \
     --force \
     -f OVERRIDES_FILE
   

   Vérifiez qu'il est opérationnel en vérifiant l'état de l'environnement correspondant :

   kubectl -n apigee get apigeeenv
   

   NAME                          STATE       AGE   GATEWAYTYPE
   apigee-org1-dev-xxx            running     2d
   

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

      Simulation :

      helm upgrade ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
        --install \
        --namespace APIGEE_NAMESPACE \
        --set envgroup=ENV_GROUP_NAME \
        -f OVERRIDES_FILE \
        --dry-run
      

      ENV_GROUP_RELEASE_NAME est le nom avec lequel vous avez déjà installé le graphique apigee-virtualhost. Dans la version 1.10 d'Apigee hybrid, il s'agit généralement de apigee-virtualhost-ENV_GROUP_NAME. Dans Apigee hybrid v1.11 et versions ultérieures, 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 : Pour les installations migrées, utilisez :

      helm upgrade ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
        --install \
        --namespace APIGEE_NAMESPACE \
        --set envgroup=ENV_GROUP_NAME \
        --force \
        -f OVERRIDES_FILE
      

      Remarque : ENV_GROUP_NAME doit être unique dans l'espace de noms apigee. Par exemple, si vous disposez d'un environnement et d'un groupe d'environnements prod, vous devez définir ce nom sur prod-envgroup. Le nom du groupe d'environnements ultérieur doit toujours être prod.
   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 get arc
      

      NAME                                STATE   AGE
      apigee-org1-dev-egroup                       2d
      

      kubectl -n apigee get ar
      

      NAME                                        STATE     AGE
      apigee-org1-dev-egroup-xxxxxx                running   2d
      

Félicitations ! Vous êtes passé à la version 1.12.0 d'Apigee hybrid. Pour tester votre mise à niveau, appelez un proxy sur la nouvelle installation. Pour obtenir un exemple, reportez-vous à l'Étape 10 : Déployer un proxy d'API dans le guide d'installation d'Apigee hybrid 1.12.

Effectuer un rollback vers la version précédente

Cette section est divisée en sections correspondant à l'état de votre composant apigee-datastore après la mise à niveau vers la version 1.12 d'Apigee hybrid. Il existe des procédures permettant de procéder à un rollback dans une ou plusieurs régions avec le composant apigee-datastore dans un état correct, ainsi que des procédures de récupération ou de restauration à partir d'une sauvegarde lorsque l'état de apigee-datastore est incorrect.

Rollback et récupération dans une seule région

Effectuer un rollback lorsque l'état de apigee-datastore est correct

Cette procédure explique comment effectuer un rollback de chaque composant Apigee hybrid de la version 1.12 vers la version 1.11 (à l'exception de apigee-datastore). Le composant apigee-datastore v1.12 est rétrocompatible avec les composants Apigee hybrid v1.11.

Avertissement : Le rollback de apigee-datastore n'est pas possible. L'incompatibilité des données entre différentes versions de la base de données Cassandra empêche le rollback vers la version précédente.

Pour effectuer un rollback vers la version 1.11 dans une installation à une seule région :

1. Avant de lancer le rollback, vérifiez que tous les pods sont en cours d'exécution :

   kubectl get pods -n APIGEE_NAMESPACE

   kubectl get pods -n apigee-system

2. Validez le lancement des composants à l'aide de Helm :

   helm -n APIGEE_NAMESPACE list

   helm -n apigee-system list

   Exemple :

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

3. Effectuez le rollback de chaque composant (sauf apigee-datastore) à l'aide des commandes suivantes :
   1. Créez la variable d'environnement suivante :
      • PREVIOUS_HELM_CHARTS_HOME : Répertoire dans lequel les graphiques Helm Apigee hybrid précédents sont installés. Il s'agit de la version vers laquelle vous effectuez le rollback.
   2. Effectuer un rollback des hôtes virtuels. Répétez la commande suivante pour chaque groupe d'environnements mentionné dans le fichier de remplacement.

      helm upgrade ENV_GROUP_RELEASE_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-virtualhost/ \
        --namespace APIGEE_NAMESPACE \
        --atomic \
        --set envgroup=ENV_GROUP_NAME \
        -f PREVIOUS_OVERRIDES_FILE
      

      ENV_GROUP_RELEASE_NAME est le nom avec lequel vous avez déjà installé le graphique apigee-virtualhost. Dans la version 1.10 d'Apigee hybrid, il s'agit généralement de apigee-virtualhost-ENV_GROUP_NAME. Dans Apigee hybrid v1.11 et versions ultérieures, il s'agit généralement de ENV_GROUP_NAME.

   3. Effectuer un rollback des environnements Répétez la commande suivante pour chaque environnement mentionné dans le fichier de remplacement.

      helm upgrade apigee-env-ENV_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-env/ \
        --install \
        --namespace APIGEE_NAMESPACE \
        --atomic \
        --set env=ENV_NAME \
        -f PREVIOUS_OVERRIDES_FILE
      

      ENV_RELEASE_NAME est le nom avec lequel vous avez déjà installé le graphique apigee-env. Dans la version 1.10 d'Apigee hybrid, il s'agit généralement de apigee-env-ENV_NAME. Dans Apigee hybrid v1.11 et versions ultérieures, il s'agit généralement de ENV_NAME.

      Vérifiez qu'il est opérationnel en vérifiant l'état de l'environnement correspondant :

      kubectl -n apigee get apigeeenv
      

      NAME                  STATE     AGE   GATEWAYTYPE
      apigee-org1-dev-xxx   running   2d
      

   4. Effectuez un rollback de l'organisation :

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

      Vérifiez qu'elle est opérationnelle en vérifiant l'état de l'organisation correspondante :

      kubectl -n apigee get apigeeorg
      

      NAME                STATE     AGE
      apigee-org1-xxxxx   running   2d
      

   5. Effectuez un rollback du gestionnaire d'entrée :

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

      Vérifiez qu'il est opérationnel en vérifiant sa disponibilité :

      kubectl -n apigee get deployment apigee-ingressgateway-manager
      

      NAME                            READY   UP-TO-DATE   AVAILABLE   AGE
      apigee-ingressgateway-manager   2/2     2            2           2d
      

   6. Effectuez un rollback de Redis :

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

      Vérifiez qu'il est opérationnel en vérifiant son état :

      kubectl -n apigee get apigeeredis default
      

      NAME      STATE     AGE
      default   running   2d
      

   7. Effectuez un rollback d'Apigee Telemetry :

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

      Vérifiez qu'il est opérationnel en vérifiant son état :

      kubectl -n apigee get apigeetelemetry apigee-telemetry
      

      NAME               STATE     AGE
      apigee-telemetry   running   2d
      

   8. Effectuez un rollback du contrôleur Apigee :

      helm upgrade operator $PREVIOUS_HELM_CHARTS_HOME/apigee-operator/ \
        --install \
        --namespace apigee-system \
        --atomic \
        -f PREVIOUS_OVERRIDES_FILE

      Vérifiez l'installation de l'opérateur Apigee :

      helm ls -n apigee-system
      

      NAME       NAMESPACE       REVISION   UPDATED                                STATUS     CHART                   APP VERSION
      operator   apigee-system   3          2023-06-26 00:42:44.492009 -0800 PST   deployed   apigee-operator-1.12.0   1.12.0
      

      Vérifiez qu'il est opérationnel en vérifiant sa disponibilité :

      kubectl -n apigee-system get deploy apigee-controller-manager
      

      NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
      apigee-controller-manager   1/1     1            1           7d20h
      

   9. Effectuez un rollback des CRD Apigee hybrid :

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

4. Vérifiez que tous les pods sont en cours d'exécution ou terminés :

   kubectl get pods -n APIGEE_NAMESPACE

   kubectl get pods -n apigee-system

5. Validez la version de tous les composants. Tous les composants doivent exécuter la version précédente, à l'exception du datastore :

   helm -n APIGEE_NAMESPACE list

   helm -n apigee-system list

   Exemple :

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

Restaurer lorsque l'état apigee-datastore n'est pas correct

Si la mise à niveau du composant apigee-datastore a échoué, vous ne pouvez pas effectuer un rollback de apigee-datastore de la version 1.12 vers la version 1.11. Au lieu de cela, vous devez effectuer une restauration à partir d'une sauvegarde effectuée à partir d'une installation v1.11. Utilisez la séquence suivante pour restaurer votre version précédente.

1. Si vous n'avez pas d'installation active de la version 1.11 d'Apigee hybrid (par exemple dans une autre région), créez une installation de la version 1.11 à l'aide de vos graphiques et fichiers de remplacement sauvegardés. Consultez les instructions d'installation de la version 1.11 d'Apigee hybrid.
2. Restaurez la région v1.11 (ou la nouvelle installation) à partir de votre sauvegarde en suivant les instructions des sections suivantes :
   • Sauvegardes Cloud Storage Interface (CSI) : sauvegarde et restauration CSI Cassandra.
   • Sauvegardes non-CSI : restauration dans une seule région.
3. Vérifier le trafic vers l'installation restaurée
4. Facultatif : Supprimez l'installation de la version 1.12 en suivant les instructions de la section Désinstaller l'environnement d'exécution hybride.

Rollback et récupération dans des environnements multirégionaux

Effectuer un rollback lorsque l'état de apigee-datastore est correct

Remarque : Utilisez cette méthode de rollback pour effectuer un rollback depuis une région hybride mise à niveau vers la version hybride précédente. Cette méthode est destinée à récupérer d'une mise à niveau ayant échoué lorsque toutes les régions n'ont pas encore été mises à niveau.

Cette procédure explique comment effectuer un rollback de chaque composant Apigee hybrid de la version 1.12 vers la version 1.11 (à l'exception de apigee-datastore). Le composant apigee-datastore v1.12 est rétrocompatible avec les composants Apigee hybrid v1.11.

1. Avant de lancer le rollback, vérifiez que tous les pods sont en cours d'exécution :

   kubectl get pods -n APIGEE_NAMESPACE

   kubectl get pods -n apigee-system

2. Assurez-vous que tous les nœuds Cassandra de toutes les régions sont à l'état UN (Up/Normal). Si un nœud Cassandra est dans un état différent, solutionnez le problème avant de lancer le processus de mise à niveau.

   Vous pouvez valider l'état de vos nœuds Cassandra à l'aide des commandes suivantes :

   1. Répertoriez les pods Cassandra :

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

      Par exemple :

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

   2. Vérifiez l'état des nœuds de chaque pod Cassandra à l'aide de la commande kubectl nodetool status :

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

      Par exemple :

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

   Si tous les pods Cassandra ne sont pas à l'état UN, suivez les instructions de la section Supprimer les nœuds "DOWN" du cluster Cassandra.

3. Accédez au répertoire dans lequel les graphiques Helm Apigee hybrid précédents sont installés.
4. Remplacez le contexte par la région qui a été mise à niveau.

   kubectl config use-context UPGRADED_REGION_CONTEXT
       

5. Vérifiez que tous les pods sont en cours d'exécution :

   kubectl get pods -n APIGEE_NAMESPACE

   kubectl get pods -n apigee-system

6. Utilisez la commande Helm pour vous assurer que toutes les versions ont été mises à niveau vers Apigee hybrid v1.12 :

   helm -n APIGEE_NAMESPACE list

   helm -n apigee-system list

   Exemple :

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

7. Effectuez le rollback de chaque composant (sauf apigee-datastore) à l'aide des commandes suivantes :
   1. Créez la variable d'environnement suivante :
      • PREVIOUS_HELM_CHARTS_HOME : Répertoire dans lequel les graphiques Helm Apigee hybrid précédents sont installés. Il s'agit de la version vers laquelle vous effectuez le rollback.
   2. Effectuer un rollback des hôtes virtuels. Répétez la commande suivante pour chaque groupe d'environnements mentionné dans le fichier de remplacement.

      helm upgrade ENV_GROUP_RELEASE_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-virtualhost/ \
        --namespace APIGEE_NAMESPACE \
        --atomic \
        --set envgroup=ENV_GROUP_NAME \
        -f PREVIOUS_OVERRIDES_FILE
      

      ENV_GROUP_RELEASE_NAME est le nom avec lequel vous avez déjà installé le graphique apigee-virtualhost. Dans la version 1.10 d'Apigee hybrid, il s'agit généralement de apigee-virtualhost-ENV_GROUP_NAME. Dans Apigee hybrid v1.11 et versions ultérieures, il s'agit généralement de ENV_GROUP_NAME.

   3. Effectuer un rollback des environnements Répétez la commande suivante pour chaque environnement mentionné dans le fichier de remplacement.

      helm upgrade apigee-env-ENV_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-env/ \
        --install \
        --namespace APIGEE_NAMESPACE \
        --atomic \
        --set env=ENV_NAME \
        -f PREVIOUS_OVERRIDES_FILE
      

      ENV_RELEASE_NAME est le nom avec lequel vous avez déjà installé le graphique apigee-env. Dans la version 1.10 d'Apigee hybrid, il s'agit généralement de apigee-env-ENV_NAME. Dans Apigee hybrid v1.11 et versions ultérieures, il s'agit généralement de ENV_NAME.

      Vérifiez que chaque environnement est opérationnel en vérifiant l'état de l'environnement correspondant :

      kubectl -n apigee get apigeeenv
      

      NAME                  STATE     AGE   GATEWAYTYPE
      apigee-org1-dev-xxx   running   2d
      

   4. Effectuez un rollback de l'organisation :

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

      Vérifiez qu'elle est opérationnelle en vérifiant l'état de l'organisation correspondante :

      kubectl -n apigee get apigeeorg
      

      NAME                STATE     AGE
      apigee-org1-xxxxx   running   2d
      

   5. Effectuez un rollback du gestionnaire d'entrée :

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

      Vérifiez qu'il est opérationnel en vérifiant sa disponibilité :

      kubectl -n apigee get deployment apigee-ingressgateway-manager
      

      NAME                            READY   UP-TO-DATE   AVAILABLE   AGE
      apigee-ingressgateway-manager   2/2     2            2           2d
      

   6. Effectuez un rollback de Redis :

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

      Vérifiez qu'il est opérationnel en vérifiant son état :

      kubectl -n apigee get apigeeredis default
      

      NAME      STATE     AGE
      default   running   2d
      

   7. Effectuez un rollback d'Apigee Telemetry :

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

      Vérifiez qu'il est opérationnel en vérifiant son état :

      kubectl -n apigee get apigeetelemetry apigee-telemetry
      

      NAME               STATE     AGE
      apigee-telemetry   running   2d
      

   8. Effectuez un rollback du contrôleur Apigee :

      helm upgrade operator $PREVIOUS_HELM_CHARTS_HOME/apigee-operator/ \
        --install \
        --namespace apigee-system \
        --atomic \
        -f PREVIOUS_OVERRIDES_FILE
      

      Vérifiez l'installation de l'opérateur Apigee :

      helm ls -n apigee-system
      

      NAME       NAMESPACE       REVISION   UPDATED                                STATUS     CHART                   APP VERSION
      operator   apigee-system   3          2023-06-26 00:42:44.492009 -0800 PST   deployed   apigee-operator-1.12.0   1.12.0
      

      Vérifiez qu'il est opérationnel en vérifiant sa disponibilité :

      kubectl -n apigee-system get deploy apigee-controller-manager
      

      NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
      apigee-controller-manager   1/1     1            1           7d20h
      

   9. Effectuez un rollback des CRD Apigee hybrid :

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

8. Validez la version de tous les composants. Tous les composants doivent exécuter la version précédente, à l'exception de datastore :

   helm -n APIGEE_NAMESPACE list

   helm -n apigee-system list

   Exemple :

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

   À ce stade, toutes les versions, à l'exception de datastore, ont fait l'objet d'un rollback vers la version précédente.

Important : Actuellement, le datastore Cassandra est partiellement mis à jour. Nous vous recommandons d'effectuer une nouvelle mise à niveau en résolvant les problèmes rencontrés lors de la mise à niveau précédente et en relançant le processus. Si vous ne pouvez pas tenter une autre mise à niveau, nous vous recommandons de récupérer le datastore à l'aide des instructions de la section Récupérer une installation multirégionale dans une version précédente.

Récupérer une installation multirégionale dans une version précédente

Récupérez la région où la mise à niveau a échoué dans le cadre d'une mise à niveau multirégionale en supprimant les références à cette mise à niveau dans les installations multirégionales. Cette méthode n'est possible que lorsqu'il existe au moins une région active sur Apigee hybrid 1.11. Le datastore v1.12 est compatible avec les composants de la version 1.11.

Pour récupérer une ou plusieurs régions ayant échoué à partir d'une région opérationnelle, procédez comme suit :

1. Redirigez le trafic de l'API des régions concernées vers la région opérationnelle. Planifiez la capacité en conséquence pour gérer le trafic détourné des régions défaillantes.
2. Mettez hors service la région concernée. Pour chaque région affectée, suivez les étapes décrites dans la section Mettre hors service une région hybride. Attendez la fin de la mise hors service avant de passer à l'étape suivante.

3. Nettoyez la région défaillante en suivant les instructions de la section Récupérer une région après un échec de mise à niveau.
4. Récupérez la région affectée. Pour effectuer une récupération, créez une région comme décrit dans la section Déploiement multirégional sur GKE, GKE On-Prem et AKS.

Restaurer une installation multirégionale à partir d'une sauvegarde avec apigee-datastore dans un état incorrect

Si la mise à niveau du composant apigee-datastore a échoué, vous ne pouvez pas effectuer de rollback de la version 1.12 vers la version 1.11. Au lieu de cela, vous devez effectuer une restauration à partir d'une sauvegarde effectuée à partir d'une installation v1.11. Utilisez la séquence suivante pour restaurer votre version précédente.

Conseil : Pour minimiser les temps d'arrêt dans les installations multirégionales, Apigee recommande de recréer et de restaurer une région à la fois.

1. Si vous n'avez pas d'installation active de la version 1.11 d'Apigee hybrid (par exemple dans une autre région), créez une installation de la version 1.11 à l'aide de vos graphiques et fichiers de remplacement sauvegardés. Consultez les instructions d'installation de la version 1.11 d'Apigee hybrid.
2. Restaurez la région v1.11 (ou la nouvelle installation) à partir de votre sauvegarde en suivant les instructions des sections suivantes :
   • Sauvegardes Cloud Storage Interface (CSI) : sauvegarde et restauration CSI Cassandra.
   • Sauvegardes non-CSI : Restauration dans plusieurs régions.
3. Vérifier le trafic vers l'installation restaurée
4. Pour les installations multirégionales, recompilez et restaurez la région suivante. Consultez les instructions de la section Effectuer une restauration à partir d'une sauvegarde, dans la section "Restaurer dans plusieurs régions".
5. Supprimez l'installation de la version 1.12 en suivant les instructions de la section Désinstaller l'environnement d'exécution hybride.

ANNEXE : Récupérer une région après un échec de mise à niveau

Supprimez un centre de données si la mise à niveau échoue de la version 1.11 vers la version 1.12.

1. Validez l'état du cluster Cassandra depuis une région active :
   1. Remplacez le contexte kubectl par la région à supprimer :

      kubectl config use-context CONTEXT_OF_LIVE_REGION

   2. Répertoriez les pods Cassandra :

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

      Par exemple :

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

   3. Exécutez dans l'un des pods Cassandra :

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

   4. Vérifiez l'état du cluster Cassandra :

      nodetool -u JMX_USER -pw JMX_PASSWORD status

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

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

   5. Décrivez le cluster pour vérifier que vous ne voyez que les adresses IP des pods Cassandra de la région active et qu'ils utilisent tous la même version de schéma :

      nodetool -u JMX_USER -pw JMX_PASSWORD describecluster

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

      nodetool -u JMX_USER -pw JMX_PASSWORD describecluster
      
      Schema versions:
          4bebf2de-0582-31b4-9c5f-e36f60127e1b: [10.48.14.16, 10.48.12.16, 10.48.0.18]
      

2. Nettoyez la réplication de l'espace de clés Cassandra :
   1. Récupérez le job user-setup et supprimez-le. Un nouveau job user-setup sera créé immédiatement.

      kubectl get jobs -n APIGEE_NAMESPACE

      Exemple :

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

      kubectl delete jobs USER_SETUP_JOB_NAME -n APIGEE_NAMESPACE

      Le résultat doit indiquer que le nouveau job démarre :

      kubectl delete jobs apigee-cassandra-user-setup-myhybridorg-8b3e61d -n apigee
      
        apigee-cassandra-user-setup-myhybridorg-8b3e61d-wl92b         0/1     Init:0/1    0               1s
        

   2. Validez les paramètres de réplication de l'espace de clés Cassandra en créant un conteneur client en suivant les instructions de la section Créer le conteneur client.
   3. Obtenez tous les espaces de clés. Exécutez dans un pod cassandra-client puis démarrez un client cqlsh :

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

      Connectez-vous au serveur Cassandra avec ddl user, car il dispose des autorisations nécessaires pour exécuter les commandes suivantes :

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

      Obtenez les espaces de clés :

      select * from system_schema.keyspaces;

      Le résultat doit se présenter comme suit, où dc-1 correspond au contrôleur de domaine actif :

      select * from system_schema.keyspaces;
      
       keyspace_name            | durable_writes | replication
      --------------------------+----------------+--------------------------------------------------------------------------------
         kvm_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
                    system_auth |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
                  system_schema |           True |                        {'class': 'org.apache.cassandra.locator.LocalStrategy'}
       quota_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
       cache_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
         rtc_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
             system_distributed |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
                         system |           True |                        {'class': 'org.apache.cassandra.locator.LocalStrategy'}
                         perses |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
                  system_traces |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
         kms_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
      
      (11 rows)
      

   4. Si pour une raison quelconque, le job user-setup continue de rencontrer des erreurs et la validation échoue, utilisez les commandes suivantes pour corriger la réplication dans les espaces de clés.
      Attention : Utilisez les commandes suivantes avec un soin extrême.

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

      Connectez-vous au serveur Cassandra avec ddl user, car il dispose des autorisations nécessaires pour exécuter les commandes suivantes :

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

      Obtenez les espaces de clés :

      select * from system_schema.keyspaces;

      Utilisez les noms d'espace de clés de la commande ci-dessus et remplacez-les dans les exemples suivants.

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

   5. Vérifiez que tous les espaces de clés sont répliqués dans la bonne région à l'aide de la commande cqlsh suivante :

      select * from system_schema.keyspaces;

      Par exemple :

      select * from system_schema.keyspaces;
      
       keyspace_name           | durable_writes | replication
      -------------------------+----------------+--------------------------------------------------------------------------------
      kvm_myhybridorg_hybrid   |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
                system_auth    |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
              system_schema    |           True |                        {'class': 'org.apache.cassandra.locator.LocalStrategy'}
      quota_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
      cache_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
      rtc_myhybridorg_hybrid   |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
         system_distributed    |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
                     system    |           True |                        {'class': 'org.apache.cassandra.locator.LocalStrategy'}
                     perses    |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
              system_traces    |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
      kms_myhybridorg_hybrid   |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
      
      (11 rows)

À ce stade, vous avez complètement supprimé toutes les références au contrôleur de domaine inactif du cluster Cassandra.

ANNEXE : Supprimer les nœuds "DOWN" du cluster Cassandra

Utilisez cette procédure lorsque vous effectuez un rollback d'une installation multirégionale et que tous les pods Cassandra ne sont pas à l'état "Up" ou "Normal" (UN).

1. Exécutez dans l'un des pods Cassandra :

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

2. Vérifiez l'état du cluster Cassandra :

   nodetool -u JMX_USER -pw JMX_PASSWORD status

3. Vérifiez que le nœud est réellement "DOWN" (DN). Exécutez dans le pod Cassandra d'une région où le pod Cassandra ne parvient pas à devenir opérationnel.

   Datacenter: dc-1
   ================
   Status=Up/Down
   |/ State=Normal/Leaving/Joining/Moving
   --  Address      Load        Tokens  Owns (effective)  Host ID                               Rack
   UN  10.48.12.16  1.15 MiB    256     100.0%            a6340ad9-37ba-4ec8-a8c2-f7b7ac931807  ra-1
   UN  10.48.0.18   1.21 MiB    256     100.0%            0d57df49-52e4-4c01-832d-d9df845ab732  ra-1
   UN  10.48.14.16  1.18 MiB    256     100.0%            39f03c51-e387-4dac-8360-6d8732e690a7  ra-1
   
   Datacenter: us-west1
   ====================
   Status=Up/Down
   |/ State=Normal/Leaving/Joining/Moving
   --  Address      Load        Tokens  Owns (effective)  Host ID                               Rack
   DN  10.8.4.4     432.42 KiB  256     100.0%            cd672398-5c45-4c88-a424-86d757951e53  rc-1
   UN  10.8.19.6    5.8 MiB     256     100.0%            84f771f3-3632-4155-b27f-a67125d73bc5  rc-1
   UN  10.8.21.5    5.74 MiB    256     100.0%            f6f21b70-348d-482d-89fa-14b7147a5042  rc-1
   

4. Supprimez la référence au nœud "DOWN" (DN). Dans l'exemple ci-dessus, nous allons supprimer la référence à l'hôte 10.8.4.4.

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

5. Une fois la référence supprimée, arrêtez le pod. Le nouveau pod Cassandra doit apparaître et rejoindre le cluster.

   kubectl delete pod -n POD_NAME

6. Vérifiez que le nouveau pod Cassandra a rejoint le cluster.

   Datacenter: dc-1
   ================
   Status=Up/Down
   |/ State=Normal/Leaving/Joining/Moving
   --  Address      Load        Tokens  Owns (effective)  Host ID                               Rack
   UN  10.48.12.16  1.16 MiB    256     100.0%            a6340ad9-37ba-4ec8-a8c2-f7b7ac931807  ra-1
   UN  10.48.0.18   1.22 MiB    256     100.0%            0d57df49-52e4-4c01-832d-d9df845ab732  ra-1
   UN  10.48.14.16  1.19 MiB    256     100.0%            39f03c51-e387-4dac-8360-6d8732e690a7  ra-1
   
   Datacenter: us-west1
   ====================
   Status=Up/Down
   |/ State=Normal/Leaving/Joining/Moving
   --  Address      Load        Tokens  Owns (effective)  Host ID                               Rack
   UN  10.8.19.6    5.77 MiB    256     100.0%            84f771f3-3632-4155-b27f-a67125d73bc5  rc-1
   UN  10.8.4.5     246.99 KiB  256     100.0%            0182e675-eec8-4d68-a465-69211b621601  rc-1
   UN  10.8.21.5    5.69 MiB    256     100.0%            f6f21b70-348d-482d-89fa-14b7147a5042  rc-1

À ce stade, vous pouvez procéder à la mise à niveau ou au rollback des régions restantes du cluster.

ANNEXE : Dépannage : apigee-datastore reste bloqué après le rollback.

Utilisez cette procédure lorsque vous avez effectué un rollback de apigee-datastore vers la version Apigee hybrid 1.11 après la mise à niveau et que celui-ci est bloqué.

1. Avant de corriger à nouveau l'état du contrôleur de datastore, vérifiez qu'il est à l'état releasing et que les pods n'apparaissent pas avec l'état du cluster Cassandra.
   1. Vérifiez que le rollback du datastore a été annulé à l'aide de la commande Helm :

      helm -n APIGEE_NAMESPACE list

      Par exemple :

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

   2. Obtenez l'état des pods Cassandra :

      kubectl get pods -n APIGEE_NAMESPACE

      Par exemple :

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

   3. Vérifiez que le contrôleur apigeeds est bloqué à l'état de publication :

      kubectl get apigeeds -n APIGEE_NAMESPACE

      Par exemple :

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

   4. Vérifiez l'état des nœuds Cassandra (notez qu'un nœud est à l'état DN, à savoir le nœud bloqué à l'état CrashLoopBackOff) :

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

      Par exemple :

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

2. Mettez à niveau le datastore à l'aide des graphiques 1.12.
   Remarque : Le contrôleur passe à nouveau à l'état releasing, mais il va cette fois créer des pods avec les images d'Apigee hybrid 1.12 qui apparaîtront, après quoi Cassandra rejoint le cluster et passe à l'état UN (UP/NORMAL).

   helm upgrade datastore APIGEE_HELM_1.12.0_HOME/apigee-datastore/   --install   --namespace APIGEE_NAMESPACE   -f overrides.yaml

3. Vérifiez que tous les pods sont à l'état Running et que le cluster Cassandra est à nouveau opérationnel.
   1. Vérifiez à nouveau que tous les pods sont à l'état READY :

      kubectl get pods -n APIGEE_NAMESPACE

      Par exemple :

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

   2. Vérifiez l'état du cluster Cassandra :

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

      Par exemple :

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

   3. Vérifiez l'état du contrôleur apigeeds :

      kubectl get apigeeds -n APIGEE_NAMESPACE

      Par exemple :

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

À ce stade, vous avez corrigé le datastore et son état devrait être running.