Visão geral do Traffic Director com serviços gRPC sem proxy

Neste guia, fornecemos uma visão geral da arquitetura do Traffic Director com serviços do gRPC sem proxy, incluindo casos de uso e padrões de arquitetura. O guia abrange as APIs mais antigas do Traffic Director. Para ver informações sobre as APIs de roteamento de serviço, consulte a visão geral.

O plano de controle gerenciado do Traffic Director permite roteamento global, balanceamento de carga e failover regional para casos de uso de malha de serviço e balanceamento de carga. Isso inclui implantações que incorporam proxies sidecar e proxies de gateway. O suporte do Traffic Director para aplicativos gRPC sem proxy oferece um modelo de implantação adicional em que os aplicativos do gRPC podem participar de uma malha de serviço sem precisar de um proxy secundário.

Em um exemplo típico, um cliente gRPC estabelece uma conexão com um servidor gRPC que hospeda sua lógica de back-end. O Traffic Director fornece aos seus clientes do gRPC informações sobre quais servidores devem ser contatados, como carregar solicitações de balanceamento para várias instâncias de um servidor e o que fazer com as solicitações se um servidor não estiver em execução.

Para uma visão geral completa de como funciona o Traffic Director, consulte a visão geral do Traffic Director.

Como o Traffic Director funciona com aplicativos gRPC

O Traffic Director configura os clientes do gRPC com uma versão do gRPC compatível, da mesma forma que os proxies secundários, como o Envoy, estão configurados. No entanto, aplicativos gRPC sem proxy conectados diretamente ao Traffic Director não precisam de proxies de arquivo secundário. Em vez disso, o Traffic Director usa APIs xDS de código aberto para configurar aplicativos gRPC diretamente. Esses aplicativos gRPC atuam como clientes xDS, conectando-se ao plano de controle global do Traffic Director. Após a conexão, os aplicativos gRPC recebem configuração dinâmica do plano de controle, o que permite a descoberta de endpoints, o balanceamento de carga, o failover regional e as verificações de integridade. Essa abordagem permite outros padrões de implantação do Traffic Director.

Na primeira ilustração, a malha de serviço é ativada usando um proxy sidecar.

Malha de serviço ativada usando um proxy sidecar.
Uma malha de serviço ativada usando um proxy de arquivo secundário (clique para ampliar)

Para configurar um proxy sidecar, o Traffic Director usa as APIs xDS. Os clientes se comunicam com o servidor por meio do proxy sidecar.

Na segunda ilustração, a malha de serviço é ativada sem um proxy sidecar com o uso de um cliente gRPC sem proxy.

Malha de serviço ativada usando gRPC sem proxy.
Uma malha de serviço ativada usando gRPC sem proxy (clique para ampliar)

Se você estiver implantando apenas serviços gRPC configurados pelo Traffic Director, será possível criar a malha de serviço sem implantar proxies. Isso facilita a implantação de recursos de malha de serviço nos aplicativos gRPC.

Esquema de resolução de nome

Para implantações sem proxy, a resolução de nomes funciona das seguintes maneiras:

  1. Defina xds como o esquema de resolução de nomes no canal do cliente gRPC ao se conectar a um serviço. O URI de destino é formatado como xds:///hostname:port. Quando a porta não é especificada, o valor padrão é 80, por exemplo, no URI de destino xds:///example.hostname.
  2. O cliente gRPC resolve o hostname:port no URI de destino enviando uma solicitação de serviço de descoberta de listener (LDS, na sigla em inglês) para o Traffic Director.
  3. O Traffic Director pesquisa as regras de encaminhamento configuradas que têm uma porta correspondente. Em seguida, ele procura o mapa de URL correspondente para uma regra de host que corresponda a hostname:port. Ele retorna a configuração de roteamento associada ao cliente gRPC.

As regras de host que você configura no Traffic Director precisam ser exclusivas em todos os mapas de URLs. Por exemplo, example.hostname, example.hostname:80 e example.hostname:8080 são regras diferentes.

Resolução de nome com diferentes tipos de implantação

O esquema de resolução de nomes é diferente para implantações sem proxy e para as que usam proxies Envoy.

O cliente gRPC usa o esquema de resolução de nome xds para se conectar a um serviço, permitindo que ele receba a configuração do serviço do Traffic Director. O cliente gRPC se comunica diretamente com o servidor gRPC.

É possível combinar padrões de implantação de proxy sidecar e sem proxy para aumentar a flexibilidade. Isso é muito útil quando sua organização e rede oferecem suporte a várias equipes com diferentes requisitos de recursos, necessidades operacionais e versões de gRPC.

Na ilustração a seguir, os clientes gRPC e sem proxy com um proxy de arquivo secundário se comunicam com um servidor gRPC. Os clientes gRPC com proxies sidecar usam o esquema de resolução de nomes dns.

Malha de serviços composta por clientes gRPC sem proxy e clientes gRPC com proxies sidecar.
Uma malha de serviço que consiste em clientes gRPC sem proxy e clientes gRPC com proxies sidecar (clique para ampliar)

Casos de uso

Os casos de uso a seguir ajudam você a entender quando usar o Traffic Director com aplicativos gRPC sem proxy. A implantação pode incluir aplicativos gRPC sem proxy, aplicativos gRPC com proxies sidecar ou um mix de ambos.

Eficiência de recursos em uma malha de serviço de grande escala

Se a malha de serviço incluir centenas ou milhares de clientes e back-ends, você poderá descobrir que o consumo total de recursos da execução de proxies de arquivo secundário começa a aumentar. Quando você usa aplicativos gRPC sem proxy, não é necessário introduzir proxies de arquivo secundário na implantação. Uma abordagem sem proxy pode resultar em ganhos de eficiência.

Aplicativos gRPC de alto desempenho

Em alguns casos de uso, cada milésimo de segundo de latência da solicitação e da resposta é importante. Nesse caso, é possível que a latência seja reduzida ao usar um aplicativo gRPC sem proxy, em vez de passar todas as solicitações por um proxy de arquivo secundário do lado do cliente e, possivelmente, um proxy de arquivo secundário do lado do servidor.

Malha de serviço para ambientes em que não é possível implantar proxies secundários

Em alguns ambientes, talvez não seja possível executar um proxy secundário como um processo adicional junto com o aplicativo cliente ou servidor. Talvez não seja possível configurar a pilha de rede de uma máquina para interceptar e redirecionar solicitações, por exemplo, usando iptables. Nesse caso, é possível usar o Traffic Director com aplicativos gRPC sem proxy para apresentar os recursos de malha de serviço aos aplicativos gRPC.

Malha de serviço heterogênea

Como os aplicativos gRPC sem proxy e o Envoy se comunicam com o Traffic Director, sua malha de serviço pode incluir os dois modelos de implantação. A inclusão de ambos os modelos permite que você satisfaça as necessidades operacionais, de desempenho e recursos, específicas de diferentes aplicativos e equipes de desenvolvimento.

Migrar de malha de serviço com proxies para malha sem proxies

Se você já tiver um aplicativo gRPC com um proxy sidecar configurado pelo Traffic Director, será possível mudar para um aplicativo gRPC sem proxy.

Quando um cliente gRPC é implantado com um proxy de arquivo secundário, ele usa o DNS para resolver o nome do host ao qual está se conectando. O proxy sidecar intercepta o tráfego para fornecer a funcionalidade da malha de serviço.

Para definir se um cliente gRPC usa a rota sem proxy ou a rota de proxy sidecar para se comunicar com um servidor gRPC, basta modificar o esquema de resolução de nome que ele usa. Os clientes sem proxy usam o esquema de resolução de nome xds, enquanto proxies secundários usam o esquema de resolução de nome dns. Alguns clientes do gRPC podem até mesmo usar a rota sem proxy ao se comunicar com um servidor gRPC, mas usam a rota de proxy sidecar ao se comunicar com outro servidor gRPC. Assim, é possível migrar gradualmente para uma implantação sem proxy.

Para migrar da malha de serviço com proxies para a malha sem proxies, crie um novo serviço do Traffic Director para uso do cliente gRPC sem proxy. É possível usar as mesmas APIs para configurar o Traffic Director para as versões atuais e novas.

Malha de serviço com um cliente gRPC que se comunica com diferentes serviços usando mecanismos sem proxy e baseados em proxy.
Malha de serviço com um cliente gRPC que se comunica com diferentes serviços usando mecanismos sem proxy e baseados em proxy (clique para ampliar)

Arquitetura e recursos

O modelo de dados de configuração para serviços do gRPC sem proxy estende o modelo de configuração do Traffic Director, com algumas adições e limitações descritas neste guia. Algumas dessas limitações são temporárias, porque o gRPC sem proxy ainda não é compatível com todos os recursos do Envoy e outros são inerentes ao uso de RPCs. Por exemplo, os redirecionamentos HTTP que usam gRPC não são compatíveis. Para entender melhor o modelo de configuração deste guia, recomendamos que você se familiarize com os conceitos e configurações do Traffic Director.

O diagrama a seguir mostra os recursos que você precisa configurar para aplicativos gRPC sem proxy.

Recursos compatíveis com gRPC sem proxy para balanceamento de carga.
Recursos compatíveis com gRPC sem proxy para balanceamento de carga (clique para ampliar)

Mapas de regras de roteamento

Um mapa de regras de roteamento define como as solicitações são roteadas na malha. Ele consiste em uma regra de encaminhamento, um proxy gRPC de destino e um mapa de URLs. Os mapas de regras de roteamento se aplicam apenas a implantações que usam as APIs de balanceamento de carga. Elas não se aplicam às APIs de roteamento de serviço ou APIs de gateway.

Regra de encaminhamento

Normalmente, você cria a regra de encaminhamento usando o endereço IP virtual e a porta do serviço que está configurando. Um cliente gRPC que usa o esquema de resolução de nome xds não executa uma busca DNS para resolver o nome do host no URI do canal. Em vez disso, esse cliente resolve o hostname[:port] no URI de destino enviando uma solicitação LDS ao Traffic Director. Não há busca de DNS envolvida, e uma entrada DNS do nome do host não é necessária.

Como resultado, o Traffic Director usa apenas a porta especificada no URI para procurar a regra de encaminhamento, ignorando o endereço IP. O valor padrão da porta é 80. Em seguida, o Traffic Director procura uma regra de host correspondente no mapa de URL associado ao proxy de destino referenciado pela regra de encaminhamento.

Portanto, uma regra de encaminhamento que faz referência a um proxy gRPC de destino com o campo validateForProxyless definido como TRUE precisa ter seu endereço IP definido como 0.0.0.0. Quando validateForProxyless é definido como TRUE, as configurações que especificam um endereço IP diferente de 0.0.0.0 são rejeitadas. Essa verificação não detecta regras de encaminhamento duplicadas com a mesma porta em outros mapas de regras de roteamento.

Observações:

  • O esquema de balanceamento de carga da regra de encaminhamento precisa ser INTERNAL_SELF_MANAGED.
  • É possível ter várias regras de encaminhamento, mas o IP:port de cada regra precisa ser exclusivo, e a porta precisa corresponder à porta especificada na regra de host.
  • Se mais de uma regra de encaminhamento tiver uma porta que corresponda à porta no URI de destino, o Traffic Director procurará um hostname[:port] correspondente nas regras de host dos mapas de URL referenciados por todas essas regras de encaminhamento. O Traffic Director procura uma correspondência exata entre hostname[:port] na regra de host e o hostname[:port] especificado no URI de destino. As regras de host e as regras padrão que contêm caracteres curinga são ignoradas.

Se mais de uma correspondência for encontrada, o comportamento será indefinido e poderá causar um comportamento imprevisível. Isso geralmente acontece quando as duas condições a seguir são atendidas:

  • O mesmo nome de host é usado em vários mapas de URLs.
  • Várias regras de encaminhamento com o esquema de balanceamento de carga INTERNAL_SELF_MANAGED especificam a mesma porta.

Por isso, recomendamos que você não reutilize o mesmo nome de host em vários mapas de URL referenciados por regras de encaminhamento que especificam a mesma porta.

Proxy gRPC de destino

Os proxies de destino apontam para mapas de URL, que, por sua vez, contêm regras usadas para rotear o tráfego para o back-end correto. Ao configurar o Traffic Director para aplicativos do gRPC, use um proxy gRPC de destino, não um proxy HTTP de destino, independentemente de você usar aplicativos gRPC sem proxy ou aplicativos gRPC que usem o Envoy.

Os proxies do gRPC de destino têm um campo chamado validateForProxyless na API REST. O valor padrão é FALSE. Definir esse campo como TRUE permite verificações de configuração para que você não ative acidentalmente um recurso incompatível com o gRPC sem proxy.

Na CLI do Google Cloud, a sinalização --validate-for-proxyless é equivalente ao campo validateForProxyless.

Como o suporte do Traffic Director a aplicativos gRPC sem proxy não inclui toda a gama de recursos disponíveis para os aplicativos gRPC com um proxy secundário, você pode usar esse campo para garantir que uma configuração inválida, que pode especificada no mapa de URL ou no serviço de back-end, seja rejeitada. A validação da configuração é feita com base nos recursos a que o Traffic Director oferece suporte com a versão mais recente do gRPC.

Mapa de URL

O mapa de URL define as regras de roteamento que os clientes gRPC sem proxy usam para enviar tráfego. O mapa de URLs contém uma ou mais regras de host no formato hostname:port. Cada uma dessas regras de host é resolvida em um serviço.

Ao configurar seu cliente gRPC, você especifica o URI de destino do serviço que o cliente precisa entrar em contato. Esse URI também usa o formato hostname:port. Esse URI corresponde à entrada da regra de host no mapa de URL.

Por exemplo, se você configurar o URI de destino xds:///myservice:8080 no seu cliente gRPC, o Traffic Director enviará a configuração correspondente à regra de host do mapa de URL para myservice:8080. Essa configuração inclui, entre outras informações, uma lista de endpoints, que são, cada um, um par de endereço IP:porta correspondente a instâncias específicas do servidor gRPC.

Se você não especificar uma porta no URI de destino, 80 será usado como o valor padrão. Isso significa que:

  • O URI de destino xds:///myservice corresponde à regra de host myservice do mapa de URL.
  • O URI de destino xds:///myservice:80 corresponde à regra de host myservice:80 do mapa de URL.
  • O URI de destino xds:///myservice não corresponde à regra de host myservice:80 do mapa de URL.
  • O URI de destino xds:///myservice:80 não corresponde à regra de host myservice do mapa de URL.

A string no URI de destino e a string na regra de host do mapa de URL precisam ser idênticas.

Para mais informações, consulte Limitações do mapa de URL.

Verificações de integridade

Uma verificação de integridade do gRPC pode verificar o status de um serviço gRPC em execução em uma instância de máquina virtual (VM) de back-end ou em um grupo de endpoints de rede (NEG).

Se uma verificação de integridade do gRPC não puder ser usada porque o servidor gRPC não implementa o protocolo de verificação de integridade do gRPC (em inglês), use uma verificação de integridade TCP. Não use uma verificação de integridade HTTP, HTTPS ou HTTP/2.

Para mais informações, consulte Verificação de integridade do gRPC e Sinalização adicional para verificações de integridade do gRPC.

Serviço de back-end

O serviço de back-end define como um cliente gRPC se comunica com um servidor gRPC. Ao criar um serviço de back-end para gRPC, defina o campo de protocolo como GRPC.

  • Um serviço de back-end configurado com um protocolo definido como GRPC também pode ser acessado por aplicativos gRPC por meio de um proxy sidecar. Nessa situação, o cliente gRPC não pode usar o esquema de resolução de nome xds.

  • Em todas as implantações do Traffic Director, o esquema de balanceamento de carga do serviço de back-end precisa ser INTERNAL_SELF_MANAGED.

Back-ends

Os back-ends hospedam as instâncias do servidor de gRPC. É possível usar grupos de instâncias gerenciadas ou não gerenciadas no Compute Engine e NEGs zonais no Google Kubernetes Engine como back-ends para hospedar as instâncias do servidor gRPC.

A seguir