Use traffic lanes and hash tagging to perform user-based canary testing - Alibaba Cloud Service Mesh

Service Mesh (ASM) permet d'isoler plusieurs versions ou fonctionnalités d'une application dans des environnements d'exécution indépendants, appelés voies de trafic, et d'acheminer le trafic des requêtes correspondantes vers la version ou la fonctionnalité cible en définissant des règles de voie. Dans un environnement de production, il peut être utile d'isoler les versions stables et les versions canari à l'aide de voies, puis d'acheminer le trafic vers différentes voies en fonction de l'identité de l'utilisateur. Plus précisément, vous pouvez souhaiter acheminer directement les requêtes de certains utilisateurs identifiés vers la version canari à des fins de test, tout en dirigeant une partie aléatoire du trafic des autres utilisateurs vers cette même version selon un pourcentage défini. Cette rubrique explique comment combiner les voies de trafic et le balisage par hachage pour mettre en œuvre des tests canari basés sur l'utilisateur.

Prérequis

Vous avez créé un cluster et l'avez ajouté à une instance ASM, dont la version est 1.18 ou ultérieure. Pour plus d'informations, consultez la rubrique Ajouter un cluster à une instance ASM.
Créez un cluster ACK managé ou un cluster ACS. Pour plus d'informations, consultez les rubriques Créer un cluster ACK managé ou Créer un cluster ACS.
Déployez une passerelle d'entrée. Pour plus d'informations, consultez la rubrique Créer une passerelle d'entrée.
Configurer la politique d'injection Sidecar.

Procédure

Ce scénario d'exemple crée trois applications suivant la chaîne d'appel ci-dessous.

mocka, version v1.
mockb, version v1.
mockc, versions v1 et v2.

Les applications utilisent l'en-tête de requête x-user-id pour identifier l'utilisateur ; cet en-tête est propagé à travers les appels de service. Ce scénario illustre les comportements suivants :

Si l'en-tête x-user-id: jason est présent, la requête est acheminée vers la nouvelle version.
Pour tous les autres utilisateurs, le système calcule un hachage de la valeur x-user-id et dirige un pourcentage spécifié d'utilisateurs vers la nouvelle version en fonction du résultat.

Étape 1 : Déployer les exemples d'applications

Créez un fichier nommé sample.yaml avec le contenu suivant.

Développer pour afficher le contenu YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mocka-v1
  labels:
    app: mocka
    version: v1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mocka
      version: v1
      ASM_TRAFFIC_TAG: v1
  template:
    metadata:
      labels:
        app: mocka
        version: v1
        ASM_TRAFFIC_TAG: v1
    spec:
      containers:
      - name: default
        image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/go-http-sample:tracing
        imagePullPolicy: IfNotPresent
        env:
        - name: version
          value: v1
        - name: app
          value: mocka
        - name: upstream_url
          value: "http://mockb:8000/"
        ports:
        - containerPort: 8000
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mockb-v1
  labels:
    app: mockb
    version: v1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mockb
      version: v1
      ASM_TRAFFIC_TAG: v1
  template:
    metadata:
      labels:
        app: mockb
        version: v1
        ASM_TRAFFIC_TAG: v1
    spec:
      containers:
      - name: default
        image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/go-http-sample:tracing
        imagePullPolicy: IfNotPresent
        env:
        - name: version
          value: v1
        - name: app
          value: mockb
        - name: upstream_url
          value: "http://mockc:8000/"
        ports:
        - containerPort: 8000
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mockc-v1
  namespace: default
  labels:
    app: mockc
    version: v1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mockc
      version: v1
      ASM_TRAFFIC_TAG: v1
  template:
    metadata:
      labels:
        app: mockc
        version: v1
        ASM_TRAFFIC_TAG: v1
    spec:
      containers:
      - name: default
        image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/go-http-sample:tracing
        imagePullPolicy: IfNotPresent
        env:
        - name: version
          value: v1
        - name: app
          value: mockc
        ports:
        - containerPort: 8000
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mockc-v2
  namespace: default
  labels:
    app: mockc
    version: v2
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mockc
      version: v2
      ASM_TRAFFIC_TAG: v2
  template:
    metadata:
      labels:
        app: mockc
        version: v2
        ASM_TRAFFIC_TAG: v2
    spec:
      containers:
      - name: default
        image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/go-http-sample:tracing
        imagePullPolicy: IfNotPresent
        env:
        - name: version
          value: v2
        - name: app
          value: mockc
        ports:
        - containerPort: 8000

À l'aide du fichier kubeconfig de votre cluster de plan de données, exécutez la commande suivante pour déployer les exemples d'applications.
```
kubectl apply -f sample.yaml
```

Étape 2 : Créer une règle de passerelle

Créez une ressource Gateway nommée ingressgateway dans le namespace istio-system en utilisant la configuration suivante. Pour plus d'informations, consultez la rubrique Gérer les règles de passerelle.

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: ingressgateway
  namespace: istio-system
spec:
  selector:
    istio: ingressgateway
  servers:
    - port:
        number: 80
        name: http
        protocol: HTTP
      hosts:
        - '*'

Étape 3 : 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, 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 puis cliquez sur OK.

Élément de configuration	Description
Name of swim lane group	Dans cet exemple, définissez la valeur sur canary.
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	Dans cet exemple, définissez la valeur sur x-user-id.
Routing Request Header	Spécifiez un en-tête que la passerelle utilise pour acheminer le trafic vers différentes voies et maintenir le contexte de voie. Vous pouvez définir n'importe quelle valeur. Dans cet exemple, définissez-la sur x-asm-prefer-tag.
Swimlane Services	Sélectionnez votre cluster Kubernetes cible et le namespace default. Dans la liste ci-dessous, sélectionnez les services mocka, mockb et mockc, puis cliquez sur l'icône pour les ajouter à la zone selected.

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

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.

Élément de configuration	Description
Swimlane Name	Définissez respectivement les valeurs s1 et s2.
Configure Service Tag	Label Key : sélectionnez ASM_TRAFFIC_TAG. Label Value : sélectionnez v1 pour une voie et v2 pour l'autre.
Add Service	Voie s1 : sélectionnez mocka(default), mockb(default) et mockc(default). Voie s2 : sélectionnez mockc(default).

L'image suivante illustre la création de la voie s1 :

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

Remarque

Par défaut, la première voie créée dans un groupe de voies devient la voie de référence. Vous pouvez modifier la voie de référence afin que, lorsqu'une requête cible un service absent d'une autre voie, celle-ci soit redirigée vers la voie de référence. Pour plus d'informations, consultez la rubrique Modifier la voie de référence en mode permissif.

Créez des règles de routage pour les voies.

Utilisez la configuration suivante pour créer une règle de routage de passerelle pour les voies. Cette règle comprend trois parties :

Les requêtes contenant x-user-id: jason sont acheminées vers la voie s2, et le système ajoute l'en-tête x-asm-prefer-tag: s2 pour marquer la requête destinée à la voie s2.
Les requêtes contenant x-asm-prefer-tag: s2 sont acheminées vers la voie s2.
Les requêtes contenant x-asm-prefer-tag: s1 sont acheminées vers la voie s1.

Développer pour afficher le contenu YAML

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: swimlane-ingress-vs
  namespace: istio-system
spec:
  gateways:
  - istio-system/ingressgateway
  hosts:
  - '*'
  http:
  # Routing rule 1: Requests with x-user-id: jason go to lane s2
  # and add x-asm-prefer-tag: s2 to mark the request for lane s2
  - match:
    - headers:
        x-user-id:
          exact: jason
      uri:
        exact: /
    name: r2
    route:
    - destination:
        host: mocka.default.svc.cluster.local
        subset: s2
      fallback:
        target:
          host: mocka.default.svc.cluster.local
          subset: s1
      headers:
        request:
          set:
            x-asm-prefer-tag: s2
  # Routing rule 2: Requests with x-asm-prefer-tag: s2 go to lane s2
  - match:
    - headers:
        x-asm-prefer-tag:
          exact: s2
      uri:
        exact: /
    name: r2
    route:
    - destination:
        host: mocka.default.svc.cluster.local
        subset: s2
      # If mocka is not in lane s2, fall back to mocka in lane s1
      fallback:
        target:
          host: mocka.default.svc.cluster.local
          subset: s1
  # Routing rule 3: Requests with x-asm-prefer-tag: s1 go to lane s1
  - match:
    - headers:
        x-asm-prefer-tag:
          exact: s1
      uri:
        exact: /
    name: r1
    route:
    - destination:
        host: mocka.default.svc.cluster.local
        subset: s1

Étape 4 : Déployer le plugin de balisage par hachage

Créez un fichier nommé wasm.yaml avec le contenu suivant.

apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
  name: hash-tagging
  namespace: istio-system
spec:
  imagePullPolicy: IfNotPresent 
  selector:
    matchLabels:
      istio: ingressgateway
  url: registry-cn-hangzhou.ack.aliyuncs.com/acs/asm-wasm-hash-tagging:v1.22.6.2-g72656ba-aliyun 
  phase: AUTHN
  pluginConfig:
    rules:
      - header: x-user-id
        modulo: 100
        tagHeader: x-asm-prefer-tag
        policies:
          # Route 20% of user traffic to lane s2
          - range: 20
            tagValue: s2
          # Route 80% of user traffic to lane s1
          - range: 100
            tagValue: s1

À l'aide du fichier kubeconfig de votre instance ASM, exécutez la commande suivante pour déployer le plugin de balisage.
```
kubectl apply -f wasm.yaml
```

Étape 5 : Vérifier la configuration

Exécutez la commande suivante pour définir une variable d'environnement temporaire correspondant à l'adresse de la passerelle d'entrée.
```
export GATEWAY_ADDRESS=`kubectl get svc -n istio-system | grep istio-ingressgateway | awk '{print $4}'`
```
Exécutez la commande suivante pour accéder à l'application en tant qu'utilisateur Jason.
```
curl ${GATEWAY_ADDRESS} -H 'x-user-id: jason'
```
Résultat attendu :
```
-> mocka(version: v1, ip: 10.0.0.15)-> mockb(version: v1, ip: 10.0.0.130)-> mockc(version: v2, ip: 10.0.0.133)%     
```
La requête est directement acheminée vers la version v2 de l'application mockc.

Exécutez la commande suivante pour acheminer aléatoirement des utilisateurs vers la nouvelle version.

 for i in 'bob' 'stacy' 'jessie' 'vance' 'jack'; do curl ${GATEWAY_ADDRESS} -H "x-user-id: $i";echo "   user $i requested"; done

Résultat attendu :

-> mocka(version: v1, ip: 10.0.0.15)-> mockb(version: v1, ip: 10.0.0.130)-> mockc(version: v1, ip: 10.0.0.131)   user bob requested
-> mocka(version: v1, ip: 10.0.0.15)-> mockb(version: v1, ip: 10.0.0.130)-> mockc(version: v1, ip: 10.0.0.131)   user stacy requested
-> mocka(version: v1, ip: 10.0.0.15)-> mockb(version: v1, ip: 10.0.0.130)-> mockc(version: v2, ip: 10.0.0.133)   user jessie requested
-> mocka(version: v1, ip: 10.0.0.15)-> mockb(version: v1, ip: 10.0.0.130)-> mockc(version: v1, ip: 10.0.0.131)   user vance requested
-> mocka(version: v1, ip: 10.0.0.15)-> mockb(version: v1, ip: 10.0.0.130)-> mockc(version: v2, ip: 10.0.0.133)   user jack requested

Les requêtes des utilisateurs Jessie et Jack sont acheminées vers la version v2 de mockc, tandis que celles des autres utilisateurs sont dirigées vers la version v1.