Anthos Service Mesh 1.9 est arrivé en fin de vie et n'est plus pris en charge. Consultez la section Mettre à niveau à partir de versions antérieures.

Accédez à la documentation la plus récente ou sélectionnez une autre version disponible :

Versions disponibles

Mettre à niveau Anthos Service Mesh vers la dernière version

Cette page explique comment exécuter le script permettant de passer de 1.8 or a 1.9 patch release à Anthos Service Mesh 1.9.8 sur un cluster GKE pour un maillage contenant un ou plusieurs clusters situés dans le même projet Google Cloud.

Les installations Anthos Service Mesh 1.7 et ultérieures sont compatibles avec les mises à niveau de versions ignorées. Pour passer directement à la version 1.10, consultez la page Mettre à niveau Anthos Service Mesh vers la dernière version.

Pour effectuer la mise à niveau où les clusters se trouvent dans différents projets, consultez le guide multiprojet pour GKE.

Cette page porte sur la mise à niveau d'Anthos Service Mesh. Pour plus d'informations sur l'exécution du script pour les nouvelles installations et pour les migrations à partir d'Istio, consultez les ressources suivantes :

Avant de commencer

Avant de commencer la mise à niveau, vérifiez que vous avez effectué les opérations suivantes :

Le script nécessite que vous disposiez des autorisations requises, ou que vous incluiez les options --enable_all ou --enable_gcp_iam_roles afin de lui permettre d'activer automatiquement l'autorisation. De même, pour autoriser le script à activer les API requises et à mettre à jour votre cluster, spécifiez l'option --enable_all ou des options d'activation plus précises.

Préparer la mise à niveau

Si vous avez personnalisé l'installation précédente, vous avez besoin des mêmes personnalisations lorsque vous effectuez une mise à niveau vers une nouvelle version d'Anthos Service Mesh ou une migration depuis Istio. Si vous avez personnalisé l'installation en ajoutant l'option --set values à istioctl install, vous devez ajouter ces paramètres à un fichier YAML IstioOperator, appelé fichier de superposition. Vous spécifiez le fichier superposé en utilisant l'option --custom_overlay avec le nom de fichier lorsque vous exécutez le script. Le script transmet le fichier de superposition à istioctl install.

Le script suit le processus de mise à niveau basé sur la révision (processus appelé mises à jour "Canary" dans la documentation d'Istio). Avec une mise à niveau basée sur la révision, le script installe une nouvelle révision du plan de contrôle en parallèle du plan de contrôle existant. Lors de l'installation de la nouvelle version, le script inclut un libellé revision qui identifie le nouveau plan de contrôle.

Vous effectuez ensuite une migration vers la nouvelle version en définissant le même libellé revision sur vos charges de travail et en effectuant un redémarrage progressif pour réinjecter les proxys afin qu'ils utilisent la nouvelle version et la nouvelle configuration d'Anthos Service Mesh. Avec cette approche, vous pouvez surveiller l'effet de la mise à niveau sur un petit pourcentage de vos charges de travail. Après avoir testé votre application, vous pouvez migrer tout le trafic vers la nouvelle version. Cette approche est beaucoup plus sûre qu'une mise à niveau sur place, où les nouveaux composants du plan de contrôle remplacent la version précédente.

Mettre à niveau Anthos Service Mesh

Définissez les options permettant d'exécuter le script. Vous incluez toujours les options suivantes : project_id, cluster_name, cluster_location et mode.

La section suivante fournit des exemples typiques d'exécution du script. Consultez la barre de navigation située à droite pour obtenir la liste des exemples. Pour obtenir une description complète des arguments du script, consultez la section Option et indicateurs.
Pour terminer la configuration d'Anthos Service Mesh, vous devez activer l'injection side-car automatique et déployer ou redéployer des charges de travail.

Examples

Cette section présente des exemples d'exécution du script des mises à niveau, ainsi que des arguments supplémentaires qui peuvent vous être utiles. Consultez la barre de navigation située à droite pour obtenir la liste des exemples.

Valider uniquement

L'exemple suivant montre comment exécuter le script avec l'option --only_validate. Avec cette option, le script n'apporte aucune modification à votre projet ou cluster et il n'installe pas Anthos Service Mesh. Lorsque vous spécifiez l'option --only_validate, le script échoue si vous incluez l'une des options --enable_*.

Le script valide les points suivants :

Votre environnement dispose des outils nécessaires.
Vous disposez de l'autorisation requise sur le projet spécifié.
Le cluster répond aux exigences minimales.
Toutes les API Google requises sont activées dans le projet.

Par défaut, le script télécharge et extrait le fichier d'installation et télécharge le package de configuration asm de GitHub dans un répertoire temporaire. Avant de quitter, le script génère un message indiquant le nom du répertoire temporaire. Vous pouvez spécifier un répertoire pour les téléchargements à l'aide de l'option --output_dir DIR_PATH. L'option --output_dir vous permet d'utiliser l'outil de ligne de commande istioctl si vous en avez besoin. De plus, les fichiers de configuration permettant d'activer les fonctionnalités facultatives sont inclus dans le répertoire asm/istio/options.

Exécutez la commande suivante pour valider votre configuration et télécharger le fichier d'installation et le package asm dans le répertoire OUTPUT_DIR :

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode upgrade \
  --output_dir DIR_PATH \
  --only_validate

En cas de réussite, le script génère ce qui suit :

./install_asm \
install_asm: Setting up necessary files...
install_asm: Creating temp directory...
install_asm: Generating a new kubeconfig...
install_asm: Checking installation tool dependencies...
install_asm: Downloading ASM..
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 57.0M  100 57.0M    0     0  30.6M      0  0:00:01  0:00:01 --:--:-- 30.6M
install_asm: Downloading ASM kpt package...
fetching package /asm from https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages to asm
install_asm: Checking for project PROJECT_ID...
install_asm: Confirming cluster information...
install_asm: Confirming node pool requirements...
install_asm: Fetching/writing GCP credentials to kubeconfig file...
Fetching cluster endpoint and auth data.
kubeconfig entry generated for cluster-1.
install_asm: Checking Istio installations...
install_asm: Checking required APIs...
install_asm: Successfully validated all requirements to install ASM from this computer.

Si l'un des tests échoue à la validation, le script génère un message d'erreur. Par exemple, si toutes les API Google requises ne sont pas activées pour votre projet, vous obtenez l'erreur suivante :

ERROR: One or more APIs are not enabled. Please enable them and retry, or run
the script with the '--enable_gcp_apis' flag to allow the script to enable them
on your behalf.

Si vous recevez un message d'erreur indiquant que vous devez exécuter le script avec une option d'activation, vous disposez des options suivantes :

Incluez l'option spécifique du message d'erreur ou l'option --enable_all lors de l'exécution du script pour effectuer l'installation réelle (c'est-à-dire sans --only_validate).
Si vous préférez, vous pouvez vous-même mettre à jour votre projet et votre cluster avant d'exécuter le script, comme décrit dans la section Configurer l'installation d'Anthos Service Mesh sur GKE.

Notez que install_asm n'autorise aucune option d'activation avec --only_validate.

Mise à niveau…

La commande suivante exécute le script pour effectuer la mise à niveau. Ce script ne vous permet pas de passer à une autre autorité de certification. Vous n'avez donc pas besoin d'inclure l'option ca.

./install_asm \
  --project_id  PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode upgrade \
  --option revisioned-istio-ingressgateway \
  --enable_all

Mettre à niveau avec un fichier superposé

Un fichier de superposition est un fichier YAML contenant une ressource personnalisée IstioOperator que vous transmettez à install_asm pour configurer le plan de contrôle. Vous pouvez ignorer la configuration par défaut du plan de contrôle et activer une fonctionnalité facultative en transmettant le fichier YAML à install_asm. Vous pouvez effectuer plusieurs couches de superpositions. Chaque fichier de superposition remplace la configuration dans les couches précédentes.

Si vous spécifiez plusieurs ressources personnalisées dans un fichier YAML, install_asm divise ce fichier en plusieurs fichiers YAML temporaires, un pour chaque ressource personnalisée. Le script divise les ressources personnalisées en fichiers distincts, car istioctl install applique uniquement la première ressource personnalisée dans un fichier YAML qui en contient plusieurs.

L'exemple suivant effectue une mise à niveau et inclut un fichier de superposition pour personnaliser la configuration du plan de contrôle. Dans la commande suivante, remplacez OVERLAY_FILE par le nom du fichier YAML.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode upgrade \
  --enable_all \
  --option revisioned-istio-ingressgateway \
  --custom_overlay OVERLAY_FILE

Mettre à niveau avec une option

L'exemple suivant effectue une mise à niveau et inclut le fichier egressgateways.yaml du package anthos-service-mesh, ce qui active une passerelle de sortie. Notez que vous n'incluez pas l'extension .yaml. Le script extrait le fichier à votre place afin que vous n'ayez pas à télécharger le package asm au préalable.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode upgrade \
  --enable_all \
  --option revisioned-istio-ingressgateway \
  --option egressgateways

Vous pouvez utiliser --option pour activer une fonctionnalité facultative. Si vous devez modifier des fichiers dans le répertoire asm/istio/options du package asm, téléchargez le package asm, apportez vos modifications et incluez le fichier à l'aide de --custom_overlay.

Pour télécharger le package asm dans le répertoire de travail actuel afin de pouvoir modifier les fichiers :

kpt pkg get \
https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm@release-1.9-asm asm

Si vous avez exécuté l'exemple Only validate (Valider uniquement) avec l'option --output_dir, les fichiers de configuration se trouvent dans le répertoire de sortie spécifié sous asm/istio/options.

Déployer et redéployer des charges de travail

Votre installation n'est pas terminée tant que vous n'avez pas activé l'injection automatique du proxy side-car (injection automatique). Les migrations depuis OSS Istio et les mises à niveau suivent le processus de mise à niveau basé sur la révision (processus appelé "mises à jour Canary" dans la documentation d'Istio). Avec une mise à niveau basée sur la révision, la nouvelle version du plan de contrôle est installée en parallèle du plan de contrôle existant. Vous déplacez ensuite certaines de vos charges de travail vers la nouvelle version, ce qui vous permet de surveiller l'effet de la mise à niveau avec un faible pourcentage des charges de travail avant de migrer tout le trafic vers la nouvelle version.

Le script définit un libellé de révision au format istio.io/rev=asm-198-6 sur istiod. Pour activer l'injection automatique, vous devez ajouter un libellé de révision correspondant à votre ou vos espaces de noms. Le libellé de révision est utilisé par le webhook d'injecteur sidecar automatique pour associer les sidecars injectés à une révision istiod particulière. Après avoir ajouté le libellé, redémarrez les pods de l'espace de noms pour que les sidecars soient injectés.

Le script crée également un déploiement istio-ingressgateway révisé. Ainsi, vous pouvez contrôler le moment où vous passez à la nouvelle version.

Obtenez le libellé de révision associé à istiod et istio-ingressgateway.
```
kubectl get pod -n istio-system -L istio.io/rev
```
La sortie de la commande ressemble à ceci :
```
NAME                                             READY   STATUS    RESTARTS   AGE   REV
istio-ingressgateway-65d884685d-6hrdk            1/1     Running   0          67m
istio-ingressgateway-65d884685d-94wgz            1/1     Running   0          67m
istio-ingressgateway-asm-182-2-8b5fc8767-gk6hb   1/1     Running   0          5s    asm-198-6
istio-ingressgateway-asm-182-2-8b5fc8767-hn4w2   1/1     Running   0          20s   asm-198-6
istiod-asm-176-1-67998f4b55-lrzpz                1/1     Running   0          68m   asm-186-8
istiod-asm-176-1-67998f4b55-r76kr                1/1     Running   0          68m   asm-186-8
istiod-asm-182-2-5cd96f88f6-n7tj9                1/1     Running   0          27s   asm-198-6
istiod-asm-182-2-5cd96f88f6-wm68b                1/1     Running   0          27s   asm-198-6
```
1. Vérifiez si vous disposez à la fois de l'ancienne et de la nouvelle version de istio-ingressgateway.
  - Si vous avez inclus l'option revisioned-istio-ingressgateway lors de la mise à niveau, une mise à niveau Canary de istio-ingressgateway a été effectuée. Dans ce cas, la sortie affiche à la fois l'ancienne et la nouvelle version de istio-ingressgateway.
  - Si vous n'avez pas inclus revisioned-istio-ingressgateway lors de la mise à niveau, une mise à niveau sur place de istio-ingressgateway a été effectuée. Dans ce cas, la sortie n'affiche que la nouvelle version.
2. 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-198-6.
3. Notez également la valeur du libellé de révision pour l'ancienne version de istiod. Vous devrez supprimer l'ancienne version de istiod lorsque vous aurez fini de déplacer les charges de travail vers la nouvelle version. Dans l'exemple de résultat, la valeur du libellé de révision pour l'ancienne version est asm-186-8.
Si vous disposez de l'ancienne et de la nouvelle version de istio-ingressgateway, remplacez istio-ingressgateway par la nouvelle révision. Dans la commande suivante, remplacez REVISION par la valeur correspondant au libellé de révision de la nouvelle version.
```
kubectl patch service -n istio-system istio-ingressgateway --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "REVISION"}]'
```
Résultat attendu : service/istio-ingressgateway patched
Ajoutez le libellé de révision à un espace de noms et supprimez le libellé istio-injection (s'il existe). Dans la commande suivante, remplacez REVISION par la valeur correspondant à la nouvelle révision de istiod.
```
kubectl label namespace NAMESPACE istio.io/rev=REVISION 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.
Redémarrez les pods pour déclencher la réinjection :
```
kubectl rollout restart deployment -n NAMESPACE
```
Vérifiez que vos pods sont configurés pour pointer vers la nouvelle version de istiod.
```
kubectl get pods -n NAMESPACE -l istio.io/rev=REVISION
```
Testez votre application pour vérifier que les charges de travail fonctionnent correctement.
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.
Si vous êtes sûr que votre application fonctionne comme prévu, continuez de suivre les étapes pour valider la transition vers la nouvelle version de istiod. Si vous rencontrez un problème avec votre application, suivez la procédure de rollback.
Exécutez à nouveau la commande suivante pour vérifier si vous disposez à la fois de l'ancienne et de la nouvelle version de istio-ingressgateway, ou seulement de la nouvelle. Cela détermine la manière dont vous gérez la transition vers la nouvelle version de istio-ingressgateway ou le rollback vers l'ancienne version.
```
kubectl get pod -n istio-system -L istio.io/rev
```
Attention : N'exécutez aucune commande qui supprime le déploiement istio-ingressgateway si vous ne disposez que de la nouvelle version de istio-ingressgateway. Cela empêcherait le trafic d'entrer dans votre maillage de services.
Terminer la transition
Si vous êtes sûr que votre application fonctionne comme prévu, supprimez l'ancien plan de contrôle pour terminer la transition vers la nouvelle version.
1. Accédez au répertoire dans lequel se trouvent les fichiers du dépôt GitHub anthos-service-mesh.
2. Configurez le webhook de validation pour utiliser le nouveau plan de contrôle.
  kubectl apply -f asm/istio/istiod-service.yaml
3. Si vous disposez à la fois de l'ancienne et de la nouvelle version de istio-ingressgateway, supprimez l'ancien déploiement istio-ingressgateway. La commande que vous exécutez varie selon que vous effectuez la migration depuis Istio ou une mise à niveau depuis une version précédente d'Anthos Service Mesh :
  Migrer
  Si vous avez effectué une migration depuis Istio, l'ancienne istio-ingressgateway ne comporte pas de libellé de révision.
  
  kubectl delete deploy/istio-ingressgateway -n istio-system
  
  Mettre à niveau
  Si vous avez mis à niveau à partir d'une version précédente d'Anthos Service Mesh, dans la commande suivante, remplacez OLD_REVISION par le libellé de révision de la version précédente de istio-ingressgateway.
  
  kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=OLD_REVISION -n istio-system --ignore-not-found=true
4. Supprimez l'ancienne version de istiod. La commande que vous utilisez varie selon que vous effectuez la migration depuis Istio ou une mise à niveau depuis une version précédente d'Anthos Service Mesh.
  Migrer
  Si vous avez effectué une migration depuis Istio, l'ancienne istiod ne comporte pas de libellé de révision.
  
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true
  
  Mettre à niveau
  Si vous avez effectué une mise à niveau à partir d'une version précédente d'Anthos Service Mesh, assurez-vous que OLD_REVISION correspond au libellé de révision de la version précédente de istiod dans la commande suivante.
  
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION -n istio-system --ignore-not-found=true
5. Supprimez l'ancienne version de la configuration IstioOperator.
  kubectl delete IstioOperator installed-state-OLD_REVISION -n istio-system
  Le résultat ressemble à ce qui suit :
  istiooperator.install.istio.io "installed-state-OLD_REVISION" deleted
Rollback
Si vous avez rencontré un problème lors du test de votre application avec la nouvelle version de istiod, procédez comme suit pour effectuer un rollback vers la version précédente :
1. Revenez à l'ancienne version de istio-ingressgateway. La commande que vous utilisez varie selon que vous disposez à la fois de l'ancienne et de la nouvelle version de istio-ingressgateway, ou seulement de la nouvelle.
  - Si vous disposez à la fois de l'ancienne et de la nouvelle version de istio-ingressgateway, exécutez la commande kubectl patch service et remplacez OLD_REVISION par l'ancienne révision.
    
    kubectl patch service -n istio-system istio-ingressgateway --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "OLD_REVISION"}]'
  - Si vous ne disposez que de la nouvelle version de istio-ingressgateway, exécutez la commande kubectl rollout undo.
    
    kubectl -n istio-system rollout undo deploy istio-ingressgateway
2. Modifiez les libellés de votre espace de noms pour activer l'injection automatique avec la version précédente de istiod. La commande que vous utilisez varie selon que vous avez utilisé un libellé de révision ou istio-injection=enabled avec la version précédente.
  - Si vous avez utilisé un libellé de révision pour l'injection automatique :
    
    kubectl label namespace NAMESPACE istio.io/rev=OLD_REVISION --overwrite
  - Si vous avez utilisé istio-injection=enabled :
    
    kubectl label namespace NAMESPACE istio.io/rev- istio-injection=enabled --overwrite
  Résultat attendu :
  namespace/NAMESPACE labeled
3. Confirmez que le libellé de révision de l'espace de noms correspond au libellé de révision de la version précédente de istiod :
  kubectl get ns NAMESPACE --show-labels
4. Redémarrez les pods pour déclencher une réinjection afin que les proxys disposent de la version précédente :
  kubectl rollout restart deployment -n NAMESPACE
5. Si vous disposez à la fois de l'ancienne et de la nouvelle version de istio-ingressgateway, supprimez le nouveau déploiement istio-ingressgateway. Assurez-vous que la valeur de REVISION dans la commande suivante est correcte.
  kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=REVISION -n istio-system --ignore-not-found=true
6. Supprimez la nouvelle version de istiod. Assurez-vous que la valeur de REVISION dans la commande suivante est correcte.
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION -n istio-system --ignore-not-found=true
7. Supprimez la nouvelle version de la configuration IstioOperator.
  kubectl delete IstioOperator installed-state-REVISION -n istio-system
  Le résultat attendu ressemble à ce qui suit :
  istiooperator.install.istio.io "installed-state-REVISION" deleted
8. Si vous n'avez pas ajouté l'option --disable_canonical_service, le script a activé le contrôleur de service canonique. Nous vous recommandons de conserver cette option activée. Cependant, si vous devez la désactiver, consultez la section Activer et désactiver le contrôleur de service canonique.

Afficher les tableaux de bord Anthos Service Mesh

Une fois que les charges de travail sont déployées sur votre cluster et que les proxys side-car ont été injectés, vous pouvez explorer les pages Anthos Service Mesh de la console Google Cloud pour consulter toutes les fonctionnalités d'observabilité offertes par Anthos Service Mesh. Notez qu'il faut environ une à deux minutes pour que les données de télémétrie soient affichées dans la console Google Cloud après le déploiement des charges de travail.

L'accès à Anthos Service Mesh dans la console Google Cloud est contrôlé par IAM (Identity and Access Management). Pour permettre l'accès aux pages Anthos Service Mesh, un propriétaire de projet doit accorder aux utilisateurs le rôle éditeur ou lecteur de projet, ou les rôles plus restrictifs décrits dans la section Contrôler l'accès à Anthos Service Mesh dans la console Google Cloud.

Dans Google Cloud Console, accédez à Anthos Service Mesh.

Accéder à Anthos Service Mesh
Sélectionnez le projet Google Cloud dans la liste déroulante de la barre de menu.
Si vous avez plusieurs maillages de services, sélectionnez le maillage dans la liste déroulante Maillage de services.

Pour en savoir plus, consultez la page Explorer Anthos Service Mesh dans la console Google Cloud.

Outre les pages Anthos Service Mesh, les métriques liées à vos services (telles que le nombre de requêtes reçues par un service particulier) sont envoyées à Cloud Monitoring, où elles apparaissent dans l'explorateur de métriques.

Pour afficher les métriques, procédez comme suit :

Dans Google Cloud Console, accédez à la page Monitoring :

Accéder à Monitoring
Sélectionnez Ressources > Explorateur de métriques.

Pour obtenir la liste complète des métriques, consultez la section Métriques Istio dans la documentation Cloud Monitoring.