Use permissive mode traffic lanes with propagated headers - Alibaba Cloud Service Mesh: Central de Documentação do Alibaba Cloud

Use traffic lanes em permissive mode para obter o version isolation da aplicação. Ao definir um E2E pass-through request header como request routing header, você pode usar o valor desse cabeçalho para rotear o tráfego para as swimlanes. Quando os serviços dentro de uma swimlane se comunicam e o serviço de destino não existe na swimlane atual, a solicitação é encaminhada para a baseline lane. Esse comportamento garante a integridade da cadeia de chamadas e simplifica o gerenciamento de tráfego.

Importante

Antes de começar, leia e compreenda o conteúdo de Usar traffic lanes em modo permissivo para gerenciar tráfego ponta a ponta e seus tópicos relacionados.

Visão geral do cenário

Este exemplo usa três serviços, mocka, mockb e mockc, para criar três swimlanes (s1, s2 e s3) que representam três versões de uma cadeia de chamadas de serviço. A swimlane s1 atua como baseline lane e contém todos os três serviços. A swimlane s2 inclui apenas os serviços mocka e mockc. A swimlane s3 contém somente o serviço mockb. Neste cenário, tanto o E2E pass-through request header quanto o request routing header estão definidos como my-trace-id.

Etapa 1: Criar um grupo de swimlanes e as swimlanes

Crie um grupo de swimlanes.

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 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	Escolha Pass Through Custom Header.
E2E Pass-through Request Header	Defina este valor como `my-trace-id`.
Swimlane service	Selecione o cluster Kubernetes de destino e o `namespace` default. Na lista de serviços, marque mocka, mockb e mockc. Clique em ícone para movê-los para a área selected.

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

Na seção Traffic Lane da página 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	Defina os nomes das três `swimlanes` como s1, s2 e s3, respectivamente.
Configure Service Tag	Label Key: Defina como ASM_TRAFFIC_TAG. Label Value: Defina como v1, v2 e v3 para as `swimlanes` `s1`, `s2` e `s3`, respectivamente.
Add Service	Para a `swimlane` `s1`: Selecione mocka(default), mockb(default) e mockc(default). Para a `swimlane` `s2`: Selecione mocka(default) e mockc(default). Para a `swimlane` `s3`: Selecione mockb(default).

Após a criação das três swimlanes, o resultado é exibido. Por padrão, a primeira swimlane criada em um grupo torna-se a baseline lane. Você pode alterar a baseline lane. Quando o tráfego é enviado para um serviço inexistente em outra swimlane, o fallback mechanism encaminha a solicitação para a baseline lane. Para mais informações sobre como alterar a baseline lane, consulte Modificar a baseline lane. Na página Traffic Rule Definition, a Baseline Lane está definida como s1 e o Ingress Type é ASM Gateway (ingressgateway).

Depois de criar as três swimlanes, o Alibaba Cloud Service Mesh gera automaticamente uma DestinationRule e um VirtualService para cada serviço no grupo de swimlanes. Para visualizá-los, escolha Traffic Management Center > DestinationRule ou Virtual Service no painel de navegação à esquerda. Por exemplo, o ASM cria automaticamente a seguinte DestinationRule e o seguinte VirtualService para o serviço mocka.

Exemplo de yaml da 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:
    - match:
        - headers:
            my-trace-id:
              exact: s1
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: s1
          fallback:
            target:
              host: mocka.default.svc.cluster.local
              subset: s1
    - match:
        - headers:
            my-trace-id:
              exact: s2
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: s2
          fallback:
            target:
              host: mocka.default.svc.cluster.local
              subset: s1
    - match:
        - headers:
            my-trace-id:
              exact: s3
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: s3
          fallback:
            target:
              host: mocka.default.svc.cluster.local
              subset: s1

Crie traffic routing rules para as três swimlanes.

Na seção Traffic Lane da página Traffic Rule Definition, localize a swimlane de destino 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 swimlane é /mock. Portanto, configure a mesma traffic routing rule para cada swimlane.

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

Após criar as traffic routing rules para as três swimlanes, o resultado é exibido. Além da correspondência exata de URI, cada regra inclui uma condição de correspondência de Headers: o nome do cabeçalho é my-trace-id, o tipo de correspondência é exato e os valores de correspondência para as swimlanes s1, s2 e s3 são s1, s2 e s3, respectivamente. A Baseline Lane está definida como s1.

Depois de criar as regras, o ASM gera automaticamente um VirtualService que define a traffic routing rule para cada swimlane. Por exemplo, o ASM gera o seguinte VirtualService para a swimlane 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:
            my-trace-id:
              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 E2E canary release

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

No comando, xxx.xxx.xxx.xxx representa o endereço ip obtido na etapa anterior.
```
export ASM_GATEWAY_IP=xxx.xxx.xxx.xxx
```
Verifique o E2E canary release.
1. Execute o comando a seguir para testar o acesso à swimlane s1.
  
  O valor s1 do campo my-trace-id corresponde ao nome da swimlane s1 configurada na Etapa 1.2.
```
for i in {1..100};  do curl -H'my-trace-id: s1' 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 confirma que as solicitações com o cabeçalho http my-trace-id: s1 são roteadas para os serviços na swimlane s1.
2. Execute o comando a seguir para testar o acesso à swimlane s2.
  
  O valor s2 do campo my-trace-id corresponde ao nome da swimlane s2 configurada na Etapa 1.2.
```
for i in {1..100};  do curl -H'my-trace-id: s2' http://${ASM_GATEWAY_IP}/mock ;  echo ''; sleep 1; done;
```
  Saída esperada:
```
mocka(version: v2, ip: 192.168.1.101)-> mockb(version: v1, ip: 192.168.1.100)-> mockc(version: v2, ip: 192.168.1.116)
```
  A saída mostra que as solicitações com o cabeçalho http my-trace-id: s2 são roteadas para os serviços na swimlane s2. Quando uma solicitação tem como alvo o serviço mockb, que não existe na swimlane s2, o fallback mechanism encaminha a solicitação para o serviço mockb na baseline lane s1. As solicitações subsequentes para o serviço mockc retornam corretamente ao serviço mockc na swimlane s2.
3. Execute o comando a seguir para testar o acesso à swimlane s3.
  
  O valor s3 do campo my-trace-id corresponde ao nome da swimlane s3 configurada na Etapa 1.2.
```
for i in {1..100};  do curl -H'my-trace-id: s3' http://${ASM_GATEWAY_IP}/mock ;  echo ''; sleep 1; done;
```
  Saída esperada:
```
mocka(version: v1, ip: 192.168.1.103)-> mockb(version: v3, ip: 192.168.1.120)-> mockc(version: v1, ip: 192.168.1.105)
```
  A saída indica que as solicitações com o cabeçalho http my-trace-id: s3 são roteadas para o serviço na swimlane s3. Quando as solicitações têm como alvo os serviços mocka e mockc, inexistentes na swimlane s3, o fallback mechanism encaminha essas solicitações para os serviços mocka e mockc na baseline lane s1.