Alibaba Cloud Service Mesh:Use traffic labels to implement an end-to-end canary release

Como funciona

O diagrama a seguir mostra a cadeia de chamadas usada neste tutorial. O Serviço A (mocka) recebe o tráfego de entrada e chama o Serviço B (mockb):

Ambos os serviços têm duas versões implantadas: base e canary. Sem rótulos de tráfego, o balanceamento de carga round-robin distribui as requisições entre as versões.

Após configurar os rótulos de tráfego, o sistema:

1. Lê o cabeçalho my-asm-prefer-tag das requisições recebidas no gateway para classificar o tráfego como version-base ou version-canary.

2. Encaminha a requisição para a versão correspondente do Serviço A.

3. Propaga a tag para o Serviço B por meio do cabeçalho my-trace-id, para que o Serviço B também encaminhe para a versão correspondente.

Pré-requisitos

Antes de iniciar, certifique-se de ter:

• Uma instância do ASM da Enterprise Edition ou Ultimate Edition, versão 1.17.2.22 ou posterior. Consulte Crie uma instância do ASM ou Atualize uma instância do ASM

• Um cluster adicionado à instância do ASM. Consulte Adicione um cluster a uma instância do ASM

• Um gateway de entrada. Consulte Crie um gateway de entrada

Arquivos de configuração de exemplo

Baixe os arquivos de configuração de exemplo usados neste tutorial. O pacote contém os seguintes arquivos:

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

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

Etapa 1: Implantar os serviços de exemplo

1. Ative a injeção automática de proxy sidecar para o namespace de destino (default neste exemplo). Consulte Ative a injeção automática de proxy sidecar.

2. Conecte-se ao cluster do Container Service for Kubernetes (ACK) com o kubectl e implante os serviços de exemplo:

   kubectl apply -n default -f application-base.yaml
   kubectl apply -n default -f application-canary.yaml

Etapa 2: Configure as regras de roteamento iniciais

Configure o Gateway, os DestinationRules e os VirtualServices para estabelecer o roteamento básico sem rótulos de tráfego.

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

   Conteúdo de routing.yaml

   apiVersion: networking.istio.io/v1beta1
   kind: Gateway
   metadata:
     name: simple-gateway
   spec:
     selector:
       istio: ingressgateway
     servers:
       - hosts:
           - "*"
         port:
           name: http
           number: 80
           protocol: HTTP
   ---
   apiVersion: networking.istio.io/v1beta1
   kind: DestinationRule
   metadata:
     name: dr-mocka
   spec:
     host: mocka
     trafficPolicy:
       loadBalancer:
         simple: ROUND_ROBIN
     subsets:
       - labels:
           version: base
         name: version-base
       - labels:
           version: canary
         name: version-canary
   ---
   apiVersion: networking.istio.io/v1beta1
   kind: DestinationRule
   metadata:
     name: dr-mockb
   spec:
     host: mockb
     trafficPolicy:
       loadBalancer:
         simple: ROUND_ROBIN
     subsets:
       - labels:
           version: base
         name: version-base
       - labels:
           version: canary
         name: version-canary
   ---
   apiVersion: networking.istio.io/v1beta1
   kind: VirtualService
   metadata:
     name: vs-gateway-mocka
   spec:
     gateways:
     - simple-gateway
     hosts:
       - "*"
     http:
     - route:
         - destination:
             host: mocka
   ---
   apiVersion: networking.istio.io/v1beta1
   kind: VirtualService
   metadata:
     name: vs-mockb
   spec:
     hosts:
       - mockb
     http:
       - route:
           - destination:
               host: mockb

   Esta configuração:

   • Cria um Gateway (simple-gateway) que aceita todo o tráfego HTTP na porta 80

   • Define DestinationRules para ambos os serviços com os subconjuntos version-base e version-canary

   • Cria VirtualServices que encaminham o tráfego sem lógica baseada em rótulos

2. Conecte-se à instância do ASM com o kubectl e aplique as regras de roteamento:

   kubectl apply -n default -f routing.yaml

3. Verifique se ambas as versões do serviço estão acessíveis.

   1. Obtenha o endereço IP público do gateway de entrada no console do ASM. Consulte Obtenha o endereço IP do gateway de entrada do ASM.

   2. Defina o IP do gateway como uma variável de ambiente. Substitua <gateway-ip> pelo endereço IP real:

      export ASM_GATEWAY_IP=<gateway-ip>

   3. Envie requisições de teste:

      for i in {1..200};  do curl   -H'my-asm-prefer-tag: version-base'  -H'my-trace-id: x000'$i  http://${ASM_GATEWAY_IP}/; echo; sleep 1; done;

   Saída esperada -- o sistema distribui o tráfego aleatoriamente entre todas as versões de ambos os serviços:

   -> mocka(version: canary, ip: 172.17.0.129)-> mockb(version: base, ip: 172.17.0.70)
   -> mocka(version: base, ip: 172.17.0.132)-> mockb(version: base, ip: 172.17.0.70)
   -> mocka(version: base, ip: 172.17.0.132)-> mockb(version: canary, ip: 172.17.0.54)
   -> mocka(version: canary, ip: 172.17.0.129)-> mockb(version: canary, ip: 172.17.0.54)

   Neste ponto, o cabeçalho my-asm-prefer-tag não surte efeito no roteamento. As requisições seguem o balanceamento de carga round-robin independentemente do valor do cabeçalho.

Etapa 3: Configure os rótulos de tráfego

Crie recursos TrafficLabel para extrair rótulos de roteamento dos cabeçalhos de requisição. O ASM usa esses rótulos para determinar se o tráfego é version-base ou version-canary. Para saber mais sobre a rotulagem de tráfego, consulte Rotule o tráfego.

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

   Conteúdo de trafficlabel.yaml

   apiVersion: istio.alibabacloud.com/v1
   kind: TrafficLabel
   metadata:
     name: trafficlabel-ns
     namespace: default
   spec:
     rules:
     - labels:
       - name: asm-labels-sample
         valueFrom:
         - $getExternalInboundRequestHeader(my-asm-prefer-tag, my-trace-id)
   ---
   apiVersion: istio.alibabacloud.com/v1
   kind: TrafficLabel
   metadata:
     name: ingressgateway
     namespace: istio-system
   spec:
     rules:
     - labels:
       - name: asm-labels-sample
         valueFrom:
         - $getInboundRequestHeader(my-asm-prefer-tag)
     workloadSelector:
       labels:
         istio: ingressgateway

   Esta configuração define dois recursos TrafficLabel:

   Recurso	Escopo	Comportamento
   trafficlabel-ns	Todos os serviços no namespace default (mocka, mockb)	Usa $getExternalInboundRequestHeader para extrair a tag de versão do cabeçalho my-asm-prefer-tag. O segundo parâmetro, my-trace-id, especifica o cabeçalho de rastreamento que a aplicação deve propagar entre os serviços.
   ingressgateway	Apenas o gateway de entrada (namespace istio-system)	Lê a tag de versão do cabeçalho my-asm-prefer-tag da requisição de entrada do cliente.

   Nota

   Este exemplo usa os nomes de cabeçalho my-asm-prefer-tag e my-trace-id. Substitua-os por cabeçalhos que correspondam à sua aplicação.

2. Conecte-se à instância do ASM com o kubectl e aplique os rótulos de tráfego:

   kubectl apply -f trafficlabel.yaml

Etapa 4: Aplique o roteamento baseado em rótulos e verifique

Esta etapa verifica progressivamente a liberação canário de ponta a ponta em três fases:

1. Roteamento de salto único -- Aplique o roteamento baseado em rótulos ao Serviço B e confirme se a tag de tráfego encaminha corretamente as requisições para a versão correspondente

2. Roteamento de cadeia completa -- Aplique o roteamento baseado em rótulos ao Serviço A no gateway para que o tráfego canário flua pelas versões canário de todos os serviços de ponta a ponta

3. Roteamento ponderado -- Combine a distribuição baseada em peso com o roteamento baseado em rótulos para controlar o percentual da liberação canário

Próximos passos

• Aumente gradualmente o peso canário à medida que ganhar confiança na nova versão.

• Para mais detalhes sobre a configuração de rotulagem de tráfego, consulte Rotule o tráfego.

• Para liberações canário de um único serviço apenas com roteamento baseado em peso, consulte Implante um aplicativo no modo de implantação blue-green e no modo de liberação por fases.