Integração do Cloud Service Mesh com o Service Directory

Este documento fornece uma vista geral de como usar o registo de serviços do Service Directory com a Cloud Service Mesh, que permite à Cloud Service Mesh encaminhar tráfego e aplicar políticas de tráfego a serviços registados no Service Directory. Este documento destina-se a programadores do Cloud Service Mesh que pretendem integrar as respetivas aplicações com outros serviços no Google Cloud.

O diretório de serviços é um registo de serviços que armazena informações sobre os serviços de rede registados no mesmo, incluindo os respetivos nomes, localizações e atributos. Pode registar os seus serviços automaticamente, capturando todos os detalhes, e todos os serviços podem ser registados, independentemente da respetiva infraestrutura.

O registo pode conter não só Google Cloud serviços, mas também serviços híbridos executados no local ou noutras nuvens públicas. Para compreender melhor as informações neste documento, recomendamos que se familiarize com os princípios básicos das operações do diretório de serviços.

Quando usa o registo de serviços do diretório de serviços com a Cloud Service Mesh, a integração disponibiliza os serviços no registo de serviços às aplicações na sua malha e às gateways configuradas pela Cloud Service Mesh. A integração do Cloud Service Mesh com o Service Directory é suportada, com o Envoy e com o gRPC sem proxy, para integrações do Service Directory com balanceadores de carga de rede de passagem interna, balanceadores de carga de aplicações internos e Private Service Connect de nível 4.

Para integrar os seus serviços, regista um serviço no Service Directory e, em seguida, associa o serviço a um serviço de back-end do Cloud Service Mesh. Depois de estabelecer uma associação, o Cloud Service Mesh consulta o Service Directory para obter informações sobre o serviço registado e como esse serviço pode ser alcançado. O Cloud Service Mesh também monitoriza quaisquer alterações ao serviço. A utilização da integração permite que a malha de serviço e o gateway autogerido enviem tráfego para estes serviços. Também lhe permite aplicar políticas, por exemplo, políticas de gestão de tráfego avançadas, que configura no Cloud Service Mesh.

Quando usa esta integração, a associação de serviços funciona como um back-end, independentemente do tipo de back-end usado pelo próprio serviço. A integração simplifica a implementação da Cloud Service Mesh, porque a Cloud Service Mesh pode enviar tráfego para o serviço independentemente do tipo de back-end.

Quando um serviço está registado no Service Directory, não precisa de configurar grupos de instâncias nem diferentes tipos de grupos de pontos finais da rede (NEGs) para ter acesso aos serviços de que precisa. Pode registar automaticamente o Google Kubernetes Engine, os balanceadores de carga internos e o Private Service Connect no Service Directory, o que simplifica ainda mais o acesso do Cloud Service Mesh a estes serviços.

Recursos usados pela integração

A integração entre o Cloud Service Mesh e o Service Directory usa os seguintes recursos.

Serviços do diretório de serviços

O Service Directory é um registo de serviços. O Service Directory permite-lhe registar vários tipos de serviços, incluindo serviços baseados na Google Cloud ou noutros ambientes (por exemplo, um centro de dados no local). Cada serviço consiste num nome exclusivo e em zero ou mais pontos finais de serviço. Um ponto final de serviço consiste num endereço, numa porta, em propriedades e em metadados. Se não existirem pontos finais,não pode encaminhar tráfego para o serviço.

Vínculos de serviços

Uma associação de serviços é um recurso que inclui o nome do domínio totalmente qualificado (FQDN) do serviço Service Directory. Por exemplo, projects/test-proj/locations/us-east1/namespaces/test-namespace/services/test-service é um FQDN para um serviço de diretório de serviços.

Serviços de back-end

Os serviços de back-end são recursos de configuração que fornecem informações à Cloud Service Mesh, incluindo os back-ends, como grupos de instâncias geridos, para os quais o serviço de back-end encaminha o tráfego. Os serviços de back-end que fazem referência a associações de serviços não podem ter back-ends. Para usar a integração do Cloud Service Mesh com o Service Directory, cria um novo serviço de back-end para referenciar associações de serviços.

Um serviço de back-end pode ter várias associações de serviços. Esta configuração é útil numa situação em que tem implementações regionais da mesma aplicação. Pode registar cada implementação regional numa instância regional do Service Directory, como serviço regional 1 e serviço regional 2. Cada um destes serviços de diretório de serviços regionais pode, em seguida, ser associado ao mesmo serviço de back-end, através de duas associações de serviços. A associação de serviços global 1 seria associada ao serviço regional 1 na região A e a associação de serviços global 2 seria associada ao serviço regional 2 na região B.

Exemplos de utilização

A integração da sua implementação do Cloud Service Mesh com o Service Directory permite novos exemplos de utilização úteis quando depende de serviços que outras equipas ou organizações detêm ou publicam.

Disponibilize os serviços existentes ao Cloud Service Mesh

O Service Directory integra-se com Google Cloud produtos como o GKE, os balanceadores de carga de rede de encaminhamento interno e os balanceadores de carga de aplicações internos. Quando os produtores de serviços criam um serviço GKE ou um equilibrador de carga, podem registá-lo no Service Directory.

Depois de um serviço ser registado no Service Directory, pode configurar a malha de serviços do Google Cloud para comunicar com esse serviço. Os clientes da Cloud Service Mesh podem comunicar com serviços executados atrás de balanceadores de carga de rede de encaminhamento interno e balanceadores de carga de aplicações internos.

Melhorar a coordenação entre os produtores e os consumidores de serviços

As grandes empresas têm muitas equipas de programadores independentes. Estas equipas disponibilizam os respetivos serviços a outras equipas para que mais equipas possam usar as capacidades fornecidas pelo serviço partilhado. Isto cria dependências entre equipas. Embora estas dependências permitam que as equipas partilhem os seus esforços, as dependências também criam custos de coordenação.

Quando usa o Service Directory, uma equipa (o produtor) regista um serviço que quer disponibilizar a outras equipas ou organizações (consumidores). O produtor partilha uma referência a este serviço com um consumidor. O consumidor pode usar esta referência para procurar o serviço do produtor no Service Directory e descobrir os pontos finais do serviço. Por exemplo, o ponto final pode ser um endereço IP virtual (VIP) no qual o serviço do produtor espera receber tráfego.

A integração do Cloud Service Mesh com o Service Directory permite-lhe automatizar o processo associando um serviço do Service Directory a um serviço de back-end do Cloud Service Mesh, o que tem as seguintes vantagens:

  • O Cloud Service Mesh resolve automaticamente os pontos finais do serviço sincronizando-os a partir do Service Directory. Se os pontos finais do serviço do Service Directory forem atualizados, o Cloud Service Mesh sincroniza automaticamente estas alterações.
  • Pode definir várias políticas de encaminhamento e gestão de tráfego, como tempos limite, na Cloud Service Mesh. Estas políticas permitem-lhe ajustar a forma como as suas aplicações emitem pedidos para o serviço Service Directory. Para ver informações sobre o encaminhamento e a gestão de tráfego na Cloud Service Mesh, consulte o artigo Gestão de tráfego avançada.
  • O Cloud Service Mesh usa capacidades de gestão de tráfego, como o balanceamento de carga baseado na proximidade, para direcionar de forma ideal o tráfego das aplicações para os pontos finais, por exemplo, minimizando o tempo de resposta.
Usar o Service Directory para a deteção de serviços.
Usar o Service Directory para a deteção de serviços (clique para aumentar)

Quando um consumidor usa a Cloud Service Mesh e anexa um serviço de back-end a um serviço do Service Directory, a sobrecarga de coordenação entre equipas é reduzida.

  • Anexa o serviço Payments pelo nome.

  • O Cloud Service Mesh partilha informações sobre o serviço Payments com os respetivos clientes.

    • Por exemplo, os proxies sidecar em execução na sua malha de serviços agora conhecem o ponto final (por exemplo, 10.0.0.1:80) através do qual o serviço pode ser alcançado.

  • As suas aplicações podem chamar este serviço pelo nome sem que você ou a sua aplicação tenham de saber nada sobre o ponto final do serviço externo. No diagrama, o serviço é o serviço Payments.

  • Quando o produtor do serviço atualiza o serviço externo (por exemplo, alterando o respetivo ponto final), o Cloud Service Mesh recebe a atualização e partilha-a perfeitamente com os respetivos clientes.

Aceda a serviços dentro de um perímetro através de um ponto de entrada

Uma equipa pode agrupar uma coleção de serviços num perímetro do VPC Service Controls e expor esses serviços através de um único ponto de entrada. Este ponto de entrada pode ser registado no Service Directory e disponibilizado aos utilizadores que pretendem aceder aos serviços dentro do perímetro. Para mais informações acerca dos perímetros do VPC Service Controls, consulte Detalhes e configuração do perímetro de serviço.

Por exemplo, uma equipa cria um gateway de entrada através de um equilibrador de carga de aplicações interno que distribui pedidos a uma coleção de serviços Kubernetes num cluster. Este gateway de entrada é registado automaticamente como um serviço no Service Directory. Um consumidor que queira aceder aos serviços Kubernetes pode procurar este gateway de entrada no Service Directory. Em seguida, o consumidor pode configurar a malha do Cloud Service Mesh para aceder aos serviços no perímetro através do gateway.

Associe serviços entre domínios

Pode ter serviços em domínios diferentes que precisa de associar.

Associe serviços entre organizações

Pode querer aceder a serviços pertencentes a outra organização, como as APIs Google (por exemplo, o Cloud SQL) ou serviços geridos de terceiros.

O Service Directory suporta o Private Service Connect. Quando cria um ponto final do Private Service Connect na sua rede, o ponto final pode ser registado como um serviço no Service Directory. Em seguida, pode anexar este serviço ao Cloud Service Mesh, para que os clientes de malha, como os clientes Envoy e gRPC, e os gateways autogeridos, como o Apigee, possam chamar estes serviços.

Usar o Service Directory para a deteção de serviços com o Private Service Connect.
Usar o diretório de serviços para a deteção de serviços com o Private Service Connect (clique para aumentar)

O exemplo anterior, que usa o Cloud Storage, ilustra como pode usar o Private Service Connect para chamar as APIs Google através de um ponto final na sua rede de nuvem privada virtual.

Ligue serviços em redes VPC

Algumas empresas usam várias redes VPC como parte da respetiva Google Cloud implementação. Nestes casos, um serviço numa rede VPC pode ter de aceder a um serviço numa rede VPC diferente. Pode configurar o peering de VPC para aceder a um serviço numa rede VPC diferente, mas esta configuração cria complicações quando existem intervalos de endereços IP sobrepostos entre redes com peering.

O Private Service Connect pode tornar um serviço numa rede VPC acessível de forma segura e privada a serviços noutra rede VPC, através de um único ponto final IP:port.

Vista detalhada da utilização do Service Directory para a deteção de serviços com o Private Service Connect.
Vista detalhada da utilização do diretório de serviços para a deteção de serviços com o Private Service Connect (clique para aumentar)

Exemplos adicionais em vários domínios

Os dois exemplos anteriores ilustram casos em que pode ter de atravessar domínios, mas existem muitos outros exemplos. Por exemplo, cria um gateway que se encontra na interseção de duas Google Cloud regiões. Os serviços numa região podem alcançar serviços noutra região através deste gateway. Regista a gateway como um serviço no Service Directory e, em seguida, usa a gateway com a malha de serviços na nuvem, conforme descrito neste documento.

Aplique políticas quando os serviços são acedidos

A malha de serviços na nuvem suporta capacidades como a gestão avançada de tráfego que são configuráveis através de políticas. Por exemplo, pode definir uma política de replicação de tráfego para que, sempre que um cliente enviar um pedido a um serviço de back-end específico, o tráfego também seja enviado para um segundo serviço de back-end.

Quando associa um serviço do Service Directory a um serviço de back-end do Cloud Service Mesh, pode configurar estes tipos de políticas no Cloud Service Mesh. Os seus proxies sidecar, proxies intermédios ou de limite, e clientes sem proxy aprendem sobre estas políticas e aplicam-nas.

Alguns exemplos:

  • Divisão de tráfego baseada em ponderação, por exemplo, entre dois serviços de diretório de serviços
  • Duplicação de tráfego, por exemplo, para um serviço de auditoria
Os pedidos do serviço `users` são replicados para o serviço `audit`
Os pedidos do serviço users são refletidos no serviço audit (clique para aumentar)

Suporte para a Cloud Service Mesh e clientes existentes

Mesmo quando a Cloud Service Mesh está implementada na sua organização, pode ter clientes que não usam a Cloud Service Mesh. Por exemplo, pode ter de aceder a um serviço a partir de uma máquina virtual que não faça parte de uma malha de serviços.

Quando associa um serviço do Service Directory a um serviço de back-end do Cloud Service Mesh, os clientes do Cloud Service Mesh recebem automaticamente informações atualizadas sobre esse serviço. Os seus clientes que não usam a malha de serviços na nuvem podem procurar e usar informações de serviços no Service Directory.

Limitações

O Cloud Service Mesh não suporta NEGs FQDN (NEGs INTERNET_FQDN_PORT) na integração do Service Directory.

O que se segue?