Visão geral das APIs de roteamento de serviço do Cloud Service Mesh
Este documento é destinado a administradores e serviços da malha ou plataforma desenvolvedores que têm um nível intermediário a avançado de familiaridade Cloud Service Mesh e conceitos de malha de serviço e quem está implantando Cloud Service Mesh no Compute Engine com instâncias de VM. Este documento se aplica a implantações usando clientes Envoy e gRPC. Para mais informações sobre Para conceitos do Cloud Service Mesh, consulte a visão geral.
O Cloud Service Mesh oferece recursos de rede de serviços aplicativos, incluindo gerenciamento avançado de tráfego, observabilidade e segurança dos dados. No entanto, configurar e operar uma malha de serviço é uma tarefa complexa para administradores e desenvolvedores de serviços.
Este documento descreve as APIs de roteamento de serviço para configurar a Cloud Service Mesh. Essas APIs foram criadas 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 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
recurso- 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.
-
- 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).
Route
recursos com os seguintes tipos:
O console do Google Cloud não oferece suporte às APIs de roteamento de serviço. Implemente esses recursos de API usando a Google Cloud CLI ou o APIs REST.
Casos de uso e benefícios
As APIs de roteamento de serviço permitem configurar a 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. A rede mesh ou
administrador da plataforma gerencia o recurso Mesh
, e os dois proprietários do serviço criam o
de roteamento do Google Cloud nos serviços.
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.
Maior confiabilidade com um modelo de autoatendimento
As APIs de roteamento de serviço usam 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 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 recursosRoute
na malha. O processo de atualização é mais confiável porque os proprietários de serviços gerenciar 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 fazer atualizações. e roteamento de alto desempenho.
Ativar uma malha de serviço que abrange vários projetos em ambientes de VPC compartilhada
O modelo de API de roteamento de serviços permite que os proprietários de serviços participem de uma malha compartilhada
infraestrutura usando VPC compartilhada e outros meios de conectividade
e manter um 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.
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
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.
Suporte principal a gRPC
Você pode configurar clientes gRPC sem proxy usando os principais atributos gRPC. como correspondência por método.
Divisão de tráfego para tráfego TCP
É possível implementar a divisão de tráfego com base em peso para 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.
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 da
Cloud Service Mesh, mesclando a malha de serviço identificada pelo nome do
recurso Mesh
. O recurso Mesh
é compatível com as seguintes implantações de 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 uma ou mais
serviço de back-end
do Google Cloud. Os serviços são configurados usando a API de serviço de back-end. Você
criar um recurso de serviço de back-end que aponte para um ou mais back-ends MIG 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.
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.
Para simplificar a administração da malha de serviços, é possível listar todos os recursos Route
anexados a um recurso Mesh
ou Gateway
.
TLSRoute
recurso
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.
Gateway
recurso
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.
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.
A malha de serviço do Cloud 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 Cloud Service Mesh 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.
Veja a seguir as principais considerações para o recurso Gateway
:
- O parâmetro de escopo
Gateway
é obrigatório. Especifique o escopo no recursoGateway
e na configuração de inicialização dos proxies do Envoy, mesmo quando houver apenas umGateway
. - 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 umtype
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
eTLSRoute
). - 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 oferece suporte à adição de recursos Route
definidos em outros
projetos para um recurso Mesh
ou Gateway
definido em um sistema de administração
projeto. Os proprietários de serviços autorizados podem adicionar diretamente as configurações de roteamento de serviço ao Mesh
ou Gateway
.
Em um cenário típico entre projetos, você escolhe um projeto (projeto host ou
projeto de administração centralmente controlado) como o projeto de administração de malha em que você cria
um recurso Mesh
. O proprietário do projeto de administração da malha autoriza Route
recursos de outros
projetos para referenciar o recurso Mesh
, permitindo que a configuração de roteamento
de outros projetos para fazer parte da malha. Um plano de dados de malha, seja Envoy ou
gRPC, ele solicita a configuração do projeto de administração e recebe uma união de todos os
das 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 projeto que você escolher, e o
funciona desde que os projetos tenham
conectividade de rede, seja por 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.*
ounetworkservices.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 conferir 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 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.
- 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 recursoMesh
, a porta usada para corresponder ao tráfego TCP não pode ser usada para veicular nada, exceto o tráfego descrito por esseTCPRoute
.- 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 recursoMesh
, o tráfego roteado pelo recursoHTTPRoute
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.
- Por exemplo, suas implantações podem incluir um recurso
- 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 saber como listar recursos de rota associados a um recurso
Mesh
ouGateway
, consulte Listar recursosRoute
. 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.