Por que o APISIX Ingress Controller é melhor que o NGINX Ingress Controller?

Ingress expõe serviços no Kubernetes, onde o roteamento de tráfego é controlado por regras configuradas no recurso Ingress. Para satisfazer um Ingress, você também deve ter um controlador Ingress.

Neste artigo, compararemos dois controladores Ingress populares para fornecer aos leitores insights sobre a seleção de controladores Ingress.

• Ingress-NGINX é um controlador Ingress implementado pela comunidade Kubernetes e é amplamente utilizado na comunidade.
• APISIX Ingress controller utiliza o Apache APISIX, um projeto de código aberto sob a ASF (Apache Software Foundation), como seu plano de dados.

Ingress NGINX vs. APISIX Ingress

Comparação de Recursos

A tabela abaixo compara os recursos básicos do Ingress NGINX e do APISIX Ingress, incluindo protocolos, sondas/resiliências de upstream, estratégias de balanceador de carga, autenticação, integração com Kubernetes, etc. A tabela foi extraída de learnk8s.io.

Diferenças

Podemos ver na figura abaixo que há mais funções e recursos integrados no APISIX Ingress do que no Ingress NGINX, incluindo suporte a protocolos, verificações de saúde e disjuntores, autenticação, integração com Kubernetes, e assim por diante.

Descoberta de Serviço

Na arquitetura de microsserviços, a aplicação é dividida em muitos microsserviços. Sempre que um microsserviço falha, ou um serviço é escalado para cima ou para baixo, o chamador precisa ser notificado o mais rápido possível para evitar falhas de chamada. Portanto, o mecanismo de registro e descoberta de serviços é vital na arquitetura de microsserviços, geralmente mantido pelo registro de serviços.

Suporte a Protocolos

Embora ambos os Ingress suportem o protocolo HTTP/HTTPS, o APISIX suporta mais protocolos. Ele suporta TLS para criptografar o tráfego TCP. Também suporta MQTT, Dubbo, e kafka para proxy.

Sondas/Resiliência de Upstream

Verificações de Saúde

Quando um nó falha ou migra, é inevitável que o nó fique indisponível. Se um grande número de solicitações acessar esses nós indisponíveis, isso causará perda de tráfego e interrupção do negócio. Portanto, é necessário realizar verificações de saúde nos nós usando sondas e direcionar as solicitações para nós saudáveis, reduzindo assim a perda de tráfego.

A funcionalidade de verificação de saúde ainda não é suportada no Ingress NGINX, mas o APISIX Ingress fornece essa funcionalidade:

• Verificação ativa: Use sondas para garantir que os Pods no backend estejam saudáveis. Quando N sondas consecutivas enviadas a um nó falharem, o nó será marcado como não saudável. O balanceador de carga ignorará os nós não saudáveis para que eles não possam receber solicitações. Habilitar verificações de saúde ativas pode efetivamente desabilitar Pods não saudáveis para evitar perda de tráfego.
• Verificação passiva: A verificação de saúde passiva não precisa iniciar sondas adicionais. Cada solicitação enviada ao nó age como uma sonda. Se N solicitações consecutivas a um nó saudável falharem, o nó será marcado como não saudável. Como não pode sentir o status do nó com antecedência, pode haver uma certa quantidade de solicitações falhas. Essa situação é relativamente comum durante atualizações contínuas, e podemos usar degradações de serviço para evitar a quantidade de solicitações falhas.

Exemplo de APISIX Ingress configurando verificações de saúde para o serviço httpbin:

apiVersion: apisix.apache.org/v2
kind: ApisixUpstream
metadata:
  name: httpbin
spec:
  healthCheck:
    passive:
      unhealthy:
        httpCodes:
          - 500
        httpFailures: 3
    active:
      type: http
      httpPath: /healthz
      healthy:
        successes: 3
        interval: 2s
        httpCodes:
          - 200

Disjuntor

O gateway é um ponto de entrada para solicitações; ele inicia chamadas para o serviço de backend. Quando o tráfego atinge o pico e a carga é pesada, o serviço de backend pode falhar ao ser chamado devido a timeout ou exceção. Quando a falha ocorre, as solicitações não podem ser empilhadas no gateway. Ele precisa retornar rapidamente, o que requer uma interrupção no gateway.

Semelhante à funcionalidade de verificação de saúde, a funcionalidade de disjuntor de serviço não é suportada no Ingress NGINX. No APISIX Ingress, o plugin api-breaker ajuda a implementar isso.

Exemplo de configuração do disjuntor no APISIX Ingress:

apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
 name: httpbin-route
spec:
 http:
 - name: rule1
   match:
     hosts:
     - httpbin.org
     paths:
       - /status/*
   backends:
   - serviceName: httpbin
     servicePort: 80
   plugins:
   - name: api-breaker
     enable: true
     config:
       break_response_code: 502
       unhealthy:
         http_statuses:
         - 505
         failures: 2
       healthy:
         http_statuses:
         - 200
         successes: 2

Suporte a Mais Plugins e Métodos de Autenticação

O Ingress NGINX usa principalmente Annotations e ConfigMap para configuração, e os plugins suportados são relativamente limitados. Se você quiser usar JWT, HAMC ou outros métodos de autenticação, você deve integrá-los você mesmo.

O APISIX Ingress suporta 80+ plugins no APISIX nativamente, que suporta vários métodos de autenticação, como JWT, HAMC, wolf-rbac, etc. Esses plugins fornecem uma ampla variedade de funcionalidades que cobrem a maioria dos cenários de uso.

Exemplo de autenticação HMAC na rota APISIX:

apiVersion: apisix.apache.org/v2
kind: ApisixConsumer
metadata:
  name: hmac-value
spec:
  authParameter:
    hmacAuth:
      value:
        access_key: papa
        secret_key: fatpa
        algorithm: "hmac-sha256"
        clock_skew: 0
---

apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
 name: httpbin-route
spec:
 http:
 - name: rule1
   match:
     hosts:
     - httpbin.org
     paths:
       - /ip
   backends:
   - serviceName: httpbin
     servicePort: 80
   authentication:
     enable: true
     type: hmacAuth

Extensibilidade do Ingress NGINX e APISIX Ingress

Quando os recursos básicos do controlador Ingress não atendem às necessidades dos usuários empresariais, ele só pode ser personalizado por meio de extensão. A seguir, explicaremos como o Ingress NGINX e o APISIX Ingress estendem seus recursos.

Como o Ingress NGINX Estende Seus Recursos

O Ingress NGINX só pode ser estendido incorporando programas Lua.

Exemplo de desenvolvimento de plugin do Ingress NGINX:

1. Escreva o programa Lua example-plugin
2. Instale o plugin em /etc/nginx/lua/plugins/<seu nome de plugin> $\rightarrow$ /etc/nginx/lua/plugins/example-plugin no pod ingress-nginx
3. Habilite o example-plugin no ConfigMap e referencie este objeto ConfigMap ao instalar o Ingress NGINX

apiVersion: v1
kind: ConfigMap
metadata:
  name: ingress-nginx-controller
  namespace: ingress-nginx
data:
  plugins: "example-plugin"

Como o APISIX Ingress Estende Seus Recursos

O APISIX Ingress fornece uma variedade de métodos para estender recursos, e os usuários empresariais podem escolher livremente o método de acordo com suas próprias necessidades. O APISIX suporta:

• Desenvolvimento de plugins via Lua: simples e com quase nenhuma perda de desempenho
• Desenvolvimento via plugin-runner: linguagens de programação como JAVA/Python/Go são suportadas para desenvolvimento, para que os usuários possam personalizar seus plugins sem aprender novas linguagens
• Plugins via WASM: qualquer linguagem que suporte a construção de WASM pode ser usada para desenvolvimento de plugins

Além disso, você pode escrever diretamente código Lua através do plugin serverless para atender rapidamente às necessidades do negócio.

Por que o APISIX Ingress Suporta CustomResourceDefinition (CRD)?

Atualmente, o APISIX Ingress suporta três configurações declarativas: Ingress, CRD e Gateway API. Vamos comparar principalmente Ingress e CRD aqui. E explicaremos a API Gateway depois.

O Ingress é mais adequado para usuários empresariais que migram do Ingress NGINX devido ao seu baixo custo de migração. Suas deficiências também são evidentes, como capacidades semânticas fracas, falta de especificações padrão, etc. E o Ingress só pode ser estendido por meio de anotações, mas as anotações não podem suportar cenários complexos. Em comparação, o CRD tem as seguintes vantagens:

• Mais fácil de usar, pois está mais alinhado com a semântica de design do plano de dados
• Reutilização de configurações para reduzir redundância
• Melhoria na funcionalidade e extensibilidade
• O plano de dados do APISIX tem uma comunidade ativa, com atualizações e lançamentos rápidos, e o CRD pode suportar mais capacidades do plano de dados facilmente

Ponto de Dor do Ingress NGINX: Recarregamento a Quente Não Suportado

Problemas Causados pela Configuração Estática

O Ingress NGINX é implementado principalmente com base em arquivos de configuração do NGINX. Embora o NGINX e o Lua sejam usados para alcançar extensões de recursos, isso só resolve parcialmente o problema dos arquivos de configuração estáticos. Ele mostra insuficiências em suas capacidades de roteamento e recarregamento. Por exemplo, a configuração do NGINX deve ser recarregada ao adicionar ou modificar uma regra. Com cada vez mais regras de roteamento e certificados, a operação de carga levará mais tempo, de alguns segundos a mais de dez segundos. Cada recarregamento do NGINX redefine o estado do balanceamento de carga, impactando negativamente o tráfego online, causando interrupções curtas, aumentando a latência de resposta e reduzindo a qualidade do balanceamento de carga.

Situações que Disparam um Recarregamento do NGINX

• Criação de um novo recurso Ingress
• Adição de seção TLS a um Ingress existente
• Alteração de Annotations do Ingress pode afetar a configuração upstream (por exemplo, anotações de balanceamento de carga não precisam ser recarregadas)
• Adição ou exclusão de um caminho no Ingress
• Exclusão de recursos Ingress, Service ou Secret
• Atualização de Secret

As situações listadas acima cobrem a maioria dos cenários de uso do controlador Ingress. Em um ambiente de cluster com aplicativos sendo frequentemente implantados, operações (criação, atualização, exclusão, etc.) de recursos como Ingress e Secret serão continuamente disparadas. Isso resultará em um aumento acentuado no número de recarregamentos do NGINX, impactando significativamente o ambiente de produção.

A arquitetura do Ingress NGINX determina que ele deve gerar a configuração do NGINX primeiro e recarregar para concluir a atualização da configuração. O problema de recarregamento não pode ser resolvido sem ajustar a arquitetura. Para resolver esse problema, o APISIX Ingress não depende mais da configuração do NGINX em sua implementação de roteamento e mudou para uma arquitetura de memória pura. O roteamento dinâmico é realizado por meio de recarregamento a quente, e o NGINX não precisa mais ser reiniciado.

Gateway API

Vantagens da API Gateway do Kubernetes

A API Gateway do Kubernetes é mais funcional que o Ingress e foi projetada para evoluir a rede de serviços do Kubernetes por meio de uma interface expressiva, extensível e orientada a funções implementada por muitos fornecedores e com amplo suporte da indústria. A API Gateway tem as seguintes características:

• Orientada a funções: O Gateway é composto por recursos de API. Diferentes recursos de API representam diferentes funções para usar e configurar recursos de rede do Kubernetes

• Forte expressividade: A API Gateway suporta funcionalidades principais, incluindo correspondência baseada em cabeçalhos, ponderação de tráfego e outras capacidades que só eram possíveis no Ingress por meio de anotações personalizadas não padronizadas

• Extensível: A API Gateway permite que diferentes recursos sejam vinculados em várias camadas de API. Isso permite personalização granular dentro da estrutura da API

Status de Suporte da API Gateway

A API Gateway do Kubernetes é um padrão para estender a malha de serviços do Kubernetes. Seu recurso Gateway pode ser usado como uma API do Kubernetes para gerenciar o ciclo de vida do gateway, o que é muito poderoso. Muitos controladores Ingress suportam ativamente, incluindo Istio, Kong, Traefik, etc. Infelizmente, o Ingress NGXIN ainda não planeja suportar a API Gateway (Status de Implementação da API Gateway), enquanto o APISIX Ingress já suporta a maioria dos recursos da API Gateway: incluindo HTTPRoute, TCPRoute, TLSRoute, UDPRoute, etc.

Resumo

Após uma comparação detalhada do APISIX Ingress e do Ingress NGINX, podemos concluir que ambos os softwares de código aberto são excelentes e as funções essenciais dos dois são semelhantes. Na arquitetura de microsserviços, no entanto, o APISIX Ingress mostra mais vantagens no suporte à governança e descoberta de serviços, fornecendo verificações de saúde e disjuntores.

O Ingress NGINX é caracterizado por sua simplicidade e facilidade de uso, com algumas deficiências evidentes, como dificuldades na extensão de recursos. O APISIX Ingress, que chegou depois, resolveu o ponto de dor do recarregamento a quente do NGINX e forneceu melhor extensibilidade e funcionalidades. Por exemplo, o suporte à API Gateway e ao CRD enriquece as capacidades do controlador Ingress em termos de desenvolvimento de projetos.

Em resumo, se você deseja selecionar um controlador Ingress com recursos mais ricos e melhor extensibilidade, o APISIX Ingress é altamente recomendado. Se você é novo no controlador Ingress e não tem muitos requisitos funcionais, o Ingress NGINX também é uma boa escolha por sua simplicidade.