Descoberta de serviços

O Cloud Service Mesh oferece descoberta de serviço e de endpoint. Esses recursos você pode agrupar as instâncias de máquina virtual (VM) e as de contêiner execute o código como endpoints dos serviços.

O Cloud Service Mesh monitora esses serviços para compartilhar informações atualizadas sobre verificação de integridade com os clientes. Portanto, quando um dos seus aplicativos usa a cliente do Cloud Service Mesh (como um proxy sidecar do Envoy ou um aplicativo gRPC sem proxy) para enviar uma solicitação, ela tem acesso informações sobre seus serviços.

No contexto da Cloud Service Mesh, um cliente é o código do aplicativo que é executado em uma VM ou em um contêiner que formula as solicitações a serem enviadas a um servidor. Um server é o código do aplicativo que recebe essas solicitações. Um cliente da Cloud Service Mesh é um Envoy, gRPC ou outro cliente xDS conectado à Cloud Service Mesh e que faz parte do plano de dados.

No plano de dados, o Envoy ou o gRPC faz o seguinte:

  1. Ele examina uma solicitação e corresponde a solicitação a um serviço de back-end, um recurso que você configura durante a implantação.
  2. Após a correspondência da solicitação, o Envoy ou o gRPC aplica as configurações anteriores de tráfego ou de segurança, escolhe um back-end ou endpoint e direciona a solicitação para esse back-end ou endpoint.

Descoberta de serviços

O Cloud Service Mesh oferece descoberta de serviços. Ao configurar o Cloud Service Mesh, você cria serviços de back-end. Você também define regras de roteamento que especificam como uma solicitação de saída (uma solicitação enviada pelo código do aplicativo e processada por um cliente da Cloud Service Mesh) é correspondida a um serviço específico. Quando um cliente do Cloud Service Mesh processa uma solicitação que corresponde a uma regra, ele pode escolha o serviço que deve receber a solicitação.

Exemplo:

  • Você tem uma VM executando o aplicativo. Esta VM tem um proxy sidecar do Envoy conectado ao Cloud Service Mesh e lida com solicitações de saída no do aplicativo.
  • Você configurou um serviço de back-end denominado payments. Esse serviço de back-end tem dois back-ends de grupos de endpoints de rede (NEG, na sigla em inglês) que apontam para várias instâncias de contêiner que executam o código do serviço payments.
  • Você configurou um recurso Mesh definindo uma malha chamada sidecar-mesh.
  • Você configurou um recurso Route que define destinos de tráfego para o serviço de back-end payments e o nome do host helloworld-gce.

Com essa configuração, quando o aplicativo (na VM) enviar uma solicitação HTTP para payments.example.com, o cliente do Cloud Service Mesh saberá que essa solicitação é destinada ao serviço payments.

Quando você usa o Cloud Service Mesh com serviços gRPC sem proxy, a descoberta de serviço funciona de maneira semelhante. No entanto, a biblioteca do gRPC, atuando como um cliente do Cloud Service Mesh, recebe apenas informações sobre os serviços para os quais você especificou um resolvedor xDS. Por padrão, o Envoy recebe informações sobre todos os serviços configurados na rede da nuvem privada virtual (VPC) especificada no arquivo de inicialização do Envoy.

Descoberta de endpoints

Com a descoberta de serviços, os clientes conhecem os serviços que você fornece. A descoberta de endpoints permite que os clientes conheçam as instâncias que executam o código.

Ao criar um serviço, você também especifica os back-ends dele. Esses back-ends são VMs em grupos gerenciados de instâncias (MIGs, na sigla em inglês) ou contêineres em NEGs. O Cloud Service Mesh monitora esses MIGs e NEGs para que sabe quando as instâncias e os endpoints são criados e removidos.

O Cloud Service Mesh compartilha continuamente informações atualizadas sobre esses e serviços com os clientes. Essa informação evita que os clientes enviem tráfego para endpoints que não existem mais. Com ela, os clientes também podem aprender sobre novos endpoints e aproveitar a capacidade extra fornecida por esses endpoints.

Além de adicionar endpoints a MIGs ou NEGs e configurar o Cloud Service Mesh, você não precisa de outras configurações para ativar a descoberta de serviços com do Cloud Service Mesh.

Interceptação de tráfego do proxy sidecar no Cloud Service Mesh

O Cloud Service Mesh oferece suporte ao modelo de proxy sidecar. Nesse modelo, quando aplicativo envia o tráfego ao seu destino, o tráfego é interceptado e o redirecionou para uma porta no proxy sidecar do host onde o aplicativo está em execução. O proxy sidecar decide como balancear a carga do tráfego e, em seguida, envia o tráfego para o destino.

Com o Cloud Service Mesh e as APIs de roteamento de serviço, a interceptação de tráfego é gerenciada automaticamente.

A seguir