Alibaba Cloud Service Mesh:Label traffic

Pré-requisitos

Antes de começar, certifique-se de ter:

• Uma instância do ASM na versão 1,17 ou posterior

• Um cluster Kubernetes associado à sua instância do ASM

• kubectl configurado para conectar-se ao cluster

Como funciona a rotulagem de tráfego

Um recurso TrafficLabel define duas coisas:

1. Escopo — Quais workloads rotular (todos os workloads de um namespace ou um subconjunto selecionado por rótulos de pod).

2. Regras — De onde extrair o valor do rótulo (cabeçalhos de requisição, rótulos de pod ou contexto de rastreamento).

Quando uma requisição entra em um gateway ou proxy sidecar, o proxy avalia as regras do TrafficLabel, resolve um valor de rótulo e o anexa como um novo cabeçalho nas requisições de saída. Os serviços downstream podem então usar esse cabeçalho para tomar decisões de roteamento.

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

Referência de campos

Variáveis de valueFrom

O campo valueFrom aceita uma lista ordenada de variáveis. O proxy as avalia em sequência e usa o primeiro resultado não vazio como valor do rótulo.

As quatro variáveis se dividem em dois grupos, de acordo com o local onde se aplicam:

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

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

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

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: {}

Rotular tráfego para um workload específico

Este exemplo rotula o tráfego do workload productpage. O valor do rótulo é resolvido a partir do cabeçalho da requisição de entrada header1 (correlacionado por x-request-id), com fallback para o rótulo de pod header2.

Ambos os exemplos desta página exigem ASM 1.17 ou posterior e utilizam o aplicativo de exemplo Bookinfo.

1. Implante o aplicativo Bookinfo. Consulte Deploy an application in an ASM instance.

2. Salve o YAML a seguir no arquivo 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. Aplique o recurso:

      kubectl apply -n default -f productpage-trafficlabel.yaml

4. Verifique se o filtro Envoy foi injetado no proxy do productpage: procure o filtro com.aliyun.traffic_label em 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. Confirme que os workloads não selecionados não foram afetados. Execute a mesma verificação no pod details: um resultado vazio confirme que nenhum filtro de rotulagem foi injetado, como esperado.

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

Rotular tráfego no nível do namespace

Omita workloadSelector para rotular o tráfego de todos os workloads em um namespace. Este exemplo rotula todos os workloads no namespace default.

1. Salve o YAML a seguir no arquivo 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. Aplique o recurso:

      kubectl apply -n default -f all-workload-for-ns-trafficlabel.yaml

3. Verifique se o filtro de rotulagem agora está presente em todos os workloads. Confira o pod details: a saída esperada indica que o filtro foi injetado em todos os workloads do 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",

Tópicos relacionados

• Deploy an application in an ASM instance — Configure workloads na sua malha antes de definir rótulos de tráfego.

• Enable distributed tracing in ASM — Propague os cabeçalhos de rastreamento exigidos por $getExternalInboundRequestHeader.

• Update an ASM instance — Atualize para o ASM 1.17+ caso esteja em uma versão anterior.