O ALB Ingress baseia-se no service Application Load Balancer (ALB) da Alibaba Cloud. Ele oferece um ponto de entrada unificado para os serviços em um cluster. Diferentemente do Nginx Ingress, o ALB Ingress é um service totalmente gerenciado, o que elimina a necessidade de manutenção manual. O recurso detecta automaticamente alterações nos recursos de Ingress em um cluster Kubernetes e distribui o tráfego para os serviços de backend com base em regras predefinidas. Além disso, o ALB Ingress possui um mecanismo robusto de dimensionamento elástico e se adapta automaticamente a mudanças dinâmicas de tráfego para garantir a estabilidade operacional do sistema.
Antes de começar
Para compreender melhor os recursos do ALB Ingress, leia este documento antes de utilizar a solução.
Antes de prosseguir, consulte a documentação oficial do Kubernetes sobre Ingress para entender os conceitos fundamentais de Ingress e Ingress Class.
Como funciona o ALB Ingress
O ALB Ingress envolve os seguintes conceitos básicos:
ALB Ingress Controller: Este componente gerencia os recursos de Ingress. Ele recupera dinamicamente as alterações nos recursos de Ingress e AlbConfig diretamente do API Server do cluster e atualiza as instâncias do ALB conforme necessário. Ao contrário do NGINX Ingress Controller, o ALB Ingress Controller atua como plano de controle para as instâncias do ALB. Ele gerencia essas instâncias, mas não processa o tráfego do usuário diretamente; as próprias instâncias do ALB encaminham o tráfego. O ALB Ingress Controller obtém dinamicamente as mudanças nos recursos de Ingress a partir do API Server do cluster e atualiza as instâncias do ALB com base nas regras de encaminhamento definidas no Ingress.
AlbConfig: Trata-se de uma Custom Resource Definition (CRD) no nível do cluster, criada pelo ALB Ingress Controller. Cada AlbConfig contém parâmetros que definem a configuração de uma única instância do ALB. Essa instância funciona como ponto de entrada de tráfego e encaminha requisições para os serviços de backend. O Application Load Balancer (ALB) gerencia totalmente esse componente. Diferentemente do Nginx Ingress Controller, o ALB Ingress não exige operações e manutenção (O&M) e oferece maior elasticidade.
IngressClass: Define a associação entre um Ingress e um AlbConfig.
Ingress: No Kubernetes, o Ingress é um objeto de recurso que estabelece regras de roteamento e acesso para tráfego externo. O ALB Ingress Controller monitora alterações nesses recursos e atualiza as instâncias do ALB para encaminhar o tráfego.
Service: Como os pods no Kubernetes são recursos temporários e dinâmicos, o Service fornece um ponto de entrada estável e unificado para pods com a mesma funcionalidade. Outras aplicações ou serviços podem se comunicar com os pods de backend ao acessar o endereço IP virtual (VIP) e a porta do Service, sem precisar rastrear possíveis alterações nos pods. Para mais informações sobre Service, consulte Service Management.
A modificação manual das configurações de instâncias do ALB pelo console de balanceamento de carga pode resultar na sobrescrita dessas alterações pelo mecanismo de sincronização automática do ALB Ingress. Isso pode causar perda de configuração ou até mesmo indisponibilidade da instância. Não modifique diretamente pelo console de balanceamento de carga as configurações de instâncias do ALB gerenciadas pelo ACK sem seguir as orientações oficiais.
Consulte o diagrama abaixo para entender a relação lógica entre as instâncias do ALB e o ALB Ingress:
Fluxo de uso do ALB Ingress
Para concluir o processo acima, consulte Create and Use ALB Ingress to Expose Services.
Quando usar ALB Ingresses em vez de NGINX Ingresses
A Alibaba Cloud gerencia os ALB Ingresses. Cada instância do ALB suporta até um milhão de QPS, dezenas de milhões de conexões simultâneas, dimensionamento automático e 99,995% de disponibilidade do service. Já os NGINX Ingresses são autogerenciados e exigem dimensionamento manual. Para uma comparação detalhada, consulte Comparison between an NGINX Ingress and an ALB Ingress.
Os ALB Ingresses são mais adequados nos seguintes cenários:
Conexões persistentes
Aplicações que exigem interação frequente, como IoT, finanças digitais e jogos online, dependem de conexões persistentes. Os ALB Ingresses aplicam alterações de configuração por meio de recarga a quente (hot reloading), sem interromper essas conexões. Por outro lado, os NGINX Ingresses precisam recarregar processos quando há mudanças na configuração, o que fecha temporariamente as conexões persistentes.
Alta concorrência
Serviços de IoT mantêm um grande volume de conexões simultâneas a partir de dispositivos terminais. Os ALB Ingresses executam na plataforma Cloud Network Management e gerenciam sessões em larga escala. Cada instância do ALB suporta dezenas de milhões de conexões.
Alto QPS
Atividades promocionais e eventos de grande repercussão demandam alta capacidade de QPS. Os ALB Ingresses realizam dimensionamento automático e adicionam endereços IP virtuais conforme o QPS aumenta. Cada instância do ALB suporta até um milhão de QPS.
Flutuações de carga de trabalho
Serviços de e-commerce e jogos sofrem grandes flutuações na carga de trabalho. O ALB oferece faturamento no modelo pagamento conforme o uso, baseado em unidades de capacidade do balanceador de carga (LCUs). Menos LCUs são consumidas fora dos horários de pico, e o ALB realiza o dimensionamento automaticamente, sem necessidade de reserva manual de recursos.
Redundância geográfica e de zona
Para aplicações que exigem alta disponibilidade, como redes sociais e streaming de mídia, utilize o Distributed Cloud Container Platform for Kubernetes (ACK One) para criar ALB multi-cluster gateways e manage multi-cluster traffic with ALB Ingresses, implementando redundância geográfica ativa e redundância de zona ativa.
Regiões e zonas do ALB Ingress
Para verificar as regiões e zonas compatíveis com o ALB Ingress, consulte ALB Supported Regions and Zones.
Recomendações para ALB Ingress em clusters de grande porte
O ALB Ingress impulsiona alterações de configuração por meio da OpenAPI da Alibaba Cloud. Em cenários com clusters grandes, muitas instâncias do ALB e inúmeras regras de Ingress, operações como atualizações de regras de encaminhamento e sincronização de grupos de servidores de backend podem sofrer atrasos durante execuções em lote (como criação ou exclusão em massa de Ingress, rolling upgrades de pods em larga escala ou atualizações frequentes de Endpoint). O tempo de efetivação da configuração depende do tempo de resposta da OpenAPI do ALB. A quantidade de recursos configuráveis está sujeita aos limites de cota do ALB.
Caso seus requisitos de negócio demandem alterações em grande escala, conclua previamente uma avaliação de capacidade e testes de estresse. Planeje o ritmo das mudanças para evitar interrupções no service ou anomalias de acesso causadas por atrasos no processamento ou excesso de cotas.
Limites do ALB Ingress
Para consultar os limites de cota do ALB Ingress, consulte ALB Quota Calculation Method.
Ao utilizar o Flannel, o ALB Ingress encaminha requisições apenas para serviços do tipo NodePort e LoadBalancer. Serviços do tipo ClusterIP não são suportados.
Log de alterações do ALB Ingress Controller
Para acessar os logs de alterações de recursos do ALB Ingress, consulte ALB Ingress Controller.