Propagate a trace ID using permissive traffic lanes - Alibaba Cloud Service Mesh

Les voies de trafic en mode permissif permettent d'isoler les versions des applications. Le système achemine le trafic vers différentes voies en fonction des en-têtes de requête propagés et entrants. Si un service appelé n'existe pas dans la voie actuelle, le système transfère la requête vers la voie de référence. Cette approche garantit l'intégrité de la chaîne d'appels et simplifie la gestion du trafic.

Important

Avant de commencer, lisez attentivement la rubrique Utiliser les voies de trafic en mode permissif pour la gestion du trafic de bout en bout et assimilez les concepts connexes.

Présentation du scénario

Cet exemple utilise trois services (mocka, mockb et mockc) pour créer trois voies de trafic représentant trois versions d'une chaîne d'appels : s1, s2 et s3. La voie s1 constitue la voie de référence et contient les trois services. La voie s2 ne contient que les services mocka et mockc. La voie s3 ne contient que le service mockb.

Étape 1 : Créer un groupe de voies et des voies

Créez un groupe de voies.

Connectez-vous à la console ASM. Dans le volet de navigation de gauche, sélectionnez Service Mesh > Mesh Management.
Sur la page Mesh Management, cliquez sur le nom de l'instance cible. Dans le volet de navigation de gauche, choisissez Traffic Management Center > Traffic Lane.

Sur la page Traffic Lane, cliquez sur Create Swimlane Group. Dans le panneau Create Swimlane Group, configurez les paramètres, puis cliquez sur OK.

Parameter

Description

Name of swim lane group

Dans cet exemple, définissez le nom sur test.

Entrance gateway

Sélectionnez ingressgateway.

Lane Mode

Sélectionnez Permissive Mode.

Pass-through Mode of Trace Context

Sélectionnez Pass Through Trace ID.

Trace ID Request Header

L'application exemple propage l'en-tête de requête my-trace-id tout au long de la chaîne d'appels. Définissez donc ce paramètre sur my-trace-id.

Routing Request Header

Cet en-tête permet à la passerelle d'acheminer le trafic entrant vers différentes voies et de maintenir le contexte de la voie. Vous pouvez spécifier n'importe quel nom d'en-tête valide. Dans cet exemple, utilisez x-asm-prefer-tag.

Swimlane Services

Sélectionnez le cluster Kubernetes cible et le namespace default. Dans la liste des services disponibles, sélectionnez mocka, mockb et mockc, puis cliquez sur l'icône pour les déplacer vers la liste selected.

Une fois la configuration terminée, le système génère automatiquement une ressource TrafficLabel correspondante. Dans le volet de navigation de gauche, cliquez sur TrafficLabel pour afficher la ressource. Par exemple, la ressource TrafficLabel suivante est générée pour le service mocka.

Exemple YAML TrafficLabel

apiVersion: istio.alibabacloud.com/v1beta1
kind: TrafficLabel
metadata:
  labels:
    asm-system: 'true'
    provider: asm
    swimlane-group: test
  name: asm-swimlane-test-mocka
  namespace: default
spec:
  rules:
    - labels:
        - name: asm-label
          valueFrom:
            - '$getExternalInboundRequestHeader(x-asm-prefer-tag, my-trace-id)'
  workloadSelector:
    labels:
      app: mocka

Créez les voies s1, s2 et s3, et associez-les respectivement aux versions v1, v2 et v3.

Sur la page Traffic Lane, dans la section Traffic Rule Definition, cliquez sur Create swimlanes.

Dans la boîte de dialogue Create swimlanes, configurez les paramètres, puis cliquez sur OK.

Parameter	Description
Swimlane Name	Nommez les trois voies s1, s2 et s3 respectivement.
Configure Service Tag	Label Key : sélectionnez ASM_TRAFFIC_TAG. Label Value : sélectionnez v1 pour la voie s1, v2 pour la voie s2 et v3 pour la voie s3.
Add Service	Voie s1 : sélectionnez mocka(default), mockb(default) et mockc(default). Voie s2 : sélectionnez mocka(default) et mockc(default). Voie s3 : sélectionnez mockb(default).

Une fois les trois voies créées, le résultat se présente comme suit :

Remarque

Par défaut, la première voie de trafic créée dans un groupe de voies devient la voie de référence. Vous pouvez modifier la voie de référence. Si une requête cible un service qui ne se trouve pas dans la voie actuelle, le mécanisme de secours la redirige vers la voie de référence. Pour plus d'informations, consultez la section Modifier la voie de référence en mode permissif.

Après la création des trois voies, le système génère une ressource DestinationRule et une ressource VirtualService pour chaque service du groupe de voies. Dans le volet de navigation de gauche, choisissez Traffic Management Center > DestinationRule ou VirtualService pour afficher ces ressources. Par exemple, les ressources DestinationRule et VirtualService suivantes sont automatiquement créées pour le service mocka.

Exemple YAML DestinationRule

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  labels:
    asm-system: 'true'
    provider: asm
    swimlane-group: test
  name: trafficlabel-dr-test-default-mocka
  namespace: istio-system
spec:
  host: mocka.default.svc.cluster.local
  subsets:
    - labels:
        ASM_TRAFFIC_TAG: v1
      name: s1
    - labels:
        ASM_TRAFFIC_TAG: v2
      name: s2

Exemple YAML VirtualService

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  labels:
    asm-system: 'true'
    provider: asm
    swimlane-group: test
  name: trafficlabel-vs-test-default-mocka
  namespace: istio-system
spec:
  hosts:
    - mocka.default.svc.cluster.local
  http:
    - name: default
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: $asm-label
          fallback:
            target:
              host: mocka.default.svc.cluster.local
              subset: s1

Créez des règles de trafic entrant pour les trois voies.

Sur la page Traffic Lane, dans la section Traffic Rule Definition, localisez la voie cible et cliquez sur Ingress traffic rules dans la colonne Actions.

Dans la boîte de dialogue Add drainage rule, configurez les paramètres, puis cliquez sur OK.

Cet exemple suppose que l'API entrante pour tous les services des voies est /mock. Configurez la même règle de trafic entrant pour chaque voie.

Parameter

Description

Ingress service

Sélectionnez mocka.default.svc.cluster.local.

Ingress traffic rules

Définissez le Name des trois règles respectivement sur r1, r2 et r3. Définissez le realm name sur *.

Matching request URI

Définissez la Method sur Exact et le Content sur /mock.

Après la création des règles de trafic entrant pour les trois voies, la configuration est la suivante : voie s1 (référence, libellé v1, avec les services mocka, mockb et mockc), voie s2 (libellé v2, avec les services mocka et mockc) et voie s3 (libellé v3, avec le service mockb). Chaque règle de trafic entrant inclut également une condition de correspondance d'en-tête pour x-asm-prefer-tag qui correspond exactement au nom de la voie respective.

Une fois les règles créées, le système génère automatiquement une règle de trafic entrant (une VirtualService) pour chaque voie. Par exemple, la VirtualService suivante est générée pour la voie s2.

Exemple YAML VirtualService

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  labels:
    asm-system: 'true'
    provider: asm
    swimlane-group: test
  name: swimlane-ingress-vs-test-s2
  namespace: istio-system
spec:
  gateways:
    - istio-system/ingressgateway
  hosts:
    - '*'
  http:
    - match:
        - headers:
            x-asm-prefer-tag:
              exact: s2
          uri:
            exact: /mock
      name: r2
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: s2
          fallback:
            target:
              host: mocka.default.svc.cluster.local
              subset: s1

Étape 2 : Vérifier la fonctionnalité de canary de bout en bout

Récupérez l'adresse IP publique de la passerelle entrante ASM. Pour plus d'informations, consultez la rubrique Obtenir l'adresse IP de la passerelle entrante ASM.
Exécutez la commande suivante pour définir une variable d'environnement.

Remplacez xxx.xxx.xxx.xxx par l'adresse IP obtenue à l'étape précédente.
```
export ASM_GATEWAY_IP=xxx.xxx.xxx.xxx
```
Vérifiez que la fonctionnalité de canary de bout en bout fonctionne comme prévu.
1. Exécutez la commande suivante pour vérifier l'accès à la voie s1.
  
  La valeur de l'en-tête x-asm-prefer-tag, s1, correspond au nom que vous avez configuré pour la voie s1 lors de la sous-étape 2 de l'étape 1.
```
for i in {1..100};  do curl   -H 'x-asm-prefer-tag: s1' -H'my-trace-id: x000'$i http://${ASM_GATEWAY_IP}/mock ;  echo ''; sleep 1; done;
```
  Résultat attendu :
```
-> mocka(version: v1, ip: 172.17.0.54)-> mockb(version: v1, ip: 172.17.0.129)-> mockc(version: v1, ip: 172.17.0.130)
```
  Le résultat montre que le trafic portant l'en-tête de requête x-asm-prefer-tag: s1 est acheminé vers les services de la voie s1, comme prévu.
2. Exécutez la commande suivante pour vérifier l'accès à la voie s2.
  
  La valeur de l'en-tête x-asm-prefer-tag, s2, correspond au nom que vous avez configuré pour la voie s2 lors de la sous-étape 2 de l'étape 1.
```
for i in {1..100};  do curl   -H 'x-asm-prefer-tag: s2' -H'my-trace-id: x000'$i http://${ASM_GATEWAY_IP}/mock ;  echo ''; sleep 1; done;
```
  Résultat attendu :
```
-> mocka(version: v2, ip: 172.17.0.9)-> mockb(version: v1, ip: 172.17.0.129)-> mockc(version: v2, ip: 172.17.0.128)
```
  Le résultat montre que le trafic portant l'en-tête de requête x-asm-prefer-tag: s2 est acheminé vers les services de la voie s2. Lorsque le trafic est envoyé au service mockb, qui n'existe pas dans la voie s2, le mécanisme de secours achemine la requête vers le service mockb de la voie de référence s1. Lorsque la chaîne d'appels se poursuit vers le service mockc, le trafic est correctement redirigé vers le service mockc de la voie s2. Il s'agit du comportement attendu.
3. Exécutez la commande suivante pour vérifier l'accès à la voie s3.
  
  La valeur de l'en-tête x-asm-prefer-tag, s3, correspond au nom que vous avez configuré pour la voie s3 lors de la sous-étape 2 de l'étape 1.
```
for i in {1..100};  do curl   -H 'x-asm-prefer-tag: s3' -H'my-trace-id: x000'$i http://${ASM_GATEWAY_IP}/mock ;  echo ''; sleep 1; done;
```
  Résultat attendu :
```
mocka(version: v1, ip: 172.17.0.54)-> mockb(version: v3, ip: 192.168.1.120)-> mockc(version: v1, ip: 172.17.0.130)
```
  Le résultat montre que le trafic portant l'en-tête de requête x-asm-prefer-tag: s3 est acheminé vers les services de la voie s3. Lorsque le trafic est envoyé aux services mocka et mockc, qui n'existent pas dans la voie s3, le mécanisme de secours achemine les requêtes vers les services mocka et mockc de la voie de référence s1. Il s'agit du comportement attendu.

Modifier la voie de référence en mode permissif

Remarque

Avant de pouvoir modifier la voie de référence, vous devez disposer d'un groupe de voies en mode permissif contenant au moins deux voies.

Connectez-vous à la console ASM. Dans le volet de navigation de gauche, sélectionnez Service Mesh > Mesh Management.
Sur la page Mesh Management, cliquez sur le nom de l'instance ASM. Dans le volet de navigation de gauche, choisissez Traffic Management Center > Traffic Lane.
Sur la page Traffic Lane, cliquez sur l'onglet du groupe de voies cible. Dans la section Traffic Rule Definition, cliquez sur l'icône située à côté de Baseline Lane.
Sélectionnez le nom de la nouvelle voie de référence et cliquez sur confirm edit.