Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Descoberta de serviços

O Traffic Director oferece descoberta de serviço e de endpoint. Esses recursos permitem agrupar as instâncias de máquina virtual (VM) e as instâncias de contêiner que executam o código como endpoints dos serviços.

O Traffic Director monitora esses serviços para compartilhar informações atualizadas com os clientes dele. Portanto, quando um dos aplicativos usa o cliente Traffic Director (como um proxy sidecar Envoy) para enviar uma solicitação, ele se beneficia de informações atualizadas sobre os serviços.

No contexto do Traffic Director, um cliente é o código do aplicativo em execução em uma VM ou em um contêiner que formula as solicitações a serem enviadas a um servidor. Um servidor é um código de aplicativo que recebe essas solicitações. Um cliente do Traffic Director é um Envoy, gRPC ou outro cliente xDS conectado ao Traffic Director e que faz parte do plano de dados.

No plano de dados, o Envoy ou o gRPC faz o seguinte:

  1. Ele examina uma solicitação e corresponde a solicitação a um serviço de back-end, um recurso que você configura durante a implantação.
  2. Depois que a solicitação é correspondida, o Envoy ou o gRPC escolhe um back-end ou um endpoint e direciona a solicitação a esse back-end ou endpoint.

Descoberta de serviços

O Traffic Director fornece descoberta de serviços. Ao configurar o Traffic Director, você cria serviços de back-end. Você também define regras de roteamento que especificam como uma solicitação de saída (uma solicitação enviada pelo código do aplicativo e processada por um cliente do Traffic Director) é correspondida a um serviço específico. Quando um cliente do Traffic Director processa uma solicitação que corresponde a uma regra, ele consegue escolher o serviço que receberá a solicitação.

Exemplo:

  • Você tem uma VM executando o aplicativo. Essa VM tem um proxy sidecar do Envoy que está conectado ao Traffic Director e processa solicitações de saída em nome do aplicativo.
  • Você configurou um serviço de back-end denominado payments. Esse serviço de back-end tem dois back-ends de grupos de endpoints de rede (NEG, na sigla em inglês) que apontam para várias instâncias de contêiner que executam o código do serviço payments.
  • Você configurou um mapa de regras de roteamento que tem uma regra de encaminhamento (por exemplo, endereço IP 0.0.0.0 e porta 80), um proxy de destino e um mapa de URL (com o nome de host de exemplo payments.example.com que aponta ao serviço payments).

Com essa configuração, quando o aplicativo (na VM) enviar uma solicitação HTTP para payments.example.com na porta 80, o cliente do Traffic Director sabe que essa solicitação é destinada ao serviço payments.

Quando você usa o Traffic Director com serviços do gRPC sem proxy, a descoberta de serviços funciona de maneira semelhante. Entretanto, a biblioteca do gRPC, atuando como um cliente do Traffic Director, recebe apenas informações sobre os serviços para os quais você especificou um resolvedor xDS. Por padrão, o Envoy recebe informações sobre todos os serviços configurados na rede da nuvem privada virtual (VPC) especificada no arquivo de inicialização do Envoy.

Descoberta de endpoints

Com a descoberta de serviços, os clientes conhecem os serviços que você fornece. A descoberta de endpoints permite que os clientes conheçam as instâncias que executam o código.

Ao criar um serviço, você também especifica os back-ends dele. Esses back-ends são VMs em grupos gerenciados de instâncias (MIGs, na sigla em inglês) ou contêineres em NEGs. O Traffic Director monitora esses MIGs e NEGs para saber quando instâncias e endpoints são criados e removidos.

O Traffic Director compartilha continuamente informações atualizadas sobre esses serviços com os clientes. Essa informação evita que os clientes enviem tráfego para endpoints que não existem mais. Com ela, os clientes também podem aprender sobre novos endpoints e aproveitar a capacidade extra fornecida por esses endpoints.

No exemplo anterior, o Traffic Director retorna os dois endpoints íntegros no MIG-1 e os três endpoints íntegros no MIG-2 para o serviço shopping-cart. Além de adicionar endpoints em MIGs ou NEGs e configurar o Traffic Director, você não precisa de outras configurações para ativar a descoberta de serviços com o Traffic Director.

Interceptação de tráfego do proxy sidecar no Traffic Director

O Traffic Director usa o modelo de proxy sidecar. Nesse modelo, quando um aplicativo envia tráfego para o destino dele, iptables intercepta o tráfego e o redireciona para o proxy sidecar no host em que o aplicativo está em execução. O proxy sidecar decide como balancear a carga do tráfego e, em seguida, envia o tráfego para o destino.

No diagrama a seguir, que pressupõe que o Traffic Director esteja configurado corretamente, o Envoy é o proxy sidecar. O proxy sidecar está sendo executado no mesmo host que o aplicativo.

Um serviço de amostra chamado Web é configurado no endereço IP virtual (VIP, na sigla em inglês) 10.0.0.1:80 em que o Traffic Director pode descobrir e balancear a carga. O Traffic Director descobre a configuração da regra de encaminhamento, que fornece o VIP e a porta. Os back-ends do serviço Web estão configurados e funcionam, mas estão localizados fora do host da VM do Compute Engine no diagrama.

O Traffic Director decide que o back-end ideal para o tráfego ao serviço Web do host é 192.168.0.1:80.

Rede do host do Traffic Director.
Rede do host do Traffic Director (clique para ampliar)

O fluxo de tráfego no diagrama é o seguinte:

  1. O aplicativo envia o tráfego para o serviço Web, que é resolvido para o endereço IP 10.0.0.1:80.
  2. O netfilter no host está configurado para que o tráfego destinado a 10.0.0.1:80 seja redirecionado para 10.0.0.1:15001.
  3. O tráfego é redirecionado para 127.0.0.1:15001, a porta de interceptação do proxy Envoy.
  4. O listener de interceptação do proxy Envoy em 127.0.0.1:15001 recebe o tráfego e pesquisa pelo destino original da solicitação (10.0.0.1:80). A pesquisa resulta que 192.168.0.1:8080 é um back-end ideal, conforme programado pelo Traffic Director.
  5. O Envoy estabelece uma conexão pela rede com tráfego HTTP de proxies e 192.168.0.1:8080 entre o aplicativo e esse back-end até que a conexão seja encerrada.

Opções de interceptação de tráfego com implantação automática do Envoy

Se você usou a implantação automática do Envoy com VMs, o Traffic Director tem outras opções de interceptação de tráfego. Faça o seguinte com estas opções:

  • Interceptar todo o tráfego
  • Excluir portas, intervalos de portas, endereços IP ou intervalos CIDR específicos

Se você estiver usando os novos recursos Mesh e Gateway da API de roteamento de serviço, todo o tráfego será interceptado automaticamente.

Para mais informações, consulte Opções de configuração da VM do Compute Engine com implantação automática do Envoy.

A seguir