Visão geral das APIs de roteamento de serviços do Traffic Director

Este documento é destinado a administradores de malha ou plataforma e desenvolvedores de serviços que têm um nível intermediário de familiaridade com os conceitos do Traffic Director e da malha de serviço. Este documento se aplica a implantações usando clientes Envoy e gRPC. Para mais informações sobre os conceitos do Traffic Director, consulte a visão geral e a visão geral dos serviços do gRPC sem proxy.

O Traffic Director oferece recursos de rede de serviços aos aplicativos, incluindo gerenciamento avançado de tráfego, observabilidade e segurança. No entanto, configurar e operar uma malha de serviço é uma tarefa complexa para administradores e desenvolvedores de serviços.

Neste documento, descrevemos as APIs de roteamento de serviço para configurar o Traffic Director. Estas APIs foram projetadas para simplificar e melhorar sua experiência geral de configuração da malha.

Este modelo de API substitui os recursos antigos de regra de encaminhamento, proxy de destino e Mapa de URL por recursos de API chamados Mesh, Gateway e Route. Estes recursos oferecem uma experiência de configuração mais relevante contextualmente, quando você define seu plano de controle de rede de serviços.

Neste documento, apresentamos o modelo e os recursos da API de roteamento de serviço a seguir.

• Mesh
  • Gerenciamento de tráfego de serviço a serviço (east-west) e configuração de segurança para proxies sidecar do Envoy e clientes gRPC sem proxy.

• Gateway

  • Gerenciamento de tráfego e configuração de segurança para proxies Envoy que atuam como gateways de entrada, permitindo que clientes externos se conectem à malha de serviço (norte-sul).

• APIs do Route com os seguintes tipos

  • HTTPRoute
  • GRPCRoute
  • TCPRoute
  • TLSRoute

O Console do Google Cloud não oferece suporte às APIs de roteamento de serviço. Implemente esses recursos da API usando a Google Cloud CLI ou as APIs REST. Além disso, não há caminho de migração automatizado das APIs mais antigas para as APIs de roteamento de serviços. Para substituir uma implantação, é preciso criar uma nova implantação do Traffic Director com as APIs de roteamento de serviço e, em seguida, encerrar a implantação antiga.

Casos de uso e benefícios

As APIs de roteamento de serviço permitem configurar o Traffic Director para implantações sem proxy gRPC e de proxy Envoy. O modelo de API de roteamento de serviço oferece vários benefícios importantes.

No diagrama a seguir, dois serviços na malha de serviço estão conectados por um recurso Mesh. Os dois recursos HTTPRoute configuram o roteamento. O administrador da malha ou da plataforma gerencia o recurso Mesh, e os dois proprietários de serviços criam a configuração de roteamento dos serviços.

Tráfego de serviço a serviço do leste-oeste em uma malha de serviço (clique para ampliar)

O design da API orientada a papéis permite a separação clara de responsabilidades.

As APIs de roteamento de serviço permitem separar as responsabilidades de configuração da malha com base nos papéis organizacionais:

• Os administradores da malha podem definir a malha lógica e a infraestrutura de gateway de entrada.
• Proprietários de serviço (desenvolvedores de aplicativos) podem definir padrões de acesso para os próprios serviços. Eles também podem definir e aplicar políticas de gerenciamento de tráfego aos serviços.

No diagrama a seguir, o Cloud Load Balancing e um recurso Gateway fornecem um gateway de entrada para o tráfego que entra na malha de um cliente que não está na malha. O administrador da malha configura e gerencia o recurso Gateway, enquanto os proprietários configuram e gerenciam os próprios serviços e o roteamento de tráfego.

Tráfego norte-sul na malha por meio de um gateway (clique para ampliar)

Maior confiabilidade com um modelo de autoatendimento

Na API Traffic Director mais antiga, o mapa de URL define o roteamento para a comunicação de serviço a serviço na malha, bem como o tráfego externo que entra na malha por meio de um balanceador de carga gerenciado. Várias equipes podem editar um único recurso de mapa de URL, que apresenta possíveis problemas de confiabilidade e complica o processo de delegação da configuração por serviço aos proprietários.

As APIs de roteamento de serviço apresentam recursos por protocolo e rota que podem ser configurados e de propriedade de proprietários de serviços independentes. Essa abordagem tem várias vantagens.

• Os proprietários de serviços agora têm autonomia sobre como querem configurar as políticas e o gerenciamento de tráfego para os próprios serviços.
• Atualizar um recurso Route não afeta outros recursos Route na malha. O processo de atualização também é menos propenso a erros, porque os proprietários de serviço gerenciam configurações muito menores.
• O proprietário do serviço responsável pelo serviço de destino ou nome do host é o proprietário de cada recurso Route.
• Os proprietários de serviços não precisam depender dos administradores da malha para atualizar o roteamento usando o recurso de mapa de URL centralizado.

Configurar apenas o que é relevante

As APIs de roteamento de serviço substituem regras de encaminhamento, proxy de destino e mapas de URL. Não é mais necessário alocar endereços IP virtuais da rede de nuvem privada virtual (VPC) para comunicação de serviço a serviço com proxies sidecar e gRPC sem proxy.

Ativar uma malha de serviço que abrange vários projetos em ambientes de VPC compartilhada

O modelo de API de roteamento de serviço permite que os proprietários de serviços participem de uma infraestrutura de malha compartilhada usando a VPC compartilhada e outros meios de conectividade, mantendo o controle independente sobre os serviços. Por exemplo, os proprietários do serviço podem definir os recursos Route nos próprios projetos. Os administradores da plataforma podem definir um Mesh em um projeto host administrado centralmente e, em seguida, conceder aos proprietários do serviço permissões do IAM para anexar os recursos Route a um Mesh ou Gateway compartilhado. O diagrama a seguir mostra um exemplo com a VPC compartilhada.

Referências entre projetos com VPC compartilhada (clique para ampliar)

As APIs de roteamento de serviços também permitem que você tenha clientes da malha de serviço conectados a redes diferentes usando o peering de rede VPC.

Rotear o tráfego com base no indicador do nome do servidor

O recurso TLSRoute permite rotear o tráfego criptografado pelo TLS com base na indicação do nome do servidor (SNI, na sigla em inglês) no handshake de TLS. É possível configurar o tráfego TLS a ser roteado para os serviços de back-end apropriados configurando a correspondência SNI no recurso TLSRoute. Nessas implantações, os proxies só roteiam o tráfego, e a sessão TLS é encerrada na instância de back-end de destino.

O recurso TLSRoute é compatível apenas com proxies Envoy implantados como proxies ou gateways sidecar.

Recurso TLSRoute anexado a um recurso Mesh

A implantação mostrada no diagrama a seguir roteia qualquer tráfego da malha de serviço em que a extensão SNI tenha o valor service1 para o serviço de back-end service1. Além disso, qualquer tráfego da malha de serviço em que a extensão SNI tenha o valor service2 é roteado para o serviço de back-end service2. O valor da extensão SNI e o nome do serviço de back-end são independentes entre si.

Recurso TLSRoute e recurso Mesh (clique para ampliar)

Recurso TLSRoute anexado a um recurso Gateway

A implantação mostrada no diagrama a seguir direciona qualquer tráfego de entrada para o recurso Gateway em que a extensão SNI tem o valor serviceA para o serviço de back-end serviceA. Além disso, qualquer tráfego de entrada para Gateway em que a extensão SNI tenha o valor serviceB é roteado para o serviço de back-end serviceB. O valor da extensão SNI e o nome do serviço de back-end são independentes entre si. O valor da extensão SNI e o cabeçalho em solicitações HTTP também são independentes.

O recurso Gateway não encerra a conexão TLS no proxy Envoy do Gateway. Em vez disso, a conexão TLS é encerrada no serviço de back-end correspondente. O Gateway não pode inspecionar nenhuma informação criptografada na camada TLS, além de ver o ClientHello, que contém uma extensão SNI de texto simples. O Gateway executa a transferência de TLS nesse modo. Os ClientHello criptografados não são compatíveis.

Recurso TLSRoute e recurso Gateway (clique para ampliar)

Compatibilidade com gRPC de primeira classe

Configure clientes gRPC sem proxy usando atributos gRPC de primeira classe, como correspondência por método, em vez de traduzir para caminhos equivalentes e usar correspondências de caminho.

Divisão de tráfego para tráfego TCP

Agora é possível implementar divisão de tráfego baseada em peso para o tráfego TCP em vários serviços de back-end. É possível configurar padrões, como lançamentos canário (azul-verde) ao atualizar o serviço. A divisão de tráfego também permite migrar o tráfego de maneira controlada, sem inatividade.

Interceptação de tráfego

Quando você usa os recursos Mesh e Gateway da API de roteamento de serviço, todo o tráfego é interceptado automaticamente. Para mais informações, consulte Opções de configuração da VM do Compute Engine com implantação automática do Envoy.

Arquitetura e recursos

Nesta seção, descrevemos o modelo da API de roteamento de serviço e seus recursos e mostramos como os recursos da API de roteamento de serviço funcionam juntos.

RecursoMesh

O recurso Mesh representa uma instância de uma malha de serviço. Você pode usá-la para criar uma malha de serviço lógica no projeto. Cada recurso Mesh precisa ter um nome exclusivo no projeto. Depois que um recurso Mesh é criado, o nome dele não pode ser modificado.

Mesh Recurso da API com sidecar do Envoy e implantações gRPC sem proxy (clique para ampliar)

O recurso Mesh é referenciado no recurso Route para adicionar rotas para serviços que fazem parte da malha.

Os clientes gRPC do proxy e do proxy Envoy recebem a configuração do Traffic Director, mesclando a malha de serviço identificada pelo nome do recurso Mesh. O nome Mesh, como um parâmetro de inicialização, é compatível com a implantação automatizada do Envoy no Compute Engine e pelo injetor automático do envoy no GKE.

O recurso Mesh é compatível com as seguintes implantações do plano de dados:

• Envoy sendo executado junto com o aplicativo como proxies sidecar
• Clientes gRPC sem proxy
• Mix de arquivos secundários do Envoy e gRPC sem proxy

RecursoRoute

O recurso Route é usado para configurar o roteamento para os serviços. Há quatro tipos diferentes de recursos da API Route. Eles definem o protocolo usado para rotear o tráfego para um serviço de back-end.

• HTTPRoute
• GRPCRoute
• TCPRoute
• TLSRoute

A API não contém uma API Route padrão. Os únicos recursos de API configuráveis são HTTPRoute, GRPCRoute, TCPRoute e TLSRoute.

O recurso Route faz referência a um ou mais recursos Mesh e Gateway para adicionar as rotas que fazem parte do Mesh ou Gateway. Um recurso Route pode referenciar os recursos Gateway e Mesh.

O recurso Route também referencia um ou mais recursos de serviço de back-end. Os serviços são configurados usando a API de serviço de back-end com o fluxo de configuração atual. As APIs de roteamento de serviços de não alteram como os serviços de back-end e as verificações de integridade são definidos na configuração do Traffic Director. Basta criar um recurso de serviço de back-end que aponte para um ou mais back-ends MIGs ou NEGs.

O diagrama a seguir mostra a relação entre os recursos Mesh, Gateway e Route, o recurso de serviço de back-end e os respectivos back-ends.

Recursos da API Route (clique para ampliar)

Você define outros recursos de gerenciamento de tráfego, como roteamento, modificações de cabeçalho, tempos limite e divisão de tráfego baseada em peso em recursos Route. Por exemplo, no diagrama a seguir, um recurso HTTPRoute define uma divisão de tráfego de 70% / 30% entre dois serviços de back-end.

Divisão de tráfego com base no peso (clique para ampliar)

RecursoTLSRoute

Use o recurso TLSRoute para rotear o tráfego TLS para serviços de back-end com base em nomes de host da SNI e no nome da negociação de protocolo da camada de aplicativo (ALPN, na sigla em inglês). A configuração TLSRoute implica na passagem de TLS, em que o proxy Envoy não encerra o tráfego TLS.

O recurso TLSRoute faz referência a um ou mais recursos Mesh e Gateway para adicionar as rotas que fazem parte da malha ou do gateway.

O recurso TLSRoute também referencia um ou mais recursos de serviço de back-end. Os serviços são configurados usando o recurso de API do serviço de back-end com o fluxo de configuração e as APIs atuais.

RecursoGateway

O recurso Gateway é usado para representar proxies Envoy que atuam como gateways de entrada, permitindo que clientes externos se conectem à malha de serviço (tráfego norte-sul). Esse recurso tem portas de detecção com um parâmetro scope. O proxy Envoy que atua como um gateway de entrada se vincula às portas especificadas e a 0.0.0.0, que representa todos os endereços IP na VM local. O diagrama a seguir mostra os proxies do Envoy implantados como um serviço de entrada e configurados pelo recurso Gateway. Neste exemplo específico, os proxies do Envoy são configurados para detectar na porta 80 nas conexões recebidas dos clientes.

O recurso da API Gateway é compatível apenas com o plano de dados do proxy Envoy. Ele não é compatível com gRPC sem proxy. gRPCRoutes são compatíveis com o recurso Gateway, mas o tráfego gRPC é roteado pelo proxy Envoy, atuando como um proxy intermediário.

Entrada da malha de serviço por umaGateway recurso (clique para ampliar)

Gateway recurso (clique para ampliar)

O que são um escopo Gateway e a configuração Gateway mesclada?

Uma instância de recurso Gateway representa as portas e configurações específicas do tráfego recebido nessas portas. O recurso da API Gateway tem um parâmetro scope, que é usado para agrupar e mesclar logicamente a configuração de dois ou mais recursos Gateway.

Por exemplo, se você quiser que os proxies Gateway detectem nas portas 80 e 443 para receber tráfego HTTP e HTTPS, respectivamente, crie dois recursos Gateway. Configure um recurso Gateway com porta 80, para tráfego HTTP, e outro com 443, para tráfego HTTPS. Preencha o campo scope com o mesmo valor. O Traffic Director mescla dinamicamente as configurações individuais de todos os gateways que têm o mesmo escopo. No lado do plano de dados, os proxies do Envoy que são executados no modo de gateway de entrada também precisam apresentar o mesmo parâmetro de escopo ao Traffic Director para receber a configuração de Gateway. Observe que você especifica o escopo ao criar o recurso Gateway e especifica o mesmo escopo que o parâmetro de inicialização para os proxies.

Gateway comportamento de mesclagem de recursos (clique para ampliar)

Veja a seguir as principais considerações para o recurso Gateway:

• O parâmetro de escopo Gateway é obrigatório. Especifique o escopo no recurso Gateway e na configuração de inicialização dos proxies do Envoy, mesmo quando houver apenas um Gateway.
• Criar um recurso Gateway não implanta um serviço com um proxy Envoy. A implantação do proxy Envoy é uma etapa separada.
• O recurso Gateway tem um type que representa o tipo de implantação de entrada. Este campo está reservado para uso futuro. O único valor atualmente compatível é OPEN_MESH, que é o valor padrão e não pode ser modificado.

Implantações de malha com protocolos e planos de dados mistos

É possível ter uma implantação mista de plano de dados, com o proxy Envoy e o gRPC sem proxy na mesma malha. Ao criar essas implantações, considere o seguinte.

• As implantações sidecar do Envoy são compatíveis com todas as rotas (HTTPRoute, GRPCRoute, TCPRoute e TLSRoute).
• As implantações gRPC sem proxy são compatíveis apenas com GRPCRoute.
• GRPCRoute é limitado a recursos compatíveis apenas com implantações sem proxy gRPC.

Topologias compatíveis em ambientes de VPC compartilhada de vários projetos

O Traffic Director permite a adição de recursos Route definidos em outros projetos a um recurso Mesh ou Gateway definido em um projeto administrador centralizado. Os proprietários de serviços autorizados podem adicionar diretamente as configurações de roteamento de serviço ao Mesh ou Gateway.

Referências entre projetos entre Mesh e Route (clique para ampliar)

Em um cenário típico de vários projetos, você escolhe um projeto (projeto host ou projeto de administrador controlado centralmente) como o projeto do administrador em malha em que cria um recurso Mesh. O proprietário do projeto do administrador da malha autoriza os recursos Route de outros projetos a fazer referência ao recurso Mesh, permitindo que a configuração de roteamento de outros projetos faça parte da malha. Um plano de dados da malha, seja o Envoy ou o gRPC, solicita a configuração do projeto administrador e recebe uma união de todas as rotas anexadas ao Mesh. Para um Gateway, as rotas também são mescladas em todas as Gateways que usam o mesmo escopo.

O projeto de administrador Mesh pode ser qualquer projeto escolhido por você, e a configuração funciona, desde que os projetos subjacentes tenham conectividade de rede VPC por meio de VPC compartilhada ou peering de rede VPC.

Permissões e papéis do IAM

Veja a seguir as permissões do IAM necessárias para receber, criar, atualizar, excluir, listar e usar com segurança os recursos Mesh e Route.

• Os administradores da malha precisam ter permissões networkservices.mesh.*.
• Os administradores do gateway precisam ter as permissões networkservices.gateways.*.
• Os proprietários de serviços precisam ter as permissões networkservices.grpcRoutes.*, networkservices.httpRoutes.* ou networkservices.tcpRoutes.*.

Os administradores do Mesh precisam conceder a permissão networkservices.mesh.use aos proprietários de serviço para que eles possam anexar recursos Route ao recurso Mesh. O mesmo modelo se aplica a recursos Gateway.

Para ver todas as permissões do IAM para recursos Mesh, acesse a página de referência de permissões do IAM e pesquise meshes.

Não são necessários papéis predefinidos adicionais. O papel predefinido atual Administrador de redes do Compute (roles/compute.networkAdmin) tem permissões networkservices.* por padrão. Talvez seja necessário adicionar as permissões descritas anteriormente aos papéis personalizados.

Comparação do roteamento de serviço e modelos de API mais antigos

Esta seção faz uma comparação tópico por tópico entre os modelos de API mais antigos e de roteamento do serviço do Traffic Director.

	APIs mais antigas	APIs de roteamento de serviços
Recursos de API	Regra de encaminhamento, proxy de destino, mapa de URL e serviço de back-end.	Gateway, malha, rota e serviço de back-end.
Endereços IP e números de porta de serviços	É preciso provisionar endereços IP e números de porta para seus serviços e configurar regras de encaminhamento, que precisam corresponder aos pares de IP:Porta para todos os casos de uso. Você precisa mapear manualmente os endereços IP para nomes de host ou usar o endereço IP "pega-tudo" 0.0.0.0.	Não é necessário configurar endereços IP para casos de uso Mesh ou Gateway. Gateway requer a configuração de números de porta.
Escopo da malha de serviço	O Traffic Director programa todos os proxies anexados à rede VPC. Portanto, o escopo da malha é a rede VPC.	O Traffic Director não programa proxies com base na rede VPC. Para comunicação entre serviços de leste a oeste, os clientes Envoy e gRPC sem proxy usam o nome do recurso Mesh. Para casos de uso do gateway de entrada norte-sul, o parâmetro scope na API Gateway, que permite que vários Gateways sejam agrupados juntos com a configuração mesclada.
Referências entre projetos em ambientes de VPC compartilhada	Não há suporte para referência entre projetos. Todos os recursos da API precisam ser configurados no mesmo projeto.	É possível criar recursos Mesh ou Gateway em um projeto gerenciado centralmente (projeto host) e proprietários de serviços podem criar os recursos Route em projetos de serviço no ambiente de VPC compartilhada. Os recursos de Route podem se referir ao Mesh ou ao Gateway localizados entre projetos.
Porta de interceptação	O parâmetro de inicialização TRAFFICDIRECTOR_INTERCEPTION_PORT precisa ser especificado em cada Envoy que se conecta ao Traffic Director. Com a implantação automática do Envoy na API Compute Engine e a injeção automática de sidecar no GKE, o valor padrão é 15001.	A porta de interceptação é configurada no recurso Mesh e aplica-se automaticamente a todos os Envoys que solicitam a configuração para esse Mesh. O valor continuará como padrão se não for especificado para 15001.

Inicialização de clientes Envoy e gRPC no Compute Engine e no GKE

	APIs mais antigas	APIs de roteamento de serviços
Como usar a implantação automática do Envoy no Compute Engine	Ao criar o modelo de VM, você especifica um parâmetro de linha de comando, --service-proxy=enabled, que inicializa dinamicamente o proxy Envoy com os atributos necessários.	Ao criar o modelo de VM, você especifica parâmetros adicionais. Por exemplo, --service-proxy=enabled, mesh=[MESH_NAME] (para malhas) ou --service-proxy=enabled, scope=[SCOPE_NAME] (para gateways). Outros atributos obrigatórios são inicializados dinamicamente. Para Envoys que servem como gateway, verifique se serving_ports não está especificado para o argumento de linha de comando --service-proxy. Para mais informações, consulte Opções de configuração da VM do Compute Engine com implantação automática do Envoy.
Como usar a injeção automática de sidecar no GKE	Especifique os atributos de inicialização obrigatórios no configMap do injetor do sidecar.	Mesmo fluxo de trabalho com os novos atributos especificados no configconfig.
Como usar a injeção manual de sidecar no GKE	Conforme explicado aqui, o pod do aplicativo precisa ter um contêiner de arquivo secundário do Envoy inicializado com os atributos necessários.	Mesmo fluxo de trabalho com os novos atributos.
Como usar o Compute Engine ou o GKE para implantar clientes gRPC	O aplicativo cliente precisa ser inicializado com os atributos necessários.	Mesmo fluxo de trabalho com os novos atributos.

Como configurar casos de uso de segurança de gateway e malha

	APIs mais antigas	APIs de roteamento de serviços
mTLS de serviço a serviço no GKE	Siga as instruções aqui para implantações baseadas em arquivo secundário do Envoy. Siga as instruções aqui para implantações baseadas em gRPC sem proxy.	As mesmas instruções são aplicáveis. A política de TLS do cliente e a política de TLS do servidor precisam ser aplicadas aos recursos de serviço de back-end e de política de endpoint. Como essas duas APIs são ortogonais para as APIs de roteamento de serviços, o fluxo de configuração permanece o mesmo de antes.
Como proteger implantações de proxy intermediário (gateway de entrada ou saída)	Siga as instruções aqui. Os recursos da política de autorização e TLS do servidor estão anexados ao recurso de proxy HTTPS de destino.	Anexe a política TLS do servidor e os recursos da política de autorização ao gateway.

Considerações e limitações

• O Console do Google Cloud não oferece suporte às APIs de roteamento de serviço nesta versão.
• Use a API xDS versão 3 ou posterior.
  • Versão mínima do Envoy 1.20.0 (já que as APIs de roteamento de serviço são compatíveis apenas com a versão 3 do xDS)
  • Versão mínima do gerador de inicialização do gRPC: v0.14.0
• O recurso TLSRoute é compatível apenas com proxies Envoy implantados como proxies ou gateways sidecar.
• Somente VMs do Compute Engine com implantação automática do Envoy e os pods do GKE com injeção automática do Envoy são compatíveis. Não é possível usar a implantação manual com as APIs de roteamento de serviço.
• O Terraform não é compatível com esta versão.
• As APIs de roteamento de serviço não são compatíveis com versões anteriores das APIs.
• Quando um recurso TCPRoute é anexado a um recurso Mesh, a porta usada para corresponder ao tráfego TCP não pode ser usada para veicular nada, exceto o tráfego descrito por esse TCPRoute.
  • Por exemplo, suas implantações podem incluir um recurso TCPRoute que corresponde à porta "8000" e um recurso HttpRoute. Quando ambos estão anexados ao mesmo recurso Mesh, o tráfego roteado pelo recurso HTTPRoute não pode usar a porta 8000, mesmo quando os endereços IP subjacentes são diferentes. Essa limitação vem da implementação de proxy do Envoy, que atribui prioridade à rota correspondente à porta primeiro.
• O recurso Gateway não provisiona um balanceador de carga gerenciado e não cria dinamicamente um serviço do Envoy.
• Os Envoys implantados automaticamente que atendem como gateways de entrada não podem ter o argumento serving_ports na sinalização --service-proxy.
• O Envoy implantado automaticamente não é compatível com o fornecimento de um número de projeto diferente do projeto da VM.

A seguir

• Para informações sobre as configurações disponíveis com as APIs de roteamento de serviço, leia os guias de configuração do roteamento de serviço do Traffic Director .
• Para ver informações sobre as APIs de roteamento de serviço, leia a documentação das APIs de serviços de rede.