Alibaba Cloud Service Mesh:Lançamento canário de ponta a ponta com o Argo CD

Pré-requisitos

• Crie uma instância do ASM nas edições Enterprise ou Ultimate com versão 1.20.6.27 ou superior. Para mais informações, consulte Criar uma instância do ASM e Atualizar uma instância do ASM.

• Adicione um cluster Kubernetes à instância do ASM.

• Instale o Argo CD e crie um gateway do ASM. Para mais detalhes, consulte as etapas 1 a 3 em Integrar o Argo CD ao ASM para implementar GitOps.

• Conecte-se ao cluster Kubernetes via kubectl. Consulte Obter o arquivo kubeconfig de um cluster e usar o kubectl para se conectar.

Informações de fundo

O Argo CD adota a metodologia GitOps para implantar e liberar serviços de aplicações. Os desenvolvedores enviam manifests YAML de recursos da aplicação (como Deployments e Services) e regras de gerenciamento de tráfego (como VirtualServices, Gateways e DestinationRules) para um repositório Git. O Argo CD monitora o estado desses recursos no cluster e os compara com o estado desejado definido no repositório. Como o repositório Git atua como fonte única da verdade, o Argo CD sincroniza os recursos automática ou manualmente sempre que detecta alterações.

O Service Mesh ASM permite usar faixas de tráfego para isolar versões específicas (ou outras características) de uma aplicação em um ambiente de execução independente. Isso facilita lançamentos canários de ponta a ponta para serviços de aplicações. A partir da versão 1.20.6.27, o ASM suporta a definição de faixas de tráfego por meio de dois recursos personalizados em YAML: ASMSwimLaneGroup e ASMSwimLane. Gerencie esses recursos personalizados com o Argo CD para implementar lançamentos canários completos. Para saber mais, consulte Visão geral das faixas de tráfego.

Etapa 1: Implantar a aplicação e as faixas de tráfego

1. Crie um exemplo de lançamento canário de ponta a ponta para a aplicação mock.

   1. Na interface do Argo CD, clique em NEW APP e configure os parâmetros a seguir.

      Parâmetro	Descrição
      Application Name	Nome da aplicação. Neste exemplo, insira mock.
      SYNC POLICY	Política de sincronização da aplicação. Selecione Automatically. Essa opção sincroniza automaticamente as definições mais recentes de recursos do repositório Git. Marque também PRUNE RESOURCES para garantir a exclusão de recursos do cluster caso suas definições sejam removidas do repositório.
      Repository URL	URL do repositório Git de source. Insira a URL do repositório de exemplo: https://github.com/AliyunContainerService/asm-labs.git. Se desejar modificar o exemplo, faça um fork deste repositório e informe a URL do seu fork.
      Revision	Tag ou branch do Git a ser sincronizada. Insira a branch do repositório de exemplo: argocd-asm.
      Path	Caminho no repositório que contém os manifests dos recursos. Insira o caminho dos recursos do exemplo: argo-cd/swimlane.
      Cluster URL	Endereço do servidor de API do cluster de destino. Insira o endereço do servidor de API do cluster Kubernetes onde o Argo CD está implantado: https://kubernetes.default.svc.

2. Após concluir a configuração, clique em CREATE na parte superior da página.

   Na página Applications do Argo CD, visualize o status da aplicação mock recém-criada.

   O status da aplicação deve ser Healthy e o status de sincronização deve ser Synced. Isso indica que a implantação e a sincronização ocorreram com sucesso.

3. Clique em a aplicação mock para verificar o status de sincronização dos recursos.

   A visualização de recursos mostra o status da aplicação como Healthy e a sincronização como Synced. Todos os recursos foram sincronizados sem erros.

   Além dos recursos Deployment e Service que definem a aplicação, o repositório Git contém recursos de gerenciamento de tráfego (como VirtualService e Gateway) e recursos de faixa de tráfego do ASM (como ASMSwimLaneGroup e ASMSwimLane).

Etapa 2: Verificar o lançamento canário de ponta a ponta

Neste exemplo, os recursos ASMSwimLaneGroup e ASMSwimLane isolam os ambientes v1 e v2 dos serviços da aplicação. Um recurso VirtualService instrui o gateway do ASM a encaminhar o tráfego para as duas versões na proporção de 1:1. Acesse repetidamente o gateway do ASM para validar o lançamento canário de ponta a ponta.

1. Obtenha o endereço ip público do gateway no console do ASM. Para mais detalhes, consulte Obter o endereço IP de um gateway do ASM.

2. Execute o comando a seguir para definir uma variável de ambiente.

   Substitua xxx.xxx.xxx.xxx pelo endereço ip obtido na etapa anterior.

   export ASM_GATEWAY_IP=xxx.xxx.xxx.xxx

3. Execute o comando abaixo para acessar o gateway do ASM repetidamente.

   for i in {1..100}; do curl http://${ASM_GATEWAY_IP}/mock; echo ''; sleep 1; done;

   Saída esperada:

   -> mocka(version: v2, ip: 10.0.239.73)-> mockb(version: v2, ip: 10.0.239.136)-> mockc(version: v2, ip: 10.0.239.139)
   -> mocka(version: v1, ip: 10.0.239.75)-> mockb(version: v1, ip: 10.0.239.138)-> mockc(version: v1, ip: 10.0.239.137)
   -> mocka(version: v2, ip: 10.0.239.73)-> mockb(version: v2, ip: 10.0.239.136)-> mockc(version: v2, ip: 10.0.239.139)
   -> mocka(version: v2, ip: 10.0.239.73)-> mockb(version: v2, ip: 10.0.239.136)-> mockc(version: v2, ip: 10.0.239.139)
   -> mocka(version: v2, ip: 10.0.239.73)-> mockb(version: v2, ip: 10.0.239.136)-> mockc(version: v2, ip: 10.0.239.139)
   -> mocka(version: v1, ip: 10.0.239.75)-> mockb(version: v1, ip: 10.0.239.138)-> mockc(version: v1, ip: 10.0.239.137)
   -> mocka(version: v1, ip: 10.0.239.75)-> mockb(version: v1, ip: 10.0.239.138)-> mockc(version: v1, ip: 10.0.239.137)
   -> mocka(version: v1, ip: 10.0.239.75)-> mockb(version: v1, ip: 10.0.239.138)-> mockc(version: v1, ip: 10.0.239.137)
   -> mocka(version: v1, ip: 10.0.239.75)-> mockb(version: v1, ip: 10.0.239.138)-> mockc(version: v1, ip: 10.0.239.137)
   -> mocka(version: v1, ip: 10.0.239.75)-> mockb(version: v1, ip: 10.0.239.138)-> mockc(version: v1, ip: 10.0.239.137)
   -> mocka(version: v1, ip: 10.0.239.75)-> mockb(version: v1, ip: 10.0.239.138)-> mockc(version: v1, ip: 10.0.239.137)
   -> mocka(version: v1, ip: 10.0.239.75)-> mockb(version: v1, ip: 10.0.239.138)-> mockc(version: v1, ip: 10.0.239.137)
   -> mocka(version: v2, ip: 10.0.239.73)-> mockb(version: v2, ip: 10.0.239.136)-> mockc(version: v2, ip: 10.0.239.139)
   -> mocka(version: v1, ip: 10.0.239.75)-> mockb(version: v1, ip: 10.0.239.138)-> mockc(version: v1, ip: 10.0.239.137)
   ...

   A saída indica que a aplicação de exemplo é composta por três serviços: mocka, mockb e mockc. A cadeia de chamadas segue a ordem mocka→mockb→mockc, e cada serviço possui versões v1 e v2. As requisições são distribuídas entre as versões v1 e v2 em uma proporção aproximada de 1:1. O isolamento da cadeia de chamadas para cada versão confirma o sucesso do lançamento canário de ponta a ponta.

Operações relacionadas

Lançar uma nova versão do serviço

O repositório Git de exemplo utilizado neste tutorial possui a seguinte estrutura de arquivos:

Para lançar uma nova versão do serviço da aplicação, faça um fork da branch argocd-asm do repositório de exemplo https://github.com/AliyunContainerService/asm-labs.git. Modifique os recursos YAML no caminho argo-cd/swimlane e envie as alterações (commit). Após o push, o Argo CD sincroniza as mudanças automaticamente. Certifique-se de que a Repository URL mencionada na Etapa 1 aponte para a URL do seu repositório com fork.

Por exemplo, para lançar uma nova versão v3 dos serviços mocka, mockb e mockc, modifique os recursos YAML no seu repositório Git conforme descrito abaixo:

1. Adicione o arquivo argo-cd/swimlane/mock-v3.yaml.

   Este arquivo YAML define os Deployments para as versões v3 dos serviços mocka, mockb e mockc.

   YAML

   apiVersion: apps/v1
   kind: Deployment
   metadata:
    name: mocka-v3
    labels:
    app: mocka
    version: v3
   spec:
    replicas: 1
    selector:
    matchLabels:
    app: mocka
    version: v3
    ASM_TRAFFIC_TAG: v3
    template:
    metadata:
    labels:
    app: mocka
    version: v3
    ASM_TRAFFIC_TAG: v3
    spec:
    containers:
    - name: default
    image: registry.cn-beijing.aliyuncs.com/aliacs-app-catalog/go-http-sample:1.0
    imagePullPolicy: IfNotPresent
    env:
    - name: version
    value: v3
    - name: app
    value: mocka
    - name: upstream_url
    value: "http://mockb:8000/"
    ports:
    - containerPort: 8000
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
    name: mockb-v3
    labels:
    app: mockb
    version: v3
   spec:
    replicas: 1
    selector:
    matchLabels:
    app: mockb
    version: v3
    ASM_TRAFFIC_TAG: v3
    template:
    metadata:
    labels:
    app: mockb
    version: v3
    ASM_TRAFFIC_TAG: v3
    spec:
    containers:
    - name: default
    image: registry.cn-beijing.aliyuncs.com/aliacs-app-catalog/go-http-sample:1.0
    imagePullPolicy: IfNotPresent
    env:
    - name: version
    value: v3
    - name: app
    value: mockb
    - name: upstream_url
    value: "http://mockc:8000/"
    ports:
    - containerPort: 8000
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
    name: mockc-v3
    labels:
    app: mockc
    version: v3
   spec:
    replicas: 1
    selector:
    matchLabels:
    app: mockc
    version: v3
    ASM_TRAFFIC_TAG: v3
    template:
    metadata:
    labels:
    app: mockc
    version: v3
    ASM_TRAFFIC_TAG: v3
    spec:
    containers:
    - name: default
    image: registry.cn-beijing.aliyuncs.com/aliacs-app-catalog/go-http-sample:1.0
    imagePullPolicy: IfNotPresent
    env:
    - name: version
    value: v3
    - name: app
    value: mockc
    ports:
    - containerPort: 8000

2. Modifique o arquivo argo-cd/swimlane/swimlanes.yaml com o conteúdo a seguir.

   Uma nova faixa de tráfego (ASMSwimLane) chamada v3 foi adicionada. Esse recurso associa-se ao grupo de faixas mock (ASMSwimLaneGroup) e especifica que Pods com o rótulo version:v3 pertencem à versão v3 do serviço.

   YAML

   apiVersion: istio.alibabacloud.com/v1
   kind: ASMSwimLane
   metadata:
    labels:
    swimlane-group: mock
    name: v1
   spec:
    labelSelector:
    version: v1
   ---
   apiVersion: istio.alibabacloud.com/v1
   kind: ASMSwimLane
   metadata:
    labels:
    swimlane-group: mock
    name: v2
   spec:
    labelSelector:
    version: v2
   ---
   apiVersion: istio.alibabacloud.com/v1
   kind: ASMSwimLane
   metadata:
    labels:
    swimlane-group: mock
    name: v3
   spec:
    labelSelector:
    version: v3

3. Atualize o arquivo argo-cd/swimlane/mock-route.yaml com o conteúdo abaixo.

   O VirtualService chamado mock foi alterado para incluir a versão v3 do serviço mocka nos destinos de rota. O campo subset mapeia para o nome da faixa de tráfego (ASMSwimLane). O campo weight no VirtualService foi ajustado para dividir o tráfego entre as versões v1, v2 e v3 na proporção de 6:3:1.

   YAML

   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: mock
    namespace: istio-system
   spec:
    gateways:
    - ingressgateway
    hosts:
    - '*'
    http:
    - match:
    - uri:
    exact: /mock
    route:
    - destination:
    host: mocka.default.svc.cluster.local
    subset: v1
    weight: 60
    - destination:
    host: mocka.default.svc.cluster.local
    subset: v2
    weight: 30
    - destination:
    host: mocka.default.svc.cluster.local
    subset: v3
    weight: 10

Documentos relacionados

• Para entender melhor os conceitos e casos de uso das faixas de tráfego do ASM, incluindo a comparação entre os modos estrito e flexível, consulte Faixas de tráfego.

• Para exemplos de configuração e descrições de campos de ASMSwimLaneGroup e ASMSwimLane, consulte Referência de CRD ASMSwimLaneGroup e ASMSwimLane.