Cloud Service Mesh com grupos de pontos finais da rede de conetividade híbrida

O Cloud Service Mesh suporta ambientes que se estendem para além do Google Cloud, incluindo centros de dados nas instalações e outras nuvens públicas que pode usar a conetividade híbrida para alcançar. Google Cloud

Configura o Cloud Service Mesh para que a sua malha de serviços possa enviar tráfego para pontos finais que estão fora de Google Cloud. Estes pontos finais incluem o seguinte:

  • Balanceadores de carga no local.
  • Aplicações de servidor numa instância de máquina virtual (VM) noutra nuvem.
  • Qualquer outro destino que possa alcançar com a conetividade híbrida e que possa ser alcançado com um endereço IP e uma porta.

Adiciona o endereço IP e a porta de cada ponto final a um grupo de pontos finais (NEG) de rede de conetividade híbrida. Os NEGs de conetividade híbrida são do tipo NON_GCP_PRIVATE_IP_PORT.

O suporte do Cloud Service Mesh para serviços nas instalações e de várias nuvens permite-lhe fazer o seguinte:

  • Encaminhe o tráfego globalmente, incluindo para os pontos finais de serviços nas instalações e em várias nuvens.
  • Usufrua das vantagens da Cloud Service Mesh e da service mesh, incluindo capacidades como a deteção de serviços e a gestão avançada de tráfego, nos serviços executados na sua infraestrutura existente fora do Google Cloud.
  • Combine as capacidades do Cloud Service Mesh com o Cloud Load Balancing para oferecer Google Cloud serviços de rede a vários ambientes.

Os NEGs de conetividade híbrida (NEGs NON_GCP_PRIVATE_IP_PORT) não são suportados com clientes gRPC sem proxy.

Exemplos de utilização

A malha de serviços na nuvem pode configurar a rede entre serviços baseados em VMs e contentores em vários ambientes, incluindo:

  • Google Cloud
  • Centros de dados nas instalações
  • Outras nuvens públicas

Encaminhe o tráfego de malha para uma localização nas instalações ou outra nuvem

O exemplo de utilização mais simples desta funcionalidade é o planeamento de trajeto. A sua aplicação está a executar um proxy Envoy do Cloud Service Mesh . A malha de serviços na nuvem informa o cliente sobre os seus serviços e os pontos finais de cada serviço.

Encaminhar tráfego de malha para uma localização nas instalações ou outra nuvem.
Encaminhamento do tráfego de malha para uma localização no local ou outra nuvem (clique para aumentar)

No diagrama anterior, quando a sua aplicação envia um pedido para o serviço on-prem, o cliente da malha de serviços na nuvem inspeciona o pedido de saída e atualiza o respetivo destino. O destino é definido como um ponto final associado ao serviço on-prem (neste caso, 10.2.0.1). Em seguida, o pedido é transmitido através da Cloud VPN ou do Cloud Interconnect para o destino pretendido.

Se precisar de adicionar mais pontos finais, atualize o Cloud Service Mesh para os adicionar ao seu serviço. Não precisa de alterar o código da aplicação.

Migre um serviço no local existente para Google Cloud

O envio de tráfego para um ponto final não pertencente aoGoogle Cloud permite-lhe encaminhar tráfego para outros ambientes. Pode combinar esta capacidade com a gestão avançada de tráfego para migrar serviços entre ambientes.

Migrar de uma localização no local para Google Cloud.
Migrar de uma localização no local para Google Cloud (clique para aumentar)

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

A divisão do tráfego permite-lhe começar por enviar 0% do tráfego para o serviço cloud e 100% para o serviço on-prem. Em seguida, pode aumentar gradualmente a proporção de tráfego enviado para o serviço cloud. Eventualmente, envia 100% do tráfego para o serviço cloud e pode desativar o serviço on-prem.

Google Cloud serviços de limite de rede para implementações nas instalações e de várias nuvens

Por último, pode combinar esta funcionalidade com as soluções de rede existentes do Google Cloud.O Google Cloud oferece uma vasta gama de serviços de rede, como o equilíbrio de carga externo global com o Google Cloud Armor para proteção contra negação de serviço distribuída (DDoS), que pode usar com a malha de serviços na nuvem para oferecer novas capacidades aos seus serviços no local ou em várias nuvens. O melhor de tudo é que não precisa de expor estes serviços no local ou em várias nuvens à Internet pública.

Implementações que abrangem vários ambientes.
Implementações que abrangem vários ambientes (clique para aumentar)

No diagrama anterior, o tráfego de clientes na Internet pública entra na rede deGoogle Clouda partir de um Google Cloud equilibrador de carga, como o nosso equilibrador de carga de aplicações externo global. Quando o tráfego atinge o balanceador de carga, pode aplicar serviços de limite de rede, como a proteção contra DDoS do Cloud Armor ou a autenticação de utilizadores do Identity-Aware Proxy (IAP). Para mais informações, consulte o artigo Serviços de limite de rede para implementações em vários ambientes.

Depois de aplicar estes serviços, o tráfego faz uma breve paragem emGoogle Cloud, onde uma aplicação ou um proxy autónomo (configurado pela Cloud Service Mesh) encaminha o tráfego através da Cloud VPN ou da Cloud Interconnect para o seu serviço no local.

Google Cloud recursos e arquitetura

Esta secção fornece informações gerais sobre os Google Cloud recursos que pode usar para fornecer uma malha de serviços gerida pelo Cloud Service Mesh para ambientes no local e multinuvem.

O diagrama seguinte representa os recursos Google Cloud que permitem o apoio técnico de serviços no local e em várias nuvens para a malha de serviços na nuvem. O recurso principal é o NEG e os respetivos pontos finais de rede. Os outros recursos são os recursos que configura como parte de uma configuração padrão da Cloud Service Mesh. 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 nas instalações e de várias nuvens.
Recursos do Compute Engine para serviços no local e multinuvem (clique para aumentar)

Quando configura a Cloud Service Mesh, usa o recurso da API de serviços de back-end globais para criar serviços. Um serviço é uma construção lógica que combina o seguinte:

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

Os serviços no local e multinuvem são como qualquer outro serviço que o Cloud Service Mesh configura. A principal diferença é que usa um NEG de conetividade híbrida para configurar os pontos finais destes serviços. Estes NEGs têm o tipo de ponto final de rede definido como NON_GCP_PRIVATE_IP_PORT. Os pontos finais que adiciona aos NEGs de conetividade híbrida têm de ser combinações válidas que os seus clientes podem alcançar, por exemplo, através da conetividade híbrida, como o Cloud VPN ou o Cloud Interconnect.IP:port

Cada NEG tem um tipo de ponto final de rede e só pode conter pontos finais de rede do mesmo tipo. Este tipo determina o seguinte:

  • O destino para o qual os seus serviços podem enviar tráfego.
  • Comportamento de verificação de funcionamento.

Quando criar o NEG, configure-o da seguinte forma para poder enviar tráfego para um destino nas instalações ou de várias nuvens.

  • Defina o tipo de ponto final de rede como NON_GCP_PRIVATE_IP_PORT. Isto representa um endereço IP acessível. Se este endereço IP estiver nas instalações ou noutro fornecedor de nuvem, tem de estar acessível a partir do Google Cloud através de conetividade híbrida, como a conetividade fornecida pelo Cloud VPN ou pelo Cloud Interconnect. Google Cloud
  • Especifique uma Google Cloud zona que minimize a distância geográfica entre Google Cloud e o seu ambiente nas instalações ou em várias nuvens. Por exemplo, se estiver a alojar um serviço num ambiente no local em Frankfurt, na Alemanha, pode especificar a zona europe-west3-a Google Cloud quando criar o NEG.

O comportamento de verificação do estado de funcionamento dos pontos finais da rede deste tipo difere do comportamento de verificação do estado de funcionamento de outros tipos de pontos finais da rede. Embora outros tipos de pontos finais de rede usem o sistema de verificação do estado de funcionamento centralizado do Google Cloud, os pontos finais de rede NON_GCP_PRIVATE_IP_PORT usam o mecanismo de verificação do estado de funcionamento distribuído do Envoy. Para mais detalhes, consulte a secção Limitações e outras considerações.

Considerações sobre conetividade e trabalhar na rede

Os seus clientes do Cloud Service Mesh, como os proxies Envoy, têm de conseguir estabelecer ligação ao Cloud Service Mesh em trafficdirector.googleapis.com:443. Se perder a conetividade com o plano de controlo do Cloud Service Mesh, acontece o seguinte:

  • Os clientes existentes do Cloud Service Mesh não podem receber atualizações de configuração do Cloud Service Mesh. Continuam a funcionar com base na respetiva configuração atual.
  • Os novos clientes do Cloud Service Mesh não conseguem estabelecer ligação ao Cloud Service Mesh. Não podem usar a malha de serviços até que a conetividade seja restabelecida.

Se quiser enviar tráfego entre o Google Cloud e os ambientes nas instalações ou em várias nuvens, os ambientes têm de estar ligados através da conetividade híbrida. Recomendamos uma ligação de alta disponibilidade ativada pelo Cloud VPN ou Cloud Interconnect.

Os endereços IP locais, de outras nuvens e Google Cloud de sub-redes, bem como os intervalos de endereços IP, não podem sobrepor-se.

Limitações e outras considerações

Seguem-se as limitações da utilização de NEGs de conetividade híbrida.

A definir proxyBind

Só pode definir o valor de proxyBind quando cria um targetHttpProxy. Não pode atualizar um targetHttpProxy existente.

Conetividade e interrupção da conetividade

Para ver detalhes sobre os requisitos e as limitações de conetividade, consulte a secção Considerações sobre conetividade 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 os NEGs têm de conter o mesmo tipo de ponto final de rede. Não pode ter um serviço de back-end com vários NEGs, cada um com diferentes tipos de pontos finais.

Um mapa de URLs pode ter regras de anfitrião que são resolvidas para diferentes serviços de back-end. Pode ter um serviço de back-end com NEGs de conetividade híbrida apenas (com pontos finais no local) e um serviço de back-end com NEGs autónomos (com pontos finais do GKE). O mapa de URLs pode conter regras, por exemplo, a divisão de tráfego com base na ponderação, que divide o tráfego entre cada um destes serviços de back-end.

Usar um NEG com pontos finais do tipo NON_GCP_PRIVATE_IP_PORT com Google Cloud back-ends

É possível criar um serviço de back-end com um NEG de conetividade híbrida que aponte para back-ends no Google Cloud. No entanto, não recomendamos este padrão porque os NEGs de conetividade híbrida não beneficiam da verificação de estado centralizada. Para uma explicação da verificação de funcionamento centralizada e da verificação de funcionamento distribuída, consulte a secção Verificação de funcionamento.

Registo de pontos finais

Se quiser adicionar um ponto final a um NEG, tem de atualizar o NEG. Isto pode ser feito manualmente ou pode ser automatizado através das APIs REST NEG ou da CLI Google Cloud. Google Cloud

Quando uma nova instância de um serviço é iniciada, pode usar as Google Cloud APIs para registar a instância com o NEG que configurou. Quando usa grupos de instâncias geridas (GIGs) do Compute Engine ou o GKE (no Google Cloud), o controlador do GIG ou do NEG processa automaticamente o registo de pontos finais, respetivamente.

Verificação de funcionamento

Quando usa NEGs de conetividade híbrida, o comportamento da verificação do estado de funcionamento difere do comportamento de verificação do estado de funcionamento centralizado padrão das seguintes formas:

  • Para pontos finais de rede do tipo NON_GCP_PRIVATE_IP_PORT, o Cloud Service Mesh configura os respetivos clientes para usar o plano de dados para processar a verificação de estado. Para evitar o envio de pedidos para back-ends em mau estado de funcionamento, as instâncias do Envoy realizam as suas próprias verificações de funcionamento e usam os seus próprios mecanismos.
  • Uma vez que o seu plano de dados processa as verificações de estado, não pode usar a Google Cloud consola, a API nem a CLI Google Cloud para obter o estado da verificação de estado.

Na prática, a utilização de NON_GCP_PRIVATE_IP_PORT significa o seguinte:

  • Uma vez que os clientes da Cloud Service Mesh processam a verificação do estado de funcionamento de forma distribuída, pode observar um aumento no tráfego de rede devido à verificação do estado de funcionamento. O aumento depende do número de clientes do Cloud Service Mesh e do número de pontos finais que cada cliente tem de verificar o estado. Por exemplo:
    • Quando adiciona outro ponto final a um NEG de conetividade híbrida, os clientes existentes do Cloud Service Mesh podem começar a verificar o estado dos pontos finais nos NEGs de conetividade híbrida.
    • Quando adiciona outra instância à sua malha de serviços (por exemplo, uma instância de VM que executa o código da sua aplicação, bem como um cliente da Cloud Service Mesh), a nova instância pode começar a verificar o estado dos pontos finais nos NEGs de conetividade híbrida.
    • O tráfego de rede devido às verificações de funcionamento aumenta a uma taxa quadrática (O(n^2)).

Rede da VPC

Uma malha de serviços é identificada exclusivamente pelo nome da rede da nuvem virtual privada (VPC). Os clientes do Cloud Service Mesh recebem a configuração do Cloud Service Mesh com base na rede VPC especificada na configuração de arranque. Por conseguinte, mesmo que a sua malha esteja totalmente fora de um Google Cloud centro de dados, tem de fornecer um nome de rede VPC válido na sua configuração de arranque.

Conta de serviço

No Google Cloud, a inicialização do Envoy predefinida está configurada para ler informações da conta de serviço a partir de um ou ambos os ambientes de implementação do Compute Engine e do GKE. Quando executado fora do Google Cloud, tem de especificar explicitamente uma conta de serviço, um nome de rede e um número do projeto no seu bootstrap do Envoy. Esta conta de serviço tem de ter autorizações suficientes para estabelecer ligação à API Cloud Service Mesh.

O que se segue?