Definir configurações avançadas

Este documento contém observações que podem ser úteis ao configurar o Cloud Service Mesh.

Observação: este guia é compatível apenas com o Cloud Service Mesh com APIs do Google Cloud e não com as APIs do Istio. Para mais informações, consulte Visão geral do Cloud Service Mesh.

Como configurar uma única VM do Compute Engine para o Cloud Service Mesh

Use este procedimento como um exemplo de como a implantação do proxy secundário e a interceptação de tráfego podem ser implementadas para fornecer a uma VM acesso aos serviços do Cloud Service Mesh.

Para usar este procedimento, você precisa ter o Docker instalado. Siga as instruções do Docker para instalar o Docker Engine.

Se você estiver seguindo este processo para configurar o Cloud Service Mesh em uma única VM, algumas tarefas de configuração exigirão que você tenha acesso a um host do Linux. O host pode ser uma máquina local ou uma VM em execução na rede de nuvem particular virtual.

Primeiro, faça o download e prepare os arquivos de configuração e os scripts de amostra.

1. Faça login no host do Linux que você está usando durante o processo de configuração.

2. Faça o download dos arquivos necessários para o host do Linux e descompacte-os:

   wget https://storage.googleapis.com/traffic-director/traffic-director-xdsv3.tar.gz
   tar -xzvf traffic-director-xdsv3.tar.gz; cd traffic-director-xdsv3
   

   Estão incluídos os seguintes arquivos:

   • sidecar.env: arquivo de configuração com variáveis de ambiente
   • iptables.sh: script para configurar as regras do netfilter
   • bootstrap_template.yaml: arquivo modelo de inicialização do Envoy
   • run.sh: script de nível superior que usa o arquivo de configuração sidecar.env para configurar iptables para interceptação e para executar o proxy sidecar do Envoy.

3. Em cada host que executa um sidecar proxy, crie um usuário do sistema para executar o processo do proxy Envoy. Esse é o usuário do proxy Envoy. O login está desativado para o usuário do proxy Envoy.

   sudo adduser --system --disabled-login envoy
   

4. Edite o arquivo sidecar.env para modificar a configuração. Leia os comentários in-line no arquivo de configuração para ver uma descrição detalhada de cada variável.

   1. No arquivo sidecar.env, defina a variável ENVOY_USER como o nome de usuário escolhido para ser o usuário do proxy Envoy.

Em seguida, para cada host de VM que executa aplicativos usando o Cloud Service Mesh, siga estas etapas:

1. Copie todo o diretório traffic-director-xdsv3 com o arquivo sidecar.env modificado para cada host de VM que executa os aplicativos em que você espera usar o Cloud Service Mesh.
2. Adicione o script run.sh ao script de inicialização do sistema, garantindo que ele seja executado após cada reinicialização da VM.

3. Em cada host de VM, execute o script run.sh:

   cd traffic-director-xdsv3
   sudo ./run.sh start
   

4. Verifique se o proxy Envoy foi iniciado corretamente.

   sudo ./run.sh status
   

   Você verá a resposta a seguir:

   OK: Envoy seems to be running.
   OK: Traffic interception seems to be enabled.
   

   É possível verificar a direção da interceptação de tráfego usando o seguinte comando:

   sudo iptables -S -t nat | grep ISTIO_REDIRECT
   

   A saída esperada é:

   -N ISTIO_REDIRECT
   -A ISTIO_OUTPUT -j ISTIO_REDIRECT
   -A ISTIO_REDIRECT -p tcp -j REDIRECT --to-ports 15001`
   

Observação: com essa configuração, todo o tráfego TCP, exceto o tráfego na porta tcp/22, é interceptado pelo proxy secundário. O tráfego para serviços TCP que não estão configurados no Cloud Service Mesh é descartado silenciosamente pelo proxy. Para evitar a perda de tráfego, siga a seção Configuração avançada de interceptação de tráfego abaixo.

Mapas de regras de roteamento

Há duas maneiras de configurar o roteamento em um mapa de regras.

É possível ativar o roteamento com base no VIP real do destino e na porta do serviço. Se você configurar um VIP do serviço como o parâmetro IPAddress da regra de encaminhamento, apenas o tráfego destinado a esse endereço e a porta associada serão correspondidos e roteados com base nos parâmetros de host e de caminho especificados no mapa de URLs.

Como alternativa, defina o endereço da regra de encaminhamento como 0.0.0.0. Isso configurará os proxies para corresponder apenas ao tráfego com base na porta de destino, independentemente do endereço IP de destino da solicitação. O tráfego é roteado com base nos parâmetros de host e de caminho especificados no mapa de URL.

Com base nessas duas abordagens e conforme configurados nas regras de host, os nomes do host associados a um par VIP de destino e porta ou com uma porta de destino (quando VIP for 0.0.0.0), precisam ser exclusivos nas configuração da malha de serviço. Ou seja, não é possível ter dois serviços diferentes, com diferentes conjuntos de back-ends, que usam o mesmo nome de host.

Independentemente do método selecionado, o tráfego ao VIP que o FQDN/nome do host do serviço resolve e a porta que o serviço está detectando precisam ser interceptados e redirecionados para o proxy secundário. Consulte Como configurar uma única VM do Compute Engine para o Cloud Service Mesh para ver todos os detalhes da configuração do host.

Cada regra de encaminhamento em uma rede VPC precisa ter uma combinação exclusiva de endereço IP e porta por rede VPC, incluindo o endereço 0.0.0.0. Se você criar mais de uma regra de encaminhamento com o mesmo endereço IP e a mesma porta em uma determinada rede VPC, somente a primeira regra de encaminhamento será válida. As outras serão ignoradas.

Para evitar a perda de tráfego, siga a seção Configuração avançada de interceptação de tráfego abaixo.

Configuração avançada de interceptação de tráfego

Se as VMs executarem aplicativos que precisam de acesso a serviços configurados pelo Cloud Service Mesh, instale um proxy secundário e configure a interceptação de tráfego nas VMs para permitir que o proxy secundário gerencie o roteamento de tráfego para os back-ends desses serviços.

Observação: se as VMs do grupo gerenciado de instâncias servirem apenas como back-end e os aplicativos não precisarem de acesso aos serviços do Cloud Service Mesh, será possível pular esta seção.

Se a interceptação de todo o tráfego de VM de saída não for aceitável para a implantação, redirecione o tráfego específico para o proxy sidecar, enquanto o restante do tráfego seguirá a rota regular definida pela configuração de rede do host.

Para isso, modifique a configuração do host da VM do Compute Engine no procedimento Configuração do Cloud Service Mesh com VMs e implantação manual do Envoy da seguinte maneira:

1. Decida o intervalo de endereços IP que os serviços controlados pelo Cloud Service Mesh vão resolver. O tráfego destinado a esses endereços IP é interceptado e redirecionado ao proxy secundário. O intervalo é específico da implantação que você está usando.

2. No arquivo sidecar.env, defina o valor de SERVICE_CIDR como esse intervalo. O tráfego para esses endereços IP é redirecionado pelo netfilter para um proxy secundário e com a carga balanceada de acordo com a configuração fornecida pelo Cloud Service Mesh.

3. O proxy secundário não é estritamente necessário para ser executado como um usuário dedicado que é excluído da interceptação de tráfego. No entanto, isso ainda é recomendado.

4. Depois de executar o script run.sh, conforme explicado no procedimento principal, iptables será configurado para a interceptação e o redirecionamento desse intervalo específico.

5. Execute o comando a seguir para verificar se o netfilter está configurado corretamente. Para ${SERVICE_CIDR}, substitua o valor que você configurou como o intervalo de endereços IP interceptado.

   sudo iptables -L -t nat | grep -E "(ISTIO_REDIRECT).+${SERVICE_CIDR})"