Use faixas de tráfego e hash tagging para testes canary baseados em usuário - Alibaba Cloud Service Mesh: Central de Documentação do Alibaba Cloud

Service Mesh (ASM) permite isolar várias versões ou recursos de uma aplicação em ambientes de execução independentes, chamados faixas de tráfego, e rotear o tráfego de requisições correspondentes para a versão ou recurso de destino mediante a definição de regras de faixa. Em produção, isole versões estáveis e de lançamento canary usando faixas e direcione o tráfego para diferentes faixas com base na identidade do usuário. Especificamente, você pode rotear requisições de usuários identificados diretamente para a versão canary para testes e, simultaneamente, direcionar uma parcela aleatória do tráfego de outros usuários para a versão canary com base em peso. Este tópico descreve como combinar faixas de tráfego e hash tagging para implementar testes canary baseados em usuário.

Pré-requisitos

Um cluster criado e adicionado a uma instância do ASM com versão 1.18 ou posterior. Para mais informações, consulte Adicionar um cluster a uma instância do ASM.
Crie um cluster gerenciado ACK ou um cluster ACS. Para mais informações, consulte Criar um cluster gerenciado ACK ou Criar um cluster ACS.
Implante um gateway de entrada. Para mais informações, consulte Criar um gateway de entrada.
Configure a política de injeção de Sidecar.

Procedimento

Este cenário de exemplo cria três aplicações com a seguinte cadeia de chamadas:

mocka, versão v1.
mockb, versão v1.
mockc, versões v1 e v2.

As aplicações usam o cabeçalho de requisição x-user-id para identificar o usuário, propagando esse cabeçalho nas chamadas de serviço. Este cenário demonstra o seguinte comportamento:

Se x-user-id: jason, a requisição é roteada para a nova versão.
Para todos os outros usuários, o sistema calcula um hash do valor de x-user-id e roteia uma porcentagem especificada deles para a nova versão com base no resultado do hash.

Etapa 1: Implantar aplicações de exemplo

Crie um arquivo chamado sample.yaml com o seguinte conteúdo:

Expandir para visualizar o conteúdo YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mocka-v1
  labels:
    app: mocka
    version: v1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mocka
      version: v1
      ASM_TRAFFIC_TAG: v1
  template:
    metadata:
      labels:
        app: mocka
        version: v1
        ASM_TRAFFIC_TAG: v1
    spec:
      containers:
      - name: default
        image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/go-http-sample:tracing
        imagePullPolicy: IfNotPresent
        env:
        - name: version
          value: v1
        - name: app
          value: mocka
        - name: upstream_url
          value: "http://mockb:8000/"
        ports:
        - containerPort: 8000
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mockb-v1
  labels:
    app: mockb
    version: v1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mockb
      version: v1
      ASM_TRAFFIC_TAG: v1
  template:
    metadata:
      labels:
        app: mockb
        version: v1
        ASM_TRAFFIC_TAG: v1
    spec:
      containers:
      - name: default
        image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/go-http-sample:tracing
        imagePullPolicy: IfNotPresent
        env:
        - name: version
          value: v1
        - name: app
          value: mockb
        - name: upstream_url
          value: "http://mockc:8000/"
        ports:
        - containerPort: 8000
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mockc-v1
  namespace: default
  labels:
    app: mockc
    version: v1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mockc
      version: v1
      ASM_TRAFFIC_TAG: v1
  template:
    metadata:
      labels:
        app: mockc
        version: v1
        ASM_TRAFFIC_TAG: v1
    spec:
      containers:
      - name: default
        image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/go-http-sample:tracing
        imagePullPolicy: IfNotPresent
        env:
        - name: version
          value: v1
        - name: app
          value: mockc
        ports:
        - containerPort: 8000
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mockc-v2
  namespace: default
  labels:
    app: mockc
    version: v2
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mockc
      version: v2
      ASM_TRAFFIC_TAG: v2
  template:
    metadata:
      labels:
        app: mockc
        version: v2
        ASM_TRAFFIC_TAG: v2
    spec:
      containers:
      - name: default
        image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/go-http-sample:tracing
        imagePullPolicy: IfNotPresent
        env:
        - name: version
          value: v2
        - name: app
          value: mockc
        ports:
        - containerPort: 8000

Com o kubeconfig do seu cluster de plano de dados, execute o comando abaixo para implantar as aplicações de exemplo:
```
kubectl apply -f sample.yaml
```

Etapa 2: Criar uma regra de gateway

Crie um recurso Gateway chamado ingressgateway no namespace istio-system com a configuração a seguir. Para mais informações, consulte Gerencie regras de gateway.

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:
        - '*'

Etapa 3: 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 no 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 as definições e clique em OK.

Item de configuração	Descrição
Name of swim lane group	Defina como canary neste exemplo.
Entrance gateway	Selecione ingressgateway.
Lane Mode	Selecione Permissive Mode.
Pass-through Mode of Trace Context	Selecione Pass Through Trace ID.
Trace ID Request Header	Defina como x-user-id neste exemplo.
Routing Request Header	Especifique um cabeçalho que o gateway usa para rotear o tráfego para diferentes faixas e manter o contexto da faixa. É possível definir qualquer valor. Neste exemplo, defina como x-asm-prefer-tag.
Swimlane Services	Selecione o cluster Kubernetes de destino e o namespace default. Na lista abaixo, selecione os serviços mocka, mockb e mockc e clique em no ícone para adicioná-los à área selected.

Crie duas faixas, s1 e s2, e vincule-as às versões v1 e v2, respectivamente.

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

Na caixa de diálogo Create swimlanes, configure as definições e clique em OK.

Item de configuração	Descrição
Swimlane Name	Defina como s1 e s2, respectivamente.
Configure Service Tag	Label Key: Selecione ASM_TRAFFIC_TAG. Label Value: Selecione v1 para uma faixa e v2 para a outra.
Add Service	Faixa s1: Selecione mocka(default), mockb(default) e mockc(default). Faixa s2: Selecione mockc(default).

A imagem a seguir mostra um exemplo de criação da faixa s1:

Após a criação de ambas as faixas, o resultado será semelhante a este:

Nota

Por padrão, a primeira faixa criada em um grupo de faixas torna-se a faixa de linha de base. É possível alterar a faixa de linha de base para que, quando o tráfego tiver como destino um serviço não presente em outra faixa, a requisição retorne à faixa de linha de base. Para mais informações, consulte Alterar a faixa de linha de base no modo permissivo.

Crie regras de roteamento para as faixas.

Use a configuração a seguir para criar uma regra de roteamento de gateway para as faixas. Esta regra possui três partes:

Requisições com x-user-id: jason são roteadas para a faixa s2, e o sistema adiciona o cabeçalho x-asm-prefer-tag: s2 para marcar a requisição para a faixa s2.
Requisições com x-asm-prefer-tag: s2 são roteadas para a faixa s2.
Requisições com x-asm-prefer-tag: s1 são roteadas para a faixa s1.

Expandir para visualizar o conteúdo YAML

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: swimlane-ingress-vs
  namespace: istio-system
spec:
  gateways:
  - istio-system/ingressgateway
  hosts:
  - '*'
  http:
  # Routing rule 1: Requests with x-user-id: jason go to lane s2
  # and add x-asm-prefer-tag: s2 to mark the request for lane s2
  - match:
    - headers:
        x-user-id:
          exact: jason
      uri:
        exact: /
    name: r2
    route:
    - destination:
        host: mocka.default.svc.cluster.local
        subset: s2
      fallback:
        target:
          host: mocka.default.svc.cluster.local
          subset: s1
      headers:
        request:
          set:
            x-asm-prefer-tag: s2
  # Routing rule 2: Requests with x-asm-prefer-tag: s2 go to lane s2
  - match:
    - headers:
        x-asm-prefer-tag:
          exact: s2
      uri:
        exact: /
    name: r2
    route:
    - destination:
        host: mocka.default.svc.cluster.local
        subset: s2
      # If mocka is not in lane s2, fall back to mocka in lane s1
      fallback:
        target:
          host: mocka.default.svc.cluster.local
          subset: s1
  # Routing rule 3: Requests with x-asm-prefer-tag: s1 go to lane s1
  - match:
    - headers:
        x-asm-prefer-tag:
          exact: s1
      uri:
        exact: /
    name: r1
    route:
    - destination:
        host: mocka.default.svc.cluster.local
        subset: s1

Etapa 4: Implantar o plugin de hash tagging

Crie um arquivo chamado wasm.yaml com o seguinte conteúdo:

apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
  name: hash-tagging
  namespace: istio-system
spec:
  imagePullPolicy: IfNotPresent 
  selector:
    matchLabels:
      istio: ingressgateway
  url: registry-cn-hangzhou.ack.aliyuncs.com/acs/asm-wasm-hash-tagging:v1.22.6.2-g72656ba-aliyun 
  phase: AUTHN
  pluginConfig:
    rules:
      - header: x-user-id
        modulo: 100
        tagHeader: x-asm-prefer-tag
        policies:
          # Route 20% of user traffic to lane s2
          - range: 20
            tagValue: s2
          # Route 80% of user traffic to lane s1
          - range: 100
            tagValue: s1

Com o kubeconfig da sua instância do ASM, execute o comando abaixo para implantar o plugin de tagging:
```
kubectl apply -f wasm.yaml
```

Etapa 5: Verifique a configuração

Execute o comando a seguir para definir uma variável de ambiente temporária para o endereço do gateway de entrada:
```
export GATEWAY_ADDRESS=`kubectl get svc -n istio-system | grep istio-ingressgateway | awk '{print $4}'`
```

Execute o comando a seguir para acessar a aplicação como Jason:

curl ${GATEWAY_ADDRESS} -H 'x-user-id: jason'

Saída esperada:

-> mocka(version: v1, ip: 10.0.0.15)-> mockb(version: v1, ip: 10.0.0.130)-> mockc(version: v2, ip: 10.0.0.133)%

A requisição é roteada diretamente para a versão v2 da aplicação mockc.

Execute o comando a seguir para rotear usuários aleatórios para a nova versão:

 for i in 'bob' 'stacy' 'jessie' 'vance' 'jack'; do curl ${GATEWAY_ADDRESS} -H "x-user-id: $i";echo "   user $i requested"; done

Saída esperada:

-> mocka(version: v1, ip: 10.0.0.15)-> mockb(version: v1, ip: 10.0.0.130)-> mockc(version: v1, ip: 10.0.0.131)   user bob requested
-> mocka(version: v1, ip: 10.0.0.15)-> mockb(version: v1, ip: 10.0.0.130)-> mockc(version: v1, ip: 10.0.0.131)   user stacy requested
-> mocka(version: v1, ip: 10.0.0.15)-> mockb(version: v1, ip: 10.0.0.130)-> mockc(version: v2, ip: 10.0.0.133)   user jessie requested
-> mocka(version: v1, ip: 10.0.0.15)-> mockb(version: v1, ip: 10.0.0.130)-> mockc(version: v1, ip: 10.0.0.131)   user vance requested
-> mocka(version: v1, ip: 10.0.0.15)-> mockb(version: v1, ip: 10.0.0.130)-> mockc(version: v2, ip: 10.0.0.133)   user jack requested

As requisições dos usuários Jessie e Jack são roteadas para a versão v2 do mockc, enquanto as demais são roteadas para a versão v1.