Configure faixas de tráfego e degradação de tráfego com base em regras de tráfego - Alibaba Cloud Service Mesh: Central de Documentação do Alibaba Cloud

As faixas de tráfego do Alibaba Cloud Service Mesh (ASM) isolam versões de aplicativos ou outras características em ambientes de execução independentes, direcionando o tráfego correspondente para as versões de destino por meio de regras de gerenciamento de tráfego, como VirtualService e DestinationRule. Quando a versão de destino fica indisponível, a degradação de tráfego roteia automaticamente as solicitações para uma versão de fallback especificada.

Pré-requisitos

Crie uma instância do ASM Enterprise Edition ou Ultimate Edition e verifique se a versão da instância é 1.17 ou posterior. Para mais informações, consulte Create an ASM instance ou Upgrade an ASM instance.
Adicione um cluster Kubernetes à instância do ASM. Para mais detalhes, consulte Add a cluster to an ASM instance.
Crie um gateway do ASM chamado ingressgateway. Para saber mais, consulte Create an ingress gateway.

Etapa 1: Implantar os services de exemplo

Para o namespace padrão, ative a injeção automática de sidecar. Para mais informações, consulte Enable automatic sidecar proxy injection.

Para mais detalhes sobre a injeção automática de sidecar, consulte Configure sidecar injection policies.
Use o arquivo kubeconfig do cluster do plano de dados e execute os seguintes comandos para implantar os services de exemplo.

Os services de exemplo incluem mocka, mockb e mockc. Cada service possui três versões: v1, v2 e v3.

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: Criar regras de tráfego para implementar uma faixa de tráfego

Conclua as seguintes subtarefas para criar as regras de roteamento de DestinationRule, VirtualService e gateway que definem a faixa de tráfego.

Crie regras de tráfego do DestinationRule

Para cada service, crie um DestinationRule a fim de definir subconjuntos de versões.

Use o seguinte conteúdo para criar o arquivo dr-mock.yaml.

O arquivo a seguir divide cada um dos services mocka, mockb e mockc em três subconjuntos: v1, v2 e v3.

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

Use o arquivo kubeconfig da instância do ASM e execute o seguinte comando para aplicar as regras de tráfego do DestinationRule.

kubectl apply -f dr-mock.yaml

Crie regras de tráfego do VirtualService

Para cada service interno, crie um VirtualService para definir o roteamento baseado na versão dentro da faixa de tráfego.

Use o seguinte conteúdo para criar o arquivo vs-mock.yaml.

O arquivo a seguir cria uma faixa de tráfego para a cadeia de invocação de services mocka→mockb→mockc. Após criar a faixa de tráfego, as solicitações enviadas por um service de uma versão específica serão encaminhadas apenas para services da mesma versão.

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

Use o arquivo kubeconfig da instância do ASM e execute o seguinte comando para aplicar as regras de tráfego do VirtualService.

kubectl apply -f vs-mock.yaml

Crie regras de roteamento de tráfego do gateway

Para direcionar solicitações externas para a faixa de tráfego com base no cabeçalho x-asm-prefer-tag, crie regras de roteamento do gateway.

Use o seguinte conteúdo para criar o arquivo gw-mock.yaml.

O arquivo a seguir cria regras de roteamento de tráfego do gateway para a cadeia de invocação de services mocka→mockb→mockc. As regras verificam o cabeçalho x-asm-prefer-tag das solicitações enviadas ao gateway e roteiam o tráfego para a versão v1, v2 ou v3 do service mocka com base no valor do cabeçalho.

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

Use o arquivo kubeconfig da instância do ASM e execute o seguinte comando para aplicar as regras de roteamento de tráfego do gateway.

kubectl apply -f gw-mock.yaml

Etapa 3: Verifique se a faixa de tráfego está em vigor

Obtenha o endereço IP público do gateway do ASM. Para mais detalhes, consulte Obtain the address of an ASM gateway.
Execute o seguinte comando para definir a variável de ambiente.

xxx.xxx.xxx.xxx é o endereço IP obtido na etapa anterior.

export ASM_GATEWAY_IP=xxx.xxx.xxx.xxx

Agora, verifique se a faixa de tráfego está em vigor.
Execute o seguinte comando e verifique as respostas da faixa de tráfego v1.

for i in {1..100};  do curl   -H 'x-asm-prefer-tag: v1' 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 esperada indica que o tráfego com o cabeçalho HTTP x-asm-prefer-tag: v1 flui para os services da versão v1.

Execute o seguinte comando e verifique as respostas da faixa de tráfego v2.

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

Saída esperada:

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

A saída esperada indica que o tráfego com o cabeçalho HTTP x-asm-prefer-tag: v2 flui para os services da versão v2.

Execute o seguinte comando e verifique as respostas da faixa de tráfego v3.

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

Saída esperada:

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

A saída esperada indica que o tráfego com o cabeçalho HTTP x-asm-prefer-tag: v3 flui para os services da versão v3.

(Opcional) Etapa 4: Configure a degradação de tráfego dentro da faixa de tráfego

Use o seguinte conteúdo e modifique o arquivo vs-mock.yaml.

O arquivo a seguir cria uma faixa de tráfego para a cadeia de invocação de services mocka→mockb→mockc. Além disso, quando a versão v2 ou v3 do mockb ou mockc fica indisponível, as solicitações serão encaminhadas para a cadeia de invocação da versão v1 do service.

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

Use o arquivo kubeconfig da instância do ASM, execute o seguinte comando e modifique as regras de tráfego do VirtualService existentes para aplicar a configuração de degradação de tráfego.

kubectl apply -f vs-mock.yaml

(Opcional) Etapa 5: Verifique se a degradação de tráfego está em vigor

Faça login no ACK console. No painel de navegação à esquerda, clique em Clusters.

Na página Clusters, clique no nome do seu cluster. No painel de navegação à esquerda, clique em Workloads > Deployments.

Na página Deployments, localize o workload mockb-v2 e clique em Scale na coluna Actions. Na caixa de diálogo Scale, defina Desired Pod Count como 1 e clique em OK. Na caixa de diálogo Confirm, clique em OK e confirme para simular uma falha no service mockb da versão v2.

Execute o seguinte comando e verifique as respostas da faixa de tráfego v2.

for i in {1..100};  do curl   -H 'x-asm-prefer-tag: v2' 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.126)-> mockc(version: v1, ip: 172.17.0.128)

A saída esperada indica que o tráfego com o cabeçalho HTTP x-asm-prefer-tag: v2 flui para os services da versão v2. Quando o tráfego passa pelo service mockb da versão v2, o sistema encaminha a solicitação para a cadeia de invocação da versão v1 do service, pois o service mockb da versão v2 falhou, implementando assim a degradação de tráfego.