Cloud Service Mesh com grupos de endpoints de rede de conectividade híbrida

O Cloud Service Mesh oferece suporte a ambientes que vão além do Google Cloud, incluindo data centers no local e outras nuvens públicas conectividade híbrida para alcançar.

Configure o Cloud Service Mesh para que sua malha de serviço possa enviar tráfego para que estão fora do Google Cloud. Esses endpoints incluem o seguinte:

  • Balanceadores de carga locais.
  • Aplicativos de servidor em uma instância de máquina virtual (VM) em outra nuvem.
  • Qualquer outro destino com acesso por meio da conectividade híbrida e com um endereço IP e uma porta.

Basta adicionar o endereço IP e a porta de cada endpoint a um grupo de endpoints de rede (NEG, na sigla em inglês) de conectividade híbrida. Os NEGs de conectividade híbrida são do tipo NON_GCP_PRIVATE_IP_PORT.

O suporte do Cloud Service Mesh para serviços locais e de várias nuvens permite fazer o seguinte:

  • Rotear o tráfego globalmente, incluindo os endpoints de serviços locais e de várias nuvens.
  • Leve os benefícios do Cloud Service Mesh e da malha de serviço, incluindo recursos como descoberta de serviços e gerenciamento avançado de tráfego, aos serviços em execução na infraestrutura atual fora do Google Cloud.
  • Combine os recursos do Cloud Service Mesh com o Cloud Load Balancing para levar os serviços de rede do Google Cloud para vários ambientes.

Os NEGs de conectividade híbrida (NEGs NON_GCP_PRIVATE_IP_PORT) não são compatíveis com clientes gRPC sem proxy.

Casos de uso

O Cloud Service Mesh pode configurar redes em serviços baseados em VM e em contêineres em vários ambientes, incluindo:

  • Google Cloud
  • Data centers locais.
  • Outras nuvens públicas

Rotear o tráfego da malha para um local ou outra nuvem

O caso de uso mais simples deste recurso é o roteamento de tráfego. Seu aplicativo está executando um proxy Envoy do Cloud Service Mesh. O Cloud Service Mesh informa o cliente sobre seus serviços e os endpoints de cada serviço.

Como rotear o tráfego da malha para um local ou outra nuvem.
Como rotear o tráfego da malha para um local ou outra nuvem (clique para ampliar)

No diagrama anterior, quando seu aplicativo envia uma solicitação para o serviço on-prem, o cliente do Cloud Service Mesh inspeciona a solicitação de saída e atualiza o destino dela. O destino é definido como um endpoint associado ao serviço on-prem (neste caso, 10.2.0.1). A solicitação passa pelo Cloud VPN ou pelo Cloud Interconnect em direção ao destino pretendido.

Se precisar adicionar mais endpoints, atualize o Cloud Service Mesh para adicioná-los a seu serviço. Não é necessário alterar o código do aplicativo.

Migrar um serviço local atual para o Google Cloud

O envio de tráfego para um endpoint que não seja do Google Cloud permite rotear o tráfego para outros ambientes. É possível combinar esse recurso com o gerenciamento de tráfego avançado para migrar serviços entre ambientes.

Como migrar de um local para o Google Cloud.
Como migrar de um local para o Google Cloud (clique para ampliar)

O diagrama anterior estende o padrão anterior. Em vez de configurar o Cloud Service Mesh para enviar todo o tráfego ao serviço on-prem, configure-o para usar a divisão de tráfego baseada em peso para dividir o tráfego em dois serviços.

A divisão de tráfego permite que você comece enviando 0% para o serviço cloud e 100% para o serviço on-prem. Em seguida, é possível aumentar gradualmente a proporção do tráfego enviado para o serviço cloud. Ao final, você terá enviado 100% do tráfego para o serviço cloud e poderá desativar o serviço on-prem.

Serviços do Edge de rede do Google Cloud para implantações no local e em várias nuvens

Por fim, é possível combinar essa funcionalidade com as soluções de rede atuais do Google Cloud. O Google Cloud oferece uma ampla variedade de serviços de rede, como o balanceamento de carga externo global com o Google Cloud Armor para proteção contra ataque distribuído de negação de serviço (DDoS, na sigla em inglês), que pode ser usado com o Cloud Service Mesh para trazer novos recursos aos serviços locais ou com várias nuvens. O melhor de tudo é que você não precisa expor esses serviços no local ou em várias nuvens à Internet pública.

Implantações que abrangem vários ambientes.
Implantações abrangendo vários ambientes (clique para ampliar)

No diagrama anterior, o tráfego de clientes na Internet pública entra na rede do Google Cloud de um balanceador de carga do Google Cloud, como nosso balanceador de carga de aplicativo externo global. Quando o tráfego chega ao balanceador de carga, é possível aplicar serviços de borda de rede, como a proteção contra DDoS do Google Cloud Armor ou a autenticação do usuário do Identity-Aware Proxy (IAP). Para mais informações, consulte Serviços de borda de rede para implantações em vários ambientes.

Depois que você aplica esses serviços, o tráfego faz uma breve parada Google Cloud, onde um aplicativo ou proxy autônomo (configurado pelo o Cloud Service Mesh) encaminha o tráfego pelo Cloud VPN ou Cloud Interconnect ao serviço no local.

Recursos e arquitetura do Google Cloud

Nesta seção, você encontra informações básicas sobre os serviços do Google Cloud, recursos que podem ser usados para fornecer uma malha de serviço gerenciado pelo Cloud Service Mesh para ambientes no local e multicloud.

O diagrama a seguir mostra os recursos do Google Cloud que permitem suporte a serviços no local e multicloud para o Cloud Service Mesh. O principal recurso é o NEG e os endpoints da rede dele. Os outros recursos são aqueles configurados como parte de uma configuração padrão da malha de serviço do Cloud. Para simplificar, o diagrama não mostra opções como vários serviços de back-end globais.

Recursos do Compute Engine para serviços locais e em várias nuvens.
Recursos do Compute Engine para serviços locais e com várias nuvens (clique para ampliar)

Ao configurar o Cloud Service Mesh, você usa a API de serviços de back-end global para criar serviços. Um serviço é uma construção lógica com a seguinte combinação:

  1. Políticas a serem aplicadas quando um cliente tenta enviar tráfego para o serviço.
  2. Um ou mais back-ends ou endpoints que processam o tráfego destinado ao serviço.

Serviços locais e em várias nuvens são como qualquer outro serviço que o Cloud Service Mesh configura. A principal diferença é que você usa um NEG de conectividade híbrida para configurar os endpoints desses serviços. Esses NEGs têm o tipo de endpoint da rede definido como NON_GCP_PRIVATE_IP_PORT. Os endpoints adicionados a NEGs de conectividade híbrida precisam ser combinações IP:port válidas que seus clientes podem alcançar, por exemplo, por meio de conectividade híbrida, como o Cloud VPN ou o Cloud Interconnect.

Cada NEG tem um tipo de endpoint de rede e só pode conter endpoints de rede do mesmo tipo. Esse tipo determina o seguinte:

  • O destino a que seus serviços podem enviar tráfego.
  • Comportamento de verificação de integridade.

Ao criar o NEG, configure-o da seguinte maneira para que seja possível enviar tráfego a um destino local ou de várias nuvens.

  • Defina o tipo de endpoint da rede como NON_GCP_PRIVATE_IP_PORT. Isso representa um endereço IP acessível. Se esse endereço IP for local ou em outro provedor de nuvem, será preciso que ele possa ser acessado pelo Google Cloud usando conectividade híbrida, como a conectividade fornecida pelo Cloud VPN ou pelo Cloud Interconnect.
  • Especifique uma zona do Google Cloud que minimize a distância geográfica entre o Google Cloud e seu ambiente local ou de várias nuvens. Por exemplo, se você estiver hospedando um serviço em um ambiente local em Frankfurt, na Alemanha, será possível especificar a zona europe-west3-a do Google Cloud ao criar o NEG.

O comportamento de verificação de integridade para endpoints da rede desse tipo é diferente do comportamento de outros tipos de endpoints de rede. Enquanto outros tipos de endpoints de rede usam o sistema de verificação de integridade centralizado do Google Cloud, os endpoints de rede NON_GCP_PRIVATE_IP_PORT usam o mecanismo de verificação de integridade distribuída do Envoy. Para mais detalhes, consulte a seção Limitações e outras considerações.

Considerações sobre conectividade e rede

Seus clientes do Cloud Service Mesh, como proxies Envoy, precisam conseguir se conectar para o Cloud Service Mesh em trafficdirector.googleapis.com:443. Se você perder a conectividade com o plano de controle do Cloud Service Mesh, acontecerá o seguinte:

  • Os clientes atuais do Cloud Service Mesh não podem receber atualizações de configuração do Cloud Service Mesh. A empresa continua a operar com base na configuração atual.
  • Os novos clientes do Cloud Service Mesh não podem se conectar a ele. Eles não poderão usar a malha de serviço até que a conectividade seja restabelecida.

Se você quiser enviar tráfego entre o Google Cloud e os ambientes locais ou de várias nuvens, será preciso que eles estejam conectados por meio da conectividade híbrida. Recomendamos uma conexão de alta disponibilidade, ativada pelo Cloud VPN ou pelo Cloud Interconnect.

Os endereços IP locais, de outra nuvem e de sub-rede do Google Cloud e os intervalos de endereços IP não devem se sobrepor.

Limitações e outras considerações

Veja a seguir as limitações do uso de NEGs de conectividade híbrida.

Como definir proxyBind

Só é possível definir o valor de proxyBind quando você cria um targetHttpProxy. Não é possível atualizar um targetHttpProxy existente.

Conectividade e interrupção na conectividade

Para detalhes sobre os requisitos e limitações de conectividade, consulte a seção Considerações sobre conectividade e rede.

Tipos de back-end mistos

Um serviço de back-end pode ter back-ends de VM ou NEG. Se um serviço de back-end tiver back-ends de NEG, todos eles precisarão conter o mesmo tipo de endpoint da rede. Não é possível ter um serviço de back-end com vários NEGs, cada um com diferentes tipos de endpoint.

Um mapa de URL pode ter regras de host que são resolvidas para serviços de back-end diferentes. É possível ter um serviço de back-end somente com NEGs de conectividade híbrida (com endpoints locais) e um serviço de back-end com NEGs independentes (com endpoints do GKE). O mapa de URL pode conter regras, por exemplo, divisão de tráfego baseada em peso, que divide o tráfego em cada um desses serviços de back-end.

Como usar um NEG com endpoints do tipo NON_GCP_PRIVATE_IP_PORT com back-ends do Google Cloud

É possível criar um serviço de back-end com um NEG de conectividade híbrida que aponta para back-ends no Google Cloud. No entanto, não recomendamos esse padrão porque os NEGs de conectividade híbrida não se beneficiam da verificação de integridade centralizada. Para uma explicação sobre a verificação de integridade centralizada e a verificação de integridade distribuída, consulte a seção Verificação de integridade.

Registro do endpoint

Se você quiser adicionar um endpoint a um NEG, será necessário atualizar o NEG. Isso pode ser feito manualmente ou pode ser automatizado usando as APIs NEG REST do Google Cloud ou a CLI do Google Cloud.

Quando uma nova instância de um serviço é iniciada, é possível usar as APIs do Google Cloud para registrar a instância com o NEG configurado. Ao usar grupos de instâncias gerenciadas do Compute Engine (MIGs) ou GKE (no Google Cloud), o controlador de MIG ou NEG processa automaticamente o registro de endpoints, respectivamente.

Verificação de integridade

Quando você usa NEGs de conectividade híbrida, o comportamento da verificação de integridade é diferente do comportamento padrão de verificação de integridade centralizada das seguintes maneiras:

  • Para endpoints de rede do tipo NON_GCP_PRIVATE_IP_PORT, o Cloud Service Mesh configura os clientes para usar o plano de dados no processo de verificação de integridade. Para evitar o envio de solicitações para back-ends não íntegros, as instâncias do Envoy executam as próprias verificações de integridade e usam os próprios mecanismos.
  • Como o plano de dados gerencia as verificações de integridade, não é possível usar o Console do Google Cloud, a API ou a Google Cloud CLI para recuperar o status da verificação de integridade.

Na prática, usar NON_GCP_PRIVATE_IP_PORT significa o seguinte:

  • Como os clientes do Cloud Service Mesh processam a verificação de integridade de maneira distribuída, é possível notar um aumento no tráfego de rede devido à verificação de integridade. O aumento depende do número de clientes da Cloud Service Mesh e do número de endpoints necessário a cada cliente para que seja feita a verificação de integridade. Por exemplo:
    • Quando você adiciona outro endpoint a um NEG de conectividade híbrida, os clientes do Cloud Service Mesh podem começar a verificar a integridade dos endpoints em NEGs de conectividade híbrida.
    • Quando você adiciona outra instância à malha de serviço, como uma instância de VM que executa o código do aplicativo e um cliente do Cloud Service Mesh, a nova instância pode começar a verificar a integridade dos endpoints em NEGs de conectividade híbrida.
    • Por causa das verificações de integridade, o tráfego de rede aumenta a uma taxa quadrática (O(n^2)).

Rede VPC

Uma malha de serviço é identificada pelo respectivo nome de rede de nuvem privada virtual (VPC). Os clientes do Cloud Service Mesh recebem a configuração do Cloud Service Mesh com base na rede VPC especificada no bootstrap configuração do Terraform. Consequentemente, mesmo que sua malha esteja completamente fora de um data center do Google Cloud, você precisa fornecer um nome de rede VPC válido na sua configuração de inicialização.

Conta de serviço

No Google Cloud, o bootstrap padrão do Envoy é configurado para ler informações da conta de serviço de um dos ambientes de implantação do Compute Engine e do GKE. Ao executar fora do Google Cloud, você precisa especificar explicitamente uma conta de serviço, um nome de rede e um número de projeto em sua inicialização do Envoy. Essa conta de serviço precisa ter permissões suficientes para se conectar à API Cloud Service Mesh.

A seguir