Visão geral dos mapas de regras de roteamento

Este documento se aplica apenas ao Cloud Service Mesh com as APIs de balanceamento de carga. Qa é altamente recomendável usar APIs de roteamento de serviço.

Um mapa de regras de roteamento consiste no seguinte:

Quando você cria e configura esses recursos para o Cloud Service Mesh, ele usa os valores para criar a configuração que é enviada ao seu plano de dados, o que inclui clientes xDS, como proxies Envoy e aplicativos gRPC sem proxy. O plano de dados processa o tráfego de acordo com essa configuração.

Uma regra de encaminhamento faz referência a um proxy de destino e tem um endereço IP e uma porta. Para implantações do Cloud Service Mesh, o esquema de balanceamento de carga da regra de encaminhamento precisa ser definido como INTERNAL_SELF_MANAGED. O proxy de destino, por sua vez, faz referência a um mapa de URL. Esses três recursos se combinam para formar um mapa de regras de roteamento.

Uma regra de encaminhamento que referencie 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.

O mapa de regras de roteamento define como o tráfego passa de clientes para servidores dentro da malha de serviço.

Tipos de proxy de destino compatíveis

O Cloud Service Mesh oferece suporte aos seguintes tipos de proxy de destino:

  • Proxy HTTP de destino, que você configura quando os clientes e servidores enviam ou recebem tráfego HTTP ou HTTP/2.
  • Proxy HTTPS de destino, configurado quando clientes e servidores enviam ou recebem tráfego HTTPS. Isso é necessário ao configurar a segurança do serviço com proxies do Envoy.
  • Proxy TCP de destino, que você configura quando os clientes e servidores enviam ou recebem tráfego TCP.
  • Proxy gRPC de destino, que você configura quando os clientes e servidores enviam ou recebem tráfego gRPC. Os proxies do gRPC de destino contêm o campo validateForProxyless, que é definido como TRUE quando você implanta serviços gRPC sem proxy.

Roteamento de tráfego com proxies sidecar do Envoy

Quando você usa o Cloud Service Mesh com proxies de sidecar do Envoy, as solicitações de cliente são roteadas da seguinte maneira:

  • A pilha de rede intercepta a solicitação e a redireciona para o proxy sidecar do Envoy.
  • O proxy secundário do Envoy analisa o endereço IP e a porta da solicitação.
  • O endereço IP e o par de portas verificados em relação ao IP e à porta especificados em todas as regras de encaminhamento que têm o esquema de balanceamento de carga definido como INTERNAL_SELF_MANAGED.
  • Se for encontrada uma regra de encaminhamento com um endereço IP e uma porta correspondentes, o Envoy verificará o proxy HTTP ou gRPC de destino a que a regra de encaminhamento faz referência.
  • O Envoy verifica o mapa de URL ao qual o proxy de destino faz referência.
  • O Envoy encaminha a solicitação de acordo com as regras especificadas no mapa de URL.

Para informações sobre como o tráfego é roteado com um proxy TCP de destino, consulte Como rotear tráfego TCP com o Cloud Service Mesh

Roteamento de tráfego com aplicativos gRPC sem proxy

Esse comportamento é diferente para aplicativos gRPC sem proxy. Ao configurar um cliente gRPC, você especifica o URI de destino do serviço que o cliente precisa entrar em contato. Esse URI usa o esquema do resolvedor de nomes xds e o formato hostname:port, por exemplo xds:///example.hostname:8080.

Quando o cliente gRPC sem proxy se conecta à Cloud Service Mesh, ela envia as informações correspondentes ao serviço da seguinte maneira:

  • O Cloud Service Mesh procura regras de encaminhamento com o esquema de balanceamento de carga definido como INTERNAL_SELF_MANAGED para encontrar regras de encaminhamento com a porta correspondente à especificada no URI de destino.
  • O Cloud Service Mesh encontra o proxy gRPC ou HTTP de destino para cada uma dessas regras de encaminhamento.
  • A Cloud Service Mesh encontra os mapas de URL referenciados por esses proxies gRPC de destino ou proxies HTTP de destino.
  • O Cloud Service Mesh verifica as regras de host no mapa de URL, que também tem o formato hostname[:port] e procura uma correspondência.
  • Quando uma correspondência é encontrada, o Cloud Service Mesh retorna regras de roteamento e informações de serviço ao cliente gRPC.

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 esse motivo, 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.

A seguir