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.
-
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. -
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
etTargetV2
ne seront plus utilisées par défaut. Toutes les métriques de proxy et de cible seront publiées dans les ressources surveilléesProxy
etTarget
.Pour continuer à émettre des métriques vers les ressources surveillées
ProxyV2
etTargetV2
, définissezmetrics.disablePrometheusPipeline
surtrue
dansoverrides.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 parCassandra
. - 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 composantapigee-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. - 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.
- Si le composant
É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 :
- 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.
- 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.
- Mettez à niveau la région nouvellement ajoutée vers Apigee hybrid 1.12.
- Basculez le trafic vers la nouvelle région et validez le trafic.
- Une fois validé, mettez à niveau l'ancienne région vers Apigee hybrid 1.12.
- Basculez tout le trafic vers l'ancienne région et validez le trafic.
- 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 :
- Sauvegardez et validez les données de chaque région avant de commencer la mise à niveau.
- 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.
- Validez le trafic dans la région qui vient d'être mise à jour.
- Mettez à niveau chaque région suivante, uniquement après avoir validé le trafic sur la région précédente.
- 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.
- Si vous gérez votre installation hybride avec
- 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
Les procédures de mise à niveau d'Apigee hybrid sont organisées dans les sections suivantes :
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 :
-
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 . . . - Supprimez un pod :
kubectl delete pod -n APIGEE_NAMESPACE CASSANDRA_POD_NAME
Par exemple :
kubectl delete pod -n apigee apigee-cassandra-default-0
- 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 . . .
-
Répertoriez les pods Cassandra :
- 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 :
- 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 - 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
- Répertoriez les pods Cassandra :
Sauvegarder vos répertoires d'installation hybrides
- 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.11. Vous pouvez utiliser n'importe quel processus de sauvegarde. Par exemple, vous pouvez créer un fichiertar
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
- 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.11 et 1.12 d'Apigee hybrid. Si vous avez besoin d'aide, consultez la documentation de votre plate-forme.
Installer l'environnement d'exécution hybride 1.12.0
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.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
- 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
- Installez les CRD Apigee mises à jour :
-
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 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
-
-
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 fichieroverrides.yaml
.Pour en savoir plus, consultez la page Configurer des pools de nœuds dédiés.
Installer les charts Helm Apigee hybrid
- 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 :
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
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
- 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
Vérifiez que
apigeedatastore
est opérationnel en vérifiant son état :kubectl -n apigee 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
Mettez à niveau le graphique :
helm upgrade telemetry apigee-telemetry/ \ --install \ --namespace APIGEE_NAMESPACE \ -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
- 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
Vérifiez qu'il est opérationnel en vérifiant son état :
kubectl -n apigee 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
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 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
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 get apigeeorg
NAME STATE AGE apigee-org1-xxxxx running 2d
- 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 deapigee-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
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
- ENV_RELEASE_NAME est le nom avec lequel vous avez déjà installé le graphique
-
Mettez à jour les groupes d'environnement (
virtualhosts
).- 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 deapigee-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
- 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
- Vous devez installer un groupe d'environnements (hôte virtuel) à la fois. Spécifiez le groupe d'environnement avec
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.
Pour effectuer un rollback vers la version 1.11 dans une installation à une seule région :
-
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
-
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
-
Effectuez le rollback de chaque composant (sauf
apigee-datastore
) à l'aide des commandes suivantes :- 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.
- 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 deapigee-virtualhost-ENV_GROUP_NAME
. Dans Apigee hybrid v1.11 et versions ultérieures, il s'agit généralement de ENV_GROUP_NAME. - 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 deapigee-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
- 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
- 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
- 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
- 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
- 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
- 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
- Créez la variable d'environnement suivante :
-
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
-
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.
- 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.
- 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.
- Vérifier le trafic vers l'installation restaurée
- 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
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.
-
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
- 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 :
- 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 - 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. - Répertoriez les pods Cassandra :
- Accédez au répertoire dans lequel les graphiques Helm Apigee hybrid précédents sont installés.
-
Remplacez le contexte par la région qui a été mise à niveau.
kubectl config use-context UPGRADED_REGION_CONTEXT
-
Vérifiez que tous les pods sont en cours d'exécution :
kubectl get pods -n APIGEE_NAMESPACE
kubectl get pods -n apigee-system
- 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
-
Effectuez le rollback de chaque composant (sauf
apigee-datastore
) à l'aide des commandes suivantes :- 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.
- 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 deapigee-virtualhost-ENV_GROUP_NAME
. Dans Apigee hybrid v1.11 et versions ultérieures, il s'agit généralement de ENV_GROUP_NAME. - 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 deapigee-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
- 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
- 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
- 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
- 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
- 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
- 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
- Créez la variable d'environnement suivante :
-
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.
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 :
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- Vérifier le trafic vers l'installation restaurée
- 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".
- 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.
-
Validez l'état du cluster Cassandra depuis une région active :
-
Remplacez le contexte kubectl par la région à supprimer :
kubectl config use-context CONTEXT_OF_LIVE_REGION
- 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 -
Exécutez dans l'un des pods Cassandra :
kubectl exec -it -n CASSANDRA_POD_NAME -- /bin/bash
-
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
-
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]
-
Remplacez le contexte kubectl par la région à supprimer :
-
Nettoyez la réplication de l'espace de clés Cassandra :
-
Récupérez le job
user-setup
et supprimez-le. Un nouveau jobuser-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 21skubectl 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 - 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.
-
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) - 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.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'};
- 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)
-
Récupérez le job
À 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
).
-
Exécutez dans l'un des pods Cassandra :
kubectl exec -it -n CASSANDRA_POD_NAME -- /bin/bash
-
Vérifiez l'état du cluster Cassandra :
nodetool -u JMX_USER -pw JMX_PASSWORD status
-
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
-
Supprimez la référence au nœud "DOWN" (
DN
). Dans l'exemple ci-dessus, nous allons supprimer la référence à l'hôte10.8.4.4
.kubectl exec -it -n apigee apigee-cassandra-default-2 -- /bin/bash nodetool -u JMX_USER -pw JMX_PASSWORD removenode HOST_ID
-
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
-
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é.
-
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.-
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 -
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 -
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 -
Vérifiez l'état des nœuds Cassandra (notez qu'un nœud est à l'état
DN
, à savoir le nœud bloqué à l'étatCrashLoopBackOff
) :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
-
Vérifiez que le rollback du datastore a été annulé à l'aide de la commande Helm :
-
Mettez à niveau le datastore à l'aide des graphiques 1.12.
helm upgrade datastore APIGEE_HELM_1.12.0_HOME/apigee-datastore/ --install --namespace APIGEE_NAMESPACE -f overrides.yaml
-
Vérifiez que tous les pods sont à l'état
Running
et que le cluster Cassandra est à nouveau opérationnel.-
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 -
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 -
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
-
Vérifiez à nouveau que tous les pods sont à l'état
À ce stade, vous avez corrigé le datastore et son état devrait être running
.