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.
Neste documento, gateway se refere a uma solução ou padrão para processar o tráfego destinado a um serviço na malha. O Gateway de entrada do Istio é uma implementação desse padrão. Neste documento, gateway é um termo genérico que se refere ao padrão geral, não à implementação do Istio.
Este documento se aplica às APIs do Cloud Service Mesh. Após as etapas de configuração preparatórias, consulte que contém instruções para implantar 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 Cloud Service Mesh 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:
- O Serviço A faz uma solicitação ao Serviço B por nome.
- Essa solicitação é interceptada e redirecionada para o proxy sidecar do serviço A.
- Em seguida, o proxy secundário envia a solicitação para um endpoint associado ao Serviço B.
No exemplo a seguir, o tráfego tem origem fora da malha de serviço e
não é transferido pelo plano de dados dela.
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 pela Cloud Service Mesh 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:
- Balanceador de carga de aplicativo interno
- Balanceador de carga de aplicativo externo
- Balanceador de carga de rede de passagem interno
- Balanceador de carga de rede de passagem externo
- Balanceador de carga de rede de proxy externo
Nesta seção, nos referimos aos gateways de primeiro e segundo nível. 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 Cloud Service Mesh é 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:
|
| 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:
|
| 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:
|
| Proxy de borda (em instâncias de VM ou contêiner) configurado pelo Cloud Service Mesh |
Os clientes precisam estar em um local onde uma das situações a seguir se aplica:
|
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:
|
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 Cloud Service Mesh, consulte a página Recursos do Cloud Service Mesh.
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 Cloud Service Mesh, 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 Cloud Service Mesh e os balanceadores de carga gerenciados do Google Cloud, use o Console do Google Cloud.
Para configurar o padrão de gateway, você provavelmente precisará da página Cloud Service Mesh 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 são compatíveis com a implantação do Cloud Load Balancing para integração integrada 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 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 serviços configurados pelo Cloud Service Mesh 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:
Os clientes enviam tráfego para um balanceador de carga gerenciado pelo Google Cloud que atua como o gateway.
- O gateway aplica políticas.
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:
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.
O gateway envia o tráfego para um proxy de borda (ou pool de proxies de borda) configurado pelo Cloud Service Mesh. 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 aplicar políticas que talvez não sejam compatíveis no balanceador de carga gerenciado pelo Google Cloud.
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:
- Balanceador de carga de aplicativo externo
- Balanceador de carga de rede de passagem externo
- Balanceador de carga de rede de proxy externo
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:
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.
Esse gateway é um proxy de borda (ou pool de proxies) configurado pela Cloud Service Mesh. 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 Cloud Service Mesh 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. Por exemplo:
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.
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 Cloud Service Mesh 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 pela Cloud Service Mesh.
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
- Para configurar um gateway de entrada, consulte Configuração do Cloud Service Mesh para um gateway de entrada.
- Para agrupar as VMs e contêineres que executam o código como endpoints dos serviços, consulte Descoberta de serviços do Cloud Service Mesh.
- Para usar o Cloud Service Mesh com a VPC compartilhada, consulte Configurar uma malha de serviços de vários clusters.
- Para saber mais sobre o Cloud Service Mesh, consulte a Visão geral do Cloud Service Mesh.