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 de 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 a terminação TLS (Ingress / HTTPRoute) para rotear o tráfego com base na indicação do nome do servidor (SNI, na sigla em inglês) para pods e aplicativos conteinerizados integrados hospedados em máquinas virtuais externas.

Recursos e funcionalidades

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

Princípios arquitetônicos

Padrão de balanceamento de carga de duas camadas: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 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 quando a estabilidade de controladores específicos é necessária.
Flexibilidade gerenciada pelo cliente:ao implantar controladores autogerenciados, os clientes ganham controle sobre os recursos e a configuração da camada 7 que não são fornecidos nativamente pelo balanceador L4 gerenciado pelo GDC.
Abstração do local da carga de trabalho:a arquitetura trata cargas de trabalho conteinerizadas e baseadas em VM de maneira consistente por meio de abstrações de serviço do Kubernetes (padrão ou sem periféricos).

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 do 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 executam o roteamento de tráfego real com base em regras de roteamento de host baseadas em SNI e terminação 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 do Kubernetes sem periféricos 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 veiculadas de um Harbor Registry local para garantir a funcionalidade em um ambiente com isolamento físico.

Principais conceitos e tecnologias

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 o seguinte:

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. Nessa solução, o cluster vai hospedar o LB L7 e os controladores dele, além das cargas de trabalho e do serviço sem periféricos 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. Para o Nginx, eles monitoram os recursos da API Gateway (como Gateway e HTTPRoute) e atualizam dinamicamente os proxies subjacentes. Para o HAProxy, eles monitoram os recursos Ingress e atualizam dinamicamente os proxies subjacentes.
- Controlador de entrada HAProxy: um controlador de entrada para Kubernetes que usa o HAProxy como um proxy reverso e balanceador de carga da camada 7, também processando o término de TLS.
- Nginx Gateway Fabric: uma implementação da API Gateway usando o NGINX como plano de dados.
Entrada e gateway (com HTTPRoute) : recursos padronizados do Kubernetes que definem a porta de escuta física (443) e as regras de roteamento de host baseadas em SNI com terminação TLS.
Carga de trabalho conteinerizada (pods) : uma implantação padrão do Kubernetes exposta internamente usando um Service regular 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 sem periféricos e um endpoint personalizado que contém o IP direto da VM.
Harbor Registry:um registro de contêiner particular usado para armazenar e veicular as imagens de proxy e aplicativos no ambiente com isolamento físico.

APIs Entrada x Gateway

O cenário de rede do Kubernetes está fazendo a transição da API Ingress legada para a API Gateway moderna. Entender as diferenças entre elas é 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 fornece roteamento baseado em host e caminho, mas o design é relativamente básico e não tem suporte integrado para gerenciamento de tráfego avançado (por exemplo, correspondência baseada 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 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, na sigla em inglês) que fornecem um modelo mais robusto e extensível para redes de serviços. Ela foi projetada para ser orientada por 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 melhor suporte a multitenância.

Nessa solução com isolamento físico do GDC, escolhemos 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. O uso da API Gateway para NGINX permite que os clientes se beneficiem dos padrões modernos e dos recursos de roteamento avançados (como HTTPRoute) que são integrados à API.
HAProxy (API Ingress) : embora a API Gateway seja a direção estratégica, selecionamos a API Ingress para 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 bem estabelecido, garantimos uma solução L7 estável e confiável para clientes que preferem o HAProxy, ao mesmo tempo em que oferecemos um caminho para recursos L7 modernos.

Suposições e restrições

Suposições

Preparaçã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 Harbor Registry local esteja configurado corretamente para armazenar e veicular imagens de proxy e 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 distribui o tráfego para os proxies L7.

Restrições

Solução gerenciada pelo cliente:não há serviço L7 gerenciado e com SLA no GDC. Essa implementação é totalmente autogerenciada pelo cliente.
Somente clusters padrão:os clusters de usuários compartilhados estão fora do escopo devido aos privilégios altos necessários para a implantação do controlador de entrada e gateway.
Maturidade da API:embora o NGINX use a API Gateway moderna, o HAProxy é restrito à 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 escalonamento, a alta disponibilidade e a aplicação de patches dos controladores de terceiros.
Limite de suporte:o suporte do Google abrange apenas a infraestrutura do GDC subjacente. 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) está congelada pela comunidade do Kubernetes, o que pode limitar os recursos de roteamento futuros.

Licenciamento

Edições da comunidade:a arquitetura foi projetada para edições da comunidade de código aberto (normalmente Apache 2.0 ou semelhante), que são sem custo financeiro, mas gerenciadas pelo cliente.
Aquisição empresarial:a aquisição e o gerenciamento de licenças comerciais, como o NGINX Plus ou o 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.