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

Esta página foi traduzida pela API Cloud Translation.

Configure configurações avançadas

Este documento contém notas que podem ser úteis ao configurar o Cloud Service Mesh.

Configurar uma única VM do Compute Engine para a Cloud Service Mesh

Use este procedimento como exemplo de como a implementação de proxy sidecar e a interceção de tráfego podem ser implementadas para fornecer a uma VM acesso aos serviços do Cloud Service Mesh.

Para usar este procedimento, tem de ter o Docker instalado. Siga as instruções da Docker para instalar o Docker Engine.

Se estiver a seguir este processo para configurar a malha de serviços na nuvem numa única VM, algumas tarefas de configuração requerem que tenha acesso a um anfitrião Linux. O anfitrião pode ser uma máquina local ou uma VM em execução na sua rede de nuvem privada virtual.

Primeiro, transfira e prepare os ficheiros de configuração e os scripts de exemplo.

Inicie sessão no anfitrião Linux que está a usar durante o processo de configuração.
Transfira o arquivo de ficheiros necessários para o anfitrião Linux e descompacte o arquivo:
```
wget https://storage.googleapis.com/traffic-director/traffic-director-xdsv3.tar.gz
tar -xzvf traffic-director-xdsv3.tar.gz; cd traffic-director-xdsv3
```
O arquivo contém os seguintes ficheiros:
- sidecar.env: ficheiro de configuração com variáveis de ambiente.
- iptables.sh: script para configurar regras de netfilter.
- bootstrap_template.yaml: ficheiro de modelo de arranque para o Envoy.
- run.sh: script de nível superior que usa o ficheiro de configuração sidecar.env para configurar o iptables para interceção e executar o proxy sidecar do Envoy.
Em cada anfitrião que execute um proxy sidecar, crie um utilizador do sistema para executar o processo do proxy Envoy. Este é o utilizador do proxy Envoy. O início de sessão está desativado para o utilizador do proxy Envoy.
```
sudo adduser --system --disabled-login envoy
```
Edite o ficheiro sidecar.env para modificar a configuração. Leia os comentários incorporados no ficheiro de configuração para ver uma descrição detalhada de cada variável.
1. No ficheiro sidecar.env, defina a variável ENVOY_USER para o nome de utilizador que escolher para ser o utilizador do proxy Envoy.

Em seguida, para cada anfitrião de VM que execute aplicações através da Cloud Service Mesh, execute os seguintes passos:

Copie todo o diretório traffic-director-xdsv3 com o ficheiro sidecar.env modificado para cada anfitrião de VM que execute aplicações que espera usar a malha de serviços na nuvem.
Adicione o script run.sh ao script de arranque do sistema, o que garante que o script é executado após cada reinício da VM.
Em cada anfitrião 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

Deverá ver o seguinte resultado:

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

Pode validar a direção da interceção de tráfego através do seguinte:

sudo iptables -S -t nat | grep ISTIO_REDIRECT

O resultado esperado é:

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

Mapas de regras de encaminhamento

Existem duas formas de configurar o encaminhamento num mapa de regras de encaminhamento.

Pode ativar o encaminhamento com base no VIP e na porta de destino reais do serviço. Se configurar um VIP do seu serviço como o parâmetro IPAddress da regra de encaminhamento, apenas o tráfego destinado a este endereço e à porta associada é correspondido e encaminhado com base nos parâmetros de anfitrião e caminho especificados no mapa de URLs.

Em alternativa, pode definir o endereço da sua regra de encaminhamento como 0.0.0.0. Isto configura os proxies para corresponderem apenas ao tráfego com base na porta de destino, independentemente do endereço IP de destino do pedido. Em seguida, o tráfego é encaminhado com base nos parâmetros de anfitrião e caminho especificados no mapa de URLs.

Com base nestas duas abordagens, os nomes de anfitrião, conforme configurados nas regras de anfitrião, associados a um par de portas e VIP de destino, ou a uma porta de destino (quando o VIP é 0.0.0.0), têm de ser únicos na configuração da malha de serviço. Ou seja, não pode ter dois serviços diferentes, com diferentes conjuntos de back-ends, que usem o mesmo nome de anfitrião.

Independentemente do método selecionado, o tráfego para o VIP para o qual o nome do anfitrião/FQDN do seu serviço é resolvido e a porta na qual o seu serviço está a escutar tem de ser intercetado e redirecionado para o proxy sidecar. Consulte o artigo Configurar uma única VM do Compute Engine para o Cloud Service Mesh para ver detalhes completos da configuração do anfitrião.

Cada regra de encaminhamento numa rede VPC tem de ter uma combinação única de endereço IP e porta por rede VPC, incluindo o endereço 0.0.0.0. Se criar mais do que uma regra de encaminhamento com o mesmo endereço IP e porta numa determinada rede da VPC, apenas a primeira regra de encaminhamento é válida. Os outros são ignorados.

Para evitar perder tráfego, siga a secção Configuração avançada da interceção de tráfego abaixo.

Configuração avançada da interceção de tráfego

Se as suas VMs executarem aplicações que precisam de acesso a serviços configurados pela Cloud Service Mesh, tem de instalar um proxy sidecar e configurar a interceção de tráfego nas VMs para permitir que o proxy sidecar faça a gestão do encaminhamento de tráfego para os back-ends desses serviços.

Se a interceção de todo o tráfego de VMs de saída não for aceitável para a sua implementação, pode redirecionar tráfego específico para o proxy sidecar, enquanto o resto do tráfego segue a rota normal definida pela configuração de rede do anfitrião.

Para o conseguir, modifique a configuração do anfitrião da VM do Compute Engine no procedimento de configuração da Cloud Service Mesh com VMs e implementação manual do Envoy da seguinte forma:

Decida o intervalo de endereços IP para os quais os serviços controlados pela Cloud Service Mesh devem ser resolvidos. O tráfego destinado a estes endereços IP é intercetado e redirecionado para o proxy sidecar. O intervalo é específico da sua implementação.
No ficheiro sidecar.env, defina o valor de SERVICE_CIDR para este intervalo. O tráfego para estes endereços IP é redirecionado pelo netfilter para um proxy sidecar e o balanceamento de carga é feito de acordo com a configuração fornecida pelo Cloud Service Mesh.
O proxy sidecar não é estritamente necessário para ser executado como um utilizador dedicado que está excluído da interceção de tráfego. No entanto, esta opção continua a ser recomendada.
Depois de executar o script run.sh, conforme indicado no procedimento principal, o iptables é configurado apenas para a interceção e o redirecionamento deste intervalo específico.
Execute o seguinte comando para verificar se o netfilter está configurado corretamente. Para ${SERVICE_CIDR}, substitua o valor que configurou como o intervalo de endereços IP intercetados.
```
sudo iptables -L -t nat | grep -E "(ISTIO_REDIRECT).+${SERVICE_CIDR})"
```