Deteção de serviços

O Cloud Service Mesh oferece deteção de serviços e pontos finais. Estas funcionalidades permitem-lhe agrupar as instâncias de máquinas virtuais (VMs) e as instâncias de contentores que executam o seu código como pontos finais dos seus serviços.

O Cloud Service Mesh monitoriza estes serviços para poder partilhar informações de verificação de estado atualizadas com os respetivos clientes. Por conseguinte, quando uma das suas aplicações usa o cliente do Cloud Service Mesh (como um proxy sidecar do Envoy ou uma aplicação gRPC sem proxy) para enviar um pedido, beneficia de informações atualizadas sobre os seus serviços.

No contexto da Cloud Service Mesh, um cliente é um código de aplicação que é executado numa VM ou num contentor que formula pedidos para enviar para um servidor. Um servidor é um código de aplicação que recebe esses pedidos. Um cliente da Cloud Service Mesh é um cliente Envoy ou gRPC ou outro cliente xDS que está ligado à Cloud Service Mesh e faz parte do plano de dados.

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

  1. Examina um pedido e faz a correspondência do pedido com um serviço de back-end, um recurso que configura durante a implementação.
  2. Depois de a solicitação ser correspondida, o Envoy ou o gRPC aplica todas as políticas de tráfego ou de segurança configuradas anteriormente, escolhe um back-end ou um ponto final e direciona a solicitação para esse back-end ou ponto final.

Deteção de serviços

O Cloud Service Mesh oferece deteção de serviços. Quando configura a malha de serviço na nuvem, cria serviços de back-end. Também define regras de encaminhamento que especificam como um pedido de saída (um pedido enviado pelo código da sua aplicação e processado por um cliente da Cloud Service Mesh) é associado a um serviço específico. Quando um cliente da Cloud Service Mesh processa um pedido que corresponde a uma regra, pode escolher o serviço que deve receber o pedido.

Por exemplo:

  • Tem uma VM a executar a sua aplicação. Esta VM tem um proxy sidecar do Envoy que está ligado ao Cloud Service Mesh e processa pedidos de saída em nome da aplicação.
  • Configurou um serviço de back-end denominado payments. Este serviço de back-end tem dois back-ends de grupo de pontos finais de rede (NEG) que apontam para várias instâncias de contentores que executam o código para o seu serviço payments.
  • Configurou um recurso Mesh que define uma malha denominada sidecar-mesh.
  • Configurou um recurso Route que define os destinos de tráfego para o serviço de back-end payments e o nome do anfitrião helloworld-gce.

Com esta configuração, quando a sua aplicação (na VM) envia um pedido HTTP para payments.example.com, o cliente do Cloud Service Mesh sabe que este pedido se destina ao serviço payments.

Quando usa o Cloud Service Mesh com serviços gRPC sem proxy, a deteção de serviços funciona de forma semelhante. No entanto, uma biblioteca gRPC que atua como um cliente do Cloud Service Mesh só recebe informações sobre os serviços para os quais especifica um resolvedor xDS. Por predefinição, o Envoy recebe informações sobre todos os serviços configurados na rede de nuvem privada virtual (VPC) especificada no ficheiro de arranque do Envoy.

Descoberta de pontos finais

A deteção de serviços permite que os clientes saibam mais sobre os seus serviços. A deteção de pontos finais permite que os clientes saibam acerca das instâncias que estão a executar o seu código.

Quando cria um serviço, também especifica os back-ends desse serviço. Estes back-ends são VMs em grupos de instâncias geridas (GIGs) ou contentores em NEGs. O Cloud Service Mesh monitoriza estes MIGs e NEGs para saber quando as instâncias e os pontos finais são criados e removidos.

A Cloud Service Mesh partilha continuamente informações atualizadas sobre estes serviços com os respetivos clientes. Estas informações permitem que os clientes evitem enviar tráfego para pontos finais que já não existem. Também permite que os clientes saibam mais sobre os novos pontos finais e tirem partido da capacidade adicional que estes pontos finais oferecem.

Além de adicionar pontos finais a MIGs ou NEGs e configurar a malha de serviços do Google Cloud, não precisa de nenhuma configuração adicional para ativar a deteção de serviços com a malha de serviços do Google Cloud.

Interceção de tráfego de proxy complementar no Cloud Service Mesh

O Cloud Service Mesh suporta o modelo de proxy sidecar. Neste modelo, quando uma aplicação envia tráfego para o respetivo destino, o tráfego é intercetado e redirecionado para uma porta no proxy sidecar no anfitrião onde a aplicação está a ser executada. O proxy sidecar decide como equilibrar a carga do tráfego e, em seguida, envia o tráfego para o respetivo destino.

Com a malha de serviços na nuvem e as APIs de encaminhamento de serviços, a interceção de tráfego é gerida automaticamente.

O que se segue?