Anthos Service Mesh por exemplo: implantações canário


Neste tutorial, você verá um caso de uso comum para implantar uma implantação canário com o Anthos Service Mesh.

O que é uma implantação canário?

Uma implantação canário encaminha uma pequena porcentagem do tráfego para uma nova versão de um microsserviço e depois amplia gradualmente toda a base de usuários, eliminando e desativando a versão antiga. Se ocorrer algum erro durante esse processo, será possível retornar o tráfego à versão antiga. Com o Anthos Service Mesh, é possível rotear o tráfego para garantir que novos serviços sejam introduzidos com segurança.

Saiba mais sobre os testes canário em Estratégias de implantação e teste de aplicativos.

Custos

Neste documento, você usará os seguintes componentes faturáveis do Google Cloud:

Para gerar uma estimativa de custo baseada na projeção de uso deste tutorial, use a calculadora de preços. Novos usuários do Google Cloud podem estar qualificados para uma avaliação gratuita.

Ao concluir este tutorial, exclua os recursos criados para evitar custos contínuos. Para mais informações, consulte Limpeza.

Antes de começar

Implantar Boutique on-line

  1. Defina o contexto atual de kubectl no cluster em que você implantou o Online Boutique:

    gcloud container clusters get-credentials CLUSTER_NAME  \
    --project=PROJECT_ID \
    --zone=CLUSTER_LOCATION
    
  2. Crie o namespace para o aplicativo de amostra e o gateway de entrada:

    kubectl create namespace onlineboutique
    
  3. Rotule o namespace onlineboutique para injetar automaticamente proxies do Envoy. Siga as etapas para ativar a injeção automática de arquivo secundário.

  4. Implante o app de amostra. Neste tutorial, você implantará o Online Boutique, um app de demonstração de microsserviço.

    kubectl apply \
    -n onlineboutique \
    -f https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-samples/main/docs/shared/online-boutique/kubernetes-manifests.yaml
    
  5. Adicione um rótulo version=v1 à implantação do productcatalog executando o seguinte comando:

    kubectl patch deployments/productcatalogservice -p '{"spec":{"template":{"metadata":{"labels":{"version":"v1"}}}}}' \
    -n onlineboutique
    

    Veja os serviços que você implantou:

    kubectl get pods -n onlineboutique
    

    Resposta esperada:

    NAME                                     READY   STATUS    RESTARTS   AGE
    adservice-85598d856b-m84m6               2/2     Running   0          2m7s
    cartservice-c77f6b866-m67vd              2/2     Running   0          2m8s
    checkoutservice-654c47f4b6-hqtqr         2/2     Running   0          2m10s
    currencyservice-59bc889674-jhk8z         2/2     Running   0          2m8s
    emailservice-5b9fff7cb8-8nqwz            2/2     Running   0          2m10s
    frontend-77b88cc7cb-mr4rp                2/2     Running   0          2m9s
    loadgenerator-6958f5bc8b-55q7w           2/2     Running   0          2m8s
    paymentservice-68dd9755bb-2jmb7          2/2     Running   0          2m9s
    productcatalogservice-84f95c95ff-c5kl6   2/2     Running   0          114s
    recommendationservice-64dc9dfbc8-xfs2t   2/2     Running   0          2m9s
    redis-cart-5b569cd47-cc2qd               2/2     Running   0          2m7s
    shippingservice-5488d5b6cb-lfhtt         2/2     Running   0          2m7s
    

    Todos os pods do aplicativo devem estar em execução, com um 2/2 na coluna READY. Isso indica que os pods têm um proxy sidecar do Envoy injetado com sucesso.

  6. Implante VirtualService e DestinationRule para a v1 de productcatalog:

    kubectl apply -f destination-vs-v1.yaml -n onlineboutique
    
    apiVersion: networking.istio.io/v1beta1
    kind: DestinationRule
    metadata:
      name: productcatalogservice
    spec:
      host: productcatalogservice
      subsets:
      - labels:
          version: v1
        name: v1
    ---
    apiVersion: networking.istio.io/v1beta1
    kind: VirtualService
    metadata:
      name: productcatalogservice
    spec:
      hosts:
      - productcatalogservice
      http:
      - route:
        - destination:
            host: productcatalogservice
            subset: v1

    Observe que apenas v1 está presente nos recursos.

  7. Acesse o aplicativo no navegador usando o endereço IP externo da entrada:

    kubectl get services -n GATEWAY_NAMESPACE
    

Na próxima seção, você conhecerá a IU do Anthos Service Mesh e verá como visualizar suas métricas.

Implante e veja seus serviços no Console do Google Cloud

  1. No console do Google Cloud, acesse a página Serviços do GKE Enterprise.

    Acessar o GKE Enterprise Services

  2. Por padrão, os serviços são exibidos na visualização da Tabela.

    A Visão geral da tabela permite que você observe todos seus serviços, bem como métricas importantes rapidamente.

    todas as cargas de trabalho de serviços

  3. No canto superior direito, clique em Topologia. Aqui você pode ver seus serviços e a interação entre eles.

    É possível expandir os serviços e ver as solicitações por segundo de cada um deles. Para isso, passe o cursor sobre eles.

    topologia de todas as cargas de trabalho de serviços

  4. Volte para a Visualização em tabela.

  5. Na Tabela de serviços, selecione productcatalogservice. Você acessará uma visão geral do serviço.

  6. No lado esquerdo da tela, clique em Tráfego.

  7. Verifique se 100% do tráfego de entrada para productcatalogservice vai para o serviço de carga de trabalho.

    Tráfego SVG do productcatalog

A próxima seção mostra como criar uma v2 do serviço productcatalog.

Implantar a v2 de um serviço

  1. Para este tutorial, productcatalogservice-v2 introduzirá uma latência de três segundos nas solicitações com o campo EXTRA_LATENCY.

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: productcatalogservice-v2
    spec:
      selector:
        matchLabels:
          app: productcatalogservice
      template:
        metadata:
          labels:
            app: productcatalogservice
            version: v2
        spec:
          containers:
          - env:
            - name: PORT
              value: '3550'
            - name: EXTRA_LATENCY
              value: 3s
            name: server
            image: gcr.io/google-samples/microservices-demo/productcatalogservice:v0.3.6
            livenessProbe:
              exec:
                command: ["/bin/grpc_health_probe", "-addr=:3550"]
            ports:
            - containerPort: 3550
            readinessProbe:
              exec:
                command: ["/bin/grpc_health_probe", "-addr=:3550"]
            resources:
              limits:
                cpu: 200m
                memory: 128Mi
              requests:
                cpu: 100m
                memory: 64Mi
          terminationGracePeriodSeconds: 5

    Aplique este recurso ao namespace onlineboutique.

    kubectl apply -f productcatalog-v2.yaml -n onlineboutique
    
  2. Verifique os pods do aplicativo.

    kubectl get pods -n onlineboutique
    

    Resposta esperada:

    NAME                                     READY   STATUS    RESTARTS   AGE
    adservice-85598d856b-8wqfd                  2/2     Running   0          25h
    cartservice-c77f6b866-7jwcr                 2/2     Running   0          25h
    checkoutservice-654c47f4b6-n8c6x            2/2     Running   0          25h
    currencyservice-59bc889674-l5xw2            2/2     Running   0          25h
    emailservice-5b9fff7cb8-jjr89               2/2     Running   0          25h
    frontend-77b88cc7cb-bwtk4                   2/2     Running   0          25h
    loadgenerator-6958f5bc8b-lqmnw              2/2     Running   0          25h
    paymentservice-68dd9755bb-dckrj             2/2     Running   0          25h
    productcatalogservice-84f95c95ff-ddhjv      2/2     Running   0          25h
    productcatalogservice-v2-6df4cf5475-9lwjb   2/2     Running   0          8s
    recommendationservice-64dc9dfbc8-7s7cx      2/2     Running   0          25h
    redis-cart-5b569cd47-vw7lw                  2/2     Running   0          25h
    shippingservice-5488d5b6cb-dj5gd            2/2     Running   0          25h
    

    Observe que agora há dois productcatalogservices listados.

  3. O DestinationRule é como especificar os subconjuntos de um serviço. Neste cenário, há um subconjunto da v1 e da v2 do productcatalogservice.

    apiVersion: networking.istio.io/v1beta1
    kind: DestinationRule
    metadata:
      name: productcatalogservice
    spec:
      host: productcatalogservice
      subsets:
      - labels:
          version: v1
        name: v1
      - labels:
          version: v2
        name: v2

    Observe o campo labels. As versões do productcatalogservice são diferenciadas depois que o tráfego é roteado pelo VirtualService.

    Aplique o DestinationRule.

    kubectl apply -f destination-v1-v2.yaml -n onlineboutique
    

Tráfego dividido entre v1 e v2

  1. VirtualService é a forma como você apresenta uma pequena porcentagem do tráfego para direcionar à v2 do productcatalogservice.

    apiVersion: networking.istio.io/v1beta1
    kind: VirtualService
    metadata:
      name: productcatalogservice
    spec:
      hosts:
      - productcatalogservice
      http:
      - route:
        - destination:
            host: productcatalogservice
            subset: v1
          weight: 75
        - destination:
            host: productcatalogservice
            subset: v2
          weight: 25

    O campo de subconjunto indica a versão e o campo de peso indica a divisão percentual do tráfego. 75% do tráfego irá para a v1 do catálogo de produtos, e 25% irá para a v2.

    Aplique o VirtualService:

    kubectl apply -f vs-split-traffic.yaml -n onlineboutique
    

Se você acessar o EXTERNAL_IP da entrada do cluster, observe que, periodicamente, o carregamento do front-end está mais lento.

Na próxima seção, você vai analisar a divisão de tráfego no console do Google Cloud do GKE Enterprise.

Observar a divisão de tráfego no Console do Google Cloud

  1. Volte ao console do Google Cloud e acesse a página de serviços do GKE Enterprise Acessar serviços do GKE Enterprise

  2. No canto superior direito, clique em Topologia.

    Expanda a carga de trabalho productcatalogservice. Você verá as implantações productcatalogservice e productcatalogservice-v2.

    topologia de productcatalog svc v1 v2 do tráfego

  3. Volte para Visualização de tabela. Clique em productcatalogservice na tabela de serviços. Volte para Tráfego na barra de navegação à esquerda.

  4. O tráfego de entrada é dividido entre v1 e v2 pela porcentagem especificada no arquivo VirtualService. Além disso, há duas cargas de trabalho do serviço productcatalog.

    No lado direito da tela, você verá métricas "Solicitações", "Taxa de erros" e "Latência". Com o Anthos Service Mesh, cada serviço terá essas métricas descritas para fornecer a você observabilidade.

    Tráfego de productcatalog svc v1 v2

Lançar ou reverter para uma versão

Após observar as métricas durante uma implantação canário, faça o lançamento no novo serviço ou reverta o serviço antigo com o recurso VirtualService.

Lançamento

Quando estiver satisfeito com o comportamento de um serviço da v2, aumente gradualmente o comportamento do tráfego para o serviço da v2. Em algum momento, o tráfego poderá ser direcionado 100% para o novo serviço.

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

Para direcionar todo o tráfego para a v2 de productcatalogservice:

kubectl apply -f vs-v2.yaml -n onlineboutique

Reverter

Se você precisar reverter para o serviço v1, aplique o destination-vs-v1.yaml anteriormente. Isso direcionará o tráfego apenas para a v1 de productcatalogservice.

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: productcatalogservice
spec:
  hosts:
  - productcatalogservice
  http:
  - route:
    - destination:
        host: productcatalogservice
        subset: v1

Para direcionar todo o tráfego para a v1 de productcatalogservice:

kubectl apply -f vs-v1.yaml -n onlineboutique

Limpar

Para evitar cobranças na sua conta do Google Cloud pelos recursos usados no tutorial, exclua o projeto que os contém ou mantenha o projeto e exclua os recursos individuais.

Para evitar cobranças recorrentes na conta do Google Cloud pelos recursos usados neste tutorial, é possível excluir o projeto ou excluir os recursos individuais.

Exclua o projeto

  1. No Cloud Shell, exclua o projeto:

    gcloud projects delete PROJECT_ID
    

Excluir os recursos

  • Se quiser evitar cobranças adicionais, exclua o cluster:

    gcloud container clusters delete  CLUSTER_NAME  \
    --project=PROJECT_ID \
    --zone=CLUSTER_LOCATION
    
  • Se quiser manter o cluster e remover o aplicativo de amostra do Online Boutique:

    1. Exclua os namespaces do aplicativo:

      kubectl delete -f namespace onlineboutique
      

      Saída esperada:

      namespace "onlineboutique" deleted
      
    2. Exclua as entradas de serviço:

      kubectl delete -f https://raw.githubusercontent.com/GoogleCloudPlatform/microservices-demo/main/istio-manifests/frontend.yaml -n onlineboutique
      kubectl delete -f https://raw.githubusercontent.com/GoogleCloudPlatform/microservices-demo/main/istio-manifests/frontend-gateway.yaml -n onlineboutique
      

      Resposta esperada:

      serviceentry.networking.istio.io "allow-egress-googleapis" deleted
      serviceentry.networking.istio.io "allow-egress-google-metadata" deleted
      

A seguir