Cloud Service Mesh com grupos de pontos finais de rede da Internet

Pode configurar a Cloud Service Mesh para usar grupos de pontos finais de rede (NEGs) da Internet do tipo INTERNET_FQDN_PORT. O serviço externo é representado pelo respetivo nome de domínio totalmente qualificado (FQDN) e número da porta no NEG. O NEG só pode conter um par FQDN:Port, e o serviço de back-end só pode conter um NEG deste tipo. O FQDN é resolvido através da ordem de resolução de nomes da rede de nuvem virtual privada (VPC) subjacente.

Expanda a malha de serviços do Cloud Service Mesh com back-ends FQDN

A malha de serviços do Cloud Service Mesh pode encaminhar o tráfego para serviços privados que são acessíveis através da conectividade híbrida, incluindo serviços no local, multinuvem e de Internet com nomes. O serviço remoto é referenciado pelo respetivo FQDN.

Estender a malha de serviço do Cloud Service Mesh a localizações no local ou em várias nuvens através de back-ends FQDN com conectividade híbrida.
Extender a malha de serviço do Cloud Service Mesh a localizações no local ou em várias nuvens através de back-ends FQDN com conetividade híbrida (clique para aumentar)

Também pode encaminhar tráfego para serviços acessíveis através da Internet pública.

Estender a malha de serviços do Cloud Service Mesh a um serviço de Internet através de back-ends FQDN.
Estender a malha de serviço do Cloud Service Mesh a um serviço de Internet usando back-ends FQDN (clique para ampliar)

Google Cloud recursos e arquitetura

Esta secção descreve os recursos e a arquitetura para configurar a Cloud Service Mesh com um NEG da Internet.

INTERNET_FQDN_PORT grupo de pontos finais da rede

Para encaminhar tráfego para um serviço externo referenciado pelo respetivo FQDN, use o NEG de Internet global do tipo INTERNET_FQDN_PORT. O NEG contém o FQDN do seu serviço e o respetivo número da porta. O Cloud Service Mesh programa o FQDN em proxies Envoy através da configuração xDS.

O Cloud Service Mesh em si não garante a resolução de nomes nem a acessibilidade dos pontos finais remotos. O FQDN tem de ser resolvível pela ordem de resolução de nomes da rede VPC à qual os proxies do Envoy estão anexados, e os pontos finais resolvidos têm de ser acessíveis a partir dos proxies do Envoy.

Verificações de funcionamento

O comportamento de verificação do estado de funcionamento dos pontos finais de rede do tipo INTERNET_FQDN_PORT difere do comportamento de verificação do estado de funcionamento de outros tipos de pontos finais de rede usados com o Cloud Load Balancing e o Cloud Service Mesh. Embora a maioria dos outros tipos de pontos finais de rede use o sistema de verificação do estado de funcionamento centralizado da Google, os NEGs usados para pontos finais em ambientes de várias nuvens (INTERNET_FQDN_PORT e NON_GCP_PRIVATE_IP_PORT) usam o mecanismo de verificação do estado de funcionamento distribuído do Envoy. Google Cloud

O Envoy suporta os seguintes protocolos para a verificação do estado de funcionamento:

  • HTTP
  • HTTPS
  • HTTP/2
  • TCP

Configura as verificações de estado através das APIs Compute Engine.

Considerações sobre o DNS

Existem duas considerações distintas relativamente ao DNS:

  • O servidor DNS que aloja os registos de recursos do seu serviço externo.
  • O modo com o qual o proxy Envoy está configurado para usar o DNS para a gestão de ligações.

Servidor Cloud DNS

Pode criar uma zona privada gerida do Cloud DNS para alojar os registos de DNS no seu projeto. Google Cloud Também pode usar outras funcionalidades do Cloud DNS, como as zonas de encaminhamento, para obter registos de um servidor DNS no local.

Modo DNS do Envoy

O modo DNS do Envoy, também denominado deteção de serviços, especifica como o proxy do Envoy usa registos DNS para gerir ligações de saída. O Cloud Service Mesh configura o Envoy para usar o modo DNS rigoroso. O modo DNS rigoroso ativa o equilíbrio de carga para todos os pontos finais resolvidos. Respeita o estado da verificação de integridade e esgota as ligações aos pontos finais que não estão em bom estado ou que já não são resolvidos através do DNS. Não pode alterar este modo.

Para mais informações sobre a deteção de serviços, consulte a documentação do Envoy.

Conetividade e encaminhamento

Se estiver a encaminhar tráfego para um serviço privado, seguem-se os requisitos para a conetividade de rede subjacente:

  • A conetividade híbrida entre a rede VPC e o centro de dados no local ou a nuvem pública de terceiros é estabelecida através do Cloud VPN ou do Cloud Interconnect.
  • As regras e as rotas da firewall da VPC estão configuradas corretamente para estabelecer acessibilidade bidirecional do Envoy aos seus pontos finais de serviço privado e, se aplicável, ao servidor DNS no local.
  • Para uma comutação por falha de alta disponibilidade regional bem-sucedida, o encaminhamento dinâmico global tem de estar ativado. Para mais detalhes, consulte o modo de encaminhamento dinâmico.

Se estiver a encaminhar tráfego para um serviço externo acessível na Internet, seguem-se os requisitos:

  • As instâncias de máquinas virtuais (VM) do cliente na rede VPC têm de ter um endereço IP externo ou o Cloud NAT.
  • A rota predefinida tem de estar presente para o tráfego de saída para a Internet.

Em ambos os casos anteriores, o tráfego usa o encaminhamento da rede VPC.

Segurança

Os backends FQDN são compatíveis com as funcionalidades de segurança da Cloud Service Mesh e as APIs. Nas ligações de saída para o seu serviço externo, pode configurar o FQDN no cabeçalho SNI através das políticas TLS do cliente.

Limitações e considerações

  • Os NEGs de Internet do tipo INTERNET_IP_PORT não são suportados com o Cloud Service Mesh.
  • A versão 1.15.0 ou posterior do Envoy é necessária com back-ends FQDN.
  • Use a Google Cloud CLI ou as APIs REST para configurar a Cloud Service Mesh. A configuração integral através da consola Google Cloud não é suportada.
  • Os back-ends FQDN só são suportados com o Envoy. O gRPC sem proxy não é suportado.

  • Quando usa o tipo NEG INTERNET_FQDN_PORT com a malha de serviços na nuvem, as verificações de estado dos pontos finais remotos são feitas através do mecanismo de verificação de estado distribuído do Envoy. Sempre que é adicionado um novo ponto final remoto, todos os proxies Envoy começam a verificar o respetivo estado de funcionamento de forma independente.

    Da mesma forma, quando um novo proxy Envoy é adicionado à malha, começa a verificar todos os pontos finais remotos. Por conseguinte, dependendo do número de proxies Envoy e pontos finais remotos na sua implementação, a malha de verificação do estado resultante pode causar um tráfego de rede significativo e uma carga indevida nos pontos finais remotos. Pode optar por não configurar as verificações de funcionamento.

  • O estado da verificação de saúde não está visível na Google Cloud consola para back-ends FQDN.

  • A verificação do estado de funcionamento que usa os protocolos UDP, SSL e gRPC não é suportada.

  • As seguintes opções de verificação de estado não são suportadas:

    • Verificação do estado de funcionamento de HTTP/HTTP2/HTTPS
      • --proxy-header
      • --response
    • Verificação de funcionamento TCP
      • --proxy-header
      • --request
      • --response

O que se segue?