Descoberta de serviços do Traffic Director

O Traffic Director oferece descoberta de serviço e de endpoint. Isso permite agrupar as VMs e os contêineres 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. Portanto, quando um dos aplicativos enviar uma solicitação usando um cliente do Traffic Director, como um proxy sidecar do Envoy, ele terá acesso a 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 está recebendo essas solicitações. Um cliente do Traffic Director é um Envoy ou um 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.

Service Discovery

O Traffic Director fornece descoberta de serviços. Ao configurar o Traffic Director, você cria serviços (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. Portanto, quando um cliente do Traffic Director processa uma solicitação que corresponde a uma regra, ele pode 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 tem dois back-ends de NEG 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, IP 0.0.0.0 e porta 80), um proxy de destino e um mapa de URL (com o nome de host payments.example.com de exemplo que aponta ao serviço payments).

Com essa configuração, quando seu aplicativo (na VM) enviar uma solicitação HTTP para payments.example.com na porta 80, o cliente do Traffic Director sabe que esta é uma 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. Mas 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 particular virtual 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. Eles podem ser VMs em grupos de instâncias gerenciadas (MIGs, na sigla em inglês) ou, em geral, contêineres em grupos de endpoint de rede (NEGs, na sigla em inglês). 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. Assim, os clientes evitam enviar tráfego para endpoints que não existem mais. Ele também permite que os clientes aprendam sobre novos endpoints e comecem a aproveitar a capacidade extra fornecida por esses endpoints.

No exemplo acima, o Traffic Director retorna os dois endpoints íntegros no MIG-1 e os três endpoints íntegros no MIG-2 do 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.

Como funciona a interceptação de tráfego de 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, o tráfego é interceptado pelo iptables e redirecionado 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, denominado Web, está configurado no VIP 10.0.0.1:80, onde ele pode ser descoberto e ter a carga balanceada pelo Traffic Director. O Traffic Director descobre a configuração por meio da 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 (clique para ampliar)
Rede do host do Traffic Director (clique para ampliar)

O fluxo de tráfego no diagrama é este:

  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 executa uma pesquisa para o destino original da solicitação (10.0.0.1:80). A pesquisa resulta em 192.168.0.1:8080 como 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.