Tráfego de entrada para sua malha

Uma malha de serviço facilita as comunicações entre os serviços em execução na malha. Mas como pegar o tráfego na malha? Use um gateway para direcionar o tráfego de fora da malha para a malha por um ponto de entrada.

Neste documento, descrevemos como usar o Cloud Load Balancing como um gateway para conseguir tráfego na malha e incluir o seguinte:

  • Considerações de alto nível para o gateway.
  • Uma visão geral das opções quando você seleciona um gateway para sua malha.
  • Recomendações de arquitetura que podem ser aplicadas à topologia do gateway.

Este documento se aplica às APIs de roteamento de serviço do Traffic Director. Depois de concluir as etapas preparatórias, consulte Configuração do Traffic Director para um gateway de entrada, que contém instruções para implantação com um gateway de entrada.

Ao projetar a malha de serviço, considere o tráfego proveniente das seguintes origens:

  • Tráfego originado dentro da malha
  • Tráfego originado fora da sua malha

O tráfego originado dentro da malha sai do plano de dados da malha de serviço para alcançar um back-end ou endpoint associado ao serviço de destino. No entanto, o tráfego originado fora da malha precisa primeiro alcançar o plano de dados da malha de serviço.

No exemplo de tráfego a seguir que se origina dentro da malha, o Traffic Director configura os proxies sidecar. Esses proxies sidecar formam o plano de dados da malha de serviço. Se o Serviço A quiser se comunicar com o Serviço B, ocorrerá o seguinte:

  1. O Serviço A faz uma solicitação ao Serviço B por nome.
  2. Essa solicitação é interceptada e redirecionada para o proxy sidecar do serviço A.
  3. Em seguida, o proxy secundário envia a solicitação para um endpoint associado ao Serviço B.
O plano de dados da malha processa o tráfego interno para a malha de serviço.
O plano de dados da malha processa o tráfego interno que vai à malha de serviço (clique para ampliar)


No exemplo a seguir, o tráfego é originado de fora da malha de serviço e não viaja pelo plano de dados dela.

O plano de dados da malha de serviço não processa tráfego externo que vai à malha de serviço.
O plano de dados da malha de serviço não processa o tráfego externo que vai à malha de serviço (clique para ampliar)

Neste exemplo, o cliente está fora da malha de serviço. Como ele não participa diretamente da malha, o cliente não sabe quais endpoints pertencem a serviços dentro da malha. Em outras palavras, como o cliente não usa um proxy configurado pelo Traffic Director para enviar solicitações de saída, ele não sabe quais pares de porta e endereço IP precisam ser usados ao enviar tráfego para o Serviço A ou Serviço B. Sem essas informações, o cliente não poderá acessar serviços dentro da malha.

Considerações para o gateway

Nesta seção, fornecemos uma visão geral dos problemas a serem considerados ao selecionar um gateway, incluindo os seguintes itens:

  • Como os clientes podem entrar no meu gateway?
  • Que políticas eu quero aplicar ao tráfego que chega ao meu gateway?
  • Como meu gateway distribui o tráfego para os serviços na minha malha?

Permitir que os clientes cheguem ao gateway para a malha

Os clientes, seja na Internet pública, no seu ambiente local ou no Google Cloud, precisam acessar um serviço na malha. Para alcançar um serviço na malha, normalmente é possível usar uma porta e um endereço IP roteáveis de forma pública ou particular que são resolvidos para um gateway. Os clientes fora da malha usam esse endereço IP e porta para enviar solicitações aos serviços da malha pelo gateway.

O Cloud Load Balancing fornece várias opções de balanceamento de carga que podem ser usadas como o gateway da malha. As principais perguntas a serem feitas ao escolher um balanceador de carga do Google Cloud para atuar como o gateway são as seguintes:

  • Meus clientes estão na Internet pública, em um ambiente local ou parte da minha rede de nuvem privada virtual (VPC)?
  • Quais protocolos de comunicação meus clientes usam?

Para ter uma visão geral das opções do Cloud Load Balancing, dependendo da localização do cliente e do protocolo de comunicação, consulte a seção Escolher um gateway para a malha.

Processar tráfego no gateway

Como o gateway fica na borda da malha, entre os clientes que estão fora da malha e os serviços que estão dentro da malha, o gateway é um local natural em que aplicar políticas quando o tráfego entra na malha. Essas políticas incluem:

  • Gerenciamento de tráfego: por exemplo, roteamento, redirecionamentos e transformação da solicitação
  • Segurança: por exemplo, terminação TLS e proteção contra negação de serviço (DDoS, na sigla em inglês) do Google Cloud Armor
  • Armazenamento em cache do Cloud CDN

A seção Escolha um gateway para a malha destaca as políticas relevantes na borda da malha.

Como enviar tráfego do gateway para um serviço na malha

Depois que o gateway aplica políticas ao tráfego de entrada, o gateway decide para onde enviar o tráfego. Para configurar isso, use as políticas de gerenciamento de tráfego e balanceamento de carga. O gateway pode, por exemplo, inspecionar o cabeçalho da solicitação para identificar o serviço da malha que receberá o tráfego. Depois que o gateway identifica o serviço, ele distribui o tráfego para um back-end específico de acordo com uma política de balanceamento de carga.

Na seção Escolher um gateway para a malha, descrevemos os back-ends para os quais um gateway pode enviar tráfego.

Escolher um gateway para a malha

O Google Cloud oferece uma ampla variedade de balanceadores de carga que podem atuar como o gateway para a malha. Nesta seção, discutimos a seleção de um gateway, comparando as seguintes opções com as dimensões relevantes para o padrão do gateway:

Nesta seção, nos referimos aos gateways de first-level e first-level. Esses termos são usados para descrever o uso de um ou dois gateways para processar o tráfego de entrada na malha.

Talvez você precise de apenas um nível, um único balanceador de carga que atua como um gateway para a malha. No entanto, às vezes, faz sentido ter vários gateways. Nessas configurações, um gateway processa o tráfego que chega ao Google Cloud e um gateway separado de segundo nível processa o tráfego à medida que entra na malha de serviço.

Por exemplo, talvez você queira aplicar políticas de segurança do Google Cloud Armor ao tráfego que entra no Google Cloud e em políticas avançadas de gerenciamento de tráfego para o tráfego que está entrando na malha. O padrão de uso de um segundo gateway configurado pelo Traffic Director é discutido na seção Gerenciar o tráfego de entrada usando um gateway de segundo nível na borda da malha.

Na tabela a seguir, comparamos os recursos disponíveis, dependendo da opção de gateway selecionada:

Gateway Local do cliente Protocolos Políticas Back-ends / endpoints
Balanceador de carga de aplicativo interno

Clientes baseados no Google Cloud na mesma região do balanceador de carga

Clientes locais dos quais as solicitações chegam na mesma região do balanceador de carga (por exemplo, usando o Cloud VPN ou o Cloud Interconnect)

HTTP/1.1

HTTP/2

HTTPS

Gerenciamento de tráfego avançado

Terminação TLS usando certificados autogerenciados

Back-ends na mesma região do Google Cloud que o balanceador de carga, executando em:

  • Back-ends de instância de máquina virtual (VM) no Compute Engine
  • Instâncias de contêiner no Google Kubernetes Engine (GKE) e Kubernetes
Balanceador de carga de aplicativo externo Clientes na Internet pública

HTTP/1.1

HTTP/2

HTTPS

Gerenciamento de tráfego

Cloud CDN (incluindo back-ends de bucket do Cloud Storage)

Terminação TLS usando certificados gerenciados pelo Google ou autogerenciados

Políticas de SSL

Google Cloud Armor para prevenção contra ataques DDoS e da Web

Suporte ao Identity-Aware Proxy (IAP) para autenticação de usuários

Back-ends em qualquer região do Google Cloud, em execução em:

  • VMs no Compute Engine
  • Instâncias de contêiner no GKE e no Kubernetes
Balanceador de carga de rede de passagem interno

Clientes baseados no Google Cloud em qualquer região. Isso exige acesso global se os clientes estiverem em uma região diferente do balanceador de carga.

Clientes locais dos quais as solicitações chegam em qualquer região do Google Cloud. Por exemplo, usando o Cloud VPN ou o Cloud Interconnect.

 TCP Back-ends na mesma região do Google Cloud que o balanceador de carga, executados em VMs no Compute Engine.
Balanceador de carga de rede de passagem externo Clientes na Internet pública TCP ou UDP Back-ends na mesma região do Google Cloud que o balanceador de carga, executados em VMs no Compute Engine.
Balanceador de carga de rede de proxy externo Clientes na Internet pública SSL ou TCP

Terminação TLS usando certificados gerenciados pelo Google ou autogerenciados (somente proxy SSL)

Políticas de SSL (somente proxy SSL)

Back-ends em qualquer região do Google Cloud, em execução em:

  • VMs no Compute Engine
  • Instâncias de contêiner no GKE e no Kubernetes
Proxy de borda
(em instâncias de VM ou contêiner) configurado pelo Traffic Director		 Os clientes devem estar em um local onde uma das seguintes condições se aplica:
  • Podem enviar uma solicitação para um balanceador de carga gerenciado pelo Google Cloud, que depois envia a solicitação ao proxy de borda. Para detalhes, consulte Gerenciar o tráfego de entrada usando um gateway de segundo nível na borda da malha.
  • Podem enviar uma solicitação por um proxy. Por exemplo, um proxy sidecar que o Traffic Director configura.
  • Podem enviar uma solicitação diretamente para o endereço IP e a porta de uma instância de VM ou contêiner que esteja executando o proxy de borda.

HTTP/1.1

HTTP/2

 Gerenciamento de tráfego avançado (incluindo suporte de regex)

Back-ends em qualquer região do Google Cloud, em execução em:

  • VMs no Compute Engine
  • Instâncias de contêiner no GKE e no Kubernetes

Para uma comparação detalhada de recursos, consulte a página Recursos do balanceador de carga. Para uma visão geral detalhada dos recursos do Traffic Director, consulte a página Recursos do Traffic Director.

Implantar e configurar gateways

A consideração final na seleção do gateway é a experiência e a ferramenta do desenvolvedor que você quer usar. O Google Cloud oferece várias abordagens para criar e gerenciar o gateway.

CLI do Google Cloud e APIs do Compute Engine

Para configurar os produtos de balanceamento de carga gerenciados do Google Cloud e o Traffic Director, use as APIs do Google Cloud CLI e do Compute Engine. A CLI gcloud e as APIs fornecem mecanismos para implantar e configurar os recursos do Google Cloud imediatamente. Para automatizar tarefas repetitivas, é possível criar scripts.

Console do Google Cloud

Para configurar o Traffic Director e os balanceadores de carga gerenciados do Google Cloud, use o Console do Google Cloud.

Para configurar um padrão de gateway, você provavelmente precisará da página Traffic Director e da página Balanceamento de carga.

GKE e entrada de vários clusters

Os controladores de rede do GKE e do GKE Enterprise também oferecem suporte à implantação do Cloud Load Balancing para integração integrada com redes de contêineres. Eles oferecem uma interface declarativa no estilo do Kubernetes para implantação e configuração de gateways. Os controladores GKE Ingress e Ingress de vários clusters gerenciam os balanceadores de carga internos e externos para enviar tráfego a um único cluster ou entre vários clusters do GKE. O recurso Ingress também pode ser configurado para apontar para os serviços configurados pelo Traffic Director implantados em clusters do GKE.

Padrões de arquitetura de gateway

Nesta seção, descrevemos padrões de alto nível e fornecemos diagramas de arquitetura para seu gateway.

O padrão mais comum envolve o uso de um balanceador de carga gerenciado pelo Google Cloud como seu gateway:

  1. Os clientes enviam tráfego para um balanceador de carga gerenciado pelo Google Cloud que atua como o gateway.

    • O gateway aplica políticas.

  2. O gateway envia o tráfego para um serviço na sua malha.

Um padrão mais avançado envolve gateways em dois níveis. Os gateways funcionam da seguinte maneira:

  1. Os clientes enviam tráfego para um balanceador de carga gerenciado pelo Google Cloud que atua como o gateway de primeiro nível.

    • O gateway aplica políticas.

  2. O gateway envia o tráfego a um proxy de borda (ou pool de proxies de borda) configurado pelo Traffic Director. Esse proxy de borda atua como um gateway de segundo nível. Esse nível realiza as seguintes tarefas:

    • Fornece uma separação clara das funções quando, por exemplo, uma equipe é responsável pelo tráfego que entra no Google Cloud, enquanto outra equipe é responsável pelo tráfego de entrada que entra na malha dessa equipe.

    • Permite que você aplique políticas que talvez não sejam compatíveis no balanceador de carga gerenciado pelo Google Cloud.

  3. O gateway de segundo nível envia o tráfego para um serviço na sua malha.

O padrão de entrada termina quando o tráfego chega a um serviço em malha. O caso comum e os padrões avançados estão descritos nas seções a seguir.

Ativar tráfego de entrada pela Internet

Se os clientes estiverem fora do Google Cloud e precisarem alcançar o Google Cloud pela Internet pública, use um dos seguintes balanceadores de carga como o gateway:

Tráfego de entrada de clientes na Internet pública para serviços de malha usando um balanceador de carga.
Tráfego de entrada de clientes na Internet pública para serviços em malha usando um balanceador de carga (clique para ampliar)

Nesse padrão, o balanceador de carga gerenciado pelo Google Cloud serve como gateway. O gateway lida com o tráfego de entrada antes de encaminhá-lo para um serviço na malha.

Por exemplo, é possível escolher um balanceador de carga de aplicativo externo como seu gateway para usar o seguinte:

  • um endereço IP roteável Anycast global disponível para uso público, que minimiza a latência e os custos de sobrecarga da rede;
  • o Google Cloud Armor e encerramento de TLS para proteger o tráfego na malha;
  • o Cloud CDN para exibir conteúdo da Web e de vídeo;
  • recursos de gerenciamento de tráfego, como roteamento baseado em host e em caminho.

Para mais informações sobre como escolher um gateway que se adeque ao seu uso, consulte a seção Escolher um gateway para a malha.

Ativar o tráfego de entrada de clientes na VPC e em redes locais conectadas

Se os clientes estiverem dentro da rede VPC ou se estiverem no local e conseguirem acessar os serviços do Google Cloud usando um método de conectividade particular (como Cloud VPN ou Cloud Interconnect), é possível usar um dos seguintes balanceadores de carga como o gateway:

Tráfego de entrada de clientes em uma rede VPC para serviços na malha usando um balanceador de carga.
Tráfego de entrada de clientes em uma rede VPC para serviços em malha usando um balanceador de carga (clique para ampliar)

Nesse padrão, o balanceador de carga gerenciado pelo Google Cloud serve como gateway. O gateway lida com o tráfego de entrada antes de encaminhá-lo para um serviço na malha.

Por exemplo, é possível escolher "Balanceador de carga de aplicativo interno" como gateway para usar estes recursos:

  • Um endereço IP endereçável particular
  • Encerramento de TLS para proteger sua malha
  • Recursos de gerenciamento de tráfego avançados, como divisão de tráfego com base no peso
  • NEGs como back-ends

Para mais informações sobre como escolher um gateway que se adeque ao seu uso, consulte a seção Escolher um gateway para a malha.

Processar tráfego de entrada usando um gateway de segundo nível na borda da malha

Dependendo das suas necessidades, considere um padrão mais avançado que adiciona outro gateway.

Tráfego de entrada de clientes externos para serviços na malha usando um balanceador de carga e um proxy de borda.
Tráfego de entrada de clientes externos para serviços em malha usando um balanceador de carga e um proxy de borda (clique para ampliar)

Esse gateway é um proxy de borda (ou pool de proxies) configurado pelo Traffic Director. Ele está atrás do balanceador de carga gerenciado pelo Google Cloud. É possível hospedar esse gateway de segundo nível no projeto usando um pool de VMs do Compute Engine (um grupo de instâncias gerenciadas) ou serviços do GKE.

Embora esse padrão seja mais avançado, ele oferece outros benefícios:

  • O balanceador de carga gerenciado pelo Google Cloud aplica um conjunto inicial de políticas. Por exemplo, a proteção do Google Cloud Armor, se você estiver usando um balanceador de carga de aplicativo externo.

  • O proxy de borda configurado pelo Traffic Director aplica um segundo conjunto de políticas que podem não estar disponíveis no balanceador de carga gerenciado pelo Google Cloud. Essas políticas incluem o gerenciamento de tráfego avançado que usa expressões regulares aplicadas a cabeçalhos HTTP e divisão de tráfego baseada em peso.

Esse padrão pode ser configurado para refletir sua estrutura organizacional. Exemplo:

  1. Uma equipe pode ser responsável por manipular o tráfego de entrada para o Google Cloud, enquanto outra equipe é responsável por processar o tráfego de entrada para a malha.

  2. Se várias equipes oferecem serviços em uma VPC compartilhada, e cada uma tem o próprio projeto de serviço, as equipes podem usar esse padrão para gerenciar e aplicar políticas nas próprias malhas. Cada equipe pode expor um gateway configurado pelo Traffic Director que pode ser acessado em um único endereço IP e par de portas. Em seguida, uma equipe pode definir e gerenciar de maneira independente as políticas aplicadas no tráfego de entrada para a malha da equipe.

Esse padrão pode ser implementado usando qualquer balanceador de carga gerenciado pelo Google Cloud, desde que o balanceador de carga envie tráfego para os back-ends que hospedam os gateways configurados pelo Traffic Director.

Usar as APIs de roteamento de serviço para o tráfego de entrada

As APIs de roteamento de serviço fornecem o recurso Gateway para configurar o gerenciamento de tráfego e a segurança dos proxies do Envoy que atuam como gateways de entrada. Isso permite que clientes externos se conectem à malha de serviço (norte-sul). Veja mais informações na visão geral do roteamento de serviços e em Configurar um gateway de entrada.

A seguir