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? Esta etapa, que pode ser direcionada usando um gateway, pode direcionar o tráfego de fora da sua malha para a malha por meio de um ponto de entrada.

Neste documento, descrevemos como usar o Cloud Load Balancing como um gateway para receber tráfego na malha.

Visão geral

Ao projetar a malha de serviço, pense no tráfego proveniente dessas origens:

  • Tráfego originado dentro da malha
  • Tráfego originado fora da 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. Mas 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 de sua malha, o Traffic Director configura seus proxies secundários. Esses proxies secundários formam o plano de dados de sua malha de serviço. Se o Serviço A quiser se comunicar com o Serviço B:

  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.
Tráfego interno da malha de serviço manipulado pelo plano de dados da malha de serviço (clique para ampliar)
O tráfego interno da malha de serviço é tratado pelo plano de dados da malha (clique para ampliar)

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

O tráfego externo para a malha de serviço não é tratado pelo plano de dados da malha de serviço (clique para ampliar)
O tráfego externo para a malha de serviço não é tratado pelo plano de dados da 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 envia solicitações de saída usando um proxy configurado pelo Traffic Director, ele não sabe quais pares de portas de endereço IP usar 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.

Os padrões de gateway descritos neste documento ajudam a resolver esse problema: como receber tráfego para sua malha?

Este documento oferece:

  • 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.

Considerações para o gateway

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

  • 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?

Como 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. Geralmente, isso é conseguido usando uma porta e um endereço IP roteáveis publicamente ou privados 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 por meio do gateway.

O Cloud Load Balancing fornece várias opções de balanceamento de carga que podem ser usadas como o gateway da sua malha. As principais perguntas a serem feitas ao escolher um balanceador de carga do Google Cloud para atuar como seu 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?

Na seção Como escolher um gateway para sua malha, fornecemos uma visão geral das opções do Cloud Load Balancing, dependendo da localização do cliente e do protocolo de comunicação.

Processamento do 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 lugar natural para aplicar políticas à medida que o tráfego entra na malha. As políticas incluem o seguinte:

  • Gerenciamento de tráfego (por exemplo, roteamento, redirecionamentos e transformação da solicitação)
  • Segurança (por exemplo, terminação TLS e proteção DDoS do Google Cloud Armor)
  • Armazenamento em cache do Cloud CDN

Na seção Como escolher um gateway para sua malha, destacamos as políticas que são 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 fazer essa configuração, 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 de 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 Como escolher um gateway para sua malha, descrevemos os back-ends para os quais um gateway pode enviar tráfego.

Como 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 primeiro e segundo nível. Eles são usados para descrever o uso de um ou dois gateways para lidar com o tráfego de entrada na sua 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 lida com o tráfego que chega ao Google Cloud e um gateway separado de segundo nível lida com 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 em Como implantar 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
Balanceamento de carga HTTP(S) interno Clientes com base no Google Cloud na mesma região que o balanceador de carga

Clientes locais com solicitações que chegam à mesma região do Google Cloud que o balanceador de carga (por exemplo, usando Cloud VPN ou Cloud Interconnect)
  • HTTP/1.1
  • HTTP/2
  • HTTPS
Gerenciamento avançado de tráfego
Encerramento de TLS usando certificados autogerenciados
Back-ends na mesma região do Google Cloud que o balanceador de carga, em execução em:

Back-ends de máquina virtual no Compute Engine

Instâncias de contêiner em:
  • Google Kubernetes Engine (GKE)
  • Kubernetes
Balanceamento de carga HTTP(S) 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 do IAP para autenticação do usuário
Back-ends em qualquer região do Google Cloud, em execução em:

Máquinas virtuais no Compute Engine

Instâncias de contêiner em:
  • Google Kubernetes Engine (GKE)
  • Kubernetes
Balanceamento de carga TCP/UDP interno Clientes baseados no Google Cloud em qualquer região; isso vai requer 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, em execução em:

Máquinas virtuais no Compute Engine
Balanceamento de carga de rede Clientes na Internet pública TCP ou UDP Back-ends na mesma região do Google Cloud que o balanceador de carga, em execução em:

Máquinas virtuais no Compute Engine
Balanceamento de carga de proxy SSL e de proxy TCP Clientes na Internet pública SSL ou TCP Encerramento 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:

Máquinas virtuais no Compute Engine

Instâncias de contêiner em:
  • Google Kubernetes Engine (GKE)
  • Kubernetes
Proxy de borda (em instâncias de VM ou contêiner) configurado pelo Traffic Director Os clientes precisam estar em um local onde uma das situações a seguir se aplica:
  • Eles 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 mais informações, consulte Como implantar um gateway de segundo nível na borda da sua malha neste documento.
  • Eles podem enviar uma solicitação por meio de um proxy, por exemplo, um proxy sidecar, configurado pelo Traffic Director.
  • 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 avançado de tráfego (incluindo suporte a regex) Back-ends em qualquer região do Google Cloud, em execução em:

Máquinas virtuais no Compute Engine

Instâncias de contêiner em:
  • Google Kubernetes Engine (GKE)
  • Kubernetes

Na página de recursos do balanceador de carga, você encontra uma comparação detalhada por recurso. As páginas de recursos do Traffic Director fornecem uma visão geral detalhada dos recursos dessa ferramenta.

Como 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.

Ferramenta de linha de comando gcloud e APIs do Compute Engine

É possível usar a ferramenta de linha de comando gcloud e as APIs do Compute Engine para configurar os produtos de balanceamento de carga gerenciados do Google Cloud e o Traffic Director. A CLI e as APIs fornecem mecanismos para implantar e configurar os recursos do Google Cloud imediatamente. É possível criar scripts para automatizar tarefas repetitivas.

Console do Google Cloud

Use o Console do Google Cloud, uma interface gráfica para configurar o Traffic Director e os balanceadores de carga gerenciados do Google Cloud. Para configurar seu padrão de gateway, você provavelmente precisará das interfaces de usuário do Cloud Load Balancing e do Traffic Director.

GKE e entrada de vários clusters

Os controladores de rede do GKE e do Anthos também são compatíveis com a implantação do Cloud Load Balancing para integração nativa com a rede 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 Anthos Ingress gerenciam as cargas internas e externas e os balanceadores de carga para enviar tráfego para 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.

Padrões

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 seu 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 seu gateway de primeiro nível.
    • O gateway aplica políticas.
  2. O gateway envia o tráfego para 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:
      1. Fornece uma separação clara das funções quando, por exemplo, uma equipe pode ser responsável pelo tráfego de entrada que entra no Google Cloud, enquanto outra equipe é responsável pelo tráfego de entrada que entra na malha dessa equipe.
      2. Permite que você aplique políticas que podem não ser 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. Veja o caso comum e os padrões avançados.

Como ativar o tráfego de entrada a partir da Internet

Se seus clientes estiverem fora do Google Cloud e precisarem acessar o Google Cloud por meio da Internet pública, use um dos balanceadores de carga a seguir como gateway.

Para mais informações para ajudar você a decidir sobre um gateway apropriado, consulte Como escolher um gateway para sua malha.

Tráfego de entrada de clientes na Internet pública para serviços em malha usando um balanceador de carga (clique para ampliar)
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, escolha Balanceamento de carga HTTP(S) como gateway para usar o seguinte:

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

Como ativar o tráfego de entrada de clientes na nuvem privada virtual e em redes locais conectadas

Se os clientes estiverem dentro da rede VPC ou se eles estiverem no local e puderem acessar os serviços do Google Cloud usando um método de conectividade particular (como o Cloud VPN ou o Cloud Interconnect), use um dos balanceadores de carga a seguir como gateway.

Para mais informações para ajudar você a decidir sobre um gateway apropriado, consulte Como escolher um gateway para sua malha.

Tráfego de entrada de clientes em uma rede VPC para serviços em malha usando um balanceador de carga (clique para ampliar)
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 Balanceamento de carga HTTP(S) interno como gateway para usar estes recursos:

  • Um endereço IP endereçável privado
  • 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

Processamento do tráfego de entrada usando um gateway de segundo nível na extremidade 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 em malha usando um balanceador de carga e um proxy de borda (clique para ampliar)
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 seu projeto usando um pool de VMs do Compute Engine (um MIG) 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, proteção do Google Cloud Armor, se você estiver usando balanceamento de carga HTTP(S).

  • 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 usando 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. Por 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.

Observe que esse padrão pode ser implementado usando qualquer balanceador de carga gerenciado pelo Google Cloud, desde que o balanceador de carga possa enviar tráfego para os back-ends que hospedam os gateways configurados pelo Traffic Director. Consulte Como escolher um gateway para sua malha para informações sobre os back-ends compatíveis com cada balanceador de carga. Para mais informações sobre como usar o Traffic Director com a VPC compartilhada, consulte Como configurar o Traffic Director com a VPC compartilhada em vários clusters do GKE.