Mettre à niveau Apigee hybrid vers la version 1.8

Remarque : Cette procédure concerne la mise à niveau depuis la version 1.7.x d'Apigee hybrid ou depuis les versions précédentes de la version 1.8.x d'Apigee hybrid vers la version 1.8.8.

Utilisez les mêmes procédures pour les mises à niveau de versions mineures (par exemple, de la version 1.7 vers la version 1.8) et pour les mises à niveau de versions de correctifs (par exemple, de la version 1.8.0 vers la version 1.8.8).

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

Si vous utilisez déjà la version hybride v1.8.0 et que vous souhaitez migrer vers la passerelle d'entrée Apigee depuis Anthos Service Mesh, consultez la page Migrer vers la passerelle d'entrée Apigee.

Présentation de la passerelle d'entrée Apigee

Depuis la version 1.8, Apigee hybrid offre une nouvelle fonctionnalité, la passerelle d'entrée Apigee, qui permet de gérer la passerelle d'entrée pour votre installation hybride. Anthos Service Mesh n'est plus une condition préalable à l'installation hybride. Avec la passerelle d'entrée Apigee, Apigee cesse de fournir la configuration de routage à Anthos Service Mesh. Après la mise à niveau, vous devez migrer le trafic vers la nouvelle passerelle d'entrée Apigee avant de pouvoir commencer à utiliser la fonctionnalité.

Apigee utilise un petit sous-ensemble de fonctionnalités d'Anthos Service Mesh pour la passerelle d'entrée. À partir de la version 1.8 d'Apigee hybrid, Apigee hybrid comprend une passerelle d'entrée installée et mise à niveau dans le cadre des mises à niveau d'Apigee hybrid. Par conséquent, vous n'avez pas besoin de développer une expertise concernant Anthos Service Mesh pour installer, mettre à niveau et gérer Apigee hybrid. Les problèmes liés aux versions de passerelle d'entrée et à la compatibilité avec les versions hybrides Apigee sont gérés automatiquement.

Deux scénarios sont possibles pour la migration :

Migration multicluster ou multirégionale (recommandée) :
Avant de passer à un nouvel objet Ingress pour Apigee, drainez tout le trafic vers un autre cluster ou une autre région du cluster que vous migrez. Cela vous laissera le temps de vérifier que la nouvelle passerelle d'entrée Apigee fonctionne comme prévu. Déplacez ensuite le trafic vers le cluster mis à jour.
Mise à niveau sur place (non recommandée dans les environnements de production) :
Pendant la mise à niveau, Apigee affiche la nouvelle passerelle d'entrée avec l'adresse IP que vous spécifiez. Vous pouvez alors vérifier que la nouvelle passerelle d'entrée Apigee fonctionne comme prévu, puis transférer le trafic vers la nouvelle entrée. Il peut y avoir un temps d'arrêt lors de cette mise à niveau.

Lorsque vous mettez à niveau Apigee hybrid vers la version 1.8, vous devez configurer la passerelle d'entrée Apigee dans votre fichier de remplacement. Après la mise à niveau, vous pouvez contrôler le type de passerelle d'entrée que vos clusters utiliseront en dirigeant les enregistrements A ou CNAME de votre bureau d'enregistrement vers l'adresse IP de la passerelle d'entrée Apigee ou d'Anthos Service Mesh.

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

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

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

Apigee vous recommande de mettre à niveau tous les clusters dès que possible afin de réduire les risques d'impact sur la production. Il n'y a pas de date limite pour mettre à niveau tous les clusters restants après la mise à niveau du premier. Toutefois, jusqu'à ce que tous les clusters restants soient mis à niveau, les opérations suivantes seront affectées :

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.7 ne peut pas être utilisée pour restaurer une instance Hybrid 1.8.
Le flux de données Cassandra ne fonctionnera pas entre les versions hybrides mixtes. Par conséquent, vos clusters Cassandra ne peuvent pas évoluer horizontalement.
L'expansion des régions et la mise hors service sera affectée, car ces opérations dépendent du flux de données Cassandra.

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

Préparez la mise à niveau.
Installez la version 1.8.8 de l'environnement d'exécution hybride.
Pour la passerelle d'entrée, choisissez l'une des options suivantes :
- (Recommandé) Utilisez la nouvelle passerelle d'entrée Apigee, suivez les étapes décrites dans la section Passer du trafic d'Anthos Service Mesh à une passerelle d'entrée Apigee.
- Continuez à utiliser Anthos Service Mesh pour votre passerelle d'entrée.

Conditions préalables

Ces instructions de mise à niveau supposent que vous avez installé Apigee hybrid version 1.7.x ou une version corrective antérieure de la version 1.8.x et que vous souhaitez la mettre à niveau vers la version 1.8.8. Si vous effectuez une mise à jour à partir d'une version antérieure, consultez les instructions figurant dans la section Mettre à niveau Apigee hybrid vers la version 1.7.

Si vous préférez continuer à utiliser Anthos Service Mesh, vous devez vous assurer qu'Anthos Service Mesh est mis à niveau vers une version compatible. Consultez le tableau Plates-formes compatibles pour connaître les versions compatibles d'Anthos Service Mesh.

Préparer la mise à jour vers la version 1.8

Sauvegarder votre installation hybride (recommandé)

Ces instructions utilisent la variable d'environnement APIGEECTL_HOME pour le répertoire de votre système de fichiers sur lequel vous avez installé apigeectl. Si nécessaire, accédez au répertoire apigeectl et définissez la variable en utilisant la commande suivante :
Linux
```
export APIGEECTL_HOME=$PWD
echo $APIGEECTL_HOME
```
macOS
```
export APIGEECTL_HOME=$PWD
echo $APIGEECTL_HOME
```
Windows
```
set APIGEECTL_HOME=%CD%
echo %APIGEECTL_HOME%
```
Créez une copie de sauvegarde de votre répertoire $APIGEECTL_HOME/ version 1.7. Exemple :
```
tar -czvf $APIGEECTL_HOME/../apigeectl-v1.7-backup.tar.gz $APIGEECTL_HOME
```
Sauvegardez votre base de données Cassandra en suivant les instructions figurant sur la page Sauvegarde et récupération de Cassandra.

Ajoutez le rôle Agent Cloud Trace au compte de service pour l'environnement d'exécution Apigee. (Facultatif)

Facultatif : Si vous prévoyez d'utiliser Cloud Trace et que vous n'avez pas encore effectué cette étape sur votre installation hybride 1.7, assurez-vous que votre compte de service pour vos services d'exécution Apigee dispose du rôle Agent Google Cloud Trace. (roles/cloudtrace.agent).

Pour les environnements de production, il s'agit généralement du compte de service apigee-runtime. Pour les environnements hors production, il s'agit généralement du compte de service apigee-non-prod.

Vous pouvez ajouter le rôle dans Cloud Console > IAM et administration > Comptes de service, ou à l'aide des commandes suivantes :

Récupérez l'adresse e-mail de votre compte de service à l'aide de la commande suivante :
Production
```
gcloud iam service-accounts list --filter "apigee-runtime"
```
Si elle correspond au modèle apigee-runtime@$ORG_NAME.iam.gserviceaccount.com, vous pouvez utiliser ce modèle à l'étape suivante.
Hors production
```
gcloud iam service-accounts list --filter "apigee-non-prod"
```
Si elle correspond au modèle apigee-non-prod@$ORG_NAME.iam.gserviceaccount.com, vous pouvez utiliser ce modèle à l'étape suivante.

Attribuez le rôle Agent Cloud Trace au compte de service :

Production

gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member="serviceAccount:apigee-runtime@$PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/cloudtrace.agent"

Hors production

gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member="serviceAccount:apigee-non-prod@$PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/cloudtrace.agent"

Exemple

gcloud projects add-iam-policy-binding hybrid-example-project \
    --member="serviceAccount:apigee-runtime@hybrid-example-project.iam.gserviceaccount.com" \
    --role="roles/cloudtrace.agent"

Où $PROJECT_ID est le nom du projet Google Cloud dans lequel Apigee hybrid est installé.

Remarque : Si votre installation utilise un nom personnalisé pour le compte de service, remplacez-le par apigee-runtime ou apigee-non-prod dans la commande.

Préparer l'installation de la passerelle d'entrée Apigee

Pour installer la passerelle d'entrée Apigee dans le cadre de la mise à niveau. Vous devez ajouter la propriété ingressGateways suivante à votre fichier de remplacement.

Syntaxe

ingressGateways:
- name: INGRESS_NAME
  replicaCountMin: REPLICAS_MIN
  replicaCountMax: REPLICAS_MAX
  resources:
    requests:
      cpu: CPU_COUNT_REQ
      memory: MEMORY_REQ
    limits:
      cpu: CPU_COUNT_LIMIT
      memory: MEMORY_LIMIT
  svcAnnotations:  # optional. See Known issue 243599452.
    SVC_ANNOTATIONS_KEY: SVC_ANNOTATIONS_VALUE
  svcLoadBalancerIP: SVC_LOAD_BALANCER_IP # optional

Exemple

ingressGateways:
- name: prod1
  replicaCountMin: 2
  replicaCountMax: 100
  resources:
    requests:
      cpu: 1
      memory: 1Gi
    limits:
      cpu: 2
      memory: 2Gi

INGRESS_NAME : nom du déploiement d'entrée. Il peut s'agir de n'importe quel nom qui répond aux exigences suivantes :
- Ne pas comporter plus de 17 caractères ;
- ne contenir que des caractères alphanumériques en minuscules et des caractères '-' ou '.' ;
- commencer par un caractère alphanumérique ;
- se terminer par un caractère alphanumérique.
Consultez la section ingressGateways[].name dans la documentation de référence sur les propriétés de configuration.
REPLICAS_MIN et REPLICAS_MAX : nombre minimal et nombre maximal d'instances répliquées pour la passerelle d'entrée Apigee dans votre installation. Pour en savoir plus et pour connaître les paramètres par défaut, consultez les sections ingressGateways[].replicaCountMin et ingressGateways[].replicaCountMax dans la documentation de référence sur les propriétés de configuration.
CPU_COUNT_REQ et MEMORY_REQ : demande de ressources processeur et mémoire pour chaque instance répliquée de la passerelle d'entrée Apigee de votre installation.
Ne spécifiez ces propriétés que si vous les avez précédemment définies pour votre passerelle d'entrée Anthos Service Mesh, par exemple dans votre fichier overlay.yaml.

Pour en savoir plus et pour connaître les paramètres par défaut, consultez les sections ingressGateways[].resources.requests.cpu et ingressGateways[].resources.requests.memory dans la documentation de référence sur les propriétés de configuration.
CPU_COUNT_LIMIT et MEMORY_LIMIT : limites maximales de ressources processeur et mémoire pour chaque instance répliquée de la passerelle d'entrée Apigee de votre installation.
Ne spécifiez ces propriétés que si vous les avez précédemment définies pour votre passerelle d'entrée Anthos Service Mesh, par exemple dans votre fichier overlay.yaml.

Pour en savoir plus et pour connaître les paramètres par défaut, consultez les sections ingressGateways[].resources.limits.cpu et ingressGateways[].resources.limits.memory dans la documentation de référence sur les propriétés de configuration.
SVC_ANNOTATIONS_KEY et SVC_ANNOTATIONS_VALUE (facultatif) :
Remarque : Le champ ingressGateways[].svcAnnotations de overrides.yaml ne fonctionne pas comme prévu. Voir Problème connu 243599452
.
Il s'agit d'une paire clé-valeur qui fournit des annotations pour votre service d'entrée par défaut. Les annotations sont utilisées par votre plate-forme cloud pour vous aider à configurer votre installation hybride, par exemple pour définir le type d'équilibreur de charge sur interne ou externe. Exemple :
```
ingressGateways:
  svcAnnotations:
    networking.gke.io/load-balancer-type: "Internal"
```
Les annotations varient selon les plates-formes. Reportez-vous à la documentation de votre plate-forme pour connaître les annotations requises et celles suggérées.

Remarque : Il n'est pas nécessaire de définir Annotations si vous créez votre propre service Kubernetes pour le déploiement d'entrée, comme indiqué sur la page Exposer la passerelle d'entrée Apigee.
Consultez la section ingressGateways[].svcAnnotations dans la documentation de référence sur les propriétés de configuration.
SVC_LOAD_BALANCER_IP (facultatif) : vous permet d'attribuer une adresse IP statique à votre équilibreur de charge. Sur les plates-formes compatibles avec la spécification de l'adresse IP de l'équilibreur de charge, celui-ci est défini avec cette adresse IP. Sur les plates-formes qui ne vous permettent pas de spécifier l'adresse IP de l'équilibreur de charge, cette propriété est ignorée.
Si aucune adresse IP statique n'est allouée à votre équilibreur de charge, omettez cette propriété dans votre fichier de remplacements.

Attention : Veillez à ne pas spécifier la même adresse IP que celle de la passerelle istio-ingressgateway actuelle. Cela peut poser des problèmes tant que ce service est toujours sur le cluster.
Remarque : Il n'est pas nécessaire de définir LoadBalancerIP si vous créez votre propre service Kubernetes pour le déploiement d'entrée, comme indiqué sur la page Exposer la passerelle d'entrée Apigee.
Consultez la section ingressGateways[].svcLoadBalancerIP dans la documentation de référence sur les propriétés de configuration.

Modifier votre fichier de remplacement pour activer ou désactiver les fonctionnalités facultatives de la version 1.8

Ajoutez les propriétés suivantes à votre fichier overrides.yaml pour activer les nouvelles fonctionnalités dans l'environnement hybride v1.8. Ces fonctionnalités sont facultatives.

L'UDCA au niveau de l'organisation est désormais activé par défaut. L'utilisation d'un seul déploiement UDCA pour gérer le trafic pour tous les environnements empêche la sous-utilisation des pods UDCA et augmente la disponibilité des ressources de nœuds pour les autres composants Apigee. L'UDCA au niveau de l'organisation utilise un seul compte de service pour tous les environnements, apigee-udca.
Si vous utilisez différents comptes de service pour UDCA dans différents environnements, sachez qu'ils utiliseront désormais le compte de service spécifié au niveau de l'organisation dans votre fichier de remplacement avec udca:serviceAccountPath, au lieu de ceux spécifiés dans le niveau d'environnement avec envs:udca:serviceAccountPath

Apigee hybrid v1.8 est compatible avec l'UDCA au niveau de l'environnement. Pour conserver l'UDCA par environnement, définissez orgScopedUDCA: false.

Remarque : La compatibilité avec les UDCA au niveau de l'environnement ne sera plus disponible dans les prochaines versions d'Apigee hybrid.

Consultez la section orgScopedUDCA dans la documentation de référence sur les propriétés de configuration.
Activez validateOrg pour exiger une validation stricte de l'activation de l'organisation et de l'environnement Apigee, et pour travailler avec le projet Google Cloud Platform spécifié dans le fichier overrides.
```
validateOrg: true
```
Remarque : Apigee hybrid n'utilise pas la validation d'organisation stricte. Pour désactiver cette fonctionnalité, définissez validateOrg: false.

Consultez la section validateOrg dans la documentation de référence sur les propriétés de configuration.

Installer l'environnement d'exécution hybride 1.8.8

Vérifiez que vous êtes bien dans le répertoire de base hybrid (c'est-à-dire le répertoire parent du répertoire dans lequel se trouve le fichier exécutable apigeectl) :
```
cd $APIGEECTL_HOME/..
```

Téléchargez le package de la version correspondant à votre système d'exploitation à l'aide de la commande suivante : Veillez à sélectionner la bonne plate-forme dans le tableau suivant :

Linux

Linux 64 bits :

curl -LO \
  https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.8.8/apigeectl_linux_64.tar.gz

macOS

Mac 64 bits :

curl -LO \
  https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.8.8/apigeectl_mac_64.tar.gz

Windows

Windows 64 bits :

curl -LO ^
  https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.8.8/apigeectl_windows_64.zip

Remplacez le nom du répertoire apigeectl/ actuel par un nom de répertoire de sauvegarde. Exemple :

Linux

mv $APIGEECTL_HOME/ $APIGEECTL_HOME-v1.7/

macOS

mv $APIGEECTL_HOME/ $APIGEECTL_HOME-v1.7/

Windows

rename %APIGEECTL_HOME% %APIGEECTL_HOME%-v1.7

Extrayez le contenu du fichier gzip téléchargé dans votre répertoire de base hybride. Le répertoire de base hybrid est le répertoire dans lequel se trouve le répertoire apigeectl-v1.7 renommé :
Linux
```
tar xvzf filename.tar.gz -C ./
```
macOS
```
tar xvzf filename.tar.gz -C ./
```
Windows
```
tar xvzf filename.zip -C ./
```
Par défaut, le contenu du fichier tar est décompressé dans un répertoire dont le nom contient la version et la plate-forme. Exemple : ./apigeectl_1.8.8-xxxxxxx_linux_64. Changez le nom de ce répertoire en apigeectl à l'aide de la commande suivante :
Linux
```
mv apigeectl_1.8.8-xxxxxxx_linux_64 apigeectl
```
macOS
```
mv apigeectl_1.8.8-xxxxxxx_mac_64 apigeectl
```
Windows
```
rename apigeectl_1.8.8-xxxxxxx_windows_64 apigeectl
```
Accédez au répertoire apigeectl :
```
cd ./apigeectl
```
Ce répertoire correspond au répertoire d'accueil apigeectl. Il s'agit de l'emplacement de la commande exécutable apigeectl.
Ces instructions utilisent la variable d'environnement $APIGEECTL_HOME pour le répertoire de votre système de fichiers dans lequel l'utilitaire apigeectl est installé. Si nécessaire, accédez au répertoire apigeectl et définissez la variable en utilisant la commande suivante :
Linux
```
export APIGEECTL_HOME=$PWD
```
```
echo $APIGEECTL_HOME
```
macOS
```
export APIGEECTL_HOME=$PWD
```
```
echo $APIGEECTL_HOME
```
Windows
```
set APIGEECTL_HOME=%CD%
```
```
echo %APIGEECTL_HOME%
```
Vérifiez la version de apigeectl à l'aide de la commande version :
```
./apigeectl version
```
```
Version: 1.8.8
```
Accédez au répertoire hybrid-base-directory/hybrid-files. Le répertoire hybrid-files correspond à l'emplacement où se trouvent les fichiers de configuration, tels que le fichier de remplacement, les certificats et les comptes de service. Exemple :
```
cd $APIGEECTL_HOME/../hybrid-files
```
Vérifiez que kubectl est défini sur le bon contexte à l'aide de la commande suivante. Le contexte actuel doit être défini sur le cluster dans lequel vous mettez à niveau Apigee hybrid.
```
kubectl config get-contexts | grep \*
```
Dans le répertoire hybrid-files :
1. Mettez à jour les liens symboliques suivants de sorte qu'ils pointent vers $APIGEECTL_HOME. Ces liens vous permettent d'exécuter la commande apigeectl nouvellement installée à partir du répertoire hybrid-files :
```
ln -nfs $APIGEECTL_HOME/tools tools
ln -nfs $APIGEECTL_HOME/config config
ln -nfs $APIGEECTL_HOME/templates templates
ln -nfs $APIGEECTL_HOME/plugins plugins
```
2. Pour vérifier que les liens symboliques ont été créés correctement, exécutez la commande suivante et assurez-vous que les chemins d'accès aux liens pointent vers les emplacements appropriés :
```
ls -l | grep ^l
```
Effectuez une initialisation en test à blanc (dry run) pour rechercher d'éventuelles erreurs :
```
${APIGEECTL_HOME}/apigeectl init -f OVERRIDES_FILE --dry-run=client
```
Où OVERRIDES_FILE est le nom de votre fichier de remplacement, par exemple ./overrides/overrides.yaml.

Conseil: Vous pouvez remplacer OVERRIDES_FILE dans l'exemple de code ci-dessus par le nom et le chemin d'accès à votre fichier de remplacement. Chaque instance de cette page sera remplacée.
Si aucune erreur ne s'affiche, initialisez Apigee hybrid 1.8.8. Cette commande va également installer et configurer la passerelle d'entrée Apigee :
```
$APIGEECTL_HOME/apigeectl init -f OVERRIDES_FILE
```
Vérifiez l'état d'initialisation :
```
$APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
```
En cas de réussite, le résultat indique : All containers ready.

Problème connu : Après avoir exécuté init et vérifié que check-ready a réussi, vous remarquerez peut-être que, si vous affichez les pods, la validation du schéma Cassandra est en état d'erreur. Cet état est considéré comme un problème connu (#245664917) et est sans conséquence. Vous pouvez ignorer sereinement l'erreur et passer à l'étape suivante : apigeectl apply.

À titre de contrôle supplémentaire, vous pouvez également exécuter cette commande pour vérifier l'état d'ApigeeDataStore :
```
kubectl describe apigeeds -n apigee
```
Dans le résultat, recherchez State: running.
Recherchez les erreurs à l'aide d'une simulation de la commande apply utilisant l'option --dry-run :
```
$APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --dry-run=client
```
Si aucune erreur ne s'affiche, appliquez vos remplacements. Sélectionnez et suivez les instructions pour les environnements de production ou hors production, selon votre installation.
Au cours de la mise à niveau, chaque composant procède à un redémarrage progressif. Par conséquent, pour les environnements de production, il est préférable d'appliquer la mise à niveau à un composant à la fois.
Production

Pour les environnements de production, vous devez mettre à niveau chaque composant Apigee hybrid individuellement, puis vérifier l'état du composant mis à niveau avant de passer au composant suivant.
1. Assurez-vous d'être dans le répertoire hybrid-files.
2. Appliquez vos remplacements pour mettre à niveau Cassandra :
  $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --datastore
3. Vérifiez que l'opération est terminée :
  $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
  Conseil : Si check-ready échoue, vous pouvez obtenir plus d'informations sur vos pods avec :
  kubectl -n NAMESPACE get pods
  
  Où NAMESPACE est votre espace de noms Apigee hybrid.
  Ne passez à l'étape suivante que lorsque les pods sont prêts.
4. Appliquez vos remplacements pour mettre à niveau les composants Telemetry, puis vérifiez que l'opération est terminée :
  $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --telemetry
  $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
5. Afficher les composants Redis :
  $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --redis
6. Appliquez vos remplacements pour mettre à niveau les composants au niveau de l'organisation (MART, Watcher et Apigee Connect), puis vérifiez que l'opération est terminée :
  $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --org
  $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
7. Appliquez vos remplacements pour mettre à niveau vos environnements. Deux possibilités s'offrent à vous :
  - Environnement par environnement : appliquez vos remplacements à un environnement à la fois et vérifiez que l'opération est terminée. Répétez cette étape pour chaque environnement :
    $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --env ENV_NAME
    
    $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
    
    Où ENV_NAME est le nom de l'environnement que vous mettez à niveau.
  - Tous les environnements à la fois : appliquez vos remplacements à tous les environnements en même temps et vérifiez que l'opération est terminée :
    $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --all-envs
    
    $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
8. Appliquez vos remplacements pour mettre à niveau les composants virtualhosts, puis vérifiez que l'opération est terminée :
  $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --settings virtualhosts
  $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
Hors production

Dans la plupart des environnements hors production, de démonstration ou expérimentaux, vous pouvez appliquer vos remplacements simultanément sur tous les composants. Si votre environnement hors production est volumineux et complexe, ou s'il imite fidèlement un environnement de production, vous pouvez suivre les instructions de mise à niveau des environnements de production.
1. Assurez-vous d'être dans le répertoire hybrid-files.
2. $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE
3. Vérifiez l'état :
  $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

Mettre à niveau votre version de Kubernetes

Mettez à niveau votre plate-forme Kubernetes vers les versions compatibles avec hybrid en version 1.8. Si vous avez besoin d'aide, consultez la documentation de votre plate-forme.

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

	Versions Apigee hybrid
Plates-formes	1.6 ⁽³⁾	1.7 ⁽³⁾	1.8 ⁽³⁾	1.9	1.10
Anthos (Google Cloud – GKE)	1.19.x 1.20.x 1.21.x	1.20.x 1.21.x 1.22.x ^{(≥ 1.7.2)} 1.23.x ^{(≥ 1.7.2)}	1.21.x ^{(≤ 1.8.3)} 1.22.x ^{(≤ 1.8.3)} 1.23.x ^{(≤ 1.8.4)} 1.24.x ^{(≥ 1.8.4)} 1.25.x ^{(≥ 1.8.4)}	1.23.x 1.24.x 1.25.x 1.26.x ^{(≥ 1.9.2)}	1.24.x 1.25.x 1.26.x
Anthos (AWS)	1.7.x 1.8.x 1.9.3+ 1.10.x	1.9.x 1.10.x 1.12.x ^{(≥ 1.7.2)}	1.10.x 1.11.x 1.12.x 1.13.x 1.25⁽¹³⁾	1.12.x 1.13.x 1.25⁽¹³⁾	1.13.x 1.25⁽¹³⁾ 1.26⁽¹³⁾
Anthos (Azure)	1.8.x	1.9.x 1.10.x 1.12.x ^{(≥ 1.7.2)}	1.10.x 1.11.x 1.12.x 1.13.x 1.14.x	1.12.x 1.13.x 1.14.x	1.13.x 1.14.x 1.15.x
Anthos (sur site – VMware)⁽¹⁾	1.7.x 1.8.x 1.9.3+ 1.10.x	1.9.x ⁽⁴⁾ 1.10.x ⁽⁴⁾ 1.11.x ⁽⁴⁾ ^{(≥ 1.7.2)} 1.12.x ⁽⁴⁾ ^{(≥ 1.7.2)}	1.10.x ⁽⁴⁾ 1.11.x ⁽⁴⁾ 1.12.x ⁽⁴⁾ ⁽⁵⁾ 1.13.x ⁽⁵⁾ 1.14.x ⁽⁵⁾ 1.15.x	1.12.x ⁽⁴⁾ 1.13.x 1.14.x 1.15.x	1.13.x 1.14.x 1.15.x 1.16.x
Anthos (Bare Metal)⁽¹⁾	1.7.x 1.8.2+ 1.9.3+ 1.10.x	1.9.x ⁽⁴⁾ 1.10.x ⁽⁴⁾ 1.11.x ⁽⁴⁾ ^{(≥ 1.7.2)} 1.12.x ⁽⁴⁾ ^{(≥ 1.7.2)}	1.10.x ⁽⁴⁾ 1.11.x ⁽⁴⁾ 1.12.x ⁽⁴⁾ ⁽⁵⁾ 1.13.x ⁽⁵⁾ 1.14.x ⁽⁵⁾ 1.15.x	1.12.x ⁽⁴⁾ 1.13.x 1.14.x 1.15.x	1.13.x 1.14.x 1.15.x 1.16.x
EKS⁽⁷⁾	1.19.x 1.20.x 1.21.x	1.21.x 1.22.x ^{(≥ 1.7.2)} 1.23.x ^{(≥ 1.7.2)}	1.22.x ^{(≤ 1.8.3)} 1.23.x ^{(≤ 1.8.4)} 1.24.x ^{(≥ 1.8.4)} 1.25.x ^{(≥ 1.8.4)}	1.23.x 1.24.x 1.25.x 1.26.x ^{(≥ 1.9.2)}	1.24.x 1.25.x 1.26.x
AKS⁽⁷⁾	1.19.x 1.20.x 1.21.x	1.21.x 1.22.x ^{(≥ 1.7.2)} 1.23.x ^{(≥ 1.7.2)}	1.22.x ^{(≤ 1.8.3)} 1.23.x ^{(≤ 1.8.4)} 1.24.x ^{(≥ 1.8.4)} 1.25.x ^{(≥ 1.8.4)}	1.23.x 1.24.x 1.25.x 1.26.x ^{(≥ 1.9.2)}	1.24.x 1.25.x 1.26.x
OpenShift⁽⁷⁾	4.6 4.7 4.8	4.7 4.8	4.8 4.9 4.10	4.10 4.11	4.11 4.12
Rancher Kubernetes Engine (RKE)⁽⁷⁾	N/A	N/A	N/A	1.3.8	v1.26.2+rke2r1
Composants	1.6 ⁽³⁾	1.7 ⁽³⁾	1.8	1.9	1.10
Anthos Service Mesh (ASM)	1.9.x 1.10.x 1.12.x 1.13.x	1.10.x 1.11.x 1.12.x 1.13.x ^{(≥ 1.7.2)} 1.14.x 1.15.x ^{(≥ 1.7.6)}	1.11.x 1.12.x 1.13.x 1.14.x 1.15.x	1.17.x⁽¹¹⁾	1.17.x⁽¹¹⁾
JDK	JDK 11	JDK 11	JDK 11	JDK 11	JDK 11
cert-manager	1.5.4	1.7.x	1.7.x 1.8.x 1.9.x 1.10.x 1.11.x	1.10.x 1.11.x	1.10.x 1.11.x 1.12.x
Cassandra	3.11.10	3.11.10	3.11.10	3.11.10	3.11.10
⁽¹⁾ Sur les versions Anthos 1.8, 1.9 et 1.10 et ultérieures, 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. ⁽²⁾ Compatibilité avec Apigee hybrid version 1.7.2 et ultérieure. ⁽³⁾ 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. ⁽⁴⁾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. ⁽⁵⁾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. ⁽⁶⁾ Compatibilité avec Apigee hybrid 1.8.4 et versions ultérieures. ⁽⁷⁾ Les clusters associés ne sont pas requis pour Apigee hybrid v1.8 et les versions ultérieures utilisant la passerelle d'entrée Apigee. ⁽⁸⁾ Non compatible avec Apigee hybrid 1.8.4 et versions ultérieures. ⁽⁹⁾ Compatibilité avec Apigee hybrid 1.7.6 et versions ultérieures. ⁽¹⁰⁾ Non compatible avec Apigee hybrid 1.8.5 et versions ultérieures. ⁽¹¹⁾ ASM est automatiquement installé avec Apigee hybrid 1.9 et les versions ultérieures. ⁽¹²⁾ Compatibilité avec Apigee hybrid 1.9.2 et versions ultérieures. ⁽¹³⁾ 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 sur les correctifs recommandés.

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

Basculer le trafic d'Anthos Service Mesh vers la passerelle d'entrée Apigee

Procédez comme suit pour basculer votre trafic vers la passerelle d'entrée Apigee :

Exposez la passerelle d'entrée Apigee. Suivez les procédures décrites dans la section Exposer la passerelle d'entrée Apigee.
Testez votre nouvelle passerelle d'entrée en appelant un proxy. Idéalement, testez tous les proxys essentiels que vous avez actuellement déployés.
Pour basculer le trafic, mettez à jour vos enregistrements DNS pour qu'ils pointent vers l'adresse IP de votre nouvelle passerelle d'entrée Apigee. En fonction de votre fournisseur DNS, vous pourrez peut-être transférer progressivement le trafic vers le nouveau point de terminaison.
Conseil : Vous pouvez trouver l'adresse IP externe de la passerelle d'entrée Apigee à l'aide de la commande suivante :
```
kubectl get svc -n apigee -l app=apigee-ingressgateway
```
Le résultat doit se présenter sous la forme suivante :
```
NAME                                        TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)                                      AGE
apigee-ingressgateway-prod-hybrid-37a39bd   LoadBalancer   192.0.2.123   233.252.0.123   15021:32049/TCP,80:31624/TCP,443:30723/TCP   16h
```
Assurez-vous que tout le trafic d'exécution fonctionne en surveillant vos tableaux de bord. Ne passez à l'étape suivante que si tout fonctionne comme prévu. Assurez-vous qu'aucun trafic ne passe par votre ancienne passerelle d'entrée (Anthos Service Mesh), car la mise à jour du DNS peut être lente à cause de la mise en cache DNS.
Pour empêcher Apigee de fournir la configuration à Anthos Service Mesh, suivez les étapes décrites dans la section Arrêter de fournir la configuration à ASM dans le guide Gérer les passerelles d'entrée Apigee.
Testez et surveillez le trafic du proxy d'API.
Suivez les instructions de la documentation Anthos Service Mesh pour désinstaller Anthos Service Mesh du cluster.

Mettre à niveau Anthos Service Mesh vers la version 1.15

Exécutez les procédures à l'aide de la documentation Anthos Service Mesh adaptée à votre plate-forme :

Les instructions d'installation et de configuration d'Anthos Service Mesh varient en fonction de la plate-forme. Les plates-formes sont réparties dans les catégories suivantes :

GKE : clusters Google Kubernetes Engine s'exécutant sur Google Cloud.
En dehors de Google Cloud : clusters Anthos s'exécutant sur :
- Anthos clusters on VMware (GKE On-Prem)
- Anthos sur solution Bare Metal
- Anthos clusters on AWS
- Amazon EKS
Autres plates-formes Kubernetes : clusters conformes, créés et exécutés sur :
- AKS
- EKS
- OpenShift

GKE

La séquence de mise à niveau vers la version 1.13.9 d'Anthos Service Mesh pour votre installation hybride est la suivante :

Anticiper la mise à niveau
Installez la nouvelle version d'Anthos Service Mesh.
Supprimez les déploiements, les services et les webhooks de la version précédente d'Anthos Service Mesh de votre installation actuelle.
Mettre à niveau vos passerelles et configurer les nouveaux webhooks

Préparer la mise à niveau d'Anthos Service Mesh vers la version 1.13.9

Passez en revue les exigences de la section Mettre à niveau Anthos Service Mesh, mais n'effectuez pas encore la mise à niveau.
Avant d'installer la nouvelle version, déterminez la révision actuelle. Vous aurez besoin de ces informations pour supprimer les déploiements, les services et les webhooks de la version précédente d'Anthos Service Mesh de votre installation actuelle. Utilisez la commande suivante pour stocker la révision istiod actuelle dans une variable d'environnement :
```
export DELETE_REV=$(kubectl get deploy -n istio-system -l app=istiod -o jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}')
echo $DELETE_REV
```
Le résultat doit se présenter sous la forme suivante : 1.12.9-asm.2

Remarque : Si la commande renvoie plusieurs valeurs, définissez la valeur de DELETE_REV sur la version la plus ancienne et suivez la procédure permettant de supprimer la version la plus ancienne, puis répétez la procédure jusqu'à ce que vous ayez supprimé toutes les versions.

Créez un fichier overlay.yaml ou vérifiez que votre overlay.yaml existant contient les éléments suivants :

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  components:
    ingressGateways:
    - name: istio-ingressgateway
      enabled: true
      k8s:
        nodeSelector:
          # default node selector, if different or not using node selectors, change accordingly.
          cloud.google.com/gke-nodepool: apigee-runtime
        resources:
          requests:
            cpu: 1000m
        service:
          type: LoadBalancer
          loadBalancerIP: STATIC_IP # If you do not have a reserved static IP, leave this out.
          ports:
            - name: http-status-port
              port: 15021
            - name: http2
              port: 80
              targetPort: 8080
            - name: https
              port: 443
              targetPort: 8443
  meshConfig:
    accessLogFormat:
      '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'

Suivez les instructions des sections suivantes de la documentation Anthos Service Mesh :
Important : Veillez à suivre les instructions pour mettre à niveau Anthos Service Mesh avec les fonctionnalités facultatives et à inclure votre overlay.yaml.
1. Téléchargez asmcli
2. Accordez des autorisations d'administrateur de cluster.
3. Validez le projet et le cluster
4. Passez à une édition supérieure avec des fonctionnalités facultatives Arrêtez avant de commencer la section "Mettre à niveau les passerelles".
Passer au nouveau plan de contrôle :
1. Obtenez le libellé de révision qui se trouve sur istiod :
```
kubectl get pod -n istio-system -L istio.io/rev
```
  La sortie de la commande ressemble à ceci :
```
    NAME                                  READY  STATUS  RESTARTS   AGE  REV
    istiod-asm-1139-10-67998f4b55-lrzpz    1/1    Running  0         68m  asm-1129-0
    istiod-asm-1139-10-67998f4b55-r76kr    1/1    Running  0         68m  asm-1129-0
    istiod-1129-0-1-5cd96f88f6-n7tj9      1/1    Running  0         27s  asm-1139-10
    istiod-1129-0-1-5cd96f88f6-wm68b      1/1    Running  0         27s  asm-1139-10
```
2. Attribuez le libellé de la révision la plus récente à une variable d'environnement.
  Dans le résultat, sous la colonne REV, notez la valeur du libellé de révision pour la nouvelle version. Dans cet exemple, la valeur est asm-1139-10.
```
export UPGRADE_REV="REVISION_LABEL"
```
3. Ajoutez le libellé de révision à l'espace de noms istio-system et supprimez le libellé istio-injection (s'il existe) à l'aide de la commande suivante.
```
kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV istio-injection- --overwrite
```
  Si "istio-injection not found" apparaît dans le résultat, vous pouvez l'ignorer. Cela signifie que l'espace de noms n'avait pas auparavant le libellé istio-injection. Étant donné que l'injection automatique échoue si un espace de noms possède à la fois le istio-injection et le libellé de révision, toutes les commandes kubectl label de la documentation Anthos Service Mesh incluent la suppression du libellé istio-injection.
4. Redémarrez les pods pour déclencher la réinjection :
```
kubectl rollout restart deployment -n istio-system
```
5. Testez votre application pour vérifier que les charges de travail fonctionnent correctement.
6. Si vous avez des charges de travail dans d'autres espaces de noms, répétez les étapes pour leur ajouter des libellés et redémarrer les pods.

Supprimez les versions précédentes :

Accédez au répertoire dans lequel vous avez installé asmcli.
Stockez le répertoire de sortie pour votre installation Anthos Service Mesh dans la variable d'environnement DIR_PATH. Il s'agit du répertoire que vous avez spécifié dans la procédure Mettre à niveau avec des fonctionnalités facultatives.
```
export DIR_PATH=OUTPUT_DIR
```

Créez un script shell contenant les commandes suivantes :

#!/bin/bash

set -ex

if [[ "${DELETE_REV}" != "${UPGRADE_REV}" ]]; then
  kubectl apply -f ${DIR_PATH}/asm/istio/istiod-service.yaml
  kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete deploy -l app=istio-ingressgateway-connectors,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete ValidatingWebhookConfiguration -l app=istiod,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete MutatingWebhookConfiguration -l app=sidecar-injector,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete IstioOperator installed-state-${DELETE_REV} -n istio-system --ignore-not-found=true
fi

Exécutez le script pour supprimer les versions précédentes.

En dehors de Google Cloud

Ces instructions concernent la mise à niveau d'Anthos Service Mesh sur :

Anthos clusters on VMware (GKE On-Prem)
Anthos sur solution Bare Metal
Anthos clusters on AWS
Amazon EKS

La séquence de mise à niveau vers la version 1.13.9 d'Anthos Service Mesh pour votre installation hybride est la suivante :

Anticiper la mise à niveau
Installez la nouvelle version d'Anthos Service Mesh.
Supprimez les déploiements, les services et les webhooks de la version précédente d'Anthos Service Mesh de votre installation actuelle.
Mettre à niveau vos passerelles et configurer les nouveaux webhooks

Préparer la mise à niveau d'Anthos Service Mesh vers la version 1.13.9

Passez en revue les exigences de la section Mettre à niveau Anthos Service Mesh, mais n'effectuez pas encore la mise à niveau.
Avant d'installer la nouvelle version, déterminez la révision actuelle. Vous aurez besoin de ces informations pour supprimer les déploiements, les services et les webhooks de la version précédente d'Anthos Service Mesh de votre installation actuelle. Utilisez la commande suivante pour stocker la révision istiod actuelle dans une variable d'environnement :
```
export DELETE_REV=$(kubectl get deploy -n istio-system -l app=istiod -o jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}')
echo $DELETE_REV
```
Le résultat doit se présenter sous la forme suivante : 1.12.9-asm.2

Remarque : Si la commande renvoie plusieurs valeurs, définissez la valeur de DELETE_REV sur la version la plus ancienne et suivez la procédure permettant de supprimer la version la plus ancienne, puis répétez la procédure jusqu'à ce que vous ayez supprimé toutes les versions.

Créez un fichier overlay.yaml ou vérifiez que votre overlay.yaml existant contient les éléments suivants :

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:  
  components:
    ingressGateways:
    - name: istio-ingressgateway
      enabled: true
      k8s:
        nodeSelector:
          # default node selector, if different or not using node selectors, change accordingly.
          cloud.google.com/gke-nodepool: apigee-runtime
        resources:
          requests:
            cpu: 1000m
        service:
          type: LoadBalancer
          loadBalancerIP: STATIC_IP # If you do not have a reserved static IP, leave this out.
          ports:
            - name: http-status-port
              port: 15021
            - name: http2
              port: 80
              targetPort: 8080
            - name: https
              port: 443
              targetPort: 8443
  values:
    gateways:
      istio-ingressgateway:
        runAsRoot: true

  meshConfig:
    accessLogFormat:
      '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'

Suivez les instructions des sections suivantes de la documentation Anthos Service Mesh :
Important : Veillez à suivre les instructions pour mettre à niveau Anthos Service Mesh avec les fonctionnalités facultatives et à inclure votre overlay.yaml.
1. Téléchargez asmcli
2. Accordez des autorisations d'administrateur de cluster.
3. Validez le projet et le cluster
4. Passez à une édition supérieure avec des fonctionnalités facultatives Arrêtez avant de commencer la section "Mettre à niveau les passerelles".
Passer au nouveau plan de contrôle :
1. Obtenez le libellé de révision qui se trouve sur istiod :
```
kubectl get pod -n istio-system -L istio.io/rev
```
  La sortie de la commande ressemble à ceci :
```
    NAME                                  READY  STATUS  RESTARTS   AGE  REV
    istiod-asm-1139-10-67998f4b55-lrzpz    1/1    Running  0         68m  asm-1129-0
    istiod-asm-1139-10-67998f4b55-r76kr    1/1    Running  0         68m  asm-1129-0
    istiod-1129-0-1-5cd96f88f6-n7tj9      1/1    Running  0         27s  asm-1139-10
    istiod-1129-0-1-5cd96f88f6-wm68b      1/1    Running  0         27s  asm-1139-10
```
2. Attribuez le libellé de la révision la plus récente à une variable d'environnement.
  Dans le résultat, sous la colonne REV, notez la valeur du libellé de révision pour la nouvelle version. Dans cet exemple, la valeur est asm-1139-10.
```
export UPGRADE_REV="REVISION_LABEL"
```
3. Ajoutez le libellé de révision à l'espace de noms istio-system et supprimez le libellé istio-injection (s'il existe) à l'aide de la commande suivante.
```
kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV istio-injection- --overwrite
```
  Si "istio-injection not found" apparaît dans le résultat, vous pouvez l'ignorer. Cela signifie que l'espace de noms n'avait pas auparavant le libellé istio-injection. Étant donné que l'injection automatique échoue si un espace de noms possède à la fois le istio-injection et le libellé de révision, toutes les commandes kubectl label de la documentation Anthos Service Mesh incluent la suppression du libellé istio-injection.
4. Redémarrez les pods pour déclencher la réinjection :
```
kubectl rollout restart deployment -n istio-system
```
5. Testez votre application pour vérifier que les charges de travail fonctionnent correctement.
6. Si vous avez des charges de travail dans d'autres espaces de noms, répétez les étapes pour leur ajouter des libellés et redémarrer les pods.

Supprimez les versions précédentes :

Accédez au répertoire dans lequel vous avez installé asmcli.
Stockez le répertoire de sortie pour votre installation Anthos Service Mesh dans la variable d'environnement DIR_PATH. Il s'agit du répertoire que vous avez spécifié dans la procédure Mettre à niveau avec des fonctionnalités facultatives.
```
export DIR_PATH=OUTPUT_DIR
```

Créez un script shell contenant les commandes suivantes :

#!/bin/bash

set -ex

if [[ "${DELETE_REV}" != "${UPGRADE_REV}" ]]; then
  kubectl apply -f ${DIR_PATH}/asm/istio/istiod-service.yaml
  kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete deploy -l app=istio-ingressgateway-connectors,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete ValidatingWebhookConfiguration -l app=istiod,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete MutatingWebhookConfiguration -l app=sidecar-injector,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete IstioOperator installed-state-${DELETE_REV} -n istio-system --ignore-not-found=true
fi

Exécutez le script pour supprimer les versions précédentes.

AKS / EKS

Dans ces instructions, le processus de mise à niveau de la version istio-1.13.9-asm.10 d'Anthos Service Mesh (Anthos Service Mesh) sur des clusters associés à Anthos est la même que pour effectuer une nouvelle installation.

Préparer l'installation d'Anthos Service Mesh

Avant d'installer la nouvelle version, déterminez la révision actuelle. Vous aurez besoin de ces informations pour supprimer le webhook de validation et le webhook en mutation de votre installation Anthos Service Mesh actuelle. Utilisez la commande suivante pour stocker la révision istiod actuelle dans une variable d'environnement :
```
export DELETE_REV=$(kubectl get deploy -n istio-system -l app=istiod -o jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}')
echo $DELETE_REV
```
Le résultat doit se présenter sous la forme suivante : 1.12.9-asm.2

Remarque : Si la commande renvoie plusieurs valeurs, définissez la valeur de DELETE_REV sur la version la plus ancienne et suivez la procédure permettant de supprimer la version la plus ancienne, puis répétez l'opération. jusqu'à ce que vous ayez supprimé toutes les versions.

Linux

Téléchargez le fichier d'installation d'Anthos Service Mesh dans votre répertoire de travail actuel :

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-linux-amd64.tar.gz

Téléchargez le fichier de signature et utilisez OpenSSL pour valider la signature :

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-linux-amd64.tar.gz.1.sig

openssl dgst -verify /dev/stdin -signature istio-1.13.9-asm.10-linux-amd64.tar.gz.1.sig istio-1.13.9-asm.10.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

Extrayez le contenu du fichier vers n'importe quel emplacement de votre système de fichiers. Par exemple, pour extraire le contenu vers le répertoire de travail actuel :

tar xzf istio-1.13.9-asm.10-linux-amd64.tar.gz

Cette commande crée un répertoire d'installation dans votre répertoire de travail actuel, nommé istio-1.13.9-asm.10, qui contient les éléments suivants :

Des exemples d'applications dans le répertoire samples
L'outil de ligne de commande istioctl que vous utilisez pour installer Anthos Service Mesh et qui se trouve dans le répertoire bin
Les profils de configuration d'Anthos Service Mesh qui se trouvent dans le répertoire manifests/profiles

Assurez-vous d'être dans le répertoire racine de l'installation Anthos Service Mesh :

cd istio-1.13.9-asm.10

Pour plus de commodité, ajoutez les outils du répertoire /bin à votre variable PATH :

export PATH=$PWD/bin:$PATH

macOS

Téléchargez le fichier d'installation d'Anthos Service Mesh dans votre répertoire de travail actuel :

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-osx.tar.gz

Téléchargez le fichier de signature et utilisez OpenSSL pour valider la signature :

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-osx.tar.gz.1.sig

openssl dgst -sha256 -verify /dev/stdin -signature istio-1.13.9-asm.10-osx.tar.gz.1.sig istio-1.13.9-asm.10.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

Extrayez le contenu du fichier vers n'importe quel emplacement de votre système de fichiers. Par exemple, pour extraire le contenu vers le répertoire de travail actuel :

tar xzf istio-1.13.9-asm.10-osx.tar.gz

Cette commande crée un répertoire d'installation dans votre répertoire de travail actuel, nommé istio-1.13.9-asm.10, qui contient les éléments suivants :

Des exemples d'applications dans le répertoire samples
L'outil de ligne de commande istioctl que vous utilisez pour installer Anthos Service Mesh et qui se trouve dans le répertoire bin
Les profils de configuration d'Anthos Service Mesh qui se trouvent dans le répertoire manifests/profiles

Assurez-vous d'être dans le répertoire racine de l'installation Anthos Service Mesh :

cd istio-1.13.9-asm.10

Pour plus de commodité, ajoutez les outils du répertoire /bin à votre variable PATH :

export PATH=$PWD/bin:$PATH

Windows

Téléchargez le fichier d'installation d'Anthos Service Mesh dans votre répertoire de travail actuel :

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-win.zip

Téléchargez le fichier de signature et utilisez OpenSSL pour valider la signature :

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-win.zip.1.sig

openssl dgst -verify - -signature istio-1.13.9-asm.10-win.zip.1.sig istio-1.13.9-asm.10.win.zip <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

Extrayez le contenu du fichier vers n'importe quel emplacement de votre système de fichiers. Par exemple, pour extraire le contenu vers le répertoire de travail actuel :

tar xzf istio-1.13.9-asm.10-win.zip

Cette commande crée un répertoire d'installation dans votre répertoire de travail actuel, nommé istio-1.13.9-asm.10, qui contient les éléments suivants :

Des exemples d'applications dans le répertoire samples
L'outil de ligne de commande istioctl que vous utilisez pour installer Anthos Service Mesh et qui se trouve dans le répertoire bin
Les profils de configuration d'Anthos Service Mesh qui se trouvent dans le répertoire manifests\profiles

Assurez-vous d'être dans le répertoire racine de l'installation Anthos Service Mesh :

cd istio-1.13.9-asm.10

Pour plus de simplicité, ajoutez les outils du répertoire \bin à votre PATH :

set PATH=%CD%\bin:%PATH%

Maintenant qu'Anthos Service Mesh Istio est installé, vérifiez la version de istioctl :
```
istioctl version
```
Créez un espace de noms appelé istio-system pour les composants du plan de contrôle :
```
kubectl create namespace istio-system
```

Installer Anthos Service Mesh

Modifiez votre fichier overlay.yaml ou créez-en un avec le contenu suivant :

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    accessLogFile: /dev/stdout
    enableTracing: true
    accessLogFormat:
      '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'
  components:
    ingressGateways:
    - name: istio-ingressgateway
      enabled: true
      k8s:
        service:
          type: LoadBalancer
          ports:
          - name: status-port
            port: 15021
            targetPort: 15021
          - name: http2
            port: 80
            targetPort: 8080
          - name: https
            port: 443
            targetPort: 8443

Installez Anthos Service Mesh avec istioctl à l'aide du profil asm-multicloud :
```
istioctl install \
    --set profile=asm-multicloud \
    --set revision="asm-1139-10" \
    --filename overlay.yaml
```
Le résultat doit se présenter sous la forme suivante :
```
kubectl get pods -n istio-system
NAME                                   READY   STATUS    RESTARTS   AGE
istio-ingressgateway-88b6fd976-flgp2   1/1     Running   0          3m13s
istio-ingressgateway-88b6fd976-p5dl9   1/1     Running   0          2m57s
istiod-asm-1139-10-798ffb964-2ls88       1/1     Running   0          3m21s
istiod-asm-1139-10-798ffb964-fnj8c       1/1     Running   1          3m21s
```
L'argument --set revision ajoute un libellé de révision au format istio.io/rev=asm-1139-10 à istiod. Le libellé de révision est utilisé par le webhook d'injecteur side-car automatique pour associer les side-cars injectés à une révision istiod particulière. Pour activer l'injection automatique side-car pour un espace de noms, vous devez lui attribuer un libellé de révision correspondant au libellé de istiod.

Vérifiez que votre installation est terminée :

kubectl get svc -n istio-system

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

NAME                   TYPE           CLUSTER-IP       EXTERNAL-IP     PORT(S)                                                                      AGE
istio-ingressgateway   LoadBalancer   172.200.48.52    34.74.177.168   15021:30479/TCP,80:30030/TCP,443:32200/TCP,15012:32297/TCP,15443:30244/TCP   3m35s
istiod                 ClusterIP      172.200.18.133   <none>          15010/TCP,15012/TCP,443/TCP,15014/TCP                                        4m46s
istiod-asm-1139-10       ClusterIP      172.200.63.220   <none>          15010/TCP,15012/TCP,443/TCP,15014/TCP                                        3m43s

Passer au nouveau plan de contrôle :
1. Obtenez le libellé de révision qui se trouve sur istiod :
```
kubectl get pod -n istio-system -L istio.io/rev
```
  La sortie de la commande ressemble à ceci :
```
    NAME                                  READY  STATUS  RESTARTS   AGE  REV
    istiod-asm-1139-10-67998f4b55-lrzpz    1/1    Running  0         68m  asm-1129-0
    istiod-asm-1139-10-67998f4b55-r76kr    1/1    Running  0         68m  asm-1129-0
    istiod-1129-0-1-5cd96f88f6-n7tj9      1/1    Running  0         27s  asm-1139-10
    istiod-1129-0-1-5cd96f88f6-wm68b      1/1    Running  0         27s  asm-1139-10
```
2. Attribuez le libellé de la révision la plus récente à une variable d'environnement.
  Dans le résultat, sous la colonne REV, notez la valeur du libellé de révision pour la nouvelle version. Dans cet exemple, la valeur est asm-1139-10.
```
export UPGRADE_REV="REVISION_LABEL"
```
3. Ajoutez le libellé de révision à l'espace de noms istio-system et supprimez le libellé istio-injection (s'il existe) à l'aide de la commande suivante.
```
kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV istio-injection- --overwrite
```
  Si "istio-injection not found" apparaît dans le résultat, vous pouvez l'ignorer. Cela signifie que l'espace de noms n'avait pas auparavant le libellé istio-injection. Étant donné que l'injection automatique échoue si un espace de noms possède à la fois le istio-injection et le libellé de révision, toutes les commandes kubectl label de la documentation Anthos Service Mesh incluent la suppression du libellé istio-injection.
4. Redémarrez les pods pour déclencher la réinjection :
```
kubectl rollout restart deployment -n istio-system
```
5. Testez votre application pour vérifier que les charges de travail fonctionnent correctement.
6. Si vous avez des charges de travail dans d'autres espaces de noms, répétez les étapes pour leur ajouter des libellés et redémarrer les pods.

Supprimez les versions précédentes :

Accédez au répertoire dans lequel vous avez installé asmcli.

Créez un script shell contenant les commandes suivantes :

#!/bin/bash

set -ex

if [[ "${DELETE_REV}" != "${UPGRADE_REV}" ]]; then
  kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete deploy -l app=istio-ingressgateway-connectors,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete ValidatingWebhookConfiguration -l app=istiod,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete MutatingWebhookConfiguration -l app=sidecar-injector,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete IstioOperator installed-state-${DELETE_REV} -n istio-system --ignore-not-found=true
fi

Exécutez le script pour supprimer les versions précédentes.

OpenShift

Préparer l'installation d'Anthos Service Mesh

Avant d'installer la nouvelle version, déterminez la révision actuelle. Vous aurez besoin de ces informations pour supprimer le webhook de validation et le webhook en mutation de votre installation Anthos Service Mesh actuelle. Utilisez la commande suivante pour stocker la révision istiod actuelle dans une variable d'environnement :
```
export DELETE_REV=$(kubectl get deploy -n istio-system -l app=istiod -o jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}')
echo $DELETE_REV
```
Le résultat doit se présenter sous la forme suivante : 1.12.9-asm.2

Remarque : Si la commande renvoie plusieurs valeurs, définissez la valeur de DELETE_REV sur la version la plus ancienne et suivez la procédure permettant de supprimer la version la plus ancienne, puis répétez l'opération. jusqu'à ce que vous ayez supprimé toutes les versions.

Linux

Attribuez la contrainte de contexte de sécurité (SCC) anyuid au système istio avec la commande suivante de la CLI OpenShift (oc) :

oc adm policy add-scc-to-group anyuid system:serviceaccounts:istio-system

Téléchargez le fichier d'installation d'Anthos Service Mesh dans votre répertoire de travail actuel :

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-linux-amd64.tar.gz

Téléchargez le fichier de signature et utilisez OpenSSL pour valider la signature :

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-linux-amd64.tar.gz.1.sig

openssl dgst -verify /dev/stdin -signature istio-1.13.9-asm.10-linux-amd64.tar.gz.1.sig istio-1.13.9-asm.10.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

Extrayez le contenu du fichier vers n'importe quel emplacement de votre système de fichiers. Par exemple, pour extraire le contenu vers le répertoire de travail actuel :

tar xzf istio-1.13.9-asm.10-linux-amd64.tar.gz

Cette commande crée un répertoire d'installation dans votre répertoire de travail actuel, nommé istio-1.13.9-asm.10, qui contient les éléments suivants :

Des exemples d'applications dans le répertoire samples
L'outil de ligne de commande istioctl que vous utilisez pour installer Anthos Service Mesh et qui se trouve dans le répertoire bin
Les profils de configuration d'Anthos Service Mesh qui se trouvent dans le répertoire manifests/profiles

Assurez-vous d'être dans le répertoire racine de l'installation Anthos Service Mesh :

cd istio-1.13.9-asm.10

Pour plus de commodité, ajoutez les outils du répertoire /bin à votre variable PATH :

export PATH=$PWD/bin:$PATH

macOS

Attribuez la contrainte de contexte de sécurité (SCC) anyuid au système istio avec la commande suivante de la CLI OpenShift (oc) :

oc adm policy add-scc-to-group anyuid system:serviceaccounts:istio-system

Téléchargez le fichier d'installation d'Anthos Service Mesh dans votre répertoire de travail actuel :

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-osx.tar.gz

Téléchargez le fichier de signature et utilisez OpenSSL pour valider la signature :

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-osx.tar.gz.1.sig

openssl dgst -sha256 -verify /dev/stdin -signature istio-1.13.9-asm.10-osx.tar.gz.1.sig istio-1.13.9-asm.10.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

Extrayez le contenu du fichier vers n'importe quel emplacement de votre système de fichiers. Par exemple, pour extraire le contenu vers le répertoire de travail actuel :

tar xzf istio-1.13.9-asm.10-osx.tar.gz

Cette commande crée un répertoire d'installation dans votre répertoire de travail actuel, nommé istio-1.13.9-asm.10, qui contient les éléments suivants :

Des exemples d'applications dans le répertoire samples
L'outil de ligne de commande istioctl que vous utilisez pour installer Anthos Service Mesh et qui se trouve dans le répertoire bin
Les profils de configuration d'Anthos Service Mesh qui se trouvent dans le répertoire manifests/profiles

Assurez-vous d'être dans le répertoire racine de l'installation Anthos Service Mesh :

cd istio-1.13.9-asm.10

Pour plus de commodité, ajoutez les outils du répertoire /bin à votre variable PATH :

export PATH=$PWD/bin:$PATH

Windows

Attribuez la contrainte de contexte de sécurité (SCC) anyuid au système istio avec la commande suivante de la CLI OpenShift (oc) :

oc adm policy add-scc-to-group anyuid system:serviceaccounts:istio-system

Téléchargez le fichier d'installation d'Anthos Service Mesh dans votre répertoire de travail actuel :

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-win.zip

Téléchargez le fichier de signature et utilisez OpenSSL pour valider la signature :

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-win.zip.1.sig

openssl dgst -verify - -signature istio-1.13.9-asm.10-win.zip.1.sig istio-1.13.9-asm.10.win.zip <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

Extrayez le contenu du fichier vers n'importe quel emplacement de votre système de fichiers. Par exemple, pour extraire le contenu vers le répertoire de travail actuel :

tar xzf istio-1.13.9-asm.10-win.zip

Cette commande crée un répertoire d'installation dans votre répertoire de travail actuel, nommé istio-1.13.9-asm.10, qui contient les éléments suivants :

Des exemples d'applications dans le répertoire samples
L'outil de ligne de commande istioctl que vous utilisez pour installer Anthos Service Mesh et qui se trouve dans le répertoire bin
Les profils de configuration d'Anthos Service Mesh qui se trouvent dans le répertoire manifests\profiles

Assurez-vous d'être dans le répertoire racine de l'installation Anthos Service Mesh :

cd istio-1.13.9-asm.10

Pour plus de simplicité, ajoutez les outils du répertoire \bin à votre PATH :

set PATH=%CD%\bin:%PATH%

Maintenant qu'Anthos Service Mesh Istio est installé, vérifiez la version de istioctl :
```
istioctl version
```
Créez un espace de noms appelé istio-system pour les composants du plan de contrôle :
```
kubectl create namespace istio-system
```

Configurer le webhook de validation

Lorsque vous installez Anthos Service Mesh, vous définissez un libellé de révision sur istiod. Vous devez définir la même révision sur le webhook de validation.

Créez un fichier nommé istiod-service.yaml avec le contenu suivant :

apiVersion: v1
kind: Service
metadata:
  name: istiod
  namespace: istio-system
  labels:
    istio.io/rev: asm-1139-10
    app: istiod
    istio: pilot
    release: istio
spec:
  ports:
    - port: 15010
      name: grpc-xds # plaintext
      protocol: TCP
    - port: 15012
      name: https-dns # mTLS with k8s-signed cert
      protocol: TCP
    - port: 443
      name: https-webhook # validation and injection
      targetPort: 15017
      protocol: TCP
    - port: 15014
      name: http-monitoring # prometheus stats
      protocol: TCP
  selector:
    app: istiod
    istio.io/rev: asm-1139-10
  meshConfig:
    accessLogFormat:
      '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'

Utilisez kubectl pour appliquer la configuration du webhook de validation :
```
kubectl apply -f istiod-service.yaml
```

Vérifiez que la configuration a bien été appliquée :

kubectl get svc -n istio-system

La réponse devrait ressembler à ceci :

NAME     TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                                 AGE
istiod   ClusterIP   172.200.18.133   <none>        15010/TCP,15012/TCP,443/TCP,15014/TCP   22s

Installer Anthos Service Mesh

Modifiez votre fichier overlay.yaml ou créez-en un avec le contenu suivant :

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    accessLogFile: /dev/stdout
    enableTracing: true
    accessLogFormat:
      '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'
  components:
    ingressGateways:
      - name: istio-ingressgateway
        enabled: true
        k8s:
          service:
            type: LoadBalancer
            ports:
            - name: status-port
              port: 15021
              targetPort: 15021
            - name: http2
              port: 80
              targetPort: 8080
            - name: https
              port: 443
              targetPort: 8443

Installez Anthos Service Mesh avec istioctl à l'aide du profil asm-multicloud :
```
istioctl install \
    --set profile=asm-multicloud \
    --set revision="asm-1139-10" \
    --filename overlayfile.yaml
```
Le résultat doit se présenter sous la forme suivante :
```
kubectl get pods -n istio-system
NAME                                   READY   STATUS    RESTARTS   AGE
istio-ingressgateway-88b6fd976-flgp2   1/1     Running   0          3m13s
istio-ingressgateway-88b6fd976-p5dl9   1/1     Running   0          2m57s
istiod-asm-1139-10-798ffb964-2ls88       1/1     Running   0          3m21s
istiod-asm-1139-10-798ffb964-fnj8c       1/1     Running   1          3m21s
```
L'argument --set revision ajoute un libellé de révision au format istio.io/rev=1.6.11-asm.1 à istiod. Le libellé de révision est utilisé par le webhook d'injecteur side-car automatique pour associer les side-cars injectés à une révision istiod particulière. Pour activer l'injection automatique side-car pour un espace de noms, vous devez lui attribuer un libellé de révision correspondant au libellé de istiod.

Vérifiez que votre installation est terminée :

kubectl get svc -n istio-system

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

NAME                   TYPE           CLUSTER-IP       EXTERNAL-IP     PORT(S)                                                                      AGE
istio-ingressgateway   LoadBalancer   172.200.48.52    34.74.177.168   15021:30479/TCP,80:30030/TCP,443:32200/TCP,15012:32297/TCP,15443:30244/TCP   3m35s
istiod                 ClusterIP      172.200.18.133   <none>          15010/TCP,15012/TCP,443/TCP,15014/TCP                                        4m46s
istiod-asm-1139-10       ClusterIP      172.200.63.220   <none>          15010/TCP,15012/TCP,443/TCP,15014/TCP                                        3m43s

Passer au nouveau plan de contrôle :
1. Obtenez le libellé de révision qui se trouve sur istiod :
```
kubectl get pod -n istio-system -L istio.io/rev
```
  La sortie de la commande ressemble à ceci :
```
    NAME                                  READY  STATUS  RESTARTS   AGE  REV
    istiod-asm-1139-10-67998f4b55-lrzpz    1/1    Running  0         68m  asm-1129-0
    istiod-asm-1139-10-67998f4b55-r76kr    1/1    Running  0         68m  asm-1129-0
    istiod-1129-0-1-5cd96f88f6-n7tj9      1/1    Running  0         27s  asm-1139-10
    istiod-1129-0-1-5cd96f88f6-wm68b      1/1    Running  0         27s  asm-1139-10
```
2. Attribuez le libellé de la révision la plus récente à une variable d'environnement.
  Dans le résultat, sous la colonne REV, notez la valeur du libellé de révision pour la nouvelle version. Dans cet exemple, la valeur est asm-1139-10.
```
export UPGRADE_REV="REVISION_LABEL"
```
3. Ajoutez le libellé de révision à l'espace de noms istio-system et supprimez le libellé istio-injection (s'il existe) à l'aide de la commande suivante.
```
kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV istio-injection- --overwrite
```
  Si "istio-injection not found" apparaît dans le résultat, vous pouvez l'ignorer. Cela signifie que l'espace de noms n'avait pas auparavant le libellé istio-injection. Étant donné que l'injection automatique échoue si un espace de noms possède à la fois le istio-injection et le libellé de révision, toutes les commandes kubectl label de la documentation Anthos Service Mesh incluent la suppression du libellé istio-injection.
4. Redémarrez les pods pour déclencher la réinjection :
```
kubectl rollout restart deployment -n istio-system
```
5. Testez votre application pour vérifier que les charges de travail fonctionnent correctement.
6. Si vous avez des charges de travail dans d'autres espaces de noms, répétez les étapes pour leur ajouter des libellés et redémarrer les pods.

Supprimez les versions précédentes :

Accédez au répertoire dans lequel vous avez installé asmcli.

Créez un script shell contenant les commandes suivantes :

#!/bin/bash

set -ex

if [[ "${DELETE_REV}" != "${UPGRADE_REV}" ]]; then
  kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete deploy -l app=istio-ingressgateway-connectors,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete ValidatingWebhookConfiguration -l app=istiod,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete MutatingWebhookConfiguration -l app=sidecar-injector,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete IstioOperator installed-state-${DELETE_REV} -n istio-system --ignore-not-found=true
fi

Exécutez le script pour supprimer les versions précédentes.

Effectuer un rollback de la mise à niveau

Suivez ces étapes ci-dessous pour effectuer le rollback vers une mise à niveau précédente :

Nettoyez les tâches terminées pour l'espace de noms d'exécution hybride, où NAMESPACE correspond à l'espace de noms spécifié dans votre fichier de remplacement, si vous avez spécifié un espace de noms. Si ce n'est pas le cas, l'espace de noms par défaut est apigee :
```
kubectl delete job -n NAMESPACE \
  $(kubectl get job -n NAMESPACE \
  -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')
```

Nettoyez les tâches terminées pour l'espace de noms apigee-system :

kubectl delete job -n apigee-system \
  $(kubectl get job -n apigee-system \
  -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')

Modifiez la variable APIGEECTL_HOME pour qu'elle pointe en direction du répertoire contenant la version précédente de apigeectl. Exemple :
```
export APIGEECTL_HOME=PATH_TO_PREVIOUS_APIGEECTL_DIRECTORY
```
Annulez les modifications apportées à votre fichier overrides :
1. Supprimez ou mettez en commentaire ingressGateways et toutes ses propriétés.
2. Définissez la valeur précédente sur virtualhosts.selector.app, par exemple :
```
virtualhosts:
  - name: my-env-group
    selector:
      app: istio-ingressgateway
```
3. Supprimez ou mettez en commentaire ao.args.disableIstioConfigInAPIServer.
Dans le répertoire racine de l'installation à restaurer, exécutez apigeectl apply, vérifiez l'état de vos pods, puis exécutez apigeectl init. Veillez à utiliser le fichier de remplacement d'origine pour la version vers laquelle vous souhaitez effectuer un rollback :
1. Dans le répertoire hybrid-files, exécutez apigeectl apply :
```
$APIGEECTL_HOME/apigeectl apply -f ORIGINAL_OVERRIDES_FILE
```
  Où ORIGINAL_OVERRIDES_FILE correspond au chemin d'accès relatif et au nom du fichier de remplacement pour l'installation hybride de votre version précédente, par exemple, ./overrides/overrides1.7.yaml.
2. Vérifiez l'état des pods :
```
kubectl -n NAMESPACE get pods
```
  Où NAMESPACE est votre espace de noms Apigee hybrid.
3. Vérifiez l'état de apigeeds :
```
kubectl describe apigeeds -n apigee
```
  Le résultat doit se présenter sous la forme suivante :
```
Status:
  Cassandra Data Replication:
  Cassandra Pod Ips:
    10.8.2.204
  Cassandra Ready Replicas:  1
  Components:
    Cassandra:
      Last Successfully Released Version:
        Revision:  v1-f8aa9a82b9f69613
        Version:   v1
      Replicas:
        Available:  1
        Ready:      1
        Total:      1
        Updated:    1
      State:        running
  Scaling:
    In Progress:         false
    Operation:
    Requested Replicas:  0
  State:                 running
```
  Ne passez à l'étape suivante que lorsque le pod apigeeds est en cours d'exécution.
4. Exécutez la commande suivante pour noter les valeurs de votre nouveau nombre d'instances dupliquées pour le processeur de messages après la mise à niveau. Si ces valeurs ne correspondent pas à celles que vous avez définies précédemment, modifiez les valeurs de votre fichier de remplacement en fonction de votre configuration précédente.
```
apigeectl apply -f ORIGINAL_OVERRIDES_FILE --dry-run=client --print-yaml --env ENV_NAME 2>/dev/null |grep "runtime:" -A 25 -B 1| grep "autoScaler" -A 2
```
  Le résultat doit se présenter sous la forme suivante :
```
      autoScaler:
        minReplicas: 2
        maxReplicas: 10
```
5. Si vous effectuez un rollback vers la version 1.8.4 ou antérieure, supprimez le déploiement de contrôleur utilisé par Apigee Hybrid 1.8.5 et versions ultérieures :
```
kubectl -n apigee-system delete deploy apigee-controller-manager
```
6. Exécutez apigeectl init :
```
$APIGEECTL_HOME/apigeectl init -f ORIGINAL_OVERRIDES_FILE
```
Supprimez le déploiement du gestionnaire de passerelle d'entrée Apigee. Ce composant n'est pertinent que pour les versions Apigee hybrid 1.8 et ultérieures.
```
kubectl delete deployment -n NAMESPACE apigee-ingress-gateway-manager
```
Où NAMESPACE est votre espace de noms Apigee hybrid.

Mettre à niveau Apigee hybrid vers la version 1.8

Présentation de la passerelle d'entrée Apigee

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

Conditions préalables

Préparer la mise à jour vers la version 1.8

Sauvegarder votre installation hybride (recommandé)

Linux

macOS

Windows

Ajoutez le rôle Agent Cloud Trace au compte de service pour l'environnement d'exécution Apigee. (Facultatif)

Production

Hors production

Production

Hors production

Exemple

Préparer l'installation de la passerelle d'entrée Apigee

Syntaxe

Exemple

Modifier votre fichier de remplacement pour activer ou désactiver les fonctionnalités facultatives de la version 1.8

Installer l'environnement d'exécution hybride 1.8.8

Linux

macOS

Windows

Linux

macOS

Windows

Linux

macOS

Windows

Linux

macOS

Windows

Linux

macOS

Windows

Production

Hors production

Mettre à niveau votre version de Kubernetes

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

Plates-formes

Composants

À propos des clusters associés

Basculer le trafic d'Anthos Service Mesh vers la passerelle d'entrée Apigee

Mettre à niveau Anthos Service Mesh vers la version 1.15

GKE

Préparer la mise à niveau d'Anthos Service Mesh vers la version 1.13.9

En dehors de Google Cloud

Préparer la mise à niveau d'Anthos Service Mesh vers la version 1.13.9

AKS / EKS

Préparer l'installation d'Anthos Service Mesh

Linux

macOS

Windows

Installer Anthos Service Mesh

OpenShift

Préparer l'installation d'Anthos Service Mesh

Linux

macOS

Windows

Configurer le webhook de validation

Installer Anthos Service Mesh

Effectuer un rollback de la mise à niveau