O Anthos Service Mesh e o Traffic Director agora são Cloud Service Mesh. Para mais informações, consulte a Visão geral do Cloud Service Mesh.

Esta página foi traduzida pela API Cloud Translation.

Definir configurações avançadas

Este documento contém observações que podem ser úteis ao configurar o 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 sidecar e a interceptação de tráfego podem ser implementadas para fornecer uma VM com 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 esse processo para configurar o Cloud Service Mesh em uma única VM, algumas tarefas de configuração vão exigir 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.

Faça login no host do Linux que você está usando durante o processo de configuração.
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.
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
```
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, execute as seguintes etapas:

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

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

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

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`

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 Cloud Service Mesh para detalhes completos de 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 executam aplicativos que precisam de acesso a serviços configurados pela Cloud Service Mesh, você precisa instalar um proxy sidecar e configurar o tráfego nas VMs para permitir que o proxy sidecar gerencie o roteamento de tráfego para os back-ends desses serviços.

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 fazer 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:

Escolha o intervalo de endereços IP controlado pelo Cloud Service Mesh que os serviços devem 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.
No arquivo sidecar.env, defina o valor de SERVICE_CIDR como esse intervalo. O tráfego para esses endereços IP é redirecionado pelo netfilter a um proxy secundário com carga balanceada de acordo com a configuração fornecida pela do Cloud Service Mesh.
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.
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.
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})"
```