Propager les en-têtes baggage - Alibaba Cloud Service Mesh - Centre de documentation Alibaba Cloud

Utilisez les voies de trafic en mode permissif pour isoler les versions des applications. Ce mécanisme propage un en-tête de requête de routage via les en-têtes baggage afin d'acheminer le trafic vers différentes voies. Lorsque des services au sein d'une voie de trafic s'appellent mutuellement, si le service cible n'existe pas dans la voie actuelle, la requête est transférée vers la voie de base. Cela 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 gérer le trafic de bout en bout ainsi que son contenu connexe.

Présentation du scénario

Cet exemple simule une chaîne d'appels composée de trois services (mocka, mockb et mockc) et de trois voies de trafic (s1, s2 et s3). Commencez par utiliser l'instrumentation automatique OpenTelemetry pour activer la propagation des en-têtes baggage pour les services. Créez ensuite trois voies de trafic en mode permissif et orientez le trafic à l'aide d'une politique de routage basée sur les poids.

Étape 1 : Déployer les exemples de services

Activez l'injection automatique du proxy sidecar pour le namespace par défaut. Pour plus d'informations, consultez la rubrique Gérer les namespaces globaux.

Remarque
Pour plus d'informations sur l'injection automatique, consultez la rubrique Configurer les politiques d'injection sidecar.

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

Contenu de mock.yaml

apiVersion: v1
kind: Service
metadata:
  name: mocka
  labels:
    app: mocka
    service: mocka
spec:
  ports:
  - port: 8000
    name: http
  selector:
    app: mocka
---
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
      annotations:
        instrumentation.opentelemetry.io/inject-java: "true"
        instrumentation.opentelemetry.io/container-names: "default"
    spec:
      containers:
      - name: default
        image: registry-cn-hangzhou.ack.aliyuncs.com/acs/asm-mock:v0.1-java
        imagePullPolicy: IfNotPresent
        env:
        - name: version
          value: v1
        - name: app
          value: mocka
        - name: upstream_url
          value: "http://mockb:8000/"
        ports:
        - containerPort: 8000
---
apiVersion: v1
kind: Service
metadata:
  name: mockb
  labels:
    app: mockb
    service: mockb
spec:
  ports:
  - port: 8000
    name: http
  selector:
    app: mockb
---
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
      annotations:
        instrumentation.opentelemetry.io/inject-java: "true"
        instrumentation.opentelemetry.io/container-names: "default"
    spec:
      containers:
      - name: default
        image: registry-cn-hangzhou.ack.aliyuncs.com/acs/asm-mock:v0.1-java
        imagePullPolicy: IfNotPresent
        env:
        - name: version
          value: v1
        - name: app
          value: mockb
        - name: upstream_url
          value: "http://mockc:8000/"
        ports:
        - containerPort: 8000
---
apiVersion: v1
kind: Service
metadata:
  name: mockc
  labels:
    app: mockc
    service: mockc
spec:
  ports:
  - port: 8000
    name: http
  selector:
    app: mockc
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mockc-v1
  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
      annotations:
        instrumentation.opentelemetry.io/inject-java: "true"
        instrumentation.opentelemetry.io/container-names: "default"
    spec:
      containers:
      - name: default
        image: registry-cn-hangzhou.ack.aliyuncs.com/acs/asm-mock:v0.1-java
        imagePullPolicy: IfNotPresent
        env:
        - name: version
          value: v1
        - name: app
          value: mockc
        ports:
        - containerPort: 8000
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mocka-v2
  labels:
    app: mocka
    version: v2
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mocka
      version: v2
      ASM_TRAFFIC_TAG: v2
  template:
    metadata:
      labels:
        app: mocka
        version: v2
        ASM_TRAFFIC_TAG: v2
      annotations:
        instrumentation.opentelemetry.io/inject-java: "true"
        instrumentation.opentelemetry.io/container-names: "default"
    spec:
      containers:
      - name: default
        image: registry-cn-hangzhou.ack.aliyuncs.com/acs/asm-mock:v0.1-java
        imagePullPolicy: IfNotPresent
        env:
        - name: version
          value: v2
        - name: app
          value: mocka
        - name: upstream_url
          value: "http://mockb:8000/"
        ports:
        - containerPort: 8000
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mockb-v2
  labels:
    app: mockb
    version: v2
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mockb
      version: v2
      ASM_TRAFFIC_TAG: v2
  template:
    metadata:
      labels:
        app: mockb
        version: v2
        ASM_TRAFFIC_TAG: v2
      annotations:
        instrumentation.opentelemetry.io/inject-java: "true"
        instrumentation.opentelemetry.io/container-names: "default"
    spec:
      containers:
      - name: default
        image: registry-cn-hangzhou.ack.aliyuncs.com/acs/asm-mock:v0.1-java
        imagePullPolicy: IfNotPresent
        env:
        - name: version
          value: v2
        - name: app
          value: mockb
        - name: upstream_url
          value: "http://mockc:8000/"
        ports:
        - containerPort: 8000
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mockc-v2
  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
      annotations:
        instrumentation.opentelemetry.io/inject-java: "true"
        instrumentation.opentelemetry.io/container-names: "default"
    spec:
      containers:
      - name: default
        image: registry-cn-hangzhou.ack.aliyuncs.com/acs/asm-mock:v0.1-java
        imagePullPolicy: IfNotPresent
        env:
        - name: version
          value: v2
        - name: app
          value: mockc
        ports:
        - containerPort: 8000
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mocka-v3
  labels:
    app: mocka
    version: v3
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mocka
      version: v3
      ASM_TRAFFIC_TAG: v3
  template:
    metadata:
      labels:
        app: mocka
        version: v3
        ASM_TRAFFIC_TAG: v3
      annotations:
        instrumentation.opentelemetry.io/inject-java: "true"
        instrumentation.opentelemetry.io/container-names: "default"
    spec:
      containers:
      - name: default
        image: registry-cn-hangzhou.ack.aliyuncs.com/acs/asm-mock:v0.1-java
        imagePullPolicy: IfNotPresent
        env:
        - name: version
          value: v3
        - name: app
          value: mocka
        - name: upstream_url
          value: "http://mockb:8000/"
        ports:
        - containerPort: 8000
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mockb-v3
  labels:
    app: mockb
    version: v3
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mockb
      version: v3
      ASM_TRAFFIC_TAG: v3
  template:
    metadata:
      labels:
        app: mockb
        version: v3
        ASM_TRAFFIC_TAG: v3
      annotations:
        instrumentation.opentelemetry.io/inject-java: "true"
        instrumentation.opentelemetry.io/container-names: "default"
    spec:
      containers:
      - name: default
        image: registry-cn-hangzhou.ack.aliyuncs.com/acs/asm-mock:v0.1-java
        imagePullPolicy: IfNotPresent
        env:
        - name: version
          value: v3
        - name: app
          value: mockb
        - name: upstream_url
          value: "http://mockc:8000/"
        ports:
        - containerPort: 8000
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mockc-v3
  labels:
    app: mockc
    version: v3
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mockc
      version: v3
      ASM_TRAFFIC_TAG: v3
  template:
    metadata:
      labels:
        app: mockc
        version: v3
        ASM_TRAFFIC_TAG: v3
      annotations:
        instrumentation.opentelemetry.io/inject-java: "true"
        instrumentation.opentelemetry.io/container-names: "default"
    spec:
      containers:
      - name: default
        image: registry-cn-hangzhou.ack.aliyuncs.com/acs/asm-mock:v0.1-java
        imagePullPolicy: IfNotPresent
        env:
        - name: version
          value: v3
        - name: app
          value: mockc
        ports:
        - containerPort: 8000

Ces annotations indiquent que le service est une application Java et demandent à l'opérateur OpenTelemetry d'instrumenter automatiquement le conteneur nommé default.

Exécutez la commande suivante pour déployer les exemples de services.
```
kubectl apply -f mock.yaml
```
L'instrumentation automatique OpenTelemetry permet aux pods de service déployés de propager automatiquement les en-têtes baggage tout au long de la chaîne d'appels.

Étape 2 : Créer un groupe de voies et ses voies de trafic

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

Saisissez test.

Entrance gateway

Sélectionnez ingressgateway.

Lane Mode

Sélectionnez Permissive Mode.

Pass-through Mode of Trace Context

Sélectionnez Pass Through Baggage Header.

Routing Request Header

Saisissez x-asm-prefer-tag.

Swimlane Services

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

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

Sur la page Traffic Lane, accédez à la section Traffic Rule Definition et cliquez sur Create swimlanes.
Dans la boîte de dialogue Create swimlanes, configurez les paramètres, puis cliquez sur OK.

Parameter	Description
Swimlane Name	Saisissez respectivement s1, s2 et s3 pour les trois voies de trafic.
Configure Service Tag	Label Key : Saisissez ASM_TRAFFIC_TAG. Label Value : Saisissez respectivement v1, v2 et v3 pour les trois voies de trafic.
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).

Par défaut, ASM définit la première voie de trafic créée dans un groupe de voies comme voie de base. Vous pouvez également modifier la voie de base. Lorsqu'un trafic est envoyé vers un service qui n'existe pas dans une autre voie de trafic, un mécanisme de secours transfère la requête vers la voie de base. Pour plus d'informations sur la modification de la voie de base, consultez la rubrique Modifier la voie de base en mode permissif.

Dans le volet de navigation de gauche de la console, sélectionnez Traffic Management Center > DestinationRule ou VirtualService pour afficher les ressources DestinationRule et VirtualService qu'ASM génère automatiquement pour chaque service du groupe de voies. Par exemple, les éléments DestinationRule et VirtualService suivants sont automatiquement créés pour le service mocka.

DestinationRule et VirtualService

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

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:
            x-asm-prefer-tag:
              exact: s1
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: s1
          fallback:
            target:
              host: mocka.default.svc.cluster.local
              subset: s1
    - match:
        - headers:
            x-asm-prefer-tag:
              exact: s2
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: s2
          fallback:
            target:
              host: mocka.default.svc.cluster.local
              subset: s1
    - match:
        - headers:
            x-asm-prefer-tag:
              exact: s3
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: s3
          fallback:
            target:
              host: mocka.default.svc.cluster.local
              subset: s1

Créez une règle de routage unifiée basée sur les poids.

Sur la page Traffic Lane, dans la section Traffic Rule Definition, cliquez sur Weight-based Routing dans la section Routing Policy.

Dans la boîte de dialogue Set Unified Routing Rules, configurez les paramètres, puis cliquez sur OK. L'exemple suivant montre comment configurer une règle de routage unifiée pour les trois voies de trafic, en supposant que l'API d'entrée pour le service de voie est /mock.

Parameter

Description

realm name

Définissez cette valeur sur *.

Matching request URI

Définissez Method sur Prefix et Content sur /.

Définissez les poids de routage pour les trois voies de trafic. Les poids déterminent la proportion de trafic envoyée vers chaque voie.

Sur la page Traffic Lane, dans la section Traffic Rule Definition, cliquez sur l'icône située à côté du numéro dans la colonne Traffic Routing Weight pour chaque voie. Dans la boîte de dialogue Edit Traffic Routing Weight, configurez les paramètres et cliquez sur OK.

Parameter	Description
Ingress service	Définissez cette valeur sur mocka.default.svc.cluster.local pour les trois voies de trafic.
Weight Value	Pour la voie s1, saisissez 60. Pour la voie s2, saisissez 20. Pour la voie s3, saisissez 20.

Étape 3 : Vérifier le déploiement canari de bout en bout

Obtenez l'adresse IP publique de la passerelle d'entrée ASM. Pour plus d'informations, consultez la rubrique Obtenir l'adresse IP de la passerelle d'entrée 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 le déploiement canari de bout en bout.

Exécutez la commande suivante pour observer le comportement d'accès à travers les trois voies de trafic.

for i in {1..100};  do curl http://${ASM_GATEWAY_IP}/ ;  echo ''; sleep 1; done;

Résultat attendu :

# Traffic to lane s1 (baseline): all services are v1.
-> mocka(version: v1, ip: 192.168.0.193)-> mockb(version: v1, ip: 192.168.0.1)-> mockc(version: v1, ip: 192.168.0.190)

# Traffic to lane s2: mocka and mockc are v2, mockb falls back to v1 in the baseline lane.
-> mocka(version: v2, ip: 192.168.0.184)-> mockb(version: v1, ip: 192.168.0.1)-> mockc(version: v2, ip: 192.168.0.189)

# Traffic to lane s3: mockb is v3, mocka and mockc fall back to v1 in the baseline lane.
-> mocka(version: v1, ip: 192.168.0.193)-> mockb(version: v3, ip: 192.168.0.2)-> mockc(version: v1, ip: 192.168.0.190)

# The output will show a mix of the above patterns, with distribution approximating 6:2:2 for s1:s2:s3.

Le résultat montre que le trafic est réparti entre les voies de trafic s1, s2 et s3 selon un ratio approximatif de 6:2:2. La voie s1 agit comme voie de base. Lorsqu'un service de la chaîne d'appels n'existe pas dans la voie cible, la requête revient vers le service correspondant dans la voie de base (s1).