Para executar um canary release em toda uma cadeia de chamadas ou impor isolamento de versão, use faixas de tráfego em modo estrito. Esse recurso isola versões relevantes (ou outros atributos) de uma aplicação em um ambiente de execução independente. Assim, apenas o tráfego que atende a condições específicas é roteado para a nova versão do serviço, o que aumenta a estabilidade e o controle do processo de release.
Pré-requisitos
-
Você criou uma instância do ASM nas edições Enterprise ou Ultimate, versão 1.18.2.111 ou posterior. Para mais informações, consulte Criar uma instância do ASM ou Atualizar uma instância do ASM.
NotaSe a versão da sua instância for 1.17.2.22 ou posterior, mas anterior à 1.18.2.111, consulte Usar o recurso de gerenciamento de tráfego no modo de faixa.
Você criou um gateway de entrada do ASM chamado ingressgateway. Para mais informações, consulte Criar um serviço de gateway de entrada.
-
Você criou um gateway chamado ingressgateway no namespace istio-system. Para mais informações, consulte Gerenciar gateways.
Exemplo
Este exemplo usa três serviços (mocka, mockb e mockc) para criar três faixas (s1, s2 e s3), que representam três versões da cadeia de chamadas do serviço.
Etapa 1: Implantar serviços de exemplo
-
Ative a injeção automática de proxy sidecar para o namespace default. Para detalhes, consulte Ativar injeção automática de proxy sidecar.
Para mais informações sobre injeção automática, consulte Configurar políticas de injeção de sidecar.
-
Execute os comandos a seguir no cluster Container Service for Kubernetes (ACK) para implantar os serviços de exemplo:
kubectl apply -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v1/mock-tracing-v1.yaml kubectl apply -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v2/mock-tracing-v2.yaml kubectl apply -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v3/mock-tracing-v3.yaml
Etapa 2: Criar um grupo de faixas e as faixas de tráfego
-
Crie um grupo de faixas.
Faça login no console do ASM. No painel de navegação à esquerda, escolha .
Na página Mesh Management, clique no nome da instância do ASM. No painel de navegação à esquerda, escolha .
-
Na página Traffic Lane, clique em Create Swimlane Group. No painel Create Swimlane Group, configure os parâmetros e clique em OK.
Parâmetro
Descrição
Name of swim lane group
Para este exemplo, insira test.
Entrance gateway
Selecione ingressgateway.
Lane Mode
Selecione Strict Mode.
Swimlane service
Selecione o cluster Kubernetes de destino e o namespace default. Na lista abaixo, selecione os serviços mocka, mockb e mockc e clique no ícone
para adicioná-los à seção selected.
-
Crie as faixas s1, s2 e s3 e vincule-as às versões v1, v2 e v3, respectivamente.
Na seção Traffic Lane da página Traffic Rule Definition, clique em Create swimlanes.
-
Na caixa de diálogo Create swimlanes, configure os parâmetros e clique em OK.
Parâmetro
Descrição
Swimlane Name
Defina os nomes das faixas como s1, s2 e s3.
Configure Service Tag
Label Key: Selecione ASM_TRAFFIC_TAG.
Label Value: Selecione v1, v2 e v3 para as faixas s1, s2 e s3, respectivamente.
Após a criação das três faixas, cada uma conterá os serviços de faixa
mocka,mockbemockc.Depois que você cria as faixas, o ASM gera automaticamente um DestinationRule e um VirtualService correspondentes para cada serviço no grupo de faixas. Para visualizar esses recursos, acesse ou VirtualService no painel de navegação à esquerda.
-
Crie uma regra de tráfego de entrada para cada faixa.
Na seção Traffic Lane da página Traffic Rule Definition, localize a faixa desejada e clique em Ingress traffic rules na coluna Actions.
-
Na caixa de diálogo Add drainage rule, configure os parâmetros e clique em OK.
Neste exemplo, a URI de entrada para os serviços da faixa é
/mock. Portanto, configure a mesma regra de tráfego de entrada para cada faixa.Parâmetro
Descrição
Ingress service
Selecione mocka.default.svc.cluster.local.
Ingress traffic rules
Defina Name como r1 e Domain Name como *.
Matching request URI
Defina Method como Exact e Content como /mock.
Add Header Matching Rule
Clique em Add Header Matching Rule. Defina Name como x-asm-prefer-tag e Method como Exact. Para as três faixas, defina Content como s1, s2 e s3, respectivamente.
Após a criação das regras de tráfego de entrada, a página Traffic Rule Definition é atualizada. As faixas agora estão marcadas como s1, s2 e s3, e os serviços da faixa (mocka, mockb e mockc) estão habilitados para todas as faixas.
Depois que você cria as regras, o sistema gera automaticamente um VirtualService que implementa a regra de tráfego de entrada para cada faixa.
Etapa 3: Verificar o canary release de ponta a ponta
Obtenha o endereço IP público do gateway de entrada do ASM. Para mais informações, consulte Obter o endereço do gateway de entrada do ASM.
-
Execute o comando a seguir para definir uma variável de ambiente.
Substitua
xxx.xxx.xxx.xxxpelo endereço IP obtido na etapa anterior.export ASM_GATEWAY_IP=xxx.xxx.xxx.xxx -
Verifique se o canary release de ponta a ponta funciona conforme o esperado.
-
Execute o comando a seguir para testar o roteamento para a faixa s1.
O valor
s1parax-asm-prefer-tagespecifica a faixa s1 configurada na Etapa 2.for i in {1..100}; do curl -H 'x-asm-prefer-tag: s1' 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 indica que as requisições com o cabeçalho HTTP
x-asm-prefer-tag: s1são roteadas para os serviços na faixa s1. -
Execute o comando a seguir para testar o roteamento para a faixa s2.
O valor
s2parax-asm-prefer-tagespecifica a faixa s2 configurada na Etapa 2.for i in {1..100}; do curl -H 'x-asm-prefer-tag: s2' 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 indica que as requisições com o cabeçalho HTTP
x-asm-prefer-tag: s2são roteadas para os serviços na faixa s2. -
Execute o comando a seguir para testar o roteamento para a faixa s3.
O valor
s3parax-asm-prefer-tagespecifica a faixa s3 configurada na Etapa 2.for i in {1..100}; do curl -H 'x-asm-prefer-tag: s3' 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 indica que as requisições com o cabeçalho HTTP
x-asm-prefer-tag: s3são roteadas para os serviços na faixa s3.
-
Roteamento de tráfego com um virtual service personalizado
O recurso de faixa de tráfego inclui uma capacidade integrada para configurar regras de roteamento de requisições. Ao criar essas regras, o ASM gera automaticamente um virtual service correspondente no gateway de entrada, permitindo que ele direcione as requisições para diferentes faixas de tráfego.
As regras de roteamento de requisições para uma faixa de tráfego fazem a correspondência com base em cabeçalhos e caminhos da requisição. Para implementar condições de correspondência mais complexas ou comportamentos de roteamento personalizados, crie um virtual service personalizado.
Ao usar um virtual service personalizado para rotear tráfego para uma faixa, evite criar regras de roteamento integradas para a mesma faixa. Um virtual service personalizado pode entrar em conflito com as regras integradas e causar distribuição de tráfego imprevisível ou incorreta.
Criar um virtual service para o gateway do ASM
-
Para continuar com o cenário de exemplo, em vez de concluir a Etapa 2.3, Criar regras de roteamento de requisições para as três faixas de tráfego, crie um virtual service com a seguinte configuração. Para mais informações, consulte Gerenciar virtual services.
apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: swimlane-ingress-vs-custom namespace: istio-system spec: gateways: - istio-system/ingressgateway hosts: - '*' http: - match: # This rule matches requests with the exact header 'env: dev'. - headers: env: exact: dev name: dev-route route: - destination: host: mocka.default.svc.cluster.local # The destination service for the traffic. subset: s2 # Set 'subset' to the name of the traffic lane. weight: 50 - destination: host: mocka.default.svc.cluster.local # The destination service for the traffic. subset: s3 # Set 'subset' to the name of the traffic lane. weight: 50 - name: base-route route: - destination: host: mocka.default.svc.cluster.local # The destination service for the traffic. subset: s1 # Set 'subset' to the name of the traffic lane. -
Execute os comandos da Etapa 3: Verificar o canary release de ponta a ponta. A saída esperada ao acessar as faixas de tráfego s1, s2 e s3 é a seguinte:
-> mocka(version: v1, ip: 192.168.0.50)-> mockb(version: v1, ip: 192.168.0.46)-> mockc(version: v1, ip: 192.168.0.48)Execute o comando a seguir para verificar o comportamento ao acessar a faixa de tráfego s1 com o cabeçalho de requisição
env: dev.for i in {1..100}; do curl -H 'x-asm-prefer-tag: s1' -H 'env: dev' http://${ASM_GATEWAY_IP}/mock ; echo ''; sleep 1; done;Saída esperada:
A saída mostra que, para requisições que incluem o cabeçalho
env: dev, o tráfego é dividido aproximadamente 50/50 entre as faixas de tráfego s2 e s3. Todas as outras requisições são roteadas para a faixa de tráfego s1.
O virtual service acima define uma regra de roteamento personalizada no gateway do ASM para encaminhar tráfego para diferentes faixas. Ao usar um virtual service personalizado para rotear tráfego para uma faixa em modo estrito, basta especificar o nome da faixa de destino no campo subset do destino da rota. Assim que uma requisição entra em uma faixa de tráfego, todas as chamadas subsequentes na cadeia de requisições permanecem dentro dessa faixa.
Criar um virtual service para sidecars
Além de definir regras no gateway de entrada, você também pode criar um virtual service aplicável a todos os sidecars. Isso permite definir regras de roteamento de requisições que controlam como os serviços dentro do cluster acessam outros serviços em uma faixa de tráfego. Diferente de um virtual service para gateway, um virtual service baseado em sidecar omite o campo gateway, e o campo hosts especifica o FQDN do serviço mocka dentro do cluster. O YAML a seguir serve como exemplo:
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: swimlane-ingress-vs-custom
namespace: istio-system
spec:
hosts:
- mocka.default.svc.cluster.local
http:
- match: # This rule matches requests with the exact header 'env: dev'.
- headers:
env:
exact: dev
name: dev-route
route:
- destination:
host: mocka.default.svc.cluster.local # The destination service for the traffic.
subset: s2 # Set 'subset' to the name of the traffic lane.
weight: 50
- destination:
host: mocka.default.svc.cluster.local # The destination service for the traffic.
subset: s3 # Set 'subset' to the name of the traffic lane.
weight: 50
- name: base-route
route:
- destination:
host: mocka.default.svc.cluster.local # The destination service for the traffic.
subset: s1 # Set 'subset' to the name of the traffic lane.-
Execute o comando a seguir para verificar o comportamento ao acessar o serviço mocka a partir de um sidecar sem o cabeçalho de requisição
env: dev.kubectl exec -it deploy/sleep -c sleep -- sh -c 'for i in $(seq 1 100); do curl http://mocka:8000; echo ""; sleep 1; done;'Saída esperada:
-> mocka(version: v1, ip: 192.168.0.50)-> mockb(version: v1, ip: 192.168.0.46)-> mockc(version: v1, ip: 192.168.0.48)A saída mostra que, sem o cabeçalho de requisição
env: dev, todas as requisições seguem a cadeia de chamadas v1, o que confirma que o tráfego é roteado para a faixa de tráfego s1. -
Execute o comando a seguir para verificar o comportamento quando a requisição inclui o cabeçalho
env: dev.kubectl exec -it deploy/sleep -c sleep -- sh -c 'for i in $(seq 1 100); do curl -H "env: dev" http://mocka:8000; echo ""; sleep 1; done;'Saída esperada:
A saída é consistente com o resultado do virtual service baseado em gateway. Ao acessar o serviço mocka com o cabeçalho de requisição
env: dev, o tráfego é dividido aproximadamente 50/50 entre as faixas de tráfego s2 e s3.
Isso funciona com o mesmo princípio do virtual service baseado em gateway. Quando outro serviço no cluster chama o serviço mocka, toda a cadeia de requisições subsequente permanece dentro da faixa de tráfego selecionada.
Documentação relacionada
Uma faixa de tráfego possui dois modos: estrito e permissivo. Para comparar esses modos, consulte Visão geral de faixas de tráfego.
O modo permissivo oferece maior flexibilidade para faixas de tráfego, especialmente quando sua aplicação usa cabeçalhos de requisição pass-through em um rastreamento. Por exemplo, é possível criar um ambiente de teste que inclua novas versões de apenas alguns serviços no rastreamento. Para detalhes, consulte Usar faixas de tráfego em modo permissivo para gerenciamento de tráfego de ponta a ponta.
É possível implementar faixas de tráfego usando regras como VirtualService e DestinationRule. Você também pode configurar o deslocamento de tráfego para rotear requisições para uma aplicação de fallback designada quando uma aplicação de uma versão específica (ou com outras características) estiver indisponível. Para mais informações, consulte Configurar faixas de tráfego e deslocamento de tráfego usando regras de tráfego.