Alibaba Cloud Service Mesh:Rotular tráfego

Pré-requisitos

Antes de começar, verifique se você tem:

• Uma instância do ASM executando a versão 1.17 ou posterior

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

• O kubectl configurado para conexão com o cluster

Como funciona a rotulagem de tráfego

Um recurso TrafficLabel define dois elementos:

1. Escopo -- As cargas de trabalho a serem rotuladas (todas as cargas de um namespace ou um subconjunto selecionado por rótulos de pod).

2. Regras -- A origem da extração do 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 valueFrom

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

As quatro variáveis dividem-se em dois grupos conforme o local de aplicação:

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 uma carga de trabalho específica

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

Ambos os exemplos nesta página exigem ASM 1.17 ou posterior e utilizam a aplicação de exemplo Bookinfo.

1. Implante a aplicação Bookinfo. Consulte Implantar uma aplicação em uma instância do ASM.

2. Salve o YAML a seguir em 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 productpage: Procure pelo 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 as cargas de trabalho não selecionadas não foram afetadas. Execute a mesma verificação no pod details: Um resultado vazio confirma que nenhum filtro de rotulagem foi injetado, conforme 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 de namespace

Omita workloadSelector para rotular o tráfego de todas as cargas de trabalho em um namespace. Este exemplo rotula todas as cargas de trabalho no namespace default.

1. Salve o YAML a seguir em 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 está presente em todas as cargas de trabalho. Verifique o pod details: Saída esperada: O filtro agora está injetado em todas as cargas de trabalho 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

• Implantar uma aplicação em uma instância do ASM -- Configure as cargas de trabalho na malha antes de definir rótulos de tráfego.

• Ativar rastreamento distribuído no ASM -- Propague os cabeçalhos de rastreamento necessários para $getExternalInboundRequestHeader.

• Atualizar uma instância do ASM -- Atualize para o ASM 1.17+ caso esteja em uma versão anterior.