Use permissive mode traffic lanes with propagated headers - Alibaba Cloud Service Mesh

Utilisez les traffic lanes en permissive mode pour assurer l'version isolation de vos applications. En définissant un E2E pass-through request header comme request routing header, vous dirigez le trafic vers des swimlanes spécifiques selon la valeur de cet en-tête. Si un service appelé au sein d'une swimlane n'existe pas dans la swimlane courante, la requête est transférée vers la baseline lane. Cette approche garantit l'intégrité de la chaîne d'appels et simplifie la gestion du trafic.

Important

Avant de commencer, lisez et comprenez la rubrique Utiliser des swimlanes en mode permissif pour gérer le trafic de bout en bout ainsi que son contenu associé.

Aperçu du scénario

Cet exemple utilise trois services, mocka, mockb et mockc, pour créer trois swimlanes (s1, s2 et s3) représentant trois versions d'une chaîne d'appels de service. La swimlane s1 constitue la baseline lane et contient les trois services. La swimlane s2 ne contient que les services mocka et mockc. La swimlane s3 ne contient que le service mockb. Dans ce scénario, l'E2E pass-through request header et l'request routing header sont tous deux définis sur my-trace-id.

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

Créez un groupe de swimlanes.

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, sélectionnez 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 et 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 Custom Header.
E2E Pass-through Request Header	Définissez cette valeur sur `my-trace-id`.
Swimlane service	Sélectionnez le cluster Kubernetes cible et le `namespace` default. Dans la liste des services, sélectionnez mocka, mockb et mockc. Cliquez sur l'icône pour les déplacer vers la zone selected.

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

Dans la section Traffic Lane de la page Traffic Rule Definition, cliquez sur Create swimlanes.

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

Parameter	Description
Swimlane Name	Définissez les noms des trois `swimlanes` respectivement sur s1, s2 et s3.
Configure Service Tag	Label Key : définissez sur ASM_TRAFFIC_TAG. Label Value : définissez respectivement sur v1, v2 et v3 pour les `swimlanes` `s1`, `s2` et `s3`.
Add Service	Pour la `swimlane` `s1` : sélectionnez mocka(default), mockb(default) et mockc(default). Pour la `swimlane` `s2` : sélectionnez mocka(default) et mockc(default). Pour la `swimlane` `s3` : sélectionnez mockb(default).

Une fois les trois swimlanes créées, le résultat s'affiche. Par défaut, la première swimlane créée dans un groupe devient la baseline lane. Vous pouvez modifier la baseline lane. Lorsque le trafic est envoyé vers un service inexistant dans une autre swimlane, le fallback mechanism transfère la requête vers la baseline lane. Pour plus d'informations sur la modification de la baseline lane, consultez la rubrique Modifier la baseline lane. Sur la page Traffic Rule Definition, la Baseline Lane est définie sur s1 et le Ingress Type est ASM Gateway (ingressgateway).

Après la création des trois swimlanes, Alibaba Cloud Service Mesh génère automatiquement une DestinationRule et une VirtualService pour chaque service du groupe de swimlane. Vous pouvez les afficher en sélectionnant Traffic Management Center > DestinationRule ou Virtual Service dans le volet de navigation de gauche. Par exemple, ASM crée automatiquement la DestinationRule et la VirtualService suivantes pour le service mocka.

Exemple de fichier 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 de fichier 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:
    - match:
        - headers:
            my-trace-id:
              exact: s1
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: s1
          fallback:
            target:
              host: mocka.default.svc.cluster.local
              subset: s1
    - match:
        - headers:
            my-trace-id:
              exact: s2
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: s2
          fallback:
            target:
              host: mocka.default.svc.cluster.local
              subset: s1
    - match:
        - headers:
            my-trace-id:
              exact: s3
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: s3
          fallback:
            target:
              host: mocka.default.svc.cluster.local
              subset: s1

Créez des traffic routing rules pour les trois swimlanes.

Dans la section Traffic Lane de la page Traffic Rule Definition, recherchez la swimlane cible et cliquez sur Ingress traffic rules dans la colonne Actions.

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

Cet exemple suppose que l'API d'entrée pour tous les services de la swimlane est /mock. Par conséquent, vous configurez la même traffic routing rule pour chaque swimlane.

Parameter	Description
Ingress service	Sélectionnez mocka.default.svc.cluster.local.
Ingress traffic rules	Pour les `traffic routing rules` des trois `swimlanes`, définissez respectivement le Name 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.

Une fois les traffic routing rules créées pour les trois swimlanes, le résultat s'affiche. En plus de la correspondance URI exacte, chaque règle inclut une condition de correspondance Headers : le nom de l'en-tête est my-trace-id, le type de correspondance est exact et les valeurs de correspondance pour les swimlanes s1, s2 et s3 sont respectivement s1, s2 et s3. La Baseline Lane est définie sur s1.

Après la création des règles, ASM génère automatiquement une VirtualService qui définit la traffic routing rule pour chaque swimlane. Par exemple, ASM génère la VirtualService suivante pour la swimlane s2.

Exemple de fichier 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:
            my-trace-id:
              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 le déploiement canari E2E

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

Dans la commande, xxx.xxx.xxx.xxx représente l'adresse IP obtenue à l'étape précédente.
```
export ASM_GATEWAY_IP=xxx.xxx.xxx.xxx
```
Vérifiez le E2E canary release.
1. Exécutez la commande suivante pour tester l'accès à la swimlane s1.
  
  La valeur my-trace-id, s1, correspond au nom de la swimlane s1 configuré à l'étape 1.2.
```
for i in {1..100};  do curl -H'my-trace-id: s1' 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 confirme que les requêtes contenant l'en-tête HTTP my-trace-id: s1 sont acheminées vers les services de la swimlane s1.
2. Exécutez la commande suivante pour tester l'accès à la swimlane s2.
  
  La valeur my-trace-id, s2, correspond au nom de la swimlane s2 configuré à l'étape 1.2.
```
for i in {1..100};  do curl -H'my-trace-id: s2' http://${ASM_GATEWAY_IP}/mock ;  echo ''; sleep 1; done;
```
  Résultat attendu :
```
mocka(version: v2, ip: 192.168.1.101)-> mockb(version: v1, ip: 192.168.1.100)-> mockc(version: v2, ip: 192.168.1.116)
```
  Le résultat indique que les requêtes contenant l'en-tête HTTP my-trace-id: s2 sont acheminées vers les services de la swimlane s2. Lorsqu'une requête cible le service mockb, qui n'existe pas dans la swimlane s2, le fallback mechanism transfère la requête vers le service mockb de la baseline lane s1. Les requêtes suivantes adressées au service mockc sont correctement acheminées vers le service mockc de la swimlane s2.
3. Exécutez la commande suivante pour tester l'accès à la swimlane s3.
  
  La valeur my-trace-id, s3, correspond au nom de la swimlane s3 configuré à l'étape 1.2.
```
for i in {1..100};  do curl -H'my-trace-id: s3' http://${ASM_GATEWAY_IP}/mock ;  echo ''; sleep 1; done;
```
  Résultat attendu :
```
mocka(version: v1, ip: 192.168.1.103)-> mockb(version: v3, ip: 192.168.1.120)-> mockc(version: v1, ip: 192.168.1.105)
```
  Le résultat indique que les requêtes contenant l'en-tête HTTP my-trace-id: s3 sont acheminées vers le service de la swimlane s3. Lorsque les requêtes ciblent les services mocka et mockc, qui n'existent pas dans la swimlane s3, le fallback mechanism transfère les requêtes vers les services mocka et mockc de la baseline lane s1.