Implement blue-green and canary release with ASM - Alibaba Cloud Service Mesh: Central de Documentação do Alibaba Cloud

O Service Mesh (ASM) desacopla o roteamento de tráfego do dimensionamento de pods, oferecendo controle percentual sobre como o tráfego chega a cada versão da aplicação — independentemente do número de réplicas.

Este guia apresenta três estratégias de release usando virtual services e destination rules, com a aplicação de exemplo Bookinfo:

Blue-green release — migre todo o tráfego de uma versão para outra em uma única etapa.
Canary release por peso — divida o tráfego entre duas versões por percentual.
Canary release por header — direcione usuários específicos para uma nova versão com base nos headers da requisição.

Pré-requisitos

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

Uma instância do ASM. Para mais informações, consulte Create an ASM instance
Pelo menos um cluster do Container Service for Kubernetes (ACK) adicionado à instância do ASM. Para mais informações, consulte Add a cluster to an ASM instance
A aplicação Bookinfo implantada no cluster ACK. Para mais informações, consulte Deploy an application in an ASM instance
Um ingress gateway implantado para o cluster ACK. Para mais informações, consulte Create an ingress gateway service

Como funciona

As destination rules definem subsets nomeados que mapeiam para rótulos de versão nos pods. Os virtual services referenciam esses subsets para controlar qual versão recebe tráfego e em que proporção.

Este guia segue uma progressão realista:

Defina subsets para todas as versões dos microsserviços do Bookinfo (destination rules).
Direcione todo o tráfego para a v1 (baseline).
Blue-green release: migre o service reviews da v1 para a v2.
Canary release por peso: divida o tráfego entre reviews v2 e v3.
Canary release por header: direcione um usuário específico para reviews v3.

Etapa 1: Crie as destination rules

Defina subsets para cada microsserviço do Bookinfo, de modo que os virtual services possam referenciá-los pelo nome. Para mais informações, consulte Manage destination rules.

Aplique as seguintes destination rules à sua instância do ASM:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: productpage
spec:
  host: productpage
  subsets:
  - name: v1
    labels:
      version: v1
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
  - name: v3
    labels:
      version: v3
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: ratings
spec:
  host: ratings
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
  - name: v2-mysql
    labels:
      version: v2-mysql
  - name: v2-mysql-vm
    labels:
      version: v2-mysql-vm
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: details
spec:
  host: details
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

Verifique se as destination rules foram criadas:

kubectl get destinationrules -o name

Saída esperada:

destinationrule.networking.istio.io/productpage
destinationrule.networking.istio.io/reviews
destinationrule.networking.istio.io/ratings
destinationrule.networking.istio.io/details

Etapa 2: Direcione todo o tráfego para a v1 (baseline)

Crie virtual services para direcionar todo o tráfego ao subset v1 de cada microsserviço do Bookinfo. Isso estabelece uma baseline estável antes de migrar o tráfego. Para mais informações, consulte Manage virtual services.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: productpage
spec:
  hosts:
  - productpage
  http:
  - route:
    - destination:
        host: productpage
        subset: v1
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - route:
    - destination:
        host: ratings
        subset: v1
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: details
spec:
  hosts:
  - details
  http:
  - route:
    - destination:
        host: details
        subset: v1

Verifique a baseline

Atualize a página de product do Bookinfo no navegador. A seção de reviews é exibida sem avaliações em estrelas, pois reviews v1 não chama o service ratings.

Confirme a regra de roteamento:

kubectl get virtualservice reviews -o yaml

A saída deve exibir subset: v1 como único destino do service reviews.

Neste ponto, os pods de reviews v2 e v3 estão em execução, mas não recebem tráfego.

Etapa 3: Blue-green release — migre para reviews v2

O blue-green release transfere todo o tráfego de uma versão para outra em uma única etapa. Atualize o virtual service do reviews para direcionar 100% do tráfego ao subset v2:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v2

Verifique o blue-green release

Atualize a página de product do Bookinfo. A seção de reviews passa a exibir estrelas pretas, confirmando que todo o tráfego chegou ao reviews v2.

Confirme a regra de roteamento:

kubectl get virtualservice reviews -o yaml

A saída deve exibir subset: v2 como único destino.

Nota: Para reverter, reaplique o virtual service da Etapa 2, que direciona o tráfego para o subset v1.

Etapa 4: Canary release por peso — divida o tráfego entre v2 e v3

Em vez de migrar todo o tráfego de uma vez, transfira gradualmente uma porcentagem para a nova versão. O virtual service a seguir divide o tráfego 50/50 entre reviews v2 e v3:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
    - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v2
      weight: 50
    - destination:
        host: reviews
        subset: v3
      weight: 50

Os valores de weight controlam o percentual de tráfego de cada versão. A soma dos pesos deve ser 100.

Verifique o canary release

Atualize a página de product do Bookinfo várias vezes. A seção de reviews alternará entre estrelas pretas (v2) e estrelas vermelhas (v3) com frequência aproximadamente igual.

Nota: Para reverter, defina weight: 100 no destino v2 e weight: 0 no v3, ou remova completamente o destino v3.

Etapa 5: Canary release por header — roteamento por identidade do usuário

Direcione usuários específicos para a nova versão com base em headers HTTP, enquanto os demais permanecem na versão atual. Essa abordagem é útil para testes internos antes de uma distribuição mais ampla.

A aplicação Bookinfo repassa o nome do usuário autenticado como o header HTTP end-user. O virtual service a seguir direciona o usuário jason para reviews v3 e todos os demais para reviews v2:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    route:
    - destination:
        host: reviews
        subset: v3
  - route:
    - destination:
        host: reviews
        subset: v2

Verifique o canary release por header

Sem fazer login, atualize a página de product do Bookinfo. A seção de reviews exibe estrelas pretas (v2).
Clique em Sign in no canto superior direito. Insira jason como nome de usuário. Nenhuma senha é necessária.
Após fazer login, atualize a página. A seção de reviews passa a exibir estrelas vermelhas (v3).

Isso funciona porque a página de product do Bookinfo inclui um header end-user nas requisições aos microsserviços de backend. Quando o valor de end-user corresponde a jason, o virtual service direciona a requisição para reviews v3.

Limpeza

Para remover as regras de roteamento criadas neste guia, exclua os virtual services e as destination rules:

kubectl delete virtualservice productpage reviews ratings details
kubectl delete destinationrule productpage reviews ratings details

Próximas etapas

Manage virtual services — explore opções de roteamento como injeção de falhas e timeouts.
Manage destination rules — configure políticas de balanceamento de carga e definições de pool de conexões para subsets.