O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Arquitetura de referência de balanceamento de carga da camada 7

Esta arquitetura de referência fornece uma solução de balanceamento de carga da camada 7 gerenciada pelo cliente no Google Distributed Cloud (GDC) com isolamento físico. Ao implantar controladores de código aberto conhecidos, como o HAProxy Kubernetes Ingress ou o NGINX Gateway Fabric, em um cluster padrão do GDC, os clientes podem rotear o tráfego L7 para ambientes híbridos sem problemas. Essa arquitetura usa o término de TLS (Ingress / HTTPRoute) para rotear o tráfego com base na indicação de nome do servidor (SNI, na sigla em inglês) para pods conteinerizados integrados e aplicativos hospedados em máquinas virtuais externas.

Recursos e funcionalidades

Roteamento avançado da camada 7: oferece suporte ao roteamento com base em host, em caminho e ao gerenciamento de tráfego avançado, como correspondência com base em cabeçalho e ponderação de tráfego.
Gerenciamento centralizado de TLS: oferece gerenciamento e encerramento centralizados de TLS.
Suporte a ambientes híbridos: roteia o tráfego L7 de maneira integrada para pods conteinerizados integrados e aplicativos hospedados em máquinas virtuais externas.
Opções de controlador flexíveis: oferece uma escolha entre o moderno NGINX Gateway Fabric (usando a API Gateway) ou o bem estabelecido controlador de entrada HAProxy.
Prontidão para isolamento físico: integrado ao Harbor Registry para armazenar e disponibilizar imagens de proxy e de aplicativos em ambientes particulares e desconectados.
Divisão de tráfego complexa: permite estratégias avançadas de distribuição de tráfego para a entrega de aplicativos modernos.

Princípios de arquitetura

Padrão de balanceamento de carga de dois níveis: essa arquitetura combina o balanceador de carga L4 integrado do GDC (como ponto de entrada) com um gateway L7 gerenciado pelo cliente implantado no Kubernetes.
Separação orientada por papéis: segue um design que separa as responsabilidades entre provedores de infraestrutura, operadores de cluster e desenvolvedores por meio de recursos específicos (como GatewayClass, Gateway e HTTPRoute ou Ingress).
Transição para padrões modernos: a arquitetura prioriza a API Gateway para recursos de roteamento modernos, mantendo o suporte à API Ingress legada, em que a estabilidade para controladores específicos é necessária.
Flexibilidade gerenciada pelo cliente: ao implantar controladores autogerenciados, os clientes ganham controle sobre os recursos e a configuração de L7 que não são fornecidos nativamente pelo balanceador de L4 gerenciado pelo GDC.
Abstração do local da carga de trabalho: a arquitetura trata as cargas de trabalho em contêineres e baseadas em VM de maneira consistente por meio de abstrações do serviço do Kubernetes (padrão ou headless).

Arquitetura conceitual

Diagrama de arquitetura conceitual para balanceamento de carga da camada 7 no GDC com isolamento físico.

Arquitetura lógica

A arquitetura lógica consiste em vários componentes funcionais que trabalham em conjunto para rotear o tráfego externo para back-ends internos ou externos:

Ponto de entrada de Ingress/Gateway: um cliente inicia solicitações HTTPS que primeiro atingem o balanceador de carga L4 do GDC. Esse balanceador integrado serve como ponto de entrada e distribui o tráfego TCP/443 para o balanceador de carga L7.
Plano de controle: os controladores de entrada ou gateway (operadores HAProxy ou NGINX) monitoram recursos do Kubernetes, como Ingress, Gateway e HTTPRoute.
Plano de dados: com base nos recursos observados, os controladores atualizam dinamicamente os proxies subjacentes que realizam o roteamento de tráfego real com base em regras de roteamento de host baseadas em SNI e encerramento de TLS.
Serviços de back-end:
- Pods conteinerizados: gerenciados como implantações padrão e expostos com serviços regulares do Kubernetes.
- VMs externas: integradas ao cluster com um serviço headless do Kubernetes e um endpoint personalizado (ou EndpointSlice) que contém o IP direto da VM.
Gerenciamento de artefatos: todas as imagens dos proxies e aplicativos são disponibilizadas em um registro local do Harbor para garantir a funcionalidade em um ambiente com isolamento físico.

Conceitos e tecnologias principais

A arquitetura usa um padrão de balanceamento de carga de duas camadas, combinando o balanceador de carga L4 integrado do GDC com um gateway L7 gerenciado pelo cliente implantado no Kubernetes. Os principais componentes incluem:

Cliente: uma entidade que inicia solicitações HTTPS para interagir com os aplicativos.
Cluster padrão do GDC: o GDC oferece uma maneira integrada de criar clusters Vanilla do Kubernetes. Nesta solução, o cluster vai hospedar o LB L7 e os controladores, além das cargas de trabalho e do serviço sem cabeçalho para VMs externas.
Balanceador de carga L4 do GDC: o balanceador de carga L4 integrado que serve como ponto de entrada, distribuindo o tráfego TCP/443 diretamente para os pods do Kubernetes que executam os controladores de entrada ou gateway.
Controladores de entrada e gateway: operadores HAProxy ou NGINX em execução no cluster padrão. No caso do Nginx, eles monitoram os recursos da API Gateway (como Gateway e HTTPRoute) e atualizam dinamicamente os proxies subjacentes. No caso do HAProxy, eles monitoram os recursos Ingress e atualizam dinamicamente os proxies subjacentes.
- Controlador de entrada HAProxy: um controlador de entrada para o Kubernetes que usa o HAProxy como um proxy reverso e um balanceador de carga de camada 7, além de processar o término de TLS.
- Nginx Gateway Fabric: uma implementação da API Gateway que usa o NGINX como plano de dados.
Ingress e Gateway (com HTTPRoute): recursos padronizados do Kubernetes que definem a porta de detecção física (443) e as regras de roteamento de host baseadas em SNI com término de TLS.
Carga de trabalho em contêiner (pods): uma implantação padrão do Kubernetes exposta internamente usando um Service comum do Kubernetes.
Carga de trabalho baseada em VM (externa): uma carga de trabalho hospedada em uma VM externa na rede do projeto, exposta ao proxy com um Service do Kubernetes headless e um endpoint personalizado que contém o IP direto da VM.
Registro do Harbor: um Container Registry particular usado para armazenar e disponibilizar as imagens de proxy e de aplicativo no ambiente com isolamento físico.

APIs Entrada x Gateway

O cenário de rede do Kubernetes está em transição da API Ingress legada para a moderna API Gateway. Entender as diferenças entre as duas é fundamental para selecionar a arquitetura certa para suas cargas de trabalho.

API Ingress: historicamente, Entrada tem sido o padrão para gerenciar o acesso externo a serviços HTTP. Ele oferece roteamento com base em host e em caminho, mas o design é relativamente básico e não tem suporte integrado para gerenciamento de tráfego avançado (por exemplo, correspondência com base em cabeçalho ou ponderação de tráfego) sem depender de anotações específicas do fornecedor. É importante ressaltar que a API Ingress agora é considerada congelada em termos de recursos pela comunidade do Kubernetes (limitações do Ingress e evolução da rede do Kubernetes).
API Gateway: geralmente chamada de V2 do Entrada, a API Gateway é uma coleção de definições de recursos personalizados (CRDs) que fornecem um modelo mais robusto e extensível para redes de serviços. Ela foi projetada para ser orientada a papéis, separando as responsabilidades entre provedores de infraestrutura (GatewayClass), operadores de cluster (Gateway) e desenvolvedores (HTTPRoute/TLSRoute) (API Gateway no GKE). Essa separação permite um controle mais granular e um melhor suporte a vários locatários.

Nesta solução do GDC com isolamento físico, escolhemos propositalmente APIs diferentes para os dois controladores em destaque:

NGINX (API Gateway): para a implementação do NGINX, usamos o NGINX Gateway Fabric, que é uma implementação madura e integrada da API Gateway. Ao usar a API Gateway para NGINX, os clientes podem se beneficiar dos padrões modernos e dos recursos avançados de roteamento (como HTTPRoute) incorporados à API.
API Ingress (HAProxy): embora a API Gateway seja a direção estratégica, selecionamos a API Ingress para o HAProxy neste guia. Isso ocorre porque a integração da API Gateway do HAProxy não é considerada madura. Ao usar o controlador de entrada HAProxy, que é bem estabelecido, garantimos uma solução L7 estável e confiável para clientes que preferem o HAProxy, além de fornecer um caminho para recursos L7 modernos.

Pressuposições e restrições

Suposições

Prontidão da infraestrutura: a implantação pressupõe a disponibilidade de clusters padrão do GDC com isolamento físico 1.15.x.
Registro local: presume-se que um registro local do Harbor esteja configurado corretamente para armazenar e exibir imagens de proxy e de aplicativos no ambiente com isolamento físico.
Ponto de entrada nativo: presume-se que o tráfego atinja primeiro o balanceador de carga L4 integrado do GDC, que o distribui para os proxies L7.

Restrições

Solução gerenciada pelo cliente: não há um serviço L7 gerenciado e com SLA no GDC. Essa implementação é totalmente autogerenciada pelo cliente.
Somente clusters padrão: os clusters de usuário compartilhados estão fora do escopo devido aos altos privilégios necessários para a implantação do controlador de entrada e do gateway.
Maturidade da API: enquanto o NGINX usa a API Gateway moderna, o HAProxy é limitado à API Ingress porque a integração da API Gateway ainda não é considerada madura.
Manutenção com isolamento físico: todas as imagens de contêiner precisam ser promovidas e gerenciadas manualmente no registro local do Harbor.
Edições da comunidade: a arquitetura foi projetada para edições da comunidade de código aberto do Nginx e do HAProxy. As edições Enterprise podem funcionar, mas não foram testadas explicitamente.
Propriedade operacional: os clientes precisam gerenciar o próprio escalonamento, a alta disponibilidade e a aplicação de patches para os controladores de terceiros.
Limite de suporte: o suporte do Google abrange apenas a infraestrutura subjacente do GDC. Problemas com o software HAProxy ou NGINX são de responsabilidade do cliente ou do fornecedor.
Obsolescência da API: a API Ingress (usada para HAProxy) tem recursos congelados pela comunidade do Kubernetes, o que pode limitar as capacidades de roteamento futuras.

Licenciamento

Edições da comunidade: a arquitetura foi projetada para edições da comunidade de código aberto (normalmente Apache 2.0 ou similar), que são de uso sem custo financeiro, mas gerenciadas pelo cliente.
Aquisição empresarial: a aquisição e o gerenciamento de licenças comerciais, como NGINX Plus ou HAProxy Enterprise, são de responsabilidade exclusiva do cliente.

Arquitetura de referência de balanceamento de carga da camada 7 Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.