Configure a integração com o diretório de serviços

Este guia pressupõe que tem uma implementação do Cloud Service Mesh em execução e que registou, pelo menos, um serviço no Service Directory. As instruções de configuração aplicam-se quer esteja a usar o Envoy ou o gRPC sem proxy.

Para usar o Service Directory e a Cloud Service Mesh, o primeiro passo é publicar o seu serviço no Service Directory. Consulte informações sobre como publicar um serviço no diretório de serviços ou a documentação do diretório de serviços para ver informações gerais.

Depois de o serviço ser registado no Service Directory, pode criar uma associação de serviços através dos recursos da API do Cloud Service Mesh. Cria um serviço de back-end dedicado à integração com o Service Directory, porque um serviço de back-end que faça referência a associações de serviços não pode ter back-ends nem uma verificação de estado associada.

Requisitos da regra de encaminhamento e da regra de anfitrião do Cloud Service Mesh com as APIs de balanceamento de carga

Quando configura a Cloud Service Mesh para utilização com o Service Directory e usa as APIs de balanceamento de carga mais antigas, siga estas diretrizes:

  1. Certifique-se de que a regra de encaminhamento da malha de serviços na nuvem usa o endereço IP virtual (VIP) 0.0.0.0.
  2. Se tiver uma zona privada, certifique-se de que a regra de anfitrião no mapa de URLs corresponde ao nome DNS que o Service Directory configura na sua zona privada do Cloud DNS.

Se não seguir estas diretrizes, é provável que os pedidos de saída das suas aplicações falhem.

Defina o ponto final da API network-services

Antes de criar e usar um serviço de back-end, certifique-se de que o ponto final da API está definido para que os recursos de associações de serviços em network-services resources sejam referenciados corretamente.network-services Defina o ponto final da API network-services com o seguinte comando.

export CLOUDSDK_API_ENDPOINT_OVERRIDES_NETWORKSERVICES="https://networkservices.googleapis.com/"

Requisitos de funções e autorizações

Certifique-se de que tem as seguintes autorizações e funções antes de criar a sua implementação do Cloud Service Mesh.

Autorizações e funções de associação de serviços

Esta secção não aborda as autorizações de proprietário, editor e leitor ao nível do projeto. Descreve as autorizações e as funções necessárias para criar, ler, atualizar e eliminar recursos.

Ação Autorização Funções
Crie uma associação de serviços. networkservices.serviceBindings.create Administrador de rede
Obtenha um vínculo de serviço. networkservices.serviceBindings.get Administrador de rede, visualizador de rede
Apresenta associações de serviços num Google Cloud projeto. networkservices.serviceBindings.list Administrador de rede, visualizador de rede
Atualizar associações de serviços. networkservices.serviceBindings.update Administrador de rede
Eliminar associações de serviços. networkservices.serviceBindings.delete Administrador de rede

Autorizações de serviço do Service Directory

O administrador do Service Directory tem de conceder a autorização servicedirectory.services.bind à conta de serviço que está a tentar anexar a associação de serviço ao serviço Service Directory. Isto permite que a conta de serviço use um serviço do Service Directory, o que significa que a conta pode fazer referência a um serviço do Service Directory numa associação de serviços.

Aplicação de autorizações

As verificações de autorizações da IAM são realizadas quando configura a Cloud Service Mesh. Tem de ter as autorizações necessárias para criar associações de serviços e associar associações de serviços a serviços específicos do Service Directory. Se tiver as autorizações corretas, pode configurar os clientes da malha para saber mais e enviar tráfego para um serviço do Service Directory.

Uma vez que estas verificações ocorrem no momento da configuração, a remoção da autorização de associação num serviço do Service Directory existente não interrompe os fluxos de tráfego. Depois de estabelecer uma associação de serviços, a remoção de uma autorização não afeta se um cliente de malha pode saber mais sobre um serviço do Service Directory e enviar tráfego para o mesmo.

Para impedir que um cliente de malha comunique com um serviço do Service Directory, pode usar outros mecanismos:

  1. Restringir o acesso ao serviço de diretório de serviços. Por exemplo, pode usar regras de firewall.
  2. Elimine o serviço Service Directory.
  3. Atualize a configuração da malha de serviços na nuvem, por exemplo, removendo a associação de serviços do serviço de back-end.

Práticas recomendadas

  • Embora o Service Directory permita o registo de pontos finais através da API Service Directory, recomendamos a utilização de integrações que se registam automaticamente no Service Directory quando estão disponíveis. Para mais informações sobre estas integrações, consulte os artigos Vista geral do Service Directory para o GKE e Vista geral do Service Directory e do Cloud Load Balancing.
  • Recomendamos que use o mesmo espaço de nomes e serviço para um determinado serviço lógico, mesmo quando esse serviço é implementado em diferentes regiões.

Use o Service Directory para a deteção de serviços

O diagrama seguinte oferece uma vista geral do estado final deste procedimento de configuração, incluindo a configuração, a forma como os diferentes sistemas interagem e como um pedido é resolvido nos pontos finais de um serviço. Este exemplo parte do princípio de que já tem um serviço registado no diretório de serviços.

Detalhes da configuração para usar o Service Directory para a deteção de serviços.
Detalhes da configuração para usar o Service Directory para a deteção de serviços (clique para aumentar)

Tornar um serviço do Service Directory disponível para a Cloud Service Mesh consiste nos seguintes passos.

  1. Crie um novo serviço de back-end na malha de serviço na nuvem e não crie back-ends para o serviço de back-end.
  2. Crie uma associação de serviço global para o serviço Service Directory.
  3. Associe o serviço do Service Directory a este serviço de back-end. Opcionalmente, defina campos e políticas adicionais no serviço de back-end.

  4. Crie uma nova configuração de encaminhamento ou atualize uma configuração existente, para que os pedidos do cliente possam ser encaminhados para o novo serviço de back-end.

Não pode definir uma verificação de estado num serviço de back-end que faça referência a uma associação de serviços. O serviço de back-end também não pode ter back-ends.

Crie a integração

Siga as instruções abaixo para integrar o Cloud Service Mesh com o Service Directory.

Crie um serviço de back-end

Siga as instruções abaixo para criar um serviço de back-end na sua implementação do Cloud Service Mesh.

  1. Crie um serviço de back-end para usar com os serviços do Service Directory.

    gcloud compute backend-services create td-sd-demo-service \
     --global \
     --load-balancing-scheme=INTERNAL_SELF_MANAGED
    
  2. Crie uma associação de serviços que referencie um serviço do Service Directory.

    gcloud beta network-services service-bindings create my-sd-binding \
     --location global \
     --service-directory-region us-east1 \
     --service-directory-namespace my-namespace \
     --service-directory-service my-service
    
  3. Vincule o serviço ao serviço de back-end.

    gcloud beta compute backend-services update td-sd-demo-service \
     --global \
     --service-bindings my-sd-binding
    

Depois de criar o serviço de back-end e associar um ou mais serviços do Service Directory, o Cloud Service Mesh começa a monitorizar os pontos finais associados ao serviço do Service Directory. Os pontos finais são pares IP:porta distintos. Para tornar este serviço encaminhável, tem de configurar o encaminhamento.

Configure o encaminhamento

Siga as instruções abaixo para atualizar a configuração de encaminhamento.

APIs de encaminhamento de serviços

O exemplo seguinte pressupõe que tem um recurso Mesh denominado sidecar- mesh. Cria um recurso HTTPRoute com nomes de anfitriões definidos como myservice.example.com e o destino definido como o serviço de back-end td-sd-demo-service que criou na secção anterior.

  1. Crie a especificação HTTPRoute e guarde-a num ficheiro denominado httproute.yaml.

    name: td-sd-demo-route
    hostnames:
    ‐ myservice.example.com
    meshes:
    ‐ projects/PROJECT_NUMBER/locations/global/meshes/sidecar-mesh
    rules:
    ‐ action:
      destinations:
      ‐ serviceName: "projects/PROJECT_NUMBER/locations/global/backendServices/td-sd-demo-service"
    
  2. Importe a especificação HTTPRoute.

    gcloud network-services httproutes import td-sd-demo-route \
      --source=httproute.yaml \
      --location=global
    

APIs de equilíbrio de carga

O exemplo seguinte pressupõe que já tem uma configuração de encaminhamento básica, incluindo um mapa de URLs denominado my-url-map.

  • Primeiro, cria um correspondente de caminho para este mapa de URLs. A correspondência de caminhos é simples. Quando é usado, é resolvido para td-sd-demo-service, que criou no passo anterior.
  • Em seguida, adiciona uma regra de anfitrião ao mapa de URLs. Esta regra de anfitrião faz com que o matcher de caminho seja usado se um pedido especificar o nome do anfitrião myservice.example.com.
  1. Crie um matcher de caminho simples que aponte para o seu serviço de back-end.

    gcloud compute url-maps add-path-matcher my-url-map \
     --global \
     --default-service td-sd-demo-service \
     --path-matcher-name my-path-matcher
    
  2. Mapeie o serviço de back-end para uma nova regra de anfitrião no mapa de URLs existente.

    gcloud compute url-maps add-host-rule my-url-map \
     --global \
     --path-matcher-name=my-path-matcher \
     --hosts=myservice.example.com
    

Anexe o mesmo serviço de várias regiões

O Cloud Service Mesh permite-lhe associar vários serviços do Service Directory ao mesmo serviço de back-end. Por exemplo, pode ter dois serviços do Service Directory, cada um idêntico, mas com pontos finais em diferentes Google Cloud regiões ou zonas. Por outras palavras, um único serviço de back-end global pode ter duas associações de serviços globais, com uma a apontar para um serviço em us-east1 e a outra a apontar para um serviço em us-west1.

  1. Crie um serviço de back-end para o seu serviço do Service Directory importado.

    gcloud compute backend-services create td-sd-demo-service \
     --global \
     --load-balancing-scheme=INTERNAL_SELF_MANAGED
    
  2. Crie uma associação de serviços ao serviço do Service Directory em us-east1.

    gcloud beta network-services service-bindings create us-east1-binding \
     --location global \
     --service-directory-region us-east1 \
     --service-directory-namespace my-namespace \
     --service-directory-service my-service \
    
  3. Crie uma associação de serviços ao serviço do Service Directory em us-west1.

    gcloud beta network-services service-bindings create us-west1-binding \
     --location global
     --service-directory-region us-west1 \
     --service-directory-namespace my-namespace \
     --service-directory-service my-service \
    
  4. Vincule os serviços us-east1 e us-west1 ao serviço de back-end.

    gcloud compute backend-services update td-sd-demo-service \
      --global \
      --service-bindings us-east1-binding,us-west1-binding
    

Aplique políticas de gestão de tráfego avançadas

Na secção anterior, usou o Cloud Service Mesh para configurar políticas de encaminhamento contra um serviço do Service Directory existente. Pode aplicar este padrão a cenários de gestão de tráfego mais avançados.

Considere este cenário. Tem um serviço de teste existente que está fora da malha do Cloud Service Mesh. O serviço de teste é um back-end para um balanceador de carga de aplicações interno. Quer repetir algum tráfego de produção originário na malha do Cloud Service Mesh para este serviço externo. O Cloud Service Mesh pode fazê-lo através do RequestMirrorPolicy, que pode enviar tráfego para outro serviço de back-end quando o pedido é processado. Este processo também é denominado duplicação de um pedido e permite-lhe examinar o tráfego sem afetar os seus serviços de produção.

Pode permitir que os clientes do Envoy reflitam o tráfego para um serviço de teste adicionando ou removendo manualmente o ponto final do serviço de teste na malha do Cloud Service Mesh. No entanto, o processo é mais simples quando usa a integração do diretório de serviços.

Usar o Service Directory para a deteção de serviços com replicação.
Usar o Service Directory para a deteção de serviços com espelhamento(clique para aumentar)

Neste exemplo, começa por direcionar um serviço de back-end para o registo do Service Directory do serviço de teste de pagamentos. Em seguida, adiciona uma política de replicação de pedidos ao serviço na Cloud Service Mesh.

  1. Crie um serviço de back-end para a política de replicação de pedidos.

    gcloud compute backend-services create payments-test-bes \
     --global \
     --load-balancing-scheme=INTERNAL_SELF_MANAGED
    
  2. Crie uma associação de serviços que referencie um serviço do Service Directory.

    gcloud beta network-services service-bindings create my-sd-binding \
     --location global \
     --service-directory-region us-east1 \
     --service-directory-namespace my-namespace \
     --service-directory-service my-service \
    
  3. Vincule o serviço do Service Directory ao serviço de back-end de teste.

    gcloud beta compute backend-services update payments-test-bes \
     --global \
     --service-bindings my-sd-binding
    
  4. Edite o mapa de URLs para refletir os pedidos para o serviço de teste.

    gcloud compute url-maps edit my-url-map \
      --region=global
    
  5. Depois de a configuração do mapa de URLs ser carregada num editor, adicione a política de replicação de pedidos para replicar pedidos para o serviço do diretório de serviços existente.

    defaultService: my-project/global/default-service
       hostRules:
        - hosts:
          - '*'
          pathMatcher: path-matcher-one
       pathMatchers:
        - defaultService: my-project/global/default-service
         name: path-matcher-one
         pathRules:
          - paths:
            - /payments/
            service: my-project/global/default-service
            requestMirrorPolicy:
              backendService: myproject/global/payments-test-bes
    

Remova uma associação de serviço de um serviço de back-end

Para remover uma vinculação de serviço do serviço de back-end, transmita uma nova lista de vinculações de serviço para o comando gcloud compute backend-services update. A nova lista não pode incluir a associação de serviços que quer eliminar:

  • Para remover todas as associações de serviços, defina a flag --no-service-bindings.
  • Para remover uma ou mais associações de serviços: transmita uma nova lista de associações de serviços que omita as associações de serviços que quer remover para a flag --service-bindings.

Adicione ou remova associações de serviços

O comando bind-service adiciona uma associação de serviços ao conjunto de associações de serviços existentes no serviço de back-end.

gcloud compute backend-services bind-service BACKEND_SERVICE_NAME \
  --service-binding-name SERVICE_BINDING_URL \
  --global

O comando unbind-service remove uma associação de serviço do conjunto de associações de serviço existentes no serviço de back-end.

gcloud compute backend-services unbind-service BACKEND_SERVICE_NAME \
  --service-binding-name SERVICE_BINDING_URL \
  --global

Os comandos bind-service e unbind-service são construções da CLI do Google Cloud. Não são construções ao nível da API.

O que se segue?