Tous les produits
Search
Centre de documentation

Alibaba Cloud Service Mesh:Label traffic

Dernière mise à jour :Sep 21, 2026

Lorsque des microservices communiquent au sein d'un maillage, il est souvent nécessaire de diriger certaines requêtes vers des versions spécifiques de service, par exemple pour des déploiements canaris, des tests A/B ou l'isolation d'environnements. L'étiquetage du trafic dans Alibaba Cloud Service Mesh (ASM) associe des tags personnalisés aux requêtes lors de leur traversée du maillage, permettant ainsi aux règles de routage en aval, aux politiques de limitation et aux disjoncteurs d'agir sur ces tags.

ASM met à disposition la définition de ressource personnalisée (CRD) TrafficLabel pour définir des règles d'étiquetage. Appliquez une ressource TrafficLabel à un namespace ou à une charge de travail spécifique : ASM injecte automatiquement la logique d'étiquetage dans les filtres du proxy Envoy.

Cas d'utilisation

  • Déploiements canaris : acheminez un pourcentage du trafic vers une nouvelle version en faisant correspondre une valeur d'en-tête.

  • Tests A/B : répartissez le trafic entre différentes variantes à l'aide de règles de routage basées sur des étiquettes.

  • Isolation d'environnement : étiquetez le trafic comme staging ou production et acheminez-le vers les backends correspondants.

Prérequis

Avant de commencer, assurez-vous de disposer des éléments suivants :

  • Une instance ASM exécutant la version 1.17 ou ultérieure

  • Un cluster Kubernetes associé à votre instance ASM

  • kubectl configuré pour se connecter au cluster

Remarque

ASM 1.17 a introduit apiVersion: istio.alibabacloud.com/v1 pour la CRD TrafficLabel. Si vous avez précédemment configuré TrafficLabel dans un cluster Container Service for Kubernetes (ACK) en utilisant apiVersion: istio.alibabacloud.com/v1beta1, modifiez la valeur apiVersion par istio.alibabacloud.com/v1 et réappliquez la ressource. Pour mettre à jour votre instance ASM, consultez la rubrique Mettre à jour une instance ASM. Pour les versions antérieures d'ASM, soumettez un ticket pour obtenir de l'aide.

Fonctionnement de l'étiquetage du trafic

Une ressource TrafficLabel définit deux éléments :

  1. Portée : les charges de travail à étiqueter (toutes les charges de travail d'un namespace ou un sous-ensemble sélectionné par des étiquettes de pod).

  2. Règles : l'emplacement d'extraction de la valeur de l'étiquette (en-têtes de requête, étiquettes de pod ou contexte de trace).

Lorsqu'une requête entre dans une passerelle ou un proxy sidecar, le proxy évalue les règles TrafficLabel, résout une valeur d'étiquette et l'ajoute en tant que nouvel en-tête aux requêtes sortantes. Les services en aval peuvent ensuite utiliser cet en-tête pour prendre des décisions de routage.

Aperçu de la structure de la CRD

Le squelette suivant illustre l'imbrication des champs TrafficLabel :

apiVersion: istio.alibabacloud.com/v1
kind: TrafficLabel
metadata:
  name: <label-name>              # Name of this TrafficLabel resource
  namespace: <namespace>          # Namespace where this resource applies
spec:
  workloadSelector:               # (Optional) Omit to apply to all workloads in the namespace
    labels:
      <key>: <value>              # Match workloads by label, e.g., app: productpage
  rules:
  - labels:
    - name: <traffic-label-name>  # Header name for the label (must follow HTTP header naming rules)
      valueFrom:
      - <variable-1>             # Primary source for the label value
      - <variable-2>             # Fallback if variable-1 returns empty

Référence des champs

Spec

Champ Type Obligatoire Description
workloadSelector WorkloadSelector Non Sélectionne les charges de travail à étiqueter. Si omis, l'étiquetage s'applique à toutes les charges de travail du namespace.
rules TrafficLabelRule[] Oui Une ou plusieurs règles d'étiquetage.

WorkloadSelector

Champ Type Obligatoire Description
labels map Non Paires clé-valeur correspondant aux étiquettes de la charge de travail.

TrafficLabelRule

Champ Type Obligatoire Description
labels Label[] Oui Les étiquettes de trafic à associer.

Label

Champ Type Obligatoire Description
name string Oui Le nom de l'étiquette de trafic. Doit respecter les conventions de nommage des en-têtes de requête HTTP.
valueFrom string[] Oui Liste ordonnée de variables. Le proxy les évalue séquentiellement et utilise le premier résultat non vide. Consultez la section Variables valueFrom.

Variables valueFrom

Le champ valueFrom accepte une liste ordonnée de variables. Le proxy les évalue séquentiellement et utilise le premier résultat non vide comme valeur de l'étiquette.

Les quatre variables se divisent en deux groupes selon leur champ d'application :

Variable S'applique à Source de la valeur de l'étiquette
$getInboundRequestHeader(headerName) Passerelles uniquement En-tête de requête entrante au niveau de la passerelle
$getExternalInboundRequestHeader(headerName, contextId) Proxies sidecar uniquement En-tête de requête entrante, corrélé sur toute la chaîne d'appel via une carte de contexte
$getLocalOutboundRequestHeader(headerName) Proxies sidecar uniquement En-tête de requête sortante défini par l'application
$getLabel(labelName) Passerelles et proxies sidecar Étiquette de pod sur le pod de la passerelle ou de la charge de travail

Variable de passerelle

$getInboundRequestHeader(headerName)

Lit l'en-tête headerName de la requête entrante arrivant sur la passerelle. La passerelle ajoute un nouvel en-tête sortant en utilisant le nom de l'étiquette défini dans la CRD TrafficLabel comme clé et la valeur extraite comme valeur.

Si headerName est laissé vide, la passerelle lit x-asm-prefer-tag par défaut.

Flux de données :

Client request                    Gateway                         Upstream service
     |                              |                                   |
     |-- headerName: tagValue ----->|                                   |
     |                              |-- userDefinedLabel: tagValue ---->|
     |                              |                                   |

Data flow for $getInboundRequestHeader

Variables de proxy sidecar

$getExternalInboundRequestHeader(headerName, contextId)

Lit l'en-tête headerName de la requête entrante arrivant sur le proxy sidecar et stocke la valeur dans une carte de contexte interne indexée par contextId. Cette carte persiste pendant 30 secondes dans la mémoire d'Envoy.

Paramètres (tous deux obligatoires) :

Paramètre Description Exemple
headerName La clé d'en-tête de requête à lire. x-asm-prefer-tag
contextId Un champ d'en-tête qui persiste tout au long de la chaîne d'appel, utilisé pour corréler le trafic entrant et sortant. Généralement un ID de trace. x-request-id

Fonctionnement de la carte de contexte :

  1. Une requête entrante arrive au sidecar. Le proxy lit headerName pour obtenir tagValue et stocke map<contextId, tagValue>.

  2. Lorsque l'application initie une requête sortante, le proxy recherche contextId dans la carte de contexte.

  3. Si une correspondance est trouvée, le proxy ajoute deux en-têtes à la requête sortante :

    • headerName: tagValue

    • userDefinedLabel: tagValue (en utilisant le nom de l'étiquette issu de la CRD TrafficLabel)

Flux de données :

Inbound request       Sidecar proxy (context map)          Outbound request
     |                         |                                 |
     |-- headerName: tagValue  |                                 |
     |-- contextId: ctx123 --->| store: ctx123 -> tagValue       |
     |                         |                                 |
     |          App initiates outbound request                   |
     |                         |-- contextId: ctx123 ----------->|
     |                         |   (lookup: ctx123 -> tagValue)  |
     |                         |-- headerName: tagValue -------->|
     |                         |-- userDefinedLabel: tagValue -->|

Data flow for $getExternalInboundRequestHeader

Remarque
  • La carte de contexte (map<contextId, tagValue>) est stockée dans la mémoire du proxy Envoy pendant 30 secondes par défaut.

  • Lorsque votre application est connectée à un système de traçage, utilisez l'ID de trace comme contextId. Différents systèmes de traçage utilisent différents IDs de trace. Pour plus de détails, consultez la documentation Tracing.

  • Les applications doivent propager les en-têtes HTTP pertinents pour permettre aux proxies Istio de corréler les spans en une trace complète. Consultez la rubrique Activer le traçage distribué dans ASM.

  • Si l'application ne propage pas contextId, le proxy sidecar ne peut pas rechercher la valeur de l'étiquette dans la carte de contexte et la requête sortante ne sera pas étiquetée.

$getLocalOutboundRequestHeader(headerName)

Lit l'en-tête headerName de la requête sortante que l'application envoie au proxy sidecar. Le proxy ajoute un nouvel en-tête sortant en utilisant le nom de l'étiquette issu de la CRD TrafficLabel comme clé et la valeur extraite comme valeur.

Utilisez cette variable lorsque l'application elle-même définit un en-tête sur ses requêtes sortantes.

Flux de données :

Application container          Sidecar proxy              Upstream service
     |                              |                          |
     |-- headerName: tagValue ----->|                          |
     |                              |-- userDefinedLabel: tagValue -->|
     |                              |                          |

Data flow for $getLocalOutboundRequestHeader

Variable d'étiquette de pod

$getLabel(labelName)

Lit l'étiquette labelName du pod de la passerelle ou du pod de la charge de travail sidecar et ajoute la valeur au trafic sortant. Si labelName est vide, le proxy lit l'étiquette ASM_TRAFFIC_TAG par défaut.

Exemple : Si un pod de Deployment possède l'étiquette ASM_TRAFFIC_TAG: test, la variable $getLabel(ASM_TRAFFIC_TAG) renvoie test.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: productpage-v1
  labels:
    app: productpage
    version: v1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: productpage
      version: v1
  template:
    metadata:
      annotations:
        sidecar.istio.io/logLevel: debug
      labels:
        app: productpage
        version: v1
        ASM_TRAFFIC_TAG: test    # This value is read by $getLabel(ASM_TRAFFIC_TAG)
    spec:
      serviceAccountName: bookinfo-productpage
      containers:
      - name: productpage
        image: docker.io/istio/examples-bookinfo-productpage-v1:1.16.2
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 9080
        volumeMounts:
        - name: tmp
          mountPath: /tmp
      volumes:
      - name: tmp
        emptyDir: {}

Étiqueter le trafic pour une charge de travail spécifique

Cet exemple étiquette le trafic de la charge de travail productpage. La valeur de l'étiquette est résolue à partir de l'en-tête de requête entrante header1 (corrélé par x-request-id), avec un repli sur l'étiquette de pod header2.

Les deux exemples de cette page nécessitent ASM 1.17 ou une version ultérieure et utilisent l'application exemple Bookinfo.

  1. Déployez l'application Bookinfo. Consultez la rubrique Déployer une application dans une instance ASM.

  2. Enregistrez le YAML suivant dans le fichier productpage-trafficlabel.yaml :

       apiVersion: istio.alibabacloud.com/v1
       kind: TrafficLabel
       metadata:
         name: productpage
         namespace: default
       spec:
         workloadSelector:
           labels:
             app: productpage          # Only applies to the productpage workload
         rules:
         - labels:
           - name: asm-labels-test-a   # Outbound header name for the label
             valueFrom:
             - $getExternalInboundRequestHeader(header1, x-request-id)  # Primary: read from inbound header
             - $getLabel(header2)                                        # Fallback: read from pod label
  3. Appliquez la ressource :

       kubectl apply -n default -f productpage-trafficlabel.yaml
  4. Vérifiez que le filtre Envoy a été injecté dans le proxy productpage : recherchez le filtre com.aliyun.traffic_label sous dynamic_listeners ou http_filters :

       kubectl exec -it -n default deploy/productpage-v1 -c istio-proxy -- \
         curl localhost:15000/config_dump
       {
         "name": "com.aliyun.traffic_label",
         "typed_config": {
           "@type": "type.googleapis.com/envoy.config.filter.traffic_label.v3alpha.TrafficLabel",
           ...
         }
       }
  5. Confirmez que les charges de travail non sélectionnées ne sont pas affectées. Exécutez la même vérification sur le pod details : un résultat vide confirme qu'aucun filtre d'étiquetage n'a été injecté, comme prévu.

       kubectl exec -it -n default deploy/details-v1 -c istio-proxy -- \
         curl localhost:15000/config_dump | grep traffic_label

Étiqueter le trafic au niveau du namespace

Omettez workloadSelector pour étiqueter le trafic de toutes les charges de travail d'un namespace. Cet exemple étiquette toutes les charges de travail du namespace default.

  1. Enregistrez le YAML suivant dans le fichier all-workload-for-ns-trafficlabel.yaml :

       apiVersion: istio.alibabacloud.com/v1
       kind: TrafficLabel
       metadata:
         name: all-workload-for-ns
         namespace: default
       spec:
         rules:                        # No workloadSelector -- applies to every workload in "default"
         - labels:
           - name: asm-labels-test-b
             valueFrom:
             - $getExternalInboundRequestHeader(header1, x-request-id)
             - $getLabel(header2)
  2. Appliquez la ressource :

       kubectl apply -n default -f all-workload-for-ns-trafficlabel.yaml
  3. Vérifiez que le filtre d'étiquetage est désormais présent sur toutes les charges de travail. Vérifiez le pod details : Résultat attendu : le filtre est maintenant injecté dans chaque charge de travail du namespace.

       kubectl exec -it -n default deploy/details-v1 -c istio-proxy -- \
         curl localhost:15000/config_dump | grep traffic_label
       "@type": "type.googleapis.com/envoy.config.filter.traffic_label.v3alpha.TrafficLabel",

Rubriques connexes