Visão geral

O Cloud Service Mesh é uma arquitetura que permite comunicação gerenciada, observável e segura entre seus serviços, facilitando a criação de aplicativos empresariais robustos compostos de muitos microsserviços na infraestrutura escolhida. Ele gerencia os requisitos comuns da execução de um serviço, como monitoramento, rede e segurança, com ferramentas consistentes e avançadas, facilitando o foco dos desenvolvedores e operadores de serviços na criação e no gerenciamento de aplicativos excelentes para os usuários.

O modelo de gerenciamento de tráfego do Cloud Service Mesh depende dos dois seguintes componentes:

• Plano de controle: gerencia e configura os proxies Envoy para rotear o tráfego e aplicar políticas.
• Plano de dados: abrange toda a comunicação de rede entre microsserviços realizada no ambiente de execução pelos proxies Envoy.

Esses componentes ativam os recursos de gerenciamento de tráfego de malha, por exemplo:

• Descoberta de serviços
• Balanceamento de carga
• Roteamento e controle de tráfego

Objetivos

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

• Configurar e usar gateways do Istio
• Aplicar as regras de destino padrão para todas as versões disponíveis
• Aplicar os serviços virtuais para rotear por padrão para apenas uma versão
• Fazer o roteamento para uma versão específica de um serviço com base na identidade do usuário
• Deslocar o tráfego gradualmente de uma versão de um microsserviço para outra
• Usar o painel do Cloud Service Mesh para ver o roteamento para várias versões
• Configurar práticas recomendadas de rede, como novas tentativas, interruptores de circuito e tempos limite

Configuração e requisitos

Nesta tarefa, você vai seguir as etapas de inicialização do laboratório.

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

1. Faça login no Google Skills usando 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 e 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:

gcloud auth list

Saída:

Credentialed accounts: - @.com (active)

Exemplo de saída:

Credentialed accounts: - google1623327_student@qwiklabs.net

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

gcloud config list project

Saída:

[core] project =

Exemplo de saída:

[core] project = qwiklabs-gcp-44776a13dea667a6 Observação: a documentação completa da gcloud está disponível no guia com informações gerais sobre a gcloud CLI .

Tarefa 1: analisar os casos de uso do gerenciamento de tráfego

Vários recursos de gerenciamento de tráfego são ativados com diferentes opções de configuração.

Exemplo: divisão de tráfego

Rotear o tráfego para várias versões de um serviço.

Exemplo: tempo limite

Definir um tempo limite, o período que o Istio espera por uma resposta a uma solicitação. O tempo limite para as solicitações HTTP é de 15 segundos, mas isso pode ser modificado.

Exemplo: novas tentativas

Uma nova tentativa é uma tentativa de concluir uma operação várias vezes caso haja um problema. Ajuste o número máximo de novas tentativas ou o número de tentativas possíveis dentro do tempo limite padrão ou modificado.

Exemplo: injeção de falhas (inserção de atrasos)

A injeção de falhas é um método de teste que introduz erros em um sistema para garantir que ele consiga suportar as condições de erro e se recuperar delas.

Este exemplo introduz um atraso de 5 segundos em 10% das solicitações da versão "v1" do microsserviço de classificação.

Exemplo: injeção de falhas (inserção de cancelamentos)

O exemplo acima retorna um código de erro HTTP 400 para 10% das solicitações da "v1" do serviço de classificação.

Exemplo: roteamento condicional com base nos rótulos de origem

Uma regra pode indicar que ela se aplica apenas a chamadas de cargas de trabalho (pods) que implementam a versão v2 do serviço de avaliações.

Exemplo: roteamento condicional com base nos cabeçalhos de solicitação

A regra acima só se aplica a uma solicitação recebida se incluir um cabeçalho "usuário final" personalizado que contenha a string "atharvak".

Tarefa 2: concluir a configuração do laboratório

O ambiente deste laboratório já foi parcialmente configurado.

• Um cluster do GKE chamado gke foi criado.
• O Cloud Service Mesh foi instalado
• O aplicativo multisserviço de exemplo Bookinfo foi implantado.

Configurar o acesso do cluster para o kubectl

1. Defina a variável de ambiente da zona:

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

2. No Cloud Shell, defina o nome do cluster das variáveis de ambiente:

   export CLUSTER_NAME=gke

3. Configure o acesso à linha de comando kubectl executando:

   export GCLOUD_PROJECT=$(gcloud config get-value project) gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $CLUSTER_ZONE --project $GCLOUD_PROJECT

   Se for solicitado, clique no botão Autorizar.

Verificar o cluster e a instalação do Cloud Service Mesh

4. Veja se o cluster está em execução:

   gcloud container clusters list

   Saída:

   NAME: gke LOCATION: {{{ project_0.default_zone| "Zone" }}} MASTER_VERSION: 1.24.8-gke.2000 MASTER_IP: 35.222.150.207 MACHINE_TYPE: e2-standard-4 NODE_VERSION: 1.24.8-gke.2000 NUM_NODES: 2 STATUS: RUNNING

5. Verifique se os pods do Kubernetes relacionados ao plano de controle do Cloud Service Mesh foram implantados:

   kubectl get pods -n asm-ingress

Saída:

NAME READY STATUS RESTARTS AGE istio-ingressgateway-69fc5475fd-4wglw 1/1 Running 0 22m istio-ingressgateway-69fc5475fd-stb7x 1/1 Running 0 22m istio-ingressgateway-69fc5475fd-vkxp4 1/1 Running 0 22m

O status do pod deve ser Em execução ou Concluído.

6. Garanta que os serviços do Kubernetes correspondentes para o plano de controle do Cloud Service Mesh estejam implantados:

   kubectl get service -n asm-ingress

Saída:

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE istio-ingressgateway LoadBalancer 34.118.232.124 34.75.207.190 15021:32645/TCP,80:31091/TCP,443:32092/TCP 30m

Verificar a implantação do Bookinfo

8. Confirme se o aplicativo foi implantado corretamente:

   kubectl get pods

   Saída:

   NAME READY STATUS details-v1-1520924117-48z17 2/2 Running productpage-v1-560495357-jk1lz 2/2 Running ratings-v1-734492171-rnr5l 2/2 Running reviews-v1-874083890-f0qf0 2/2 Running reviews-v2-1343845940-b34q5 2/2 Running reviews-v3-1813607990-8ch52 2/2 Running Observação: cada pod tem dois contêineres, que são o contêiner do aplicativo e o proxy sidecar do Istio.

9. Revise os serviços de aplicativo em execução:

   kubectl get services

   Saída:

   NAME TYPE CLUSTER-IP EXTERNAL-IP ... details ClusterIP 10.7.248.49 kubernetes ClusterIP 10.7.240.1 productpage ClusterIP 10.7.248.22 ratings ClusterIP 10.7.247.26 reviews ClusterIP 10.7.246.22

Tarefa 3: instalar gateways para ativar a entrada

Em um ambiente do Kubernetes, o recurso Ingress é usado para especificar os serviços que devem ser expostos fora do cluster. No Cloud Service Mesh, uma abordagem melhor, que também funciona no Kubernetes e em outros ambientes, é usar um recurso de gateway. Com um gateway, é possível aplicar recursos da malha, como monitoramento, mTLS e regras avançadas de roteamento, ao tráfego que entra no cluster.

Os gateways superam as limitações de Ingress do Kubernetes separando a especificação L4-L6 da L7. O gateway configura as funções L4-L6, como as portas a serem expostas ou o protocolo a ser usado. Em seguida, os proprietários de serviços vinculam o VirtualService para configurar opções de roteamento de tráfego L7, como roteamento com base em caminhos, cabeçalhos, pesos etc.

Há duas opções para implantar gateways: compartilhados ou dedicados. Os gateways compartilhados usam um único gateway centralizado que é utilizado por muitos aplicativos, possivelmente em vários namespaces. No exemplo abaixo, o gateway no namespace de entrada delega a propriedade das rotas aos namespaces de aplicativos, mas mantém o controle sobre a configuração do TLS. Isso funciona bem ao usar certificados TLS compartilhados ou infraestrutura compartilhada. Neste laboratório, vamos usar essa opção.

Os gateways dedicados oferecem controle e propriedade total a um único namespace, já que um namespace de aplicativo tem um gateway dedicado próprio. Isso funciona bem para aplicativos que exigem isolamento por segurança ou desempenho.

Instalar um gateway de entrada no cluster

1. Crie um namespace para o gateway:

   kubectl create namespace ingress

2. Rotule o namespace do gateway com um identificador de revisão para injeção automática:

   kubectl label namespace ingress istio.io/rev=asm-managed --overwrite

   O identificador de revisão é usado pelo webhook do injetor do sidecar para associar os proxies injetados a uma revisão específica do plano de controle.

   Ignore a mensagem "istio-injection not found" na saída. Isso significa que o namespace não tinha o identificador "istio-injection" anteriormente, o que é normal em novas implantações ou instalações do Service Mesh.

   Como a injeção automática falha se um namespace tiver os rótulos istio-injection e revision, todos os comandos kubectl label na documentação do Service Mesh incluem a remoção do rótulo istio-injection.

3. Faça o download e aplique os arquivos de configuração do gateway. Isso inclui os pods e serviços que vão receber primeiro as solicitações de entrada de fora do cluster:

cat <<'EOF' > ingress.yaml apiVersion: v1 kind: ServiceAccount metadata: name: istio-ingressgateway namespace: ingress --- apiVersion: v1 kind: Service metadata: name: istio-ingressgateway namespace: ingress labels: app: istio-ingressgateway istio: ingressgateway spec: ports: # status-port exposes a /healthz/ready endpoint that can be used with GKE Ingress health checks - name: status-port port: 15021 protocol: TCP targetPort: 15021 # As portas expostas nos recursos do gateway precisam ser expostas aqui. - name: http2 port: 80 - name: https port: 443 selector: istio: ingressgateway app: istio-ingressgateway type: LoadBalancer --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: istio-ingressgateway namespace: ingress rules: - apiGroups: - "" resources: - secrets verbs: - get - watch - list --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: istio-ingressgateway namespace: ingress roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: istio-ingressgateway subjects: - kind: ServiceAccount name: istio-ingressgateway --- apiVersion: policy/v1 kind: PodDisruptionBudget metadata: name: istio-ingressgateway namespace: ingress spec: maxUnavailable: 1 selector: matchLabels: istio: ingressgateway app: istio-ingressgateway --- apiVersion: apps/v1 kind: Deployment metadata: name: istio-ingressgateway namespace: ingress spec: replicas: 1 selector: matchLabels: app: istio-ingressgateway istio: ingressgateway template: metadata: annotations: # Isto é necessário para injetar o gateway com a # configuração obrigatória. inject.istio.io/templates: gateway labels: app: istio-ingressgateway istio: ingressgateway spec: containers: - name: istio-proxy image: auto # A imagem será atualizada automaticamente sempre que o pod for iniciado. serviceAccountName: istio-ingressgateway --- apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: istio-ingressgateway namespace: ingress spec: maxReplicas: 5 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 80 minReplicas: 3 scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: istio-ingressgateway EOF kubectl apply -n ingress -f ingress.yaml

4. Depois de criar a implantação, verifique se os novos serviços estão funcionando:

   kubectl get pod,service -n ingress

   O recurso é um LoadBalancer. O gateway de entrada usa um balanceador de carga externo do TCP no GCP.

5. Implante o gateway para especificar a porta e o protocolo a serem usados. Neste caso, o gateway ativa o tráfego HTTP pela porta 80:

   cat <<EOF | kubectl apply -f - apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: bookinfo-gateway namespace: ingress spec: selector: istio: ingressgateway servers: - port: number: 80 name: http protocol: HTTP hosts: - "*" EOF

   O recurso gateway precisa estar no mesmo namespace que a implantação do gateway.

6. Implante o VirtualService para rotear o tráfego dos pods e do serviço do gateway que você acabou de criar para o aplicativo BookInfo:

   cat <<EOF | kubectl apply -f - apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: bookinfo spec: hosts: - "*" gateways: - ingress/bookinfo-gateway http: - match: - uri: exact: /productpage - uri: prefix: /static - uri: exact: /login - uri: exact: /logout - uri: prefix: /api/v1/products route: - destination: host: productpage port: number: 9080 EOF

   O recurso VirtualService precisa estar no mesmo namespace que o aplicativo. Ele estabelece o serviço productpage como o destino padrão.

7. Verifique se o gateway e o VirtualService foram criados e observe que o VirtualService está apontando para o gateway:

   kubectl get gateway,virtualservice

8. Salve este IP externo no seu ambiente do Cloud Shell:

   export GATEWAY_URL=$(kubectl get svc -n ingress istio-ingressgateway \ -o=jsonpath='{.status.loadBalancer.ingress[0].ip}') echo The gateway address is $GATEWAY_URL

Observação: se o endereço do gateway estiver vazio, aguarde de 1 a 2 minutos e tente o último comando novamente. Faça isso até ter um endereço na variável $GATEWAY_URL.

Gerar tráfego em segundo plano

Gere tráfego em segundo plano no aplicativo para que seja possível conhecer alguns dados interessantes ao analisar o painel do Service Mesh.

1. No Cloud Shell, instale o siege, uma ferramenta de geração de carga:

   sudo apt install siege

2. Com o siege, crie tráfego para seus serviços:

   siege http://${GATEWAY_URL}/productpage

Acessar o aplicativo BookInfo

1. No Cloud Shell, abra outra guia clicando no ícone + na barra de menu do Cloud Shell.

2. Defina a variável de ambiente da zona:

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

3. Inicialize a nova guia do Cloud Shell:

   export CLUSTER_NAME=gke export GCLOUD_PROJECT=$(gcloud config get-value project) gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $CLUSTER_ZONE --project $GCLOUD_PROJECT export GATEWAY_URL=$(kubectl get svc istio-ingressgateway \ -o=jsonpath='{.status.loadBalancer.ingress[0].ip}' -n ingress)

4. Para confirmar se o aplicativo Bookinfo responde, envie uma solicitação curl a ele por algum pod dentro do cluster, por exemplo, ratings:

   kubectl exec -it \ $(kubectl get pod -l app=ratings -o jsonpath='{.items[0].metadata.name}') \ -c ratings -- curl productpage:9080/productpage \ | grep -o "<title>.*</title>"

   Saída:

   <title>Simple Bookstore App</title>

5. Confirme que o app Bookinfo responde a uma solicitação curl enviada a ele de fora do cluster usando o IP externo salvo anteriormente:

   curl -I http://${GATEWAY_URL}/productpage

   Saída:

   HTTP/1.1 200 OK content-type: text/html; charset=utf-8 content-length: 5293 server: istio-envoy date: Wed, 01 Feb 2023 13:28:58 GMT x-envoy-upstream-service-time: 27

6. Abra o aplicativo Bookinfo no navegador. Execute este comando no Cloud Shell para receber o URL completo:

   echo http://${GATEWAY_URL}/productpage

Parabéns! Você expôs um endpoint HTTP do serviço productpage do Bookinfo a tráfego externo. Os recursos de configuração do gateway permitem que o tráfego externo entre na malha de serviço e disponibilizam os recursos de política e gerenciamento de tráfego para os serviços de borda.

Clique em Verificar meu progresso para conferir o objetivo. Instale gateways para ativar a entrada.

Tarefa 4: usar o painel do Service Mesh para ver o roteamento para várias versões

Há alguns itens a serem observados quando se trata de visualizar dados no painel do Service Mesh.

O primeiro é que, na maioria das páginas, leva de 1 a 2 minutos para que os dados fiquem disponíveis para exibição. Isso significa que, se você analisar uma página, ela não terá os dados esperados por 1 ou 2 minutos. Se não encontrar os dados que você quer, aguarde um minuto e atualize a página.

A página "Topologia" também tem um grande atraso inicial antes da exibição dos dados. Pode levar até 5 minutos para o conjunto de dados inicial ficar disponível. Se você vir uma mensagem informando que não há dados, aguarde um pouco, atualize a página e retorne à visualização de topologia.

Nos parágrafos anteriores, você recebeu a instrução de esperar e a atualizar a página. Acontece que, além do atraso nos dados, muitas páginas não mostram as informações disponíveis sem que sejam atualizadas manualmente. Por isso, se os dados esperados não estiverem aparecendo, atualize a página no navegador.

Visualizar informações de roteamento na visualização em tabela

1. No menu de navegação, selecione Kubernetes Engine > Recursos > Malha de serviço.

   

Observação: se a visualização de topologia não aparecer, atualize a janela do navegador.

2. Clique no serviço productpage e selecione Serviços conectados à esquerda.

3. Selecione a guia Saída e observe os dois serviços chamados pelos pods productpage.

4. Clique no serviço avaliações.

   

5. Observe as estatísticas de serviço e selecione o link Infraestrutura no menu à esquerda.

Há vários pods executando diferentes versões da lógica de avaliação que recebem tráfego enviado para o serviço de avaliações.

6. Clique em Tráfego no menu à esquerda para ver outra visualização de distribuição de tráfego.

   

   Há uma distribuição relativamente uniforme do tráfego nos três pods de back-end que executam as diferentes versões da lógica do aplicativo.

Visualizar informações de roteamento na visualização de topologia

1. Clique no logotipo do Service Mesh no canto superior esquerdo para retornar à página principal do painel.

Observação: se uma mensagem de erro for exibida indicando que não há dados disponíveis para o gráfico ou se você vir um gráfico que não tem todo o tráfego esperado, aguarde de 1 a 2 minutos e tente novamente.

2. Reorganize o gráfico de malha para conseguir visualizar facilmente:

   • o serviço productpage acessando a implantação productpage;
   • a implantação productpage acessando o serviço avaliações;
   • o serviço avaliações direcionando para três versões de avaliações.

   

3. Clique no nó de serviço avaliações e veja as consultas por segundo relativas para cada versão de back-end.

   

Tarefa 5: aplicar as regras de destino padrão para todas as versões disponíveis

Nesta tarefa, você define todas as versões disponíveis, chamadas de subconjuntos, nas regras de destino.

1. Revise a configuração encontrada no GitHub. Ela define 4 recursos DestinationRule, um para cada serviço.

2. Aplique a configuração com o seguinte comando no Cloud Shell:

   wget https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/networking/destination-rule-all.yaml sed -i 's#istio\.io/v1#istio\.io/v1alpha3#g' destination-rule-all.yaml kubectl apply -f destination-rule-all.yaml

   Saída:

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

3. Verifique se foram definidos 4 recursos DestinationRule.

   kubectl get destinationrules

   Saída:

   NAME HOST AGE details details 1m productpage productpage 1m ratings ratings 1m reviews reviews 1m

4. Analise os detalhes das regras de destino:

   kubectl get destinationrules -o yaml

   Observe que subsets são definidos dentro do spec de um DestinationRule.

5. Aguarde 1 ou 2 minutos e retorne ao painel do Service Mesh.

6. Analise as visualizações de tabela e topologia e confirme se o tráfego continua sendo distribuído uniformemente nas três versões do back-end. Clique em MOSTRAR LINHA DO TEMPO para ajustar o período exibido no gráfico, facilitando a análise dos dados de seu interesse.

Clique em Verificar meu progresso para conferir o objetivo. Aplique regras de destino.

Tarefa 6: aplicar os serviços virtuais para rotear por padrão para apenas uma versão

Nesta tarefa, você aplicará serviços virtuais a cada serviço que roteia todo o tráfego para a v1 da carga de trabalho do serviço.

1. Revise a configuração encontrada no GitHub. Essa configuração define 4 recursos VirtualService, um para cada serviço.

2. Aplique a configuração com o seguinte comando no Cloud Shell:

   wget https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/networking/virtual-service-all-v1.yaml sed -i 's#istio\.io/v1#istio\.io/v1alpha3#g' virtual-service-all-v1.yaml kubectl apply -f virtual-service-all-v1.yaml

   Saída:

   virtualservice.networking.istio.io/productpage created virtualservice.networking.istio.io/reviews created virtualservice.networking.istio.io/ratings created virtualservice.networking.istio.io/details created

   Como a propagação da configuração é consistente, aguarde alguns segundos para que os serviços virtuais entrem em vigor.

3. Verifique se as 4 rotas, os recursos VirtualService, foram definidas:

   kubectl get virtualservices

   Saída:

   NAME GATEWAYS HOSTS AGE bookinfo ["ingress/bookinfo-gateway"] ["*"] 19m details ["details"] 6s productpage ["productpage"] 7s ratings ["ratings"] 6s reviews ["reviews"] 7s

4. No Cloud Shell, acesse o endereço IP externo do gateway de entrada:

   echo $GATEWAY_URL

5. Teste a nova configuração de roteamento usando a UI do Bookinfo.

   • Abra o site do Bookinfo no navegador. O URL é http://[GATEWAY_URL]/productpage, em que $GATEWAY_URL é o endereço IP externo da entrada.

   • Atualize a página algumas vezes para emitir várias solicitações.

   Observe que a parte Avaliações de livros da página não mostra estrelas, não importa quantas vezes você atualize. Isso acontece porque você configurou a malha para rotear todo o tráfego do serviço de avaliações para a versão reviews:v1, que não acessa o serviço de avaliação com estrelas.

6. Aguarde 1 ou 2 minutos e retorne ao painel do Service Mesh acessando Menu de navegação > Kubernetes Engine > Service Mesh > avaliações > Infraestrutura.

7. Selecione MOSTRAR LINHA DO TEMPO e concentre o gráfico nos últimos 5 minutos do tráfego. Você verá que o tráfego passa da distribuição uniforme para a carga de trabalho versão 1 o tempo todo.

   

   Também é possível ver a nova distribuição de tráfego na guia Tráfego ou na visualização de topologia. No entanto, ambos levam alguns minutos a mais antes que os dados sejam mostrados.

Clique em Verificar meu progresso para conferir o objetivo. Aplique os serviços virtuais.

Tarefa 7: fazer o roteamento para uma versão específica de um serviço com base na identidade do usuário

Nesta tarefa, você altera a configuração da rota para que todo o tráfego de um usuário específico seja roteado para uma versão específica do serviço. Nesse caso, todo o tráfego do usuário Jason será roteado para o serviço reviews:v2, a versão que inclui o recurso de avaliação com estrelas.

Observação: o Istio não retém informações sobre a identidade do usuário. Este exemplo é possível porque o serviço productpage adiciona o cabeçalho personalizado de um usuário final em todas as solicitações HTTP de saída no serviço de avaliações.

1. Revise a configuração encontrada no GitHub. Essa configuração define um recurso VirtualService.

2. Aplique a configuração com o seguinte comando no Cloud Shell:

   wget https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/networking/virtual-service-reviews-test-v2.yaml sed -i 's#istio\.io/v1#istio\.io/v1alpha3#g' virtual-service-reviews-test-v2.yaml kubectl apply -f virtual-service-reviews-test-v2.yaml

   Saída:

   virtualservice.networking.istio.io/reviews configured

3. Confirme se a regra está criada:

   kubectl get virtualservice reviews

   Saída:

   NAME GATEWAYS HOSTS AGE reviews ["reviews"] 35m

4. Teste a nova configuração de roteamento usando a UI do Bookinfo:

   • Navegue novamente para /productpage do aplicativo Bookinfo.

   • Desta vez, clique em Fazer login e use o Nome de usuário jason com qualquer senha.

   • Observe que a UI mostra as estrelas do serviço de avaliação.

   Você pode sair e tentar fazer login como outro usuário. Você não verá mais as estrelas com as avaliações.

Para visualizar melhor o efeito do novo roteamento de tráfego, crie uma nova carga em segundo plano de solicitações autenticadas para o serviço.

5. Inicie uma nova sessão do siege, gerando apenas 20% do tráfego do primeiro, mas com todas as solicitações autenticadas como jason:

   curl -c cookies.txt -F "username=jason" -L -X \ POST http://$GATEWAY_URL/login cookie_info=$(grep -Eo "session.*" ./cookies.txt) cookie_name=$(echo $cookie_info | cut -d' ' -f1) cookie_value=$(echo $cookie_info | cut -d' ' -f2) siege -c 5 http://$GATEWAY_URL/productpage \ --header "Cookie: $cookie_name=$cookie_value"

6. Aguarde um ou dois minutos, atualize a página que mostra a telemetria de infraestrutura, ajuste a linha do tempo para mostrar a hora atual e verifique no painel do Service Mesh. Você vai notar que cerca de 85% das solicitações nos últimos minutos foram para a versão 1 porque não estão autenticadas. Cerca de 15% foram para a versão 2 porque foram criados como jason.

7. No Cloud Shell, pressione Ctrl+c para cancelar a sessão do siege.

8. Para finalizar a tarefa, remova os serviços virtuais do aplicativo:

   kubectl delete -f virtual-service-all-v1.yaml

   Saída:

   virtualservice.networking.istio.io "productpage" deleted virtualservice.networking.istio.io "reviews" deleted virtualservice.networking.istio.io "ratings" deleted virtualservice.networking.istio.io "details" deleted

9. Aguarde 1 ou 2 minutos, atualize o painel do Service Mesh, ajuste a linha do tempo para mostrar a hora atual e confirme se o tráfego está novamente equilibrado entre as versões.

   

Clique em Verificar meu progresso para conferir o objetivo. Configuração de roteamento específica do usuário.

Tarefa 8: deslocar o tráfego gradualmente de uma versão de um microsserviço para outra

Nesta tarefa, você migrará gradualmente o tráfego de uma versão de um microsserviço para outra. Por exemplo, é possível usar essa abordagem para migrar o tráfego de uma versão mais antiga para uma versão nova.

Você enviará 50% do tráfego para reviews:v1 e 50% para reviews:v3. Depois, fará a migração enviando 100% do tráfego para reviews:v3.

No Service Mesh, é possível alcançar essa meta configurando uma sequência de regras que fazem o roteamento de uma porcentagem do tráfego para um serviço ou outro.

1. No Cloud Shell, roteie todo o tráfego para a versão v1 de cada serviço:

   kubectl apply -f virtual-service-all-v1.yaml

   Saída:

   virtualservice.networking.istio.io/productpage created virtualservice.networking.istio.io/reviews created virtualservice.networking.istio.io/ratings created virtualservice.networking.istio.io/details created

2. Navegue novamente para /productpage do aplicativo Bookinfo e confirme se você não vê estrelas com avaliações. Todo o tráfego está sendo roteado para o back-end v1.

3. Aguarde um minuto, atualize o painel do Service Mesh, ajuste a linha do tempo para mostrar a hora atual e confirme se todo o tráfego foi roteado para o back-end v1.

4. Transfira 50% do tráfego de reviews:v1 para reviews:v3.

   wget https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/networking/virtual-service-reviews-50-v3.yaml sed -i 's#istio\.io/v1#istio\.io/v1alpha3#g' virtual-service-reviews-50-v3.yaml kubectl apply -f virtual-service-reviews-50-v3.yaml

   Saída:

   virtualservice.networking.istio.io/reviews configured

5. Navegue novamente para /productpage do aplicativo Bookinfo.

6. Atualize a visualização para emitir várias solicitações.

   Observe uma distribuição praticamente uniforme de avaliações sem estrelas, da v1, e avaliações com estrelas vermelhas, da v3, que acessa o serviço de avaliações.

7. Aguarde 1 minuto, atualize a página, ajuste a linha do tempo para mostrar a hora atual e confirme no painel do Service Mesh que o tráfego para o serviço de avaliações é dividido 50/50 entre v1 e v3.

   

8. Transfira os 50% de tráfego restantes para reviews:v3.

9. Supondo que você determine que o serviço reviews:v3 é estável, faça o roteamento de 100% do tráfego para reviews:v3 aplicando esse serviço virtual:

   wget https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/networking//virtual-service-reviews-v3.yaml sed -i 's#istio\.io/v1#istio\.io/v1alpha3#g' virtual-service-reviews-v3.yaml kubectl apply -f virtual-service-reviews-v3.yaml

   Saída:

   virtualservice.networking.istio.io/reviews configured

10. Teste a nova configuração de roteamento usando a UI do Bookinfo.

11. Navegue novamente para /productpage do aplicativo Bookinfo.

12. Atualize /productpage. Você sempre verá avaliações de livros com estrelas na cor vermelha.

13. Aguarde um minuto, atualize a página e confirme no painel do Service Mesh que todo o tráfego enviado ao serviço de avaliações é enviado para a v3.

    

14. Para finalizar, remova os serviços virtuais do aplicativo.

    kubectl delete -f virtual-service-all-v1.yaml

    Saída:

    virtualservice.networking.istio.io "productpage" deleted virtualservice.networking.istio.io "reviews" deleted virtualservice.networking.istio.io "ratings" deleted virtualservice.networking.istio.io "details" deleted

Nesta tarefa, você migrou de uma versão antiga para uma nova do serviço de avaliações usando o recurso de roteamento ponderado do Service Mesh. É muito diferente de fazer uma migração de versão com recursos de implantação das plataformas de orquestração de contêineres, que usam o escalonamento de instâncias para gerenciar o tráfego.

Clique em Verificar meu progresso para conferir o objetivo. Migre o tráfego da v1 para a v3.

Tarefa 9: adicionar tempos limite para evitar esperar indefinidamente pelas respostas do serviço

Um tempo limite para solicitações HTTP pode ser especificado usando o campo "timeout" da regra de rota. Por padrão, o tempo limite da solicitação está desativado, mas nesta tarefa você vai substituir o tempo limite do serviço de avaliações por 1 segundo. Para ver o efeito, você também introduz um atraso artificial de dois segundos nas chamadas para o serviço de classificações. Vamos começar introduzindo o atraso.

1. No Cloud Shell, roteie todo o tráfego para a versão v1 de cada serviço:

   kubectl apply -f virtual-service-all-v1.yaml

   Saída:

   virtualservice.networking.istio.io/productpage created virtualservice.networking.istio.io/reviews created virtualservice.networking.istio.io/ratings created virtualservice.networking.istio.io/details created

2. Encaminhe as solicitações para a v2 do serviço de avaliações, ou seja, uma versão que chama o serviço de classificação:

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

3. Adicione um atraso de 2 segundos às chamadas para o serviço de classificação:

   kubectl apply -f - <<EOF apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: ratings spec: hosts: - ratings http: - fault: delay: percent: 100 fixedDelay: 2s route: - destination: host: ratings subset: v1 EOF

4. Abra o URL do Bookinfo http://$GATEWAY_URL/productpage no navegador. O aplicativo Bookinfo vai funcionar normalmente (com as estrelas de classificação exibidas), mas haverá um atraso de 2 segundos sempre que você atualizar a página. Se o aplicativo Bookinfo não funcionar normalmente, mude o atraso para 1 segundo e tente de novo.

5. Acesse as avaliações / métricas para ver que a latência está aumentando para 2 segundos. Se você mudou o atraso para 1 segundo, a latência deve aumentar para 1 segundo.

   

6. Agora adicione um tempo limite de solicitação de meio segundo para chamadas ao serviço de avaliações:

   kubectl apply -f - <<EOF apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: reviews spec: hosts: - reviews http: - route: - destination: host: reviews subset: v2 timeout: 0.5s EOF

7. Atualize a página da web do Bookinfo.

Agora, ele vai retornar em cerca de 1 segundo em vez de 2, e as avaliações não estarão disponíveis.

Observação: a resposta leva 1 segundo, mesmo que o tempo limite esteja configurado para meio segundo, porque há uma nova tentativa codificada no serviço productpage. Portanto, ele chama o serviço de avaliações que está atingindo o tempo limite duas vezes antes de retornar. Se quiser mudar a configuração de novas tentativas, configure o VirtualService executando o comando mostrado abaixo. kubectl apply -f - <<EOF apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: productpage spec: hosts: - productpage http: - route: - destination: host: productpage subset: v1 retries: attempts: 1 perTryTimeout: 2s EOF

8. Para finalizar, remova os serviços virtuais do aplicativo.

   kubectl delete -f virtual-service-all-v1.yaml

   Saída:

   virtualservice.networking.istio.io "productpage" deleted virtualservice.networking.istio.io "reviews" deleted virtualservice.networking.istio.io "ratings" deleted virtualservice.networking.istio.io "details" deleted

Nesta tarefa, você usou o Istio para definir o tempo limite de solicitação para chamadas ao microsserviço de avaliações como meio segundo. Por padrão, o tempo limite da solicitação fica desativado. Como o serviço de avaliações chama o serviço de classificação ao processar solicitações, você usou o Istio para injetar um atraso de 2 segundos nas chamadas para classificações. Isso fez com que o serviço de avaliações levasse mais de meio segundo para ser concluído e, consequentemente, você pôde ver o tempo limite em ação.

Você observou que, em vez de mostrar avaliações, a página do produto Bookinfo (que chama o serviço de avaliações para preencher a página) exibiu a mensagem: "No momento, as avaliações de produtos não estão disponíveis para este livro". Isso aconteceu porque ele recebeu o erro de tempo limite do serviço de avaliações.

Clique em Verificar meu progresso para conferir o objetivo. Adicione tempos limite para o serviço de classificação.

Tarefa 10: adicionar interruptores de circuito para aumentar a resiliência dos microsserviços

Esta tarefa mostra como configurar o interruptor de circuitos para conexões, solicitações e detecção de outliers.

A interrupção de circuito é um padrão importante para criar aplicativos de microsserviços resilientes. Ela permite escrever aplicativos que limitam o impacto de falhas, picos de latência e outros efeitos indesejáveis de peculiaridades da rede.

Nesta tarefa, você vai configurar regras de interrupção de circuito e testar a configuração acionando intencionalmente o interruptor de circuito.

1. No Cloud Shell, roteie todo o tráfego para a versão v1 de cada serviço:

   kubectl apply -f virtual-service-all-v1.yaml

   Saída:

   virtualservice.networking.istio.io/productpage created virtualservice.networking.istio.io/reviews created virtualservice.networking.istio.io/ratings created virtualservice.networking.istio.io/details created

2. Crie uma regra de destino para aplicar as configurações de interrupção de circuito ao chamar o serviço productpage:

   kubectl apply -f - <<EOF apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: productpage spec: host: productpage subsets: - name: v1 labels: version: v1 trafficPolicy: connectionPool: tcp: maxConnections: 1 http: http1MaxPendingRequests: 1 maxRequestsPerConnection: 1 outlierDetection: consecutive5xxErrors: 1 interval: 1s baseEjectionTime: 3m maxEjectionPercent: 100 EOF

3. No Cloud Shell, acesse a primeira guia e pressione Ctrl+c para interromper o siege.

4. Crie um cliente para enviar tráfego ao serviço productpage.

Deve ser um cliente simples de teste de carga chamado fortio. Com o Fortio, é possível controlar o número de conexões, a simultaneidade e os atrasos das chamadas HTTP de saída. Você vai usar esse cliente para "acionar" as políticas de interruptor de circuito definidas no DestinationRule:

kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.9/samples/httpbin/sample-client/fortio-deploy.yaml

5. Faça login no pod do cliente e use a ferramenta fortio para chamar productpage. Transmita em curl para indicar que você só quer fazer uma chamada:

   export FORTIO_POD=$(kubectl get pods -lapp=fortio -o 'jsonpath={.items[0].metadata.name}') kubectl exec "$FORTIO_POD" -c fortio -- /usr/bin/fortio curl -quiet http://${GATEWAY_URL}/productpage

6. Chame o serviço com duas conexões simultâneas (-c 2) e envie 20 solicitações (-n 20):

   kubectl exec "$FORTIO_POD" -c fortio -- /usr/bin/fortio load -c 2 -qps 0 -n 20 -loglevel Warning http://${GATEWAY_URL}/productpage

   É interessante notar que quase todas as solicitações foram atendidas. Isso é interessante porque maxConnections: 1 e http1MaxPendingRequests: 1. Essas regras indicam que, se você exceder mais de uma conexão e solicitação simultaneamente, haverá algumas falhas quando o istio-proxy abrir o circuito para mais solicitações e conexões.

   No entanto, vemos que o istio-proxy permite alguma flexibilidade:

   Code 200 : 17 (85.0 %) Code 503 : 3 (15.0 %)

7. Aumente o número de conexões simultâneas para 3:

   kubectl exec "$FORTIO_POD" -c fortio -- /usr/bin/fortio load -c 3 -qps 0 -n 30 -loglevel Warning http://${GATEWAY_URL}/productpage

   Agora você começa a ver o comportamento esperado de interrupção do circuito. Apenas 36,7% das solicitações foram bem-sucedidas, e o restante foi bloqueado pela interrupção do circuito:

   Code 200 : 11 (36.7 %) Code 503 : 19 (63.3 %)

Clique em Verificar meu progresso para conferir o objetivo. Adicione interruptores de circuito.

Revisão

Neste laboratório, você aprendeu várias maneiras de gerenciar e rotear o tráfego para diferentes finalidades. Você também ajustou e visualizou o deslocamento de tráfego por conta própria, inclusive camada 7, camada do aplicativo e roteamento, que aparecem nos cabeçalhos de solicitação.

Próximas etapas

• Leia mais sobre gerenciamento de tráfego no Istio
• Leia mais sobre implantações canário usando o Istio.

Finalize o laboratório

Após concluir o laboratório, clique em Terminar o laboratório. O Google Skills remove os recursos usados e limpa a conta para você.

Você poderá classificar sua experiência neste 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.