Propagar um trace ID usando faixas de tráfego permissivas - Alibaba Cloud Service Mesh: Central de Documentação do Alibaba Cloud

Faixas de tráfego em modo permissivo permitem isolar versões de aplicações. O sistema roteia o tráfego para diferentes faixas com base nos cabeçalhos de requisição propagados e nos cabeçalhos de requisição de entrada. Quando os serviços dentro de uma faixa se comunicam e o serviço de destino não existe na faixa atual, o sistema encaminha a requisição para a faixa base. Esse mecanismo garante a integridade da cadeia de chamadas e simplifica o gerenciamento de tráfego.

Importante

Antes de começar, leia e compreenda o tópico Usar faixas de tráfego em modo permissivo para gerenciamento de tráfego ponta a ponta e seus conceitos relacionados.

Visão geral do cenário

Este exemplo utiliza três serviços (mocka, mockb e mockc) para criar três faixas de tráfego que representam três versões de uma cadeia de chamadas: s1, s2 e s3. A faixa s1 é a faixa base e contém todos os três serviços. A faixa s2 contém apenas os serviços mocka e mockc. A faixa s3 contém apenas o serviço mockb.

Etapa 1: Criar um grupo de faixas e faixas

Crie um grupo de faixas.

Faça login no console do ASM. No painel de navegação à esquerda, escolha Service Mesh > Mesh Management.
Na página Mesh Management, clique em nome da instância desejada. No painel de navegação à esquerda, escolha Traffic Management Center > Traffic Lane.

Na página Traffic Lane, clique em Create Swimlane Group. No painel Create Swimlane Group, configure os parâmetros e clique em OK.

Parâmetro	Descrição
Name of swim lane group	Neste exemplo, defina o nome como test.
Entrance gateway	Selecione ingressgateway.
Lane Mode	Selecione Permissive Mode.
Pass-through Mode of Trace Context	Selecione Pass Through Trace ID.
Trace ID Request Header	A aplicação de exemplo propaga o cabeçalho de requisição `my-trace-id` ao longo da cadeia de chamadas. Portanto, defina este parâmetro como `my-trace-id`.
Routing Request Header	Este cabeçalho é usado pelo gateway para rotear o tráfego de entrada para diferentes faixas e manter o contexto da faixa. Especifique qualquer nome de cabeçalho válido. Neste exemplo, use x-asm-prefer-tag.
Swimlane Services	Selecione o cluster Kubernetes desejado e o namespace default. Na lista de serviços disponíveis, selecione mocka, mockb e mockc, e clique em ícone para movê-los para a lista selected.

Após concluir a configuração, o sistema gera automaticamente um resource TrafficLabel correspondente. No painel de navegação à esquerda, clique em TrafficLabel para visualizar o resource. Por exemplo, o seguinte TrafficLabel é gerado para o serviço mocka.

Exemplo de YAML do TrafficLabel

apiVersion: istio.alibabacloud.com/v1beta1
kind: TrafficLabel
metadata:
  labels:
    asm-system: 'true'
    provider: asm
    swimlane-group: test
  name: asm-swimlane-test-mocka
  namespace: default
spec:
  rules:
    - labels:
        - name: asm-label
          valueFrom:
            - '$getExternalInboundRequestHeader(x-asm-prefer-tag, my-trace-id)'
  workloadSelector:
    labels:
      app: mocka

Crie as faixas s1, s2 e s3 e associe-as às versões v1, v2 e v3, respectivamente.

Na página Traffic Lane, na seção Traffic Rule Definition, clique em Create swimlanes.

Na caixa de diálogo Create swimlanes, configure os parâmetros e clique em OK.

Parâmetro	Descrição
Swimlane Name	Nomeie as três faixas como s1, s2 e s3, respectivamente.
Configure Service Tag	Label Key: Selecione ASM_TRAFFIC_TAG. Label Value: Selecione v1 para a faixa s1, v2 para a faixa s2 e v3 para a faixa s3.
Add Service	Faixa s1: Selecione mocka(default), mockb(default) e mockc(default). Faixa s2: Selecione mocka(default) e mockc(default). Faixa s3: Selecione mockb(default).

Após a criação das três faixas, o resultado será semelhante à figura a seguir:

Nota

Por padrão, a primeira faixa de tráfego criada em um grupo de faixas torna-se a faixa base. É possível modificar a faixa base posteriormente. Caso uma requisição tenha como destino um serviço que não esteja na faixa atual, o mecanismo de fallback a encaminhará para a faixa base. Para mais informações, consulte Modificar a faixa base no modo permissivo.

Depois que as três faixas são criadas, o sistema gera um DestinationRule e um VirtualService para cada serviço no grupo de faixas. No painel de navegação à esquerda, escolha Traffic Management Center > DestinationRule ou VirtualService para visualizar esses resources. Por exemplo, os seguintes DestinationRule e VirtualService são criados automaticamente para o serviço mocka.

Exemplo de YAML do DestinationRule

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

Exemplo de YAML do VirtualService

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:
    - name: default
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: $asm-label
          fallback:
            target:
              host: mocka.default.svc.cluster.local
              subset: s1

Crie regras de tráfego de entrada para as três faixas.

Na página Traffic Lane, na seção Traffic Rule Definition, localize a faixa desejada e clique em Ingress traffic rules na coluna Actions.

Na caixa de diálogo Add drainage rule, configure os parâmetros e clique em OK.

Este exemplo considera que a API de entrada para todos os serviços da faixa é /mock. Configure a mesma regra de tráfego de entrada para cada faixa.

Parâmetro	Descrição
Ingress service	Selecione mocka.default.svc.cluster.local.
Ingress traffic rules	Defina o Name das três regras como r1, r2 e r3, respectivamente. Defina o realm name como *.
Matching request URI	Defina o Method como Exact e o Content como /mock.

Após criar as regras de tráfego de entrada para as três faixas, a configuração fica da seguinte forma: faixa s1 (base, rótulo v1, com os serviços mocka, mockb e mockc), faixa s2 (rótulo v2, com os serviços mocka e mockc) e faixa s3 (rótulo v3, com o serviço mockb). Cada regra de tráfego de entrada também inclui uma condição de correspondência de cabeçalho para x-asm-prefer-tag que corresponde exatamente ao nome da faixa associada.

Ao criar as regras, o sistema gera automaticamente uma regra de tráfego de entrada (um VirtualService) para cada faixa. Por exemplo, o seguinte VirtualService é gerado para a faixa s2.

Exemplo de YAML do VirtualService

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  labels:
    asm-system: 'true'
    provider: asm
    swimlane-group: test
  name: swimlane-ingress-vs-test-s2
  namespace: istio-system
spec:
  gateways:
    - istio-system/ingressgateway
  hosts:
    - '*'
  http:
    - match:
        - headers:
            x-asm-prefer-tag:
              exact: s2
          uri:
            exact: /mock
      name: r2
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: s2
          fallback:
            target:
              host: mocka.default.svc.cluster.local
              subset: s1

Etapa 2: Verificar o recurso de canário ponta a ponta

Obtenha o endereço IP público do gateway de entrada do ASM. Para mais informações, consulte Obter o endereço IP do gateway de entrada do ASM.
Execute o comando a seguir para definir uma variável de ambiente.

Substitua xxx.xxx.xxx.xxx pelo endereço IP obtido na etapa anterior.
```
export ASM_GATEWAY_IP=xxx.xxx.xxx.xxx
```
Verifique se o recurso de canário ponta a ponta funciona conforme o esperado.
1. Execute o comando a seguir para verificar o acesso à faixa s1.
  
  O valor do cabeçalho x-asm-prefer-tag, s1, corresponde ao nome configurado para a faixa s1 na subetapa 2 da Etapa 1.
```
for i in {1..100};  do curl   -H 'x-asm-prefer-tag: s1' -H'my-trace-id: x000'$i http://${ASM_GATEWAY_IP}/mock ;  echo ''; sleep 1; done;
```
  Saída esperada:
```
-> mocka(version: v1, ip: 172.17.0.54)-> mockb(version: v1, ip: 172.17.0.129)-> mockc(version: v1, ip: 172.17.0.130)
```
  A saída mostra que o tráfego com o cabeçalho de requisição x-asm-prefer-tag: s1 foi roteado para os serviços na faixa s1, conforme esperado.
2. Execute o comando a seguir para verificar o acesso à faixa s2.
  
  O valor do cabeçalho x-asm-prefer-tag, s2, corresponde ao nome configurado para a faixa s2 na subetapa 2 da Etapa 1.
```
for i in {1..100};  do curl   -H 'x-asm-prefer-tag: s2' -H'my-trace-id: x000'$i http://${ASM_GATEWAY_IP}/mock ;  echo ''; sleep 1; done;
```
  Saída esperada:
```
-> mocka(version: v2, ip: 172.17.0.9)-> mockb(version: v1, ip: 172.17.0.129)-> mockc(version: v2, ip: 172.17.0.128)
```
  A saída indica que o tráfego com o cabeçalho de requisição x-asm-prefer-tag: s2 foi roteado para os serviços na faixa s2. Quando o tráfego é enviado ao serviço mockb, que não existe na faixa s2, o mecanismo de fallback roteia a requisição para o serviço mockb na faixa base s1. À medida que a cadeia de chamadas continua até o serviço mockc, o tráfego é corretamente roteado de volta para o serviço mockc na faixa s2. Esse é o comportamento esperado.
3. Execute o comando a seguir para verificar o acesso à faixa s3.
  
  O valor do cabeçalho x-asm-prefer-tag, s3, corresponde ao nome configurado para a faixa s3 na subetapa 2 da Etapa 1.
```
for i in {1..100};  do curl   -H 'x-asm-prefer-tag: s3' -H'my-trace-id: x000'$i http://${ASM_GATEWAY_IP}/mock ;  echo ''; sleep 1; done;
```
  Saída esperada:
```
mocka(version: v1, ip: 172.17.0.54)-> mockb(version: v3, ip: 192.168.1.120)-> mockc(version: v1, ip: 172.17.0.130)
```
  A saída demonstra que o tráfego com o cabeçalho de requisição x-asm-prefer-tag: s3 foi roteado para os serviços na faixa s3. Como os serviços mocka e mockc não existem na faixa s3, o mecanismo de fallback roteia as requisições para os serviços mocka e mockc na faixa base s1. Esse é o comportamento esperado.

Modificar a faixa base no modo permissivo

Nota

Para modificar a faixa base, é necessário ter um grupo de faixas em modo permissivo com pelo menos duas faixas.

Faça login no console do ASM. No painel de navegação à esquerda, escolha Service Mesh > Mesh Management.
Na página Mesh Management, clique em nome da instância do ASM. No painel de navegação à esquerda, escolha Traffic Management Center > Traffic Lane.
Na página Traffic Lane, clique em aba do grupo de faixas desejado. Na seção Traffic Rule Definition, clique em ícone ao lado de Baseline Lane.
Selecione o nome da nova faixa base e clique em confirm edit.