Visão geral das APIs de roteamento de serviço do Cloud Service Mesh

Observação: este guia é compatível apenas com o Cloud Service Mesh com APIs do Google Cloud e não com as APIs do Istio. Para mais informações, consulte Visão geral do Cloud Service Mesh.

Este documento é destinado a administradores de malha ou plataforma e desenvolvedores de serviços que têm um nível de familiaridade intermediário a avançado com os conceitos do Cloud Service Mesh e da malha de serviço e que estão implantando o Cloud Service Mesh no Compute Engine com instâncias de VM. Este documento se aplica a implantações que usam clientes Envoy e gRPC. Para mais informações sobre os conceitos do Cloud Service Mesh, consulte a visão geral.

O Cloud Service Mesh oferece recursos de rede de serviços para seus 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 Cloud Service Mesh. Essas APIs foram projetadas para simplificar e melhorar a experiência geral de configuração da malha.

O modelo de roteamento de serviço usa recursos de API chamados Mesh, Gateway e Route. Esses recursos fornecem uma experiência de configuração contextualmente relevante quando você define seu plano de controle da rede de serviços.

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

• Mesh recursos
  • 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).

• Recursos Route com os seguintes tipos:

  • HTTPRoute
  • GRPCRoute
  • TCPRoute
  • TLSRoute

O console do Google Cloud não oferece suporte para as APIs de roteamento de serviço. Implemente esses recursos de API usando a Google Cloud CLI ou as APIs REST.

Casos de uso e benefícios

As APIs de roteamento de serviço permitem configurar o Cloud Service Mesh para implantações de proxy gRPC e Envoy sem proxy. 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 do serviço 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

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

• Os proprietários de serviços têm autonomia sobre como querem configurar políticas e 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 é mais confiável porque os proprietários de serviços gerenciam pequenas configurações.
• 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.

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

Com o modelo de API de roteamento de serviço, os proprietários de serviços podem participar de uma infraestrutura de malha compartilhada usando a VPC compartilhada e outros meios de conectividade, mantendo 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 encaminha qualquer tráfego de malha de serviço em que a extensão SNI tem 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)

Suporte principal a gRPC

Você pode configurar clientes gRPC sem proxy usando atributos gRPC principais, como a correspondência por método.

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

É possível implementar a 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 de proxy Envoy e gRPC sem proxy recebem a configuração do Cloud Service Mesh mesclando a malha de serviço identificada pelo nome do recurso Mesh. O recurso Mesh oferece suporte às 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 faz referência a um ou mais recursos do serviço de back-end. Os serviços são configurados usando a API do serviço de back-end. Crie um recurso de serviço de back-end que aponte para um ou mais back-ends de MIG ou NEG.

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)

Para simplificar a administração da malha de serviço, liste todos os recursos Route anexados a um recurso Mesh ou Gateway.

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.

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 Cloud Service Mesh 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 executados no modo de gateway de entrada também precisam apresentar o mesmo parâmetro de escopo ao Cloud Service Mesh para receber a configuração 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 Cloud Service Mesh é compatível com a adição de recursos Route definidos em outros projetos a um recurso Mesh ou Gateway definido em um projeto de administração centralizada. 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 entre projetos, escolha um projeto (projeto host ou projeto de administração centralmente controlado) como o projeto de administração da malha em que você cria um recurso Mesh. O proprietário do projeto de administração da malha autoriza 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, Envoy ou gRPC, solicita a configuração do projeto de administração 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 administração Mesh pode ser qualquer um que você escolher e a configuração funciona desde que os projetos subjacentes tenham conectividade de rede VPC, seja por meio da VPC compartilhada ou do 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 as permissões networkservices.mesh.*.
• Os administradores de 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 da malha precisam conceder a permissão networkservices.mesh.use aos proprietários do serviço para que eles possam anexar os recursos Route ao recurso Mesh. O mesmo modelo se aplica a recursos Gateway.

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

Não são necessários papéis predefinidos adicionais. O papel predefinido Administrador de rede 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.

Considerações e limitações

• O console do Google Cloud não oferece suporte às APIs de roteamento de serviço.
• Use a API xDS versão 3 ou mais recente.
  • 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.
• 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 como listar recursos de rota associados a um recurso Mesh ou Gateway, consulte Listar recursos Route. Esse recurso está na visualização.
• Para ver informações sobre as APIs de roteamento de serviço, leia a documentação das APIs de serviços de rede.