how to implement traffic lanes and traffic degradation based on traffic rule configurations - Alibaba Cloud Service Mesh: Central de Documentação do Alibaba Cloud

Ao lançar vários microsserviços simultaneamente, é essencial testar cada versão do serviço como uma cadeia de chamadas completa, sem impactar o tráfego de produção. As faixas de tráfego isolam as cadeias de chamadas dos serviços versionados em ambientes de execução independentes. Dessa forma, uma solicitação que entra em uma faixa permanece nela de ponta a ponta. Caso uma versão dentro da faixa fique indisponível, o desvio de tráfego redireciona as solicitações para uma versão de fallback designada, evitando interrupções.

As etapas a seguir abordam a configuração completa no Service Mesh (ASM): definição de subconjuntos de versões com DestinationRules, roteamento de tráfego entre serviços por versão com VirtualServices, direcionamento de tráfego de entrada para faixas específicas via cabeçalhos HTTP e configuração de fallback quando o destino de uma faixa estiver indisponível.

Como funcionam as faixas de tráfego

Uma faixa de tráfego é construída a partir de três primitivos de gerenciamento de tráfego do Istio:

Primitivo	Função nas faixas de tráfego
DestinationRule	Declara subconjuntos de versões (v1, v2, v3) para cada serviço com base nos rótulos dos pods. Define quais versões existem.
VirtualService	Roteia o tráfego entre serviços com base em `sourceLabels`, mantendo as solicitações na mesma faixa de versão. Define para onde o tráfego vai.
Gateway + VirtualService	Direciona o tráfego de entrada para a faixa correta com base em um cabeçalho HTTP (`x-asm-prefer-tag`). Funciona como o ponto de entrada para uma faixa.

O diagrama abaixo ilustra três faixas, cada uma contendo uma cadeia de chamadas completa v1, v2 ou v3:

                    ┌─────────────────────────────────────┐
  x-asm-prefer-tag: │  Lane v1: mocka v1 → mockb v1 → mockc v1  │
  v1                └─────────────────────────────────────┘
                    ┌─────────────────────────────────────┐
  x-asm-prefer-tag: │  Lane v2: mocka v2 → mockb v2 → mockc v2  │
  v2                └─────────────────────────────────────┘
                    ┌─────────────────────────────────────┐
  x-asm-prefer-tag: │  Lane v3: mocka v3 → mockb v3 → mockc v3  │
  v3                └─────────────────────────────────────┘

O desvio de tráfego adiciona um mecanismo de fallback: se uma versão de serviço em uma faixa ficar indisponível, o ASM redireciona o tráfego para uma versão de fallback designada (geralmente a v1).

Pré-requisitos

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

Uma instância do ASM das edições Enterprise ou Ultimate, versão 1,17 ou posterior. Consulte Crie uma instância do ASM ou Atualize uma instância do ASM
Um cluster Kubernetes adicionado à instância do ASM. Consulte Adicionar um cluster a uma instância do ASM
Um gateway do ASM chamado ingressgateway. Consulte Crie um gateway de entrada

Etapa 1: Implantar serviços de exemplo

Este tutorial utiliza três serviços de exemplo — mocka, mockb e mockc —, cada um implantado em três versões (v1, v2, v3). A cadeia de chamadas flui de mocka para mockb e depois para mockc.

Ative a injeção automática de proxy sidecar no namespace default. Para mais detalhes, consulte a seção "Enable automatic sidecar injection" no tópico Gerencie namespaces globais ou veja Ative injeção automática de proxy sidecar.

Implante os serviços de exemplo usando o arquivo kubeconfig do cluster no plano de dados:

   kubectl apply -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v1/application-v1.yaml
   kubectl apply -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v2/application-v2.yaml
   kubectl apply -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v3/application-v3.yaml

Etapa 2: Defina subconjuntos de versões com DestinationRules

Os DestinationRules declaram os subconjuntos de versões disponíveis para cada serviço. Cada subconjunto mapeia pods com um rótulo version correspondente.

Crie um arquivo chamado dr-mock.yaml com o conteúdo a seguir. Campos principais:

Campo	Descrição
`namespace: istio-system`	Aplicado no namespace do plano de controle do ASM, não no namespace da aplicação.
`host`	Nome totalmente qualificado do serviço, como `mocka.default.svc.cluster.local`.
`subsets[].labels.version`	Corresponde ao rótulo `version` nos pods implantados na Etapa 1.

Show dr-mock.yaml

   apiVersion: networking.istio.io/v1beta1
   kind: DestinationRule
   metadata:
     name: mocka
     namespace: istio-system
   spec:
     host: mocka.default.svc.cluster.local
     subsets:
       - labels:
           version: v1
         name: v1
       - labels:
           version: v2
         name: v2
       - labels:
           version: v3
         name: v3
   ---
   apiVersion: networking.istio.io/v1beta1
   kind: DestinationRule
   metadata:
     name: mockb
     namespace: istio-system
   spec:
     host: mockb.default.svc.cluster.local
     subsets:
       - labels:
           version: v1
         name: v1
       - labels:
           version: v2
         name: v2
       - labels:
           version: v3
         name: v3
   ---
   apiVersion: networking.istio.io/v1beta1
   kind: DestinationRule
   metadata:
     name: mockc
     namespace: istio-system
   spec:
     host: mockc.default.svc.cluster.local
     subsets:
       - labels:
           version: v1
         name: v1
       - labels:
           version: v2
         name: v2
       - labels:
           version: v3
         name: v3

Aplique o DestinationRule usando o arquivo kubeconfig da instância do ASM:
```
   kubectl apply -f dr-mock.yaml
```

Etapa 3: Roteador tráfego dentro das faixas usando VirtualServices

Os VirtualServices roteiam o tráfego entre serviços com base em sourceLabels, mantendo as solicitações na mesma faixa de versão. Quando o mocka v2 chama o mockb, o VirtualService identifica o rótulo de origem version: v2 e encaminha a solicitação para o mockb v2.

Crie um arquivo chamado vs-mock.yaml com o conteúdo a seguir. Campos principais: As regras de roteamento são avaliadas de cima para baixo. A primeira correspondência vence.

Campo	Descrição
`sourceLabels`	Corresponde ao rótulo `version` do pod chamador. Um chamador v2 alcança apenas destinos v2, mantendo o tráfego dentro da faixa.
`subset`	Referencia o nome do subconjunto definido no DestinationRule (Etapa 2).

Show vs-mock.yaml

   apiVersion: networking.istio.io/v1alpha3
   kind: VirtualService
   metadata:
     name: mockb
     namespace: istio-system
   spec:
     hosts:
       - mockb.default.svc.cluster.local
     http:
     - match:
       - sourceLabels:
           version: v1
       route:
       - destination:
           host: mockb.default.svc.cluster.local
           subset: v1
     - match:
       - sourceLabels:
           version: v2
       route:
       - destination:
           host: mockb.default.svc.cluster.local
           subset: v2
     - match:
       - sourceLabels:
           version: v3
       route:
       - destination:
           host: mockb.default.svc.cluster.local
           subset: v3
   ---
   apiVersion: networking.istio.io/v1alpha3
   kind: VirtualService
   metadata:
     name: mockc
     namespace: istio-system
   spec:
     hosts:
       - mockc.default.svc.cluster.local
     http:
     - match:
       - sourceLabels:
           version: v1
       route:
       - destination:
           host: mockc.default.svc.cluster.local
           subset: v1
     - match:
       - sourceLabels:
           version: v2
       route:
       - destination:
           host: mockc.default.svc.cluster.local
           subset: v2
     - match:
       - sourceLabels:
           version: v3
       route:
       - destination:
           host: mockc.default.svc.cluster.local
           subset: v3

Aplique o VirtualService usando o arquivo kubeconfig da instância do ASM:
```
   kubectl apply -f vs-mock.yaml
```

Etapa 4: Roteador tráfego de entrada para faixas via cabeçalhos HTTP

Um Gateway e um VirtualService no nível do gateway direcionam as solicitações recebidas para a faixa correta com base no cabeçalho HTTP x-asm-prefer-tag. Durante testes canário, um engenheiro de QA ou um pipeline de CI/CD adiciona x-asm-prefer-tag: v2 às solicitações de teste. Isso as roteia para a faixa v2, enquanto o tráfego de produção continua fluindo para a v1.

Crie um arquivo chamado gw-mock.yaml com o conteúdo a seguir. Campos principais:

Campo	Descrição
`selector: istio: ingressgateway`	Vincula o Gateway aos pods do gateway de entrada do ASM.
`x-asm-prefer-tag`	Determina qual faixa recebe a solicitação. O valor deve corresponder exatamente a uma versão (v1, v2 ou v3).
`uri: exact: /mock`	Tanto o cabeçalho quanto a URI devem corresponder para que a rota seja aplicada.

Show gw-mock.yaml

   apiVersion: networking.istio.io/v1beta1
   kind: Gateway
   metadata:
     name: ingressgateway
     namespace: istio-system
   spec:
     selector:
       istio: ingressgateway
     servers:
       - port:
           number: 80
           name: http
           protocol: HTTP
         hosts:
           - '*'
   ---
   apiVersion: networking.istio.io/v1beta1
   kind: VirtualService
   metadata:
     name: ingressgateway
     namespace: istio-system
   spec:
     gateways:
       - istio-system/ingressgateway
     hosts:
       - '*'
     http:
       - match:
           - headers:
               x-asm-prefer-tag:
                 exact: v1
             uri:
               exact: /mock
         route:
           - destination:
               host: mocka.default.svc.cluster.local
               subset: v1
       - match:
           - headers:
               x-asm-prefer-tag:
                 exact: v2
             uri:
               exact: /mock
         route:
           - destination:
               host: mocka.default.svc.cluster.local
               subset: v2
       - match:
           - headers:
               x-asm-prefer-tag:
                 exact: v3
             uri:
               exact: /mock
         route:
           - destination:
               host: mocka.default.svc.cluster.local
               subset: v3

Aplique o Gateway e as regras de roteamento usando o arquivo kubeconfig da instância do ASM:
```
   kubectl apply -f gw-mock.yaml
```

Etapa 5: Verifique as faixas de tráfego

Obtenha o endereço IP público do gateway do ASM. Para detalhes, consulte a Etapa 2 em Integrar KServe com ASM.
Defina o IP do gateway como uma variável de ambiente. Substitua xxx.xxx.xxx.xxx pelo endereço IP real:
```
   export ASM_GATEWAY_IP=xxx.xxx.xxx.xxx
```

Envie solicitações de teste para cada faixa e verifique se o tráfego permanece na versão correta. Teste a faixa v1: Saída esperada: Todos os três serviços respondem com a versão v1, confirmando que o tráfego permanece na faixa v1. Teste a faixa v2: Saída esperada: Teste a faixa v3: Saída esperada: Cada faixa roteia o tráfego exclusivamente para serviços da versão correspondente, confirmando que o isolamento da faixa funciona corretamente.

   for i in {1..100};  do curl   -H 'x-asm-prefer-tag: v1' http://${ASM_GATEWAY_IP}/mock ;  echo ''; sleep 1; done;

   -> mocka(version: v1, ip: 172.17.0.54)-> mockb(version: v1, ip: 172.17.0.129)-> mockc(version: v1, ip: 172.17.0.130)

   for i in {1..100};  do curl   -H 'x-asm-prefer-tag: v2' http://${ASM_GATEWAY_IP}/mock ;  echo ''; sleep 1; done;

   -> mocka(version: v2, ip: 172.17.0.9)-> mockb(version: v2, ip: 172.17.0.126)-> mockc(version: v2, ip: 172.17.0.128)

   for i in {1..100};  do curl   -H 'x-asm-prefer-tag: v3' http://${ASM_GATEWAY_IP}/mock ;  echo ''; sleep 1; done;

   -> mocka(version: v3, ip: 172.17.0.132)-> mockb(version: v3, ip: 172.17.0.127)-> mockc(version: v3, ip: 172.17.0.69)

Etapa 6: Adicionar desvio de tráfego com fallback

O desvio de tráfego aumenta a resiliência das faixas. Com uma configuração de fallback, o ASM redireciona o tráfego para uma versão estável (v1) quando a versão alvo está indisponível, prevenindo interrupções de serviço durante lançamentos canário.

Substitua o conteúdo de vs-mock.yaml pela configuração a seguir. Isso adiciona um bloco fallback às rotas v2 e v3, direcionando o tráfego para o subconjunto v1 quando a versão alvo estiver inacessível. Campos principais:

Campo	Descrição
`fallback.target.host` e `fallback.target.subset`	O destino de fallback. Aqui, tanto `mockb` quanto `mockc` retornam para a v1.
Rota v1 (sem fallback)	A v1 serve como linha de base estável, portanto não precisa de um destino de fallback.
Fallback por rota	O destino de fallback de cada versão é configurado independentemente.

Show updated vs-mock.yaml

   apiVersion: networking.istio.io/v1alpha3
   kind: VirtualService
   metadata:
     name: mockb
     namespace: istio-system
   spec:
     hosts:
       - mockb.default.svc.cluster.local
     http:
     - match:
       - sourceLabels:
           version: v1
       route:
       - destination:
           host: mockb.default.svc.cluster.local
           subset: v1
     - match:
       - sourceLabels:
           version: v2
       route:
       - destination:
           host: mockb.default.svc.cluster.local
           subset: v2
         fallback:
           target:
             host: mockb.default.svc.cluster.local
             subset: v1
     - match:
       - sourceLabels:
           version: v3
       route:
       - destination:
           host: mockb.default.svc.cluster.local
           subset: v3
         fallback:
           target:
             host: mockb.default.svc.cluster.local
             subset: v1
   ---
   apiVersion: networking.istio.io/v1alpha3
   kind: VirtualService
   metadata:
     name: mockc
     namespace: istio-system
   spec:
     hosts:
       - mockc.default.svc.cluster.local
     http:
     - match:
       - sourceLabels:
           version: v1
       route:
       - destination:
           host: mockc.default.svc.cluster.local
           subset: v1
     - match:
       - sourceLabels:
           version: v2
       route:
       - destination:
           host: mockc.default.svc.cluster.local
           subset: v2
         fallback:
           target:
             host: mockc.default.svc.cluster.local
             subset: v1
     - match:
       - sourceLabels:
           version: v3
       route:
       - destination:
           host: mockc.default.svc.cluster.local
           subset: v3
         fallback:
           target:
             host: mockc.default.svc.cluster.local
             subset: v1

Aplique o VirtualService atualizado usando o arquivo kubeconfig da instância do ASM:
```
   kubectl apply -f vs-mock.yaml
```

Etapa 7: Verifique o desvio de tráfego

Simule uma falha de serviço para confirme se o roteamento de fallback funciona.

Faça login no console do ACK. No painel de navegação à esquerda, clique em Clusters.
Na página Clusters, clique em no nome do cluster alvo e escolha Workloads > Deployments no painel de navegação à esquerda.
Na página Deployments, localize a carga de trabalho mockb-v2 e clique em Scale na coluna Actions. Na caixa de diálogo Scale, defina Desired Number of Pods como 1 e clique em OK. Clique em Confirm para aplicar. Isso simula uma falha no serviço mockb v2.
Envie solicitações de teste para a faixa v2: Saída esperada: A solicitação entra pelo mocka v2 (correspondendo ao cabeçalho x-asm-prefer-tag: v2). Como o mockb v2 está indisponível, o tráfego é desviado para o mockb v1, que então roteia para o mockc v1 através da faixa v1. O desvio de tráfego funciona conforme esperado.
```
   for i in {1..100};  do curl   -H 'x-asm-prefer-tag: v2' http://${ASM_GATEWAY_IP}/mock ;  echo ''; sleep 1; done;
```
```
   -> mocka(version: v2, ip: 172.17.0.9)-> mockb(version: v1, ip: 172.17.0.126)-> mockc(version: v1, ip: 172.17.0.128)
```

Limpar recursos

Para remover todos os recursos criados neste tutorial:

# Delete traffic rules (using ASM kubeconfig)
kubectl delete -f gw-mock.yaml
kubectl delete -f vs-mock.yaml
kubectl delete -f dr-mock.yaml

# Delete sample services (using cluster kubeconfig)
kubectl delete -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v1/application-v1.yaml
kubectl delete -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v2/application-v2.yaml
kubectl delete -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v3/application-v3.yaml