Vista geral das APIs de encaminhamento de serviços do Cloud Service Mesh

Nota: este guia só suporta a Cloud Service Mesh com Google Cloud APIs e não suporta as APIs Istio. Para mais informações, consulte o artigo Vista geral do Cloud Service Mesh.

Este documento destina-se a administradores de malhas ou plataformas e programadores de serviços com um nível de familiaridade intermédio a avançado com a malha de serviços do Google Cloud e os conceitos de malha de serviços, e que estão a implementar a malha de serviços do Google Cloud no Compute Engine com instâncias de VM. Este documento aplica-se a implementações que usam clientes Envoy e gRPC. Para mais informações sobre os conceitos do Cloud Service Mesh, consulte a vista geral.

A malha de serviços na nuvem oferece capacidades de rede de serviços às suas aplicações, incluindo gestão de tráfego avançada, observabilidade e segurança. No entanto, configurar e operar uma malha de serviço é uma tarefa complexa para os administradores de malhas e os programadores de serviços.

Este documento descreve as APIs de encaminhamento de serviços para configurar a malha de serviços na nuvem. Estas APIs foram concebidas para simplificar e melhorar a sua experiência geral de configuração da malha.

O modelo de encaminhamento de serviços usa recursos de API denominados Mesh, Gateway e Route. Estes recursos oferecem uma experiência de configuração relevante para o contexto quando define o plano de controlo de rede de serviços.

Este documento apresenta o seguinte modelo de API de encaminhamento de serviços e recursos.

• Meshrecurso
  • Configuração de segurança e gestão de tráfego de serviço a serviço (leste-oeste) para proxies sidecar do Envoy e clientes gRPC sem proxy.

• Gatewayrecurso

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

• Route recursos com os seguintes tipos:

  • HTTPRoute
  • GRPCRoute
  • TCPRoute
  • TLSRoute

A Google Cloud consola não oferece suporte para as APIs de encaminhamento de serviços. Tem de implementar estes recursos da API através da CLI Google Cloud ou das APIs REST.

Exemplos de utilização e vantagens

As APIs de encaminhamento de serviços permitem-lhe configurar a malha de serviços na nuvem para implementações de proxy do Envoy e gRPC sem proxy. O modelo de API de encaminhamento de serviços permite várias vantagens importantes.

No diagrama seguinte, dois serviços na malha de serviços estão ligados por um recurso Mesh. Os dois recursos HTTPRoute configuram o encaminhamento. O administrador da malha ou da plataforma gere o recurso Mesh, e os dois proprietários dos serviços criam a configuração de encaminhamento para os respetivos serviços.

Tráfego de serviço a serviço de leste a oeste numa malha de serviços (clique para aumentar)

A criação de APIs orientada para funções permite uma separação clara das responsabilidades

As APIs de encaminhamento de serviços permitem-lhe separar as responsabilidades de configuração da malha com base em funções organizacionais:

• Os administradores da malha podem definir a malha lógica, bem como a infraestrutura do gateway de entrada.
• Os proprietários de serviços (programadores de aplicações) podem definir de forma independente padrões de acesso para os respetivos serviços. Também podem definir e aplicar políticas de gestão de tráfego aos respetivos serviços.

No diagrama seguinte, o Cloud Load Balancing e um recurso Gateway fornecem um gateway de entrada para o tráfego que entra na malha a partir de um cliente que não está na malha. O administrador da malha configura e gere o recurso Gateway, enquanto os proprietários dos serviços configuram e gerem os respetivos serviços e o encaminhamento de tráfego.

Tráfego norte-sul para a malha através de um gateway (clique para aumentar)

Fiabilidade melhorada com o modelo self-service

As APIs de encaminhamento de serviços usam recursos por protocolo e por rota que podem ser configurados e detidos por proprietários de serviços independentes. Esta abordagem tem várias vantagens.

• Os proprietários de serviços têm autonomia sobre a forma como querem configurar as políticas e a gestão de tráfego para os serviços que detêm.
• A atualização de um recurso Route não afeta outros recursos Route na malha. O processo de atualização é mais fiável porque os proprietários dos serviços gerem configurações pequenas.
• O proprietário do serviço responsável pelo serviço de destino ou pelo nome do anfitrião é proprietário de cada recurso Route.
• Os proprietários dos serviços não têm de depender dos administradores da malha para atualizar o encaminhamento.

Ative uma malha de serviços que abranja vários projetos em ambientes de VPC partilhada

O modelo de API de encaminhamento de serviços permite que os proprietários de serviços participem numa infraestrutura de malha partilhada usando a VPC partilhada e outros meios de conetividade, ao mesmo tempo que mantêm o controlo independente sobre os respetivos serviços. Por exemplo, os proprietários de serviços podem definir os recursos Route nos seus próprios projetos. Os administradores da plataforma podem definir um Mesh num projeto anfitrião administrado centralmente e, em seguida, conceder autorizações do IAM aos proprietários dos serviços para anexarem os respetivos recursos Route a um Mesh ou Gateway partilhado. O diagrama seguinte mostra um exemplo com a VPC partilhada.

Referência entre projetos com a VPC partilhada (clique para aumentar)

As APIs de encaminhamento de serviços também permitem ter clientes de malha de serviços ligados a diferentes redes através do intercâmbio de redes VPC.

Encaminhe tráfego com base no indicador do nome do servidor

O recurso TLSRoute permite-lhe encaminhar o tráfego encriptado com TLS com base na Indicação do nome do servidor (SNI) no handshake do TLS. Pode configurar o tráfego TLS para ser encaminhado para os serviços de back-end adequados configurando a correspondência SNI no recurso TLSRoute. Nestas implementações, os proxies apenas encaminham o tráfego e a sessão TLS é terminada na instância de back-end de destino.

O recurso TLSRoute só é suportado com proxies Envoy implementados como proxies ou gateways sidecar.

TLSRoute recurso anexado a um Mesh recurso

A implementação apresentada no diagrama seguinte 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, todo o tráfego da malha de serviço em que a extensão SNI tem o valor service2 é encaminhado 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 aumentar)

TLSRoute recurso anexado a um Gateway recurso

A implementação apresentada no diagrama seguinte encaminha todo o tráfego de entrada para o recurso Gateway, onde a extensão SNI tem o valor serviceA, para o serviço de back-end serviceA. Além disso, todo o tráfego de entrada para o Gateway em que a extensão SNI tem o valor serviceB é encaminhado 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 nos pedidos HTTP também são independentes.

O recurso Gateway não termina a ligação TLS no proxy Envoy do Gateway. Em alternativa, a ligação TLS é terminada no serviço de back-end correspondente. O Gateway não pode inspecionar nenhuma informação encriptada na camada TLS, exceto ver o ClientHello, que contém uma extensão SNI de texto simples. O Gateway realiza a transferência direta de TLS neste modo. Tenha em atenção que o formato ClientHello encriptado não é suportado.

Recurso TLSRoute e recurso Gateway (clique para aumentar)

Compatibilidade com gRPC principal

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

Pode implementar a divisão de tráfego baseada no peso para o tráfego TCP em vários serviços de back-end. Pode configurar padrões, como implementações canary (azul-verde), quando atualiza o seu serviço. A divisão de tráfego também lhe permite migrar tráfego de forma controlada sem tempo de inatividade.

Interceção de tráfego

Quando usa a API Service Routing e os recursos Mesh e Gateway, todo o tráfego é intercetado automaticamente. Para mais informações, consulte o artigo Opções de configuração da VM do Compute Engine com implementação automática do Envoy.

Arquitetura e recursos

Esta secção descreve o modelo de API de encaminhamento de serviços e os respetivos recursos, e ajuda a compreender como os recursos da API de encaminhamento de serviços funcionam em conjunto.

Mesh recurso

O recurso Mesh representa uma instância de uma malha de serviços. Use-o para criar uma malha de serviços lógica no seu projeto. Cada recurso Mesh tem de ter um nome exclusivo no projeto. Depois de criar um recurso Mesh, não é possível modificar o respetivo nome.

MeshRecurso da API com o sidecar do Envoy e implementações gRPC sem proxy (clique para aumentar)

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

O proxy Envoy e os clientes gRPC sem proxy recebem a configuração do Cloud Service Mesh ao aderirem à malha de serviços identificada pelo nome do recurso Mesh. O recurso Mesh suporta as seguintes implementações do plano de dados:

• O Envoy é executado juntamente com a aplicação como proxies complementares
• Clientes gRPC sem proxy
• Combinação de sidecar do Envoy e clientes gRPC sem proxy

Route recurso

O recurso Route é usado para configurar o encaminhamento para os serviços. Existem quatro tipos diferentes do recurso da API Route. Definem o protocolo usado para encaminhar o tráfego para um serviço de back-end.

• HTTPRoute
• GRPCRoute
• TCPRoute
• TLSRoute

A API não contém uma API Route literalmente. Os únicos recursos da 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 da configuração Mesh ou Gateway correspondente. Um recurso Route pode referenciar recursos Gateway e Mesh.

O recurso Route também faz referência a um ou mais recursos de serviço de back-end. Os serviços são configurados através da API de serviços de back-end. Cria um recurso de serviço de back-end que aponta para um ou mais back-ends de MIG ou NEG.

O diagrama seguinte mostra as relações entre os recursos Mesh, Gateway e Route, o recurso de serviço de back-end e os respetivos back-ends.

Recursos da API Route (clique para aumentar)

Define outras capacidades de gestão de tráfego, como o encaminhamento, as modificações de cabeçalhos, os limites de tempo e a divisão de tráfego baseada no peso em recursos Route. Por exemplo, no diagrama seguinte, um recurso HTTPRoute define uma divisão de tráfego de 70% / 30% entre dois serviços de back-end.

Divisão do tráfego com base no peso (clique para aumentar)

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

TLSRoute recurso

Use o recurso TLSRoute para encaminhar o tráfego TLS para serviços de back-end com base nos nomes de anfitriões SNI e no nome da negociação de protocolo da camada de aplicação (ALPN). TLSRouteA configuração implica a passagem de TLS, em que o proxy Envoy não termina 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 configuração de malha ou gateway correspondente.

O recurso TLSRoute também faz referência a um ou mais recursos de serviços de back-end. Os serviços são configurados através do recurso da API de serviço de back-end.

Gateway recurso

O recurso Gateway é usado para representar proxies do Envoy que atuam como gateways de entrada, permitindo que os clientes externos se liguem à malha de serviços (tráfego norte-sul). Este recurso tem portas de escuta juntamente com um parâmetro scope. O proxy Envoy que funciona como um gateway de entrada associa-se às portas especificadas e a 0.0.0.0, que representa todos os endereços IP na VM local. O diagrama seguinte mostra proxies Envoy implementados como um serviço de entrada e configurados pelo recurso Gateway. Neste exemplo específico, os proxies Envoy estão configurados para monitorizar a porta 80 para ligações recebidas de clientes.

O recurso da API Gateway só é compatível com o plano de dados do proxy Envoy. Não suporta gRPC sem proxy. gRPCRoutes são suportados no recurso Gateway, mas o tráfego gRPC é encaminhado pelo proxy Envoy, que atua como um proxy intermédio.

Entrada de malha de serviço através de um recurso Gateway (clique para aumentar)

Recurso Gateway (clique para aumentar)

O que é um Gateway âmbito e uma configuração Gateway unida?

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

Por exemplo, se quiser que os proxies Gateway escutem nas portas 80 e 443 para receberem tráfego HTTP e HTTPS, respetivamente, cria dois recursos Gateway. Configure um recurso Gateway com a porta 80 para tráfego HTTP e o outro com a porta 443 para tráfego HTTPS. Atribua o mesmo valor ao campo scope em cada um. A malha de serviços na nuvem une dinamicamente as configurações individuais de todos os gateways que têm o mesmo âmbito. No lado do plano de dados, os proxies Envoy que são executados no modo de gateway de entrada também têm de apresentar o mesmo parâmetro de âmbito ao Cloud Service Mesh para receber a configuração Gateway. Tenha em atenção que especifica o âmbito quando cria o recurso Gateway e especifica o mesmo âmbito que o parâmetro de arranque para os proxies.

Comportamento de união de recursos Gateway (clique para aumentar)

Seguem-se as principais considerações para o recurso Gateway:

• O parâmetro de âmbito Gateway é obrigatório. Especifique o âmbito no recurso Gateway e na configuração de arranque dos proxies Envoy, mesmo quando existe apenas um Gateway.
• A criação de um recurso Gateway não implementa um serviço com um proxy Envoy. A implementação do proxy Envoy é um passo separado.
• O recurso Gateway tem um type que representa o tipo de implementação de entrada. Este campo está reservado para utilização futura. O único valor atualmente compatível é OPEN_MESH, que é o valor predefinido e não pode ser modificado.

Implementações de malhas com protocolos e planos de dados mistos

Pode ter uma implementação de plano de dados mista, com o proxy Envoy e o gRPC sem proxy na mesma malha. Quando criar implementações deste tipo, considere o seguinte.

• As implementações do sidecar do Envoy suportam todas as rotas (HTTPRoute, GRPCRoute, TCPRoute e TLSRoute).
• As implementações de gRPC sem proxy só suportam GRPCRoute.
• O GRPCRoute está limitado a funcionalidades suportadas apenas por implementações sem proxy gRPC.

Topologias suportadas em ambientes de VPC partilhada com vários projetos

O Cloud Service Mesh suporta a adição de recursos Route definidos noutros projetos a um recurso Mesh ou Gateway definido num projeto de administração centralizada. Os proprietários de serviços autorizados podem adicionar diretamente as respetivas configurações de encaminhamento de serviços ao Mesh ou Gateway.

Referência entre projetos entre recursos do Mesh e do Route (clique para aumentar)

Num cenário típico entre projetos, escolhe um projeto (projeto anfitrião ou projeto de administração controlado centralmente) como o projeto de administração da malha onde cria um recurso Mesh. O proprietário do projeto de administração da malha autoriza os recursos Route de outros projetos a referenciar o recurso Mesh, permitindo que a configuração de encaminhamento de outros projetos faça parte da malha. Um plano de dados de malha, seja o Envoy ou o gRPC, pede a configuração ao 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 unidas em todos os Gateways que usam o mesmo âmbito.

O projeto de administração Meshpode ser qualquer projeto que escolher e a configuração funciona desde que os projetos subjacentes tenham conetividade de rede VPC, através da VPC partilhada ou da interligação de redes VPC.

Autorizações e funções de IAM

Seguem-se as autorizações de IAM necessárias para obter, criar, atualizar, eliminar, listar e usar os recursos Mesh e Route de forma segura.

• Os administradores do Mesh têm de ter autorizações networkservices.mesh.*.
• Os administradores de gateways têm de ter autorizações networkservices.gateways.*.
• Os proprietários dos serviços têm de ter autorizações networkservices.grpcRoutes.*, networkservices.httpRoutes.* ou networkservices.tcpRoutes.*.

Os administradores da malha têm de conceder a autorização networkservices.mesh.use aos proprietários dos serviços para que estes possam anexar os respetivos recursos Route ao recurso Mesh. O mesmo modelo aplica-se aos recursos Gateway.

Para ver todas as autorizações de IAM para recursos Mesh, aceda à página de referência de autorizações de IAM e pesquise meshes.

Não são necessárias funções predefinidas adicionais. A função predefinida existente Compute Network Admin (roles/compute.networkAdmin) tem autorizações networkservices.* por predefinição. Pode ter de adicionar as autorizações descritas anteriormente às suas funções personalizadas.

Considerações e limitações

• A Google Cloud consola não suporta as APIs de encaminhamento de serviços.
• Use a versão 3 da API xDS ou posterior.
  • Versão mínima do Envoy 1.20.0 (uma vez que as APIs de encaminhamento de serviços só são compatíveis com a versão 3 do xDS)
  • Versão mínima do gerador de arranque do gRPC v0.14.0
• O recurso TLSRoute só é suportado com proxies Envoy implementados como proxies auxiliares ou gateways.
• Apenas são suportadas VMs do Compute Engine com implementação automática do Envoy e pods do GKE com injeção automática do Envoy. Não pode usar a implementação manual com as APIs de encaminhamento de serviços.
• As APIs de encaminhamento de serviços não são retrocompatíveis com as APIs mais antigas.
• Quando um recurso TCPRoute está anexado a um recurso Mesh, a porta usada para fazer a correspondência do tráfego TCP não pode ser usada para publicar nada, exceto o tráfego descrito por este TCPRoute.
  • Por exemplo, as suas implementações podem incluir um recurso TCPRoute que corresponda à porta "8000" e a um recurso HttpRoute. Quando ambos estão anexados ao mesmo recurso Mesh, o tráfego encaminhado pelo recurso HTTPRoute não pode usar a porta 8000, mesmo quando os endereços IP subjacentes são diferentes. Esta limitação resulta da implementação do proxy Envoy, que atribui precedência primeiro à rota com correspondência de porta.
• O recurso Gateway não aprovisiona um equilibrador de carga gerido e não cria dinamicamente um serviço Envoy.
• Os Envoys implementados automaticamente que funcionam como gateways de entrada não podem ter o argumento serving_ports para a flag --service-proxy.
• O Envoy implementado automaticamente não suporta o fornecimento de um número do projeto diferente do projeto da VM.

O que se segue?

• Para informações sobre como listar recursos de trajetos associados a um recurso Mesh ou Gateway, consulte o artigo Liste recursos Route.
• Para informações sobre as APIs de encaminhamento de serviços, leia a documentação das APIs de serviços de rede.