Visão geral

Neste laboratório, você vai aprender a instalar o Cloud Service Mesh (CSM) no Google Kubernetes Engine. O Cloud Service Mesh é um serviço gerenciado baseado no Istio, a principal malha de serviço de código aberto.

A malha de serviço fornece uma estrutura para conectar, proteger e gerenciar microsserviços. Ela oferece uma camada de rede sobre o Kubernetes, com recursos como balanceamento de carga avançado, autenticação entre serviços e monitoramento, sem exigir mudanças no código de serviço.

O Cloud Service Mesh oferece um pacote com outros recursos e ferramentas para você observar e gerenciar serviços seguros e confiáveis de maneira unificada: Neste laboratório, você também vai aprender a usar alguns desses recursos:

• Os registros e métricas de serviço do tráfego HTTP(S) no cluster do GKE da malha são ingeridos automaticamente no Google Cloud.
• Os painéis de serviço pré-configurados mostram as informações necessárias para você entender os serviços.
• Com a telemetria detalhada, você analisa métricas e registros, filtrando e fracionando os dados em vários atributos.
• O resumo das relações entre serviços mostra quem se conecta a cada serviço e os serviços que são interdependentes.
• Os objetivos de nível de serviço (SLOs) oferecem insights sobre a integridade dos serviços. Você pode definir SLOs e alertas facilmente para seus padrões de integridade de serviço.

O Cloud Service Mesh é a forma mais fácil e avançada de implementar nos clusters do GKE Enterprise uma malha de serviço baseada no Istio.

Objetivos

Neste laboratório, você vai aprender a fazer o seguinte:

• Instalar o Cloud Service Mesh com tracing ativado e configurado para usar o Cloud Trace como back-end.
• Implantar o Bookinfo, um aplicativo multisserviços com o Istio ativado.
• Permitir acesso externo usando um gateway de entrada do Istio.
• Usar o aplicativo Bookinfo.
• Avaliar o desempenho do serviço usando os recursos do Cloud Trace no Google Cloud.
• Criar e monitorar objetivos de nível de serviço (SLOs).
• Usar o painel do Cloud Service Mesh para entender o desempenho do serviço.

Configuração e requisitos

Para cada laboratório, você recebe um novo projeto do Google Cloud e um conjunto de recursos por um determinado período e sem custos financeiros.

1. Faça login no Qwiklabs em uma janela anônima.

2. Confira o tempo de acesso do laboratório (por exemplo, 1:15:00) e finalize todas as atividades nesse prazo.
   Não é possível pausar o laboratório. Você pode reiniciar o desafio, mas vai precisar refazer todas as etapas.

3. Quando tudo estiver pronto, clique em Começar o laboratório.

4. Anote as credenciais (Nome de usuário e Senha). É com elas que você vai fazer login no Console do Google Cloud.

5. Clique em Abrir Console do Google.

6. Clique em Usar outra conta, depois copie e cole as credenciais deste laboratório nos locais indicados.
   Se você usar outras credenciais, vai receber mensagens de erro ou cobranças.

7. Aceite os termos e pule a página de recursos de recuperação.

Depois que você concluir as etapas iniciais de login, o painel do projeto será exibido.

8. Clique em Selecionar um projeto, destaque o ID do seu projeto do GCP e clique em Abrir para selecionar o projeto.

Ative o Google Cloud Shell

O Google Cloud Shell é uma máquina virtual com ferramentas de desenvolvimento. Ele tem um diretório principal permanente de 5 GB e é executado no Google Cloud.

O Cloud Shell oferece acesso de linha de comando aos recursos do Google Cloud.

1. No console do Cloud, clique no botão "Abrir o Cloud Shell" na barra de ferramentas superior direita.

   

2. Clique em Continuar.

O provisionamento e a conexão do ambiente podem demorar um pouco. Quando você estiver conectado, já estará autenticado, e o projeto estará definido com seu PROJECT_ID. Exemplo:

A gcloud é a ferramenta de linha de comando do Google Cloud. Ela vem pré-instalada no Cloud Shell e aceita preenchimento com tabulação.

• Para listar o nome da conta ativa, use este comando:

Saída:

Exemplo de saída:

• Para listar o ID do projeto, use este comando:

Saída:

Exemplo de saída:

Tarefa 1: Instalar o Cloud Service Mesh com tracing ativado

Um cluster do Google Kubernetes Engine (GKE) chamado gke já foi criado e registrado. Você vai instalar o Cloud Service Mesh nesse cluster e substituir a configuração padrão para ativar os componentes opcionais de tracing.

Configure o acesso do kubectl e verifique o cluster

Para definir variáveis de ambiente para uso em scripts, execute os seguintes comandos no Cloud Shell:

1. Defina a variável de ambiente do nome do cluster.

   CLUSTER_NAME=gke

2. Defina as variáveis de ambiente de zona e região.

   CLUSTER_ZONE={{{ project_0.default_zone| "Zone added at lab start" }}} CLUSTER_REGION={{{ project_0.default_region| "Region added at lab start" }}}

3. Defina a variável de ambiente do ID do projeto.

   PROJECT_ID={{{ project_0.project_id | "PROJECT ID added at lab start" }}}

4. Defina a variável de ambiente do número do projeto.

   PROJECT_NUMBER=$(gcloud projects describe ${PROJECT_ID} \ --format="value(projectNumber)")

5. Defina a variável de ambiente do ID do projeto da frota.

   FLEET_PROJECT_ID="${PROJECT_ID}"

6. Defina a variável de ambiente IDNS.

   IDNS="${PROJECT_ID}.svc.id.goog"

7. Defina o diretório de saída.

   DIR_PATH=.

8. Verifique se as variáveis de ambiente foram definidas corretamente.

   printf '\nCLUSTER_NAME:'$CLUSTER_NAME'\nCLUSTER_ZONE:'$CLUSTER_ZONE'\nPROJECT_ID:'$PROJECT_ID'\nPROJECT_NUMBER:'$PROJECT_NUMBER'\nFLEET PROJECT_ID:'$FLEET_PROJECT_ID'\nIDNS:'$IDNS'\nDIR_PATH:'$DIR_PATH'\n'

   Saída:

   CLUSTER_NAME:gke CLUSTER_ZONE:{{{ project_0.default_zone| "Zone" }}} PROJECT_ID:{{{ project_0.project_id | "PROJECT ID" }}} PROJECT_NUMBER:946429310725 FLEET PROJECT_ID:{{{ project_0.project_id | "PROJECT ID" }}} IDNS:{{{ project_0.project_id | "PROJECT ID" }}}.svc.id.goog DIR_PATH:.

9. Configure o kubectl para gerenciar o cluster do GKE:

   gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $CLUSTER_ZONE --project $PROJECT_ID

10. Verifique a configuração do kubectl:

    kubectl config view

Saída:

11. Verifique se o cluster está em execução:

Saída:

Ative o GKE Enterprise

12. Ative o GKE Enterprise na linha de comando. Isso também ativa automaticamente a API Fleet (GKE Hub).

13. Registre o cluster do GKE chamado gke na frota do projeto.

14. Verifique se o cluster foi registrado na frota.

Instale o Cloud Service Mesh

15. Ative o Cloud Service Mesh no projeto da frota.

16. Ative o gerenciamento automático do plano de controle do Cloud Service Mesh.

17. Verifique se o plano de controle está sendo gerenciado.

Aguarde até que o controlPlaneManagement mude o estado de PROVISIONING para REVISION_READY. Isso pode levar alguns minutos.

Saída:

18. Ative o Cloud Service Mesh para enviar telemetria ao Cloud Trace.

19. Verifique se o mapa de configuração foi ativado: kubectl get configmap

Saída:

Parabéns!

Agora você tem um cluster do GKE com o Cloud Service Mesh instalado. As métricas do Kubernetes estão sendo registradas no Cloud Monitoring, os registros estão sendo gravados no Cloud Logging e as informações de trace distribuído estão sendo enviadas ao Cloud Trace.

Tarefa 2: Instalar o aplicativo microservices-demo no cluster

O Online Boutique é um aplicativo nativo da nuvem, criado para demonstrar microsserviços. Ele consiste em um aplicativo de microsserviços de 10 níveis. Com esse aplicativo de comércio eletrônico da web, os usuários podem procurar itens, adicioná-los ao carrinho e finalizar a compra.

O Google usa o aplicativo para demonstrar o uso de tecnologias como Kubernetes/GKE, Istio/ASM, Google Operations Suite, gRPC e OpenCensus. Ele funciona em qualquer cluster do Kubernetes (como um local) e no Google Kubernetes Engine. É fácil de implantar com pouca ou nenhuma configuração.

Saiba mais sobre o aplicativo no repositório do GitHub.

Configure o plano de dados da malha

1. Ative a injeção de sidecar do Istio:

   kubectl label namespace default istio.io/rev- istio-injection=enabled --overwrite

   Saída:

   namespace/default labeled

2. Para permitir que o Google gerencie seu plano de dados e que os proxies sidecar sejam atualizados automaticamente, anote o namespace:

   kubectl annotate --overwrite namespace default \ mesh.cloud.google.com/proxy='{"managed":"true"}'

   Saída:

   namespace/default annotated

Instalar o aplicativo Online Boutique no cluster do GKE

1. Implante o aplicativo:

   kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/microservices-demo/master/release/kubernetes-manifests.yaml kubectl patch deployments/productcatalogservice -p '{"spec":{"template":{"metadata":{"labels":{"version":"v1"}}}}}'

2. Para acessar o aplicativo de fora do cluster, instale o gateway de entrada:

   git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages kubectl apply -f anthos-service-mesh-packages/samples/gateways/istio-ingressgateway

3. Instale as definições de recurso personalizadas necessárias

   kubectl apply -k "github.com/kubernetes-sigs/gateway-api/config/crd/experimental?ref=v0.6.0" kubectl kustomize "https://github.com/GoogleCloudPlatform/gke-networking-recipes.git/gateway-api/config/mesh/crd" | kubectl apply -f -

4. Configure o gateway:

   kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/microservices-demo/master/release/istio-manifests.yaml

5. Volte para Kubernetes e clique em Cargas de trabalho. Em Rede, clique nas páginas Gateways, serviços e entrada e verifique se as novas implantações e serviços foram criados no cluster do GKE.

   Observação: para facilitar a análise das informações apresentadas, filtre a página por cluster, tipo de objeto e namespace.

6. Analise o aplicativo de demonstração usando o console e a interface.

   Observação: quando as cargas de trabalho mostrarem o status OK, use o endereço IP associado ao serviço frontend-external (de qualquer um dos clusters) para fazer o seguinte:
   • Consulte a página Serviços e entradas no console.
   • Analise o cluster usando o Cloud Shell.

7. Confira a implantação usando o Cloud Shell

   kubectl get deployments

   Saída:

   NAME READY UP-TO-DATE AVAILABLE AGE adservice 1/1 1 1 2m39s cartservice 1/1 1 1 2m41s checkoutservice 1/1 1 1 2m44s currencyservice 1/1 1 1 2m40s emailservice 1/1 1 1 2m45s frontend 1/1 1 1 2m43s istio-ingressgateway 3/3 3 3 2m24s loadgenerator 1/1 1 1 2m41s paymentservice 1/1 1 1 2m42s productcatalogservice 1/1 1 1 2m42s recommendationservice 1/1 1 1 2m43s redis-cart 1/1 1 1 2m39s shippingservice 1/1 1 1 2m40s

8. Confira os serviços usando o Cloud Shell

   kubectl get services

   Saída:

   NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE adservice ClusterIP 10.28.7.144 9555/TCP 7m37s cartservice ClusterIP 10.28.12.9 7070/TCP 7m40s checkoutservice ClusterIP 10.28.15.239 5050/TCP 7m42s currencyservice ClusterIP 10.28.14.145 7000/TCP 7m39s emailservice ClusterIP 10.28.11.181 5000/TCP 7m43s frontend ClusterIP 10.28.1.40 80/TCP 7m41s frontend-external LoadBalancer 10.28.15.84 34.66.85.60 80:31445/TCP 7m41s istio-ingressgateway LoadBalancer 10.28.0.95 34.68.255.184 15021:30153/TCP,80:31266/TCP,443:30286/TCP 7m22s kubernetes ClusterIP 10.28.0.1 443/TCP 62m paymentservice ClusterIP 10.28.1.138 50051/TCP 7m41s productcatalogservice ClusterIP 10.28.8.22 3550/TCP 7m40s recommendationservice ClusterIP 10.28.0.104 8080/TCP 7m42s redis-cart ClusterIP 10.28.5.71 6379/TCP 7m38s shippingservice ClusterIP 10.28.5.69 50051/TCP 7m39s

9. Abra uma nova guia e insira o endereço IP do serviço frontend-external.

10. Clique em várias páginas para entender o aplicativo.

Tarefa 3. Analisar a funcionalidade do pacote de operações do Google Cloud

Ao instalar um cluster do GKE ou do Anthos, é possível ativar a coleta e o encaminhamento de métricas e registros do cluster para o Cloud Logging e o Cloud Monitoring. Assim é possível monitorar o cluster, os nós, os pods e até mesmo os contêineres nesse cluster. No entanto, o GKE e o Anthos não monitoram a comunicação entre microsserviços.

Com o Cloud Service Mesh, como cada solicitação passa por um proxy do Envoy, é possível coletar e inspecionar as informações de telemetria dos microsserviços. As extensões do proxy Envoy enviam essa telemetria ao Google Cloud, onde é possível inspecioná-la. Use os painéis do Cloud Trace para investigar solicitações e latências e conferir um detalhamento de todos os serviços envolvidos em uma solicitação.

1. No console do Google Cloud, acesse o menu de navegação e clique em Trace.

   Um gráfico de trace mostra as solicitações de serviço feitas no aplicativo de demonstração.

2. Clique em um ponto que aparece mais acima no gráfico (representando um tempo de solicitação geral maior).

• Quanto tempo levou a solicitação?
• Quando a solicitação foi feita?
• Qual serviço foi chamado?
• Quais outros serviços foram chamados durante a execução da solicitação?
• Em quê foi gasta a maior parte do tempo no processamento da solicitação?

Saiba como intepretar as informações de trace na documentação do Cloud Trace.

Tarefa 4. Implantar uma versão canário com alta latência

Nesta tarefa, você vai implantar uma nova versão de um serviço com um problema que causa alta latência. Nas tarefas subsequentes, você vai usar as ferramentas de observabilidade para diagnosticar e resolver o problema.

1. No Cloud Shell, clone o repositório que tem os arquivos de configuração necessários para esta parte do laboratório:

   git clone https://github.com/GoogleCloudPlatform/istio-samples.git \ ~/istio-samples

2. Crie a nova regra de destino no cluster gke:

   kubectl apply -f ~/istio-samples/istio-canary-gke/canary/destinationrule.yaml

3. Crie o novo catálogo de produtos no cluster gke:

   kubectl apply -f ~/istio-samples/istio-canary-gke/canary/productcatalog-v2.yaml

4. Crie uma divisão de tráfego no cluster gke:

   kubectl apply -f ~/istio-samples/istio-canary-gke/canary/vs-split-traffic.yaml Observação: você está criando:
   • Uma DestinationRule para definir o roteamento de solicitações entre as versões do serviço
   • Uma nova implantação do serviço de catálogo de produtos com alta latência
   • Um VirtualService para dividir o tráfego do catálogo de produtos em 75% para v1 e 25% para v2
   Abra cada arquivo de configuração no editor do Cloud Shell para entender melhor a definição de cada novo recurso.

Tarefa 5. Definir seu objetivo de nível de serviço

Quando você não estiver usando o Cloud Service Mesh, defina SLOs com a API Service Monitoring. Ao usar o Cloud Service Mesh, assim como no cluster gke, é possível definir e monitorar SLOs pelo painel do Cloud Service Mesh.

1. No console do Google Cloud, no Menu de navegação, clique em Kubernetes Engine para abrir o painel do GKE.

   Há um cluster registrado na frota.

2. No painel lateral, em Recursos, clique em Malha de serviço para acessar o painel do Cloud Service Mesh.

   Um resumo do desempenho do serviço, incluindo informações de SLO, é exibido. Você vai definir um novo SLO para o serviço de catálogo de produtos.

3. Na lista Serviços, clique em productcatalogservice.

4. No painel de menu, clique em Saúde.

5. Clique em +CreateSLO.

6. No painel Definir seu SLI, em métrica, selecione Latência.

7. Selecione Baseada em solicitações como o método de avaliação.

8. Clique em Continuar.

9. Em Limite de latência, selecione 1000 e clique em Continuar.

10. Em Tipo de período, selecione Calendário.

11. Em Prazo, selecione Dia no calendário.

    Observação: 99% de disponibilidade em um único dia é diferente de 99% durante um mês. O primeiro SLO não permitiria mais de 14 minutos de inatividade consecutivos (24 horas * 1%), enquanto o segundo SLO permite tempo de inatividade consecutivo de até aproximadamente 7 horas (30 dias * 1%).

12. Em Meta de desempenho, selecione 99,5%.

    O gráfico Prévia mostra a comparação da sua meta com os dados históricos reais.

13. Clique em Continuar.

14. Confira Nome de exibição: 99,5% - Latência - Dia do calendário.

    Ajuste se necessário.

    O documento JSON gerado automaticamente também é mostrado. Você pode usar as APIs para automatizar a criação de SLOs no futuro.

15. Para criar o SLO, clique em +CreateSLO.

Tarefa 6. Diagnosticar o problema

Usar métricas de serviço para identificar onde está o problema

1. Clique na entrada do SLO na lista.

   Uma visualização expandida será mostrada. Seu SLO provavelmente vai mostrar que você já está fora da margem de erro. Se não, aguarde de 3 a 5 minutos e atualize a página. Você vai acabar esgotando sua margem de erro, porque muitas das solicitações para o serviço vão atingir o novo back-end, que tem alta latência.

2. No painel de menu, clique em Métricas.

   Role a tela para baixo até a seção Latência da visualização Métricas e observe que a latência do serviço aumentou alguns minutos antes, por volta do momento em que você implantou a versão canary do serviço.

3. No menu suspenso Detalhar por, selecione Serviço de origem.

   Quais pods estão mostrando alta latência e impedindo que você cumpra o SLO?

4. Para voltar à página "Malha de serviço", clique em Malha de serviço no painel de menu.

   A página mostra que um SLO está fora da margem de erro. Mostra também um indicador de aviso ao lado do serviço com problema na lista Serviços.

   Observação: você definiu apenas um SLO para um único serviço. Em um ambiente de produção real, provavelmente haveria vários SLOs para cada serviço.
   Além disso, você não definiu nenhuma política de alertas para o SLO. Você provavelmente faria o Cloud Monitoring executar um alerta se estivesse esgotando a margem de erro mais rápido do que o esperado.

Usar o Cloud Trace para entender melhor onde está o atraso

1. No console do Google Cloud, no Menu de navegação, clique em Trace > Explorador de traces.

2. Clique em um ponto que esteja em torno de 3.000 ms. Ele representa uma das solicitações ao serviço de catálogo de produtos.

   Todo o tempo parece ser gasto no próprio serviço de catálogo. Há chamadas para outros serviços, mas todas parecem retornar muito rapidamente. Algo no serviço de catálogo de produtos está demorando muito.

   Observação: o Cloud Service Mesh coleta automaticamente informações sobre chamadas de rede na malha e mostra dados que documentam o tempo gasto nessas chamadas. Isso é útil e não exigiu esforço extra do desenvolvedor.
   No entanto, o tempo gasto na carga de trabalho, neste caso, o pod de serviço do catálogo de produtos, não é instrumentado diretamente pelo Istio. Se necessário, para conseguir esse nível de detalhes, o desenvolvedor adicionaria uma lógica de instrumentação ao próprio serviço.

Tarefa 7. Reverter a versão e verificar se há uma melhoria

1. No Cloud Shell, reverta a versão canário da regra de destino:

   kubectl delete -f ~/istio-samples/istio-canary-gke/canary/destinationrule.yaml

2. No Cloud Shell, reverta a versão canário do catálogo de produtos:

   kubectl delete -f ~/istio-samples/istio-canary-gke/canary/productcatalog-v2.yaml

3. No Cloud Shell, reverta a versão canário da divisão de tráfego:

   kubectl delete -f ~/istio-samples/istio-canary-gke/canary/vs-split-traffic.yaml

4. No console do Google Cloud, clique em Menu de navegação > Anthos > Malha de serviço.

5. Clique em productcatalogservice e, no painel de menu, clique em Saúde.

   Observe a porcentagem de conformidade atual.

6. Clique em Métricas.

   No gráfico de latência, todas as séries mostram uma queda que corresponde ao momento em que você reverteu a versão incorreta da carga de trabalho.

7. Volte à página Saúde.

8. Compare a métrica de compliance atual com a que você verificou antes. Ela está mais alta, indicando que não há mais solicitações com alta latência.

Tarefa 8. Visualizar a malha com o painel do Cloud Service Mesh

1. No Menu de navegação, clique em Kubernetes Engine > Malha de serviço.

2. Confira a topologia no lado direito.

   Um gráfico representando sua malha de serviço é exibido.

   

   Se você não encontrar um gráfico de topologia completo como este, talvez nem todos os dados de topologia tenham sido coletados. Pode levar mais de 10 minutos para que esses dados apareçam no gráfico. Você pode continuar para a próxima seção e voltar ao gráfico mais tarde.

3. Clique no nó da carga de trabalho de front-end e observe os serviços chamados por essa carga de trabalho.

   

Explore mais e entenda melhor a arquitetura do aplicativo. É possível reorganizar nós, detalhar cargas de trabalho para mostrar as implantações e pods constituintes, mudar períodos e mais.

Parabéns! Você usou as ferramentas do pacote de operações do Google Cloud para avaliar, resolver problemas e melhorar o desempenho do serviço no cluster do GKE Enterprise.

Revisão

Neste laboratório, você aprendeu sobre geração de registros, monitoramento e rastreamento usando o pacote de operações do Google Cloud.

Finalize o laboratório

Clique em Terminar o laboratório após a conclusão. O Google Cloud Ensina remove os recursos usados e limpa a conta por você.

Você vai poder avaliar sua experiência no laboratório. Basta selecionar o número de estrelas, digitar um comentário e clicar em Enviar.

O número de estrelas indica o seguinte:

• 1 estrela = muito insatisfeito
• 2 estrelas = insatisfeito
• 3 estrelas = neutro
• 4 estrelas = satisfeito
• 5 estrelas = muito satisfeito

Feche a caixa de diálogo se não quiser enviar feedback.

Para enviar seu feedback, fazer sugestões ou correções, use a guia Suporte.

Copyright 2026 Google LLC. Todos os direitos reservados. Google e o logotipo do Google são marcas registradas da Google LLC. Todos os outros nomes de empresas e produtos podem ser marcas registradas das empresas a que estão associados.