O Nginx Ingress e o APIG Ingress roteiam tráfego externo para clusters Kubernetes, mas diferem no modelo de gerenciamento, na arquitetura e na profundidade de recursos. O Nginx Ingress é autogerenciado com controle total de personalização, enquanto o APIG Ingress é totalmente gerenciado, com segurança integrada, descoberta avançada de service e sem sobrecarga operacional.
Quando escolha cada gateway
escolha o Nginx Ingress se:
O tráfego é moderado e o gateway não é um gargalo de recursos
Sua equipe consegue manter componentes autogerenciados: ajuste de réplicas, atualizações de plugins e recargas de certificados
É necessária personalização profunda por meio de scripts Lua
As anotações padrão do Kubernetes Ingress atendem aos seus requisitos de roteamento
Suas cargas de trabalho execute em clusters ACK gerenciados, clusters ACK Serverless ou clusters ACS
escolha o APIG Ingress se:
Tráfego intenso exige throughput consistente sem ajuste manual
É desejável um gateway totalmente gerenciado, sem sobrecarga operacional para dimensionamento ou upgrades
É necessário Web Application Firewall (WAF) integrado, autenticação JWT/OIDC ou circuit breaking sem integrações extras
Seus service de backend estão registrados no Nacos, Eureka ou em registros baseados em DNS (não apenas no Kubernetes)
Você gerencia tráfego norte-sul e leste-oeste em ambientes de cloud híbrida ou multi-datacenter
Você já execute o Nginx Ingress e deseja um caminho de migração — o APIG Ingress converte as anotações do Nginx Ingress automaticamente
Comparação de recursos
|
Dimensão |
Nginx Ingress |
APIG Ingress |
|
Posicionamento do product |
Gateway de camada 7 com roteamento avançado. Componente autogerenciado com controle total de personalização. |
Gateway unificado de tráfego, microservice e segurança. Múltiplos padrões de descoberta de service e estratégias de liberação grayscale: canary, testes A/B, blue-green e proporções de tráfego personalizadas. Profundamente integrado a containers; conecta-se diretamente aos IPs dos pods de backend. |
|
Arquitetura de service |
Nginx + extensões de plugins Lua. Contagem de réplicas e limites de recursos configurados manualmente. |
Istiod + Envoy. Cada usuário obtém uma instância dedicada. |
|
Desempenho |
Depende de ajuste manual. Scripts Lua aceitam hot updates para algumas alterações de configuração, mas o uso intenso de Lua degrada o throughput. |
A aceleração de hardware aumenta o throughput HTTPS em ~80%. Com ajustes no sistema operacional e ajustes internos, o desempenho é ~40% maior que o de gateways criados internamente. As transações por segundo (TPS) são ~90% maiores que as do Nginx Ingress open source com 30% a 40% de utilização de CPU. |
|
Roteamento básico |
Roteamento baseado em conteúdo; modificação de cabeçalhos HTTP, redirecionamentos, reescritas e limitação de taxa. |
Roteamento baseado em conteúdo; modificação de cabeçalhos HTTP, redirecionamentos, reescritas, limitação de taxa, CORS, timeout e retry. Balanceamento de carga padrão (round-robin, aleatório, menor número de conexões, hash consistente) além de prefetch, que aumenta gradualmente o tráfego para uma instância de backend em uma janela configurável. |
|
Operações |
Mantido pelo usuário. Dimensionamento com Horizontal Pod Autoscaler (HPA). Exige ajuste proativo de especificações. |
Totalmente gerenciado. Dimensionamento com HPA. Sem ajuste manual de especificações. |
|
Integração cloud-native |
Funciona com clusters ACK gerenciados, clusters ACK Serverless e clusters ACS. |
Funciona com clusters ACK gerenciados. Suporta a conversão transparente de anotações do Nginx Ingress. |
|
Casos de uso típicos |
Cenários que exigem gateways altamente personalizados. Implantações canary e blue-green para aplicações cloud-native. |
Tráfego norte-sul: a descoberta de service de backend suporta Nacos, Kubernetes, DNS e IPs fixos. Tráfego leste-oeste: comunicação interna entre clouds híbridas, múltiplos data centers e múltiplos domínios de service, com integração transparente a sistemas de service mesh. |
|
Protocolos suportados |
HTTP, HTTPS |
HTTP, HTTPS |
|
Transformação de protocolo |
Não suportado |
HTTP para Dubbo; HTTPS para Dubbo |
|
Suporte a Ingress |
Kubernetes Ingress padrão |
Kubernetes Ingress padrão. Converte anotações do Nginx Ingress automaticamente (Supported annotations for APIG Ingress). |
|
Alterações de configuração |
Alterações de certificados e plugins Lua exigem recarga do processo, interrompendo conexões persistentes. Outras alterações usam hot updates de Lua. |
Hot updates para todas as alterações de configuração, incluindo certificados e plugins Wasm. Usa o mecanismo List-Watch para propagação quase em tempo real. |
|
Administração de service |
Descoberta de service: Kubernetes. Liberação grayscale: implantações canary. Alta disponibilidade: limitação de taxa. |
Descoberta de service: Kubernetes, Nacos, Eureka, DNS e IPs fixos. Liberação grayscale: roteamento baseado em canary e tags. Alta disponibilidade: integração com o Application High Availability service (AHAS) para limitação de taxa, circuit breaking e degradação. Teste de service: mocking. |
|
Segurança |
HTTPS; listas de permissões e de bloqueios de IP. |
HTTPS (integrado ao SSL Certificate service); proteção WAF (integra-se ao Alibaba Cloud Web Application Firewall); listas de permissões e de bloqueios de IP; integra-se ao SSL Certificate service. |
|
Autenticação e autorização |
BasicAuth; OAuth |
BasicAuth; OAuth; JWT; OIDC; IDaaS; autenticação personalizada |
|
Extensibilidade |
Scripts Lua |
Plugins Wasm (suporte a múltiplas linguagens); plugins Lua |
|
Observabilidade |
Logs de acesso; Prometheus |
Logs de acesso (integra-se ao Simple Log service (SLS) e ao Application Real-Time Monitoring service (ARMS)); métricas (integra-se ao ARMS Prometheus); rastreamento (integra-se ao Tracing Analysis); alertas (integra-se ao ARMS Prometheus) |
|
Integração de ecossistema |
Nginx service Mesh |
Istio service Mesh |