Implantar a migração com a expansão de malha do Istio

Last reviewed 2023-11-02 UTC

Neste documento, descrevemos como inicializar e configurar uma malha de serviço para oferecer suporte à migração recurso a recurso de um data center local para o Google Cloud. Ele pressupõe que você conhece a arquitetura de referência associada. Ele é destinado a administradores, desenvolvedores e engenheiros que querem usar uma malha de serviço que encaminha dinamicamente o tráfego para o ambiente de origem ou para o Google Cloud.

O objetivo deste guia de implantação é ajudar você a migrar de um ambiente fora do Google Cloud (como um provedor de nuvem local ou de outro tipo) para o Google Cloud. Essas migrações têm uma camada de complexidade de rede, já que é preciso configurar um canal de comunicação seguro entre os ambientes que são e que não são do Google Cloud.

Arquitetura

O diagrama a seguir mostra como é possível usar uma malha de serviço para rotear o tráfego para microsserviços em execução no ambiente de origem ou para o Google Cloud:

No diagrama, o gateway do Istio fornece uma malha de serviço que vincula os microsserviços de um aplicativo. O Google Kubernetes Engine (GKE) atua como um contêiner para definir os limites de cada microsserviço. Para mais informações, consulte Suporte à migração com a expansão de malha do Istio.

Você usará os softwares a seguir nesta implantação:

• Ubuntu Server e Container-Optimized OS: sistemas operacionais usados nesta implantação.
• Docker Engine: plataforma para executar cargas de trabalho conteinerizadas.
• Docker Compose: uma ferramenta para definir e executar apps do Docker.
• Istio: uma malha de serviço de código aberto.
• Kiali: uma ferramenta para visualizar as malhas de serviço do Istio.
• Envoy: um proxy secundário usado pelo Istio para incluir serviços na malha.

A carga de trabalho de exemplo

Nesta implantação, você usa o app Bookinfo, que é um app de microsserviços poliglota de quatro camadas que mostra informações sobre livros. Esse app foi desenvolvido para execução no Kubernetes, mas é implantado em uma instância do Compute Engine usando o Docker e o Docker Compose. Com o Docker Compose, você descreve apps de vários contêineres por meio de descritores YAML. Depois, é possível iniciar o app executando um único comando.

Embora essa carga de trabalho de exemplo já esteja em contêiner, essa abordagem também se aplica a serviços que não estão. Nesses casos, é possível adicionar uma fase de modernização, em que você conteineriza os serviços que pretende migrar.

O aplicativo Bookinfo tem quatro componentes de microsserviços:

• productpage: chama os microsserviços details, ratings e reviews para preencher a página de detalhes do livro
• details: exibe informações sobre livros
• reviews: contém resenhas literárias
• ratings: retorna informações de classificação de livros para acompanhar a resenha de um livro

Para demonstrar o Istio e os recursos dele, os autores e administradores do app Bookinfo implementaram várias versões de alguns desses componentes. Nesta implementação, você implantará apenas uma versão de cada componente.

Objetivos

• Inicializar um ambiente que simule o data center local.
• Implantar e testar cargas de trabalho de exemplo no data center local.
• Configurar o ambiente de destino no Google Cloud.
• Migrar a carga de trabalho do data center local para o ambiente de destino.
• Testar as cargas de trabalho em execução no ambiente de destino.
• desativar o data center local.

Custos

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

• Compute Engine
• Google Kubernetes Engine (GKE)
• Persistent Disk
• Networking

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.

prepare o ambiente

Você realiza a maioria das etapas desta implantação no Cloud Shell.

1. No Console do Google Cloud, ative o Cloud Shell.

   Ativar o Cloud Shell

   Na parte inferior do Console do Google Cloud, uma sessão do Cloud Shell é iniciada e exibe um prompt de linha de comando. O Cloud Shell é um ambiente shell com a CLI do Google Cloud já instalada e com valores já definidos para o projeto atual. A inicialização da sessão pode levar alguns segundos.

2. No Cloud Shell, verifique a quantidade de espaço livre que você tem:

   df -h
   

   Para concluir esta implantação, você precisa de cerca de 200 MB de espaço livre.

3. Altere o diretório de trabalho para o diretório ${HOME}:

   cd "${HOME}"
   

4. Clone o repositório Git, que contém os scripts e os arquivos de manifesto que serão implantados, e configure a carga de trabalho de exemplo:

   git clone https://github.com/GoogleCloudPlatform/solutions-istio-mesh-expansion-migration
   

5. Faça a autenticação com o Application Default Credentials (ADC):

   gcloud auth application-default login
   

   A saída mostra o caminho para o arquivo Application Default Credentials:

   Credentials saved to file:
   [/tmp/tmp.T5Qae7XwAO/application_default_credentials.json]
   

   Anote o caminho do arquivo Application Default Credentials. Essas credenciais serão usadas por qualquer biblioteca que solicite o ADC.

6. Inicialize as variáveis de ambiente:

   APPLICATION_DEFAULT_CREDENTIALS_PATH=APPLICATION_DEFAULT_CREDENTIALS_PATH
   BILLING_ACCOUNT_ID=BILLING_ACCOUNT_ID
   DEFAULT_FOLDER=DEFAULT_FOLDER
   DEFAULT_PROJECT=DEFAULT_PROJECT
   DEFAULT_REGION=DEFAULT_REGION
   DEFAULT_ZONE=DEFAULT_ZONE
   GKE_CLUSTER_NAME=istio-migration
   DEPLOYMENT_DIRECTORY_PATH="$(pwd)"/solutions-istio-mesh-expansion-migration
   ORGANIZATION_ID=ORGANIZATION_ID
   

   Substitua:

   • APPLICATION_DEFAULT_CREDENTIALS_PATH: o caminho para o arquivo ADC da etapa anterior.
   • BILLING_ACCOUNT_ID: o ID da conta de faturamento que será usada.
   • DEFAULT_FOLDER: o ID da pasta do Google Cloud em que o projeto do Google Cloud será criado. Se você quiser que o Terraform crie o projeto diretamente na organização do Google Cloud, deixe essa string vazia.
   • DEFAULT_PROJECT: o ID do projeto do Google Cloud que provisiona os recursos para concluir esta implantação. O Terraform cria esse projeto quando você provisiona o ambiente.
   • DEFAULT_REGION: a região padrão em que os recursos são provisionados.
   • DEFAULT_ZONE: a zona padrão em que os recursos são provisionados.
   • ORGANIZATION_ID: o ID da sua organização do Google Cloud.

Provisionar os ambientes

Nesta seção, você provisiona os seguintes ambientes para esta implantação:

• Ambiente que simula o data center de origem no local.
• Ambiente que simula o destino da migração.

Nesta implantação, os dois ambientes são executados no Google Cloud. Essa abordagem ajuda a simplificar o processo de configuração porque há apenas uma fase de inicialização. Provisione automaticamente os ambientes de origem e de destino usando o Terraform.

1. No Cloud Shell, altere o diretório de trabalho para o diretório do repositório:

   cd "${DEPLOYMENT_DIRECTORY_PATH}"
   

2. Inicialize a configuração de back-end do Terraform:

   scripts/init.sh \
   --application-credentials "${APPLICATION_DEFAULT_CREDENTIALS_PATH}" \
   --billing-account-id "${BILLING_ACCOUNT_ID}" \
   --default-folder "${DEFAULT_FOLDER}" \
   --default-project "${DEFAULT_PROJECT}" \
   --default-region "${DEFAULT_REGION}" \
   --default-zone "${DEFAULT_ZONE}" \
   --organization-id "${ORGANIZATION_ID}"
   

   O script init.sh faz o seguinte:

   • Gera os descritores para configurar o back-end do Terraform.
   • Inicializa o diretório de trabalho do Terraform.

3. Altere o diretório de trabalho para o diretório terraform:

   cd "${DEPLOYMENT_DIRECTORY_PATH}"/terraform
   

4. Aplique as alterações com o Terraform:

   terraform apply
   

5. Quando solicitado, revise as alterações propostas e confirme-as respondendo a yes.

   O resultado será assim:

   Apply complete! Resources: 27 added, 0 changed, 0 destroyed
   

Ao aplicar as alterações propostas com o Terraform, você automatiza as seguintes tarefas:

• Criação de regras de firewall para permitir o acesso externo aos microsserviços e às comunicações com o banco de dados e entre nós.
• Criar e ativar uma conta de serviço para as instâncias do Compute Engine usarem. Recomendamos que você limite a conta de serviço apenas aos papéis e às permissões de acesso necessários para executar o app. Para esta implantação, a conta de serviço das instâncias do Compute Engine requer apenas o papel Leitor do Compute (roles/compute.viewer). Esse papel concede acesso somente leitura aos recursos do Compute Engine.
• Provisionamento e configuração de uma instância do Compute Engine para hospedar as cargas de trabalho que serão migradas como um ambiente de origem. Ao configurar a instância do Compute Engine, você fornece um script de inicialização que instala o Docker, o Docker Compose e o Dnsmasq.
• Criação e ativação de uma conta de serviço para o cluster do GKE para hospedar as cargas de trabalho como um ambiente de destino. Nesta implantação, você cria uma conta de serviço que os nós do cluster do GKE usam. Recomendamos que você limite a conta de serviço apenas aos papéis e às permissões de acesso necessários para executar o app. Para esta implantação, os papéis necessários à conta de serviço para nós do cluster do GKE são os seguintes:
  • Leitor do Monitoring (roles/monitoring.viewer)
  • Gravador de métricas do Monitoring (roles/monitoring.metricWriter)
  • Gravador de registros (roles/logging.logWriter), conforme descrito em Como aumentar a segurança do seu cluster
• Provisionamento e configuração de um cluster do GKE para hospedar as cargas de trabalho como um ambiente de destino. Para provisionar os clusters do GKE, o Terraform usa o módulo Terraform do Kubernetes Engine.

Implantar a carga de trabalho no ambiente de origem

Nesta implantação, você implanta o app Bookinfo do Istio como a carga de trabalho que será migrada. Veja no diagrama a seguir a arquitetura do ambiente de origem:

No diagrama, os clientes acessam a carga de trabalho de exemplo em execução no Compute Engine. Para reduzir a complexidade neste exemplo, os clientes se conectam diretamente a uma única instância do Compute Engine. Em um ambiente de produção, essa conexão direta é improvável, porque você precisa de uma camada de balanceamento de carga para executar várias instâncias de uma carga de trabalho.

1. No Cloud Shell, altere o diretório de trabalho para o diretório do repositório:

   cd "${DEPLOYMENT_DIRECTORY_PATH}"
   

2. Implante as cargas de trabalho nas instâncias do Compute Engine:

   scripts/workloads.sh \
   --deploy-with "COMPOSE" \
   --default-project "${DEFAULT_PROJECT}" \
   --default-region "${DEFAULT_REGION}" \
   --default-zone "${DEFAULT_ZONE}"
   

   O script workloads.sh faz o seguinte:

   • Configura o projeto, a região e a zona padrão.
   • Copia os descritores do Docker Compose para as instâncias do Compute Engine.
   • Implanta a carga de trabalho de exemplo usando o Docker Compose.

   Se você ainda não criou um arquivo de chave SSH para autenticar com instâncias do Compute Engine, a CLI gcloud solicitará que você gere um.

   Na saída, você vê uma confirmação da implantação e como pode acessá-la. O resultado será assim:

   You can access the workload by loading http://COMPUTE_ENGINE_PRODUCTPAGE_EXTERNAL_IP:9080/productpage
   

   Na saída, COMPUTE_ENGINE_PRODUCTPAGE_EXTERNAL_IP é o endereço IP em que a carga de trabalho é veiculada. Anote o endereço IP, porque você o usará em uma etapa posterior.

Testar sua implantação no ambiente de origem

• Abra um navegador e acesse o seguinte URL, em que COMPUTE_ENGINE_PRODUCTPAGE_EXTERNAL_IP é o endereço IP da etapa anterior:

  http://COMPUTE_ENGINE_PRODUCTPAGE_EXTERNAL_IP:9080/productpage
  

Uma página do Bookinfo é exibida com detalhes sobre livros e classificações relevantes:

Configurar o Istio

Nesta seção, você configurará o ambiente de destino no Google Cloud instalando o Istio e, em seguida, usará o Istio para expor a carga de trabalho de exemplo. Veja no diagrama a seguir a arquitetura do ambiente de destino:

No diagrama, o Istio expõe a carga de trabalho em execução no Compute Engine.

Instalar o Istio

1. No Cloud Shell, altere o diretório de trabalho para o diretório do repositório:

   cd "${DEPLOYMENT_DIRECTORY_PATH}"
   

2. Instale o Istio:

   scripts/install-istio.sh \
   --cluster-name "${GKE_CLUSTER_NAME}" \
   --google-cloud-project "${DEFAULT_PROJECT}" \
   --cluster-region "${DEFAULT_REGION}"
   

   O script install-istio.sh faz o seguinte:

   • Faz o download da distribuição do Istio.
   • Instala o Istio no cluster do GKE do ambiente de destino.
   • Implanta um gateway para expor os serviços na malha de serviço.
   • Configura o Istio para permitir a expansão da malha de serviço nas instâncias do Compute Engine que simulam o ambiente de origem.
   • Instala ferramentas de monitoramento e visualização de malha de serviço, como o Kiali.

   Quando a execução desse comando terminar, o console mostrará uma confirmação da instalação. O resultado será assim:

   ✔ Istio core installed
   ✔ Istiod installed
   ✔ Ingress gateways installed
   ✔ Egress gateways installed
   ✔ Installation complete
   

Configurar a expansão de malha do Istio

Nesta seção, você conecta a instância do Compute Engine que simula o ambiente de origem à malha de serviço. A malha de serviço processa a conexão dos microsserviços no ambiente legado que serão migrados para o ambiente de destino. Nesta fase, a malha de serviço está vazia, aguardando que os serviços sejam registrados. A malha de serviço ainda não está recebendo tráfego de produção.

1. No Cloud Shell, altere o diretório de trabalho para o diretório do repositório:

   cd "${DEPLOYMENT_DIRECTORY_PATH}"
   

2. Instale e configure o Istio na instância do Compute Engine:

   scripts/compute-engine-mesh-expansion-setup.sh \
   --default-project "${DEFAULT_PROJECT}" \
   --default-region "${DEFAULT_REGION}" \
   --default-zone "${DEFAULT_ZONE}"
   

   O script compute-engine-mesh-expansion-setup.sh faz o seguinte:

   • Instala o Istio nas instâncias do Compute Engine do ambiente de origem.
   • Inicia o serviço Istio nas instâncias do Compute Engine.

Expor a carga de trabalho

Nesta seção, você registra as cargas de trabalho em execução na instância do Compute Engine e simula o ambiente de origem na malha de serviço do Istio.

O script workloads.sh executado nesta seção configura regras de roteamento para dividir o tráfego de produção entre serviços em execução no ambiente legado e no ambiente de destino, usando a malha de serviço. Como o roteamento de tráfego dentro da malha de serviço é transparente para os clientes, eles não sabem que a configuração de roteamento foi alterada.

1. No Cloud Shell, altere o diretório de trabalho para o diretório do repositório:

   cd "${DEPLOYMENT_DIRECTORY_PATH}"
   

2. Exponha as cargas de trabalho:

   scripts/workloads.sh \
   --default-project "${DEFAULT_PROJECT}" \
   --default-region "${DEFAULT_REGION}" \
   --default-zone "${DEFAULT_ZONE}" \
   --expose-with "ISTIO_COMPUTE_ENGINE"
   

3. O script workloads.sh faz o seguinte:

   • Configura o projeto, a região e a zona padrão.
   • Ativa a injeção automática de sidecar para evitar edições manuais nos descritores de implantação.
   • Registra as cargas de trabalho em execução na instância do Compute Engine na malha configurando os endpoints WorkloadEntry e os Serviços correspondentes.
   • Implanta o ServiceEntries para permitir o tráfego para o servidor de metadados do Compute Engine e as APIs do Cloud.
   • Implanta os serviços virtuais para rotear o tráfego do gateway do Istio para a instância productpage em execução na instância do Compute Engine.

   Na saída, você vê uma confirmação da implantação e como pode acessá-la. O resultado será assim:

   You can access the workload by loading http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/productpage
   

   Na saída, ISTIO_INGRESS_GATEWAY_EXTERNAL_IP é o endereço IP em que a carga de trabalho é veiculada. Anote o endereço IP, porque você o usará em uma etapa posterior.

Testar a expansão de malha do Istio

Nesta seção, você testará a carga de trabalho de exemplo em execução na instância do Compute Engine que usou o Istio para expor.

• Abra um navegador e acesse o seguinte URL, em que ISTIO_INGRESS_GATEWAY_EXTERNAL_IP é o endereço IP da etapa anterior:

  http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/productpage
  

O ponto de entrada do ambiente de origem (que se conecta à instância do Compute Engine) ainda está disponível nesta fase. Ao migrar um ambiente de produção, recomendamos que você redirecione gradualmente o tráfego para o ambiente de destino atualizando a configuração da camada de balanceamento de carga.

Visualizar a malha de serviço

Nesta seção, você usa o Kiali para ver uma representação visual da malha de serviço.

1. Abra um navegador e acesse o seguinte URL, em que ISTIO_INGRESS_GATEWAY_EXTERNAL_IP é o endereço IP da etapa anterior:

   http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/kiali/console/graph/namespaces/?edges=requestDistribution&graphType=versionedApp&namespaces=default%2Cistio-system&idleNodes=false&duration=60&refresh=15000&operationNodes=false&idleEdges=false&injectServiceNodes=true&layout=dagre
   

   O painel de serviços do Kiali é exibido.

2. No Cloud Shell, execute uma solicitação várias vezes para a página principal da carga de trabalho de exemplo:

   ISTIO_INGRESS_GATEWAY_EXTERNAL_IP="$(kubectl get svc istio-ingressgateway -n istio-system -o jsonpath='{.status.loadBalancer.ingress[0].ip}')"
   
   for i in {1..10000}; do curl -s -o /dev/null -w "$(date --iso-8601=ns) - %{http_code}\n"  http://"${ISTIO_INGRESS_GATEWAY_EXTERNAL_IP}"/productpage; done
   

   A solicitação gera tráfego para o app Bookinfo. A saída mostra uma lista dos carimbos de data/hora de cada solicitação HTTP para o serviço productpage e o código de retorno HTTP de cada solicitação (200, neste caso).

   O resultado será assim:

   2021-06-09T10:16:15,355323181+00:00 - 200
   2021-06-09T10:16:15,355323182+00:00 - 200
   2021-06-09T10:16:15,355323183+00:00 - 200
   [...]
   

   A solicitação leva algum tempo para ser concluída. Portanto, deixe-a em execução e prossiga para a próxima etapa.

3. No painel de serviços do Kiali, você vê um diagrama da malha atual, com tráfego roteado para serviços em execução no Compute Engine. Todo o tráfego é roteado do microsserviço istio-ingressgateway para productpage, que é executado na instância do Compute Engine com o rótulo da versão compute-engine, e para o serviço kiali para visualizar a malha de serviço.

   Você não vê os outros serviços no gráfico (details, reviews e ratings) porque o microsserviço productpage executado no Compute Engine se conecta diretamente a outros microsserviços em execução no Compute Engine. O microsserviço productpage não passa pela malha de serviço.

   Se você quiser que todo o tráfego passe pela malha de serviço, será necessário reconfigurar as cargas de trabalho em execução no Compute Engine para apontar para os serviços na malha, em vez de se conectar diretamente a eles.

   Se o diagrama a seguir não aparecer no painel do Kiali, atualize a página.

   

   O diagrama no painel do Kiali mostra que o tráfego é roteado para serviços em execução no Compute Engine.

4. No Cloud Shell, para interromper o comando de geração de tráfego, pressione Control+C.

Migrar a carga de trabalho

Nesta seção, você migra os componentes da carga de trabalho de exemplo da instância do Compute Engine para o cluster do GKE. Para cada microsserviço da carga de trabalho de exemplo, faça o seguinte:

• Implante uma instância do microsserviço no cluster do GKE.
• Comece a rotear o tráfego para as instâncias do microsserviço em execução no Compute Engine e no GKE.

O diagrama a seguir mostra a arquitetura do sistema para esta seção:

No diagrama, o Cloud Load Balancing encaminha o tráfego para o gateway do Istio e, em seguida, o Istio encaminha o tráfego para os serviços em execução no Compute Engine ou para os serviços em execução no GKE.

Para migrar os componentes da carga de trabalho de exemplo, faça os procedimentos a seguir:

1. No Cloud Shell, altere o diretório de trabalho para o diretório do repositório:

   cd "${DEPLOYMENT_DIRECTORY_PATH}"
   

2. Implante as cargas de trabalho no ambiente de destino:

   scripts/workloads.sh \
   --default-project "${DEFAULT_PROJECT}" \
   --default-region "${DEFAULT_REGION}" \
   --default-zone "${DEFAULT_ZONE}" \
   --deploy-with "GKE"
   

   O script workloads.sh faz o seguinte:

   • Ativa a injeção automática de sidecar para evitar edições manuais nos descritores de implantação.
   • Implanta ServiceAccounts e implantações para executar as cargas de trabalho de exemplo no cluster do GKE.

   Você vê uma confirmação da implantação e como acessá-la. A resposta será semelhante a:

   You can access the workload by loading http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/productpage
   

A malha de serviço encaminha o tráfego para as cargas de trabalho de exemplo em execução nas instâncias do Compute Engine e para aquelas em execução no cluster do GKE.

Testar a carga de trabalho em execução no Compute Engine e no GKE

Nesta seção, você testa a carga de trabalho de exemplo que implantou no Compute Engine e no GKE.

• Abra um navegador e acesse o seguinte URL, em que ISTIO_INGRESS_GATEWAY_EXTERNAL_IP é o endereço IP da etapa anterior:

  http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/productpage
  

  Uma página Bookinfo é exibida com informações sobre livros e classificações relevantes.

Como você implantou a mesma versão da carga de trabalho de exemplo no Compute Engine e no cluster do GKE, a saída é igual a do teste anterior

Visualizar a malha de serviço

Nesta seção, você usa o Kiali para ver uma representação visual da malha de serviço.

1. Abra um navegador e acesse o seguinte URL, em que ISTIO_INGRESS_GATEWAY_EXTERNAL_IP é o endereço IP da etapa anterior:

   http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/kiali/console/graph/namespaces/?edges=requestDistribution&graphType=versionedApp&namespaces=default%2Cistio-system&idleNodes=false&duration=60&refresh=15000&operationNodes=false&idleEdges=false&injectServiceNodes=true&layout=dagre
   

2. No Cloud Shell, execute uma solicitação várias vezes para a página principal da carga de trabalho de exemplo:

   ISTIO_INGRESS_GATEWAY_EXTERNAL_IP="$(kubectl get svc istio-ingressgateway -n istio-system -o jsonpath='{.status.loadBalancer.ingress[0].ip}')"
   for i in {1..10000}; do curl -s -o /dev/null -w "$(date --iso-8601=ns) - %{http_code}\n"  http://"${ISTIO_INGRESS_GATEWAY_EXTERNAL_IP}"/productpage; done
   

   O comando gera tráfego para o app Bookinfo. A saída esperada é uma lista das datas das solicitações HTTP para o serviço productpage e o código de retorno HTTP de cada solicitação (neste caso, 200 OK). A resposta será parecida com esta:

   2021-06-09T10:16:15,355323181+00:00 - 200
   2021-06-09T10:16:15,355323182+00:00 - 200
   2021-06-09T10:16:15,355323183+00:00 - 200
   [...]
   

3. No painel de serviços do Kiali, você vê um diagrama da malha atual, com tráfego roteado para os serviços em execução no Compute Engine e no GKE.

   Cada instância de um microsserviço tem um rótulo para explicar a revisão.

   • As instâncias em execução no Compute Engine têm um rótulo de compute-engine.
   • As instâncias em execução no GKE têm uma string extra, por exemplo, v1 ou v3.

   As instâncias em execução no Compute Engine se conectam diretamente às outras instâncias do Compute Engine sem passar pela malha de serviço. Portanto, você não vê o tráfego que passa das instâncias em execução no Compute Engine para outras instâncias.

   Se o diagrama a seguir não aparecer no painel do Kiali, atualize a página.

   

   O diagrama no painel do Kiali mostra o tráfego roteado para serviços em execução no Compute Engine e para serviços em execução no GKE.

4. No Cloud Shell, para interromper o comando de geração de tráfego, pressione Control+C.

Rotear o tráfego apenas para o cluster do GKE

Nesta seção, você encaminha o tráfego para as instâncias de serviço de carga de trabalho que estão em execução apenas no cluster do GKE. Para cada serviço da carga de trabalho de exemplo, exclua a referência WorkloadEntry que aponta para o serviço em execução no Compute Engine. A exclusão faz com que o serviço selecione apenas as instâncias de microsserviço em execução no cluster do GKE, e o tráfego será roteado somente para o cluster do GKE. O diagrama a seguir mostra a arquitetura do sistema para esta seção:

1. No Cloud Shell, altere o diretório de trabalho para o diretório do repositório:

   cd "${DEPLOYMENT_DIRECTORY_PATH}"
   

2. Exponha as cargas de trabalho somente no ambiente de destino:

   scripts/workloads.sh \
   --default-project "${DEFAULT_PROJECT}" \
   --default-region "${DEFAULT_REGION}" \
   --default-zone "${DEFAULT_ZONE}" \
   --expose-with "GKE_ONLY"
   

   O script workloads.sh exclui as referências WorkloadEntry que apontam para as instâncias de microsserviço em execução no Compute Engine a partir do cluster do GKE.

   Você vê uma confirmação da implantação e como acessá-la. A resposta será semelhante a:

   You can access the workload by loading http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/productpage
   

A entrada de serviço usa workloadSelector para selecionar automaticamente a carga de trabalho de exemplo em execução no cluster do GKE.

Testar a carga de trabalho em execução no GKE

• Abra um navegador e acesse o seguinte URL, em que ISTIO_INGRESS_GATEWAY_EXTERNAL_IP é o endereço IP da etapa anterior:

  http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/productpage
  

  Uma página Bookinfo é exibida com informações sobre livros e classificações relevantes.

Visualizar a malha de serviço

Nesta seção, você usa o Kiali para ver uma representação visual da malha de serviço.

1. Abra um navegador e acesse o seguinte URL, em que ISTIO_INGRESS_GATEWAY_EXTERNAL_IP é o endereço IP da etapa anterior:

   http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/kiali/console/graph/namespaces/?edges=requestDistribution&graphType=versionedApp&namespaces=default%2Cistio-system&idleNodes=false&duration=60&refresh=15000&operationNodes=false&idleEdges=false&injectServiceNodes=true&layout=dagre
   

2. No Cloud Shell, execute uma solicitação várias vezes para a página principal da carga de trabalho de exemplo:

   ISTIO_INGRESS_GATEWAY_EXTERNAL_IP="$(kubectl get svc istio-ingressgateway -n istio-system -o jsonpath='{.status.loadBalancer.ingress[0].ip}')"
   for i in {1..10000}; do curl -s -o /dev/null -w "$(date --iso-8601=ns) - %{http_code}\n"  http://"${ISTIO_INGRESS_GATEWAY_EXTERNAL_IP}"/productpage; done
   

   Esse comando gera tráfego para o app Bookinfo. A saída esperada é uma lista da datas das solicitações HTTP para o serviço productpage e o código de retorno HTTP de cada solicitação (neste caso, 200 OK). A resposta será parecida com esta:

   2021-06-09T10:16:15,355323181+00:00 - 200
   2021-06-09T10:16:15,355323182+00:00 - 200
   2021-06-09T10:16:15,355323183+00:00 - 200
   [...]
   

3. O painel de serviços do Kiali mostra um diagrama da malha atual com o tráfego roteado para serviços em execução no GKE. Você implantou duas instâncias de cada microsserviço: uma executada na instância do Compute Engine e outra no cluster do GKE. No entanto, como você removeu as referências de WorkloadEntry que apontam para as instâncias de microsserviço executadas no Compute Engine, os serviços selecionam apenas as instâncias de microsserviço em execução no cluster do GKE.

   Se o diagrama a seguir não aparecer no painel do Kiali, atualize a página.

   

   O diagrama no painel do Kiali mostra o tráfego roteado para serviços em execução no GKE.

4. No Cloud Shell, para interromper o comando de geração de tráfego, pressione Control+C.

Desativar o ambiente de origem

Como todo o tráfego agora está roteado para o cluster do GKE, é possível interromper as instâncias da carga de trabalho em execução no Compute Engine.

Durante uma migração de produção, mantenha o data center de origem pronto para sua estratégia de reversão. Recomendamos que você comece a desativar o data center de origem somente quando tiver certeza de que a nova solução está funcionando conforme o esperado e que todos os mecanismos de backup e tolerância a falhas estejam em vigor.

O diagrama a seguir mostra a arquitetura do sistema para esta seção:

No diagrama, o Istio encaminha o tráfego para serviços em execução apenas no GKE, e as cargas de trabalho em execução no Compute Engine são desativadas.

Para desativar o ambiente de origem, faça o seguinte:

1. No Cloud Shell, altere o diretório de trabalho para o diretório do repositório:

   cd "${DEPLOYMENT_DIRECTORY_PATH}"
   

2. Exponha as cargas de trabalho somente no ambiente de destino:

   scripts/workloads.sh \
   --default-project "${DEFAULT_PROJECT}" \
   --default-region "${DEFAULT_REGION}" \
   --default-zone "${DEFAULT_ZONE}" \
   --deploy-with "GKE_ONLY"
   

   O script workloads.sh interrompe os contêineres em execução nas instâncias do Compute Engine.

Limpar

Para evitar cobranças na sua conta do Google Cloud pelos recursos usados na implantação, exclua o projeto ou mantenha o projeto e exclua cada um dos recursos.

Excluir o projeto

Cuidado: excluir um projeto tem os seguintes efeitos:

• Tudo no projeto é excluído. Se você tiver usado um projeto existente para as tarefas neste documento, a exclusão dele incluirá a exclusão de quaisquer outros trabalhos feitos no projeto.
• Os IDs do projeto personalizados são perdidos. Ao criar o projeto, você pode ter criado um código do projeto personalizado para ser usado no futuro. Para preservar os URLs que usam o ID do projeto, como um URL appspot.com, exclua recursos específicos do projeto, em vez de excluir o projeto inteiro.

Se você planeja passar por várias arquiteturas, tutoriais ou guias de início rápido, a reutilização de projetos pode evitar que você exceda os limites da cota do projeto.

1. No Console do Google Cloud, acesse a página Gerenciar recursos.

   Acessar "Gerenciar recursos"

2. Na lista de projetos, selecione o projeto que você quer excluir e clique em Excluir .
3. Na caixa de diálogo, digite o ID do projeto e clique em Encerrar para excluí-lo.

Excluir recursos individuais

1. No Cloud Shell, altere o diretório de trabalho para o diretório do repositório:

   cd "${DEPLOYMENT_DIRECTORY_PATH}"/terraform
   

2. Exclua os recursos que você provisionou:

   terraform destroy -auto-approve
   

A seguir

• Leia sobre o GKE.
• Leia sobre o Istio.
• Para mais arquiteturas de referência, diagramas e práticas recomendadas, confira a Central de arquitetura do Cloud.