Traffic Director com grupos de endpoints de rede da Internet

É possível configurar o Traffic Director para usar grupos de endpoints de rede (NEGs) da Internet do tipo INTERNET_FQDN_PORT. O serviço externo é representado pelo nome de domínio totalmente qualificado (FQDN, na sigla em inglês) e pelo número da porta no NEG. O NEG pode conter apenas um par de FQDN:Port, e o serviço de back-end pode conter apenas um NEG desse tipo. O FQDN é resolvido usando a ordem de resolução de nomes da rede de nuvem privada virtual (VPC) subjacente.

Expandir a malha de serviço do Traffic Director usando back-ends de FQDN

A malha de serviço do Traffic Director pode rotear o tráfego para serviços particulares acessíveis por conectividade híbrida, incluindo serviços nomeados no local, de várias nuvens e da Internet. O serviço remoto é referenciado pelo FQDN.

Como estender a malha de serviço do Traffic Director para ambientes no local ou de várias nuvens usando back-ends de FQDN pela conectividade híbrida
Como estender a malha de serviço do Traffic Director para ambientes no local ou de várias nuvens usando back-ends de FQDN pela conectividade híbrida (clique para ampliar)

Também é possível rotear o tráfego para serviços acessíveis pela Internet pública.

Como estender a malha de serviço do Traffic Director a um serviço da Internet usando back-ends de FQDN.
Como estender a malha de serviço do Traffic Director a um serviço da Internet usando back-ends de FQDN (clique para ampliar)

Recursos e arquitetura do Google Cloud

Nesta seção, descrevemos os recursos e a arquitetura para configurar o Traffic Director com um NEG na Internet.

Grupo de endpoints de rede INTERNET_FQDN_PORT

Para rotear o tráfego para um serviço externo referenciado pelo FQDN, use o NEG global da Internet do tipo INTERNET_FQDN_PORT. O NEG contém o FQDN do serviço e o número da porta. O Traffic Director programa o FQDN em proxies do Envoy usando a configuração xDS.

O Traffic Director não garante a resolução de nomes e a acessibilidade dos endpoints remotos. O FQDN precisa ser resolvido pela ordem de resolução de nomes da rede VPC em que os proxies do Envoy estão anexados, e os endpoints resolvidos precisam ser acessíveis pelos proxies do Envoy.

Verificações de integridade

O comportamento da verificação de integridade para endpoints de rede do tipo INTERNET_FQDN_PORT é diferente do comportamento da verificação de integridade para outros tipos de endpoints de rede usados com o Cloud Load Balancing e o Traffic Director. Embora a maioria dos outros tipos de endpoint de rede use o sistema de verificação de integridade centralizado do Google Cloud, os NEGs usados para endpoints em ambientes com várias nuvens (INTERNET_FQDN_PORT e NON_GCP_PRIVATE_IP_PORT) usam o mecanismo de verificação de integridade distribuído do Envoy.

O Envoy é compatível com os seguintes protocolos para verificação de integridade:

  • HTTP
  • HTTPS
  • HTTP/2
  • TCP

Configure as verificações de integridade usando as APIs do Compute Engine.

Considerações sobre DNS

Há duas considerações distintas sobre o DNS:

  • O servidor DNS que hospeda os registros de recurso do serviço externo.
  • O modo com que o proxy Envoy está configurado para usar o DNS para o gerenciamento de conexões.

Servidor do Cloud DNS

É possível criar uma zona particular gerenciada do Cloud DNS para hospedar os registros DNS no projeto do Google Cloud. Também é possível usar outros recursos do Cloud DNS, como as zonas de encaminhamento, para buscar registros de um servidor DNS local.

Modo DNS do Envoy

O modo DNS do Envoy, também conhecido como descoberta de serviços, especifica como o proxy Envoy usa registros DNS para gerenciar conexões de saída. O Traffic Director configura o Envoy para usar o modo DNS restrito. O modo DNS restrito permite o balanceamento de carga para todos os endpoints resolvidos. Ele respeita o status de verificação de integridade e drena conexões com endpoints que não são íntegros ou não são mais resolvidos com DNS. Não é possível mudar esse modo.

Para mais informações sobre a descoberta de serviços, consulte a documentação do Envoy.

Conectividade e roteamento

Se você estiver roteando o tráfego para um serviço particular, estes são os requisitos para a conectividade de rede subjacente:

  • Conectividade híbrida entre a rede VPC e o data center no local ou a nuvem pública de terceiros estabelecida usando o Cloud VPN ou o Cloud Interconnect.
  • Regras e as rotas de firewall da VPC configuradas corretamente para estabelecer a acessibilidade bidirecional do Envoy aos endpoints do serviço particular e, se aplicável, ao servidor DNS no local.
  • Para um failover de alta disponibilidade regional bem-sucedido, o roteamento dinâmico global precisa estar ativado. Para saber mais, consulte modo de roteamento dinâmico.

Se você estiver roteando o tráfego para um serviço externo que pode ser acessado na Internet, é necessário atender aos requisitos a seguir:

  • As instâncias de máquina virtual (VM, na sigla em inglês) do cliente na rede VPC precisam ter um endereço IP externo ou o Cloud NAT.
  • A rota padrão precisa estar presente para o tráfego de saída para a Internet.

Nos dois casos anteriores, o tráfego usa o roteamento da rede VPC.

Segurança

Os back-ends FQDN são compatíveis com APIs e recursos de segurança do Traffic Director. Nas conexões de saída ao serviço externo, é possível configurar o FQDN no cabeçalho SNI usando políticas TLS do cliente.

Limitações e considerações

  • Os NEGs da Internet do tipo INTERNET_IP_PORT não são compatíveis com o Traffic Director.
  • O Envoy versão 1.15.0 ou superior é necessário com back-ends FQDN.
  • Use a CLI do Google Cloud ou as APIs REST para configurar o Traffic Director. A configuração completa usando o Console do Google Cloud não é aceita.
  • Os back-ends FQDN são compatíveis apenas com o Envoy. O gRPC sem proxy não é aceito.

  • Ao usar o tipo de NEG INTERNET_FQDN_PORT com o Traffic Director, as verificações de integridade dos endpoints remotos são feitas usando o mecanismo de verificação de integridade distribuída do Envoy. Sempre que um novo endpoint remoto é adicionado, todos os proxies Envoy iniciam a verificação de integridade de maneira independente.

    Da mesma forma, quando um novo proxy Envoy é adicionado à malha, ele começa a verificar todos os endpoints remotos. Portanto, dependendo do número de proxies Envoy e endpoints remotos na implantação, a malha de verificação de integridade resultante pode gerar muito tráfego de rede e uma carga indevida nos endpoints remotos. É possível optar por não configurar as verificações de integridade.

  • O status da verificação de integridade não é visível no Console do Google Cloud para back-ends de FQDN.

  • A verificação de integridade que usa os protocolos UDP, SSL e gRPC não é aceita.

  • As seguintes opções de verificação de integridade não são aceitas:

    • Verificação de integridade HTTP/HTTP2/HTTPS
      • --proxy-header
      • --response
    • Verificação de integridade do TCP
      • --proxy-header
      • --request
      • --response

A seguir