¿Por qué el APISIX Ingress Controller es mejor que el NGINX Ingress Controller?

Ingress expone servicios en Kubernetes, donde el enrutamiento del tráfico se controla mediante reglas configuradas en el recurso Ingress. Para satisfacer un Ingress, también debes tener un controlador Ingress.

En este artículo, compararemos dos controladores Ingress populares para brindar a los lectores información sobre cómo seleccionar controladores Ingress.

• Ingress-NGINX es un controlador Ingress implementado por la comunidad de Kubernetes y es ampliamente utilizado en la comunidad.
• APISIX Ingress controller utiliza Apache APISIX, un proyecto de código abierto bajo la ASF (Apache Software Foundation), como su plano de datos.

Ingress NGINX vs. APISIX Ingress

Comparación de características

La siguiente tabla compara las características básicas de Ingress NGINX y APISIX Ingress, incluyendo protocolos, sondeos/resiliencias de upstream, estrategias de balanceador de carga, autenticación, integración con Kubernetes, etc. La tabla está extraída de learnk8s.io.

Diferencias

Podemos ver en la siguiente figura que hay más funciones y características integradas en APISIX Ingress que en Ingress NGINX, incluyendo soporte de protocolos, chequeos de salud y cortocircuitos, autenticación, integración con Kubernetes, etc.

Descubrimiento de servicios

En la arquitectura de microservicios, la aplicación se divide en muchos microservicios. Cada vez que un microservicio falla o un servicio se escala hacia arriba o hacia abajo, el llamador debe ser notificado lo antes posible para evitar fallos en las llamadas. Por lo tanto, el mecanismo de registro y descubrimiento de servicios es vital en la arquitectura de microservicios, generalmente mantenido por el registro de servicios.

Soporte de protocolos

Aunque ambos Ingress admiten el protocolo HTTP/HTTPS, APISIX admite más protocolos. Soporta TLS para cifrar el tráfico TCP. También admite MQTT, Dubbo, y kafka para proxy.

Sondas/resiliencia de upstream

Chequeos de salud

Cuando un nodo falla o migra, es inevitable que el nodo no esté disponible. Si una gran cantidad de solicitudes acceden a estos nodos no disponibles, causará pérdida de tráfico e interrupción del negocio. Por lo tanto, es necesario realizar chequeos de salud en los nodos utilizando sondas y dirigir las solicitudes a nodos saludables, reduciendo así la pérdida de tráfico.

La funcionalidad de chequeo de salud aún no es compatible en Ingress NGINX, pero APISIX Ingress proporciona esta funcionalidad:

• Chequeo activo: Utiliza sondas para asegurar que los Pods en el backend estén saludables. Cuando N sondas consecutivas enviadas a un nodo fallan, el nodo se marcará como no saludable. El balanceador de carga ignorará los nodos no saludables para que no puedan recibir solicitudes. Habilitar los chequeos de salud activos puede deshabilitar efectivamente los Pods no saludables para evitar la pérdida de tráfico.
• Chequeo pasivo: El chequeo de salud pasivo no necesita iniciar sondas adicionales. Cada solicitud enviada al nodo actúa como una sonda. Si N solicitudes consecutivas a un nodo saludable fallan, el nodo se marcará como no saludable. Dado que no puede detectar el estado del nodo de antemano, puede haber una cierta cantidad de solicitudes fallidas. Esta situación es relativamente común durante las actualizaciones continuas, y podemos usar degradaciones de servicio para evitar la cantidad de solicitudes fallidas.

Ejemplo de APISIX Ingress configurando chequeos de salud para el servicio 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

Cortocircuito

El gateway es un punto de entrada para las solicitudes; inicia llamadas al servicio backend. Cuando hay picos de tráfico y la carga es pesada, el servicio backend puede fallar debido a tiempo de espera o excepción. Cuando ocurre el fallo, las solicitudes no pueden apilarse en el gateway. Necesita devolver rápidamente, lo que requiere un cortocircuito en el gateway.

Similar a la función de chequeo de salud, la función de cortocircuito de servicio no es compatible en Ingress NGINX. En APISIX Ingress, el plugin api-breaker ayuda a implementar esto.

Ejemplo de configuración del cortocircuito en 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

Soporte de más plugins y métodos de autenticación

Ingress NGINX utiliza principalmente Annotations y ConfigMap para la configuración, y los plugins admitidos son relativamente limitados. Si deseas usar JWT, HAMC u otros métodos de autenticación, debes integrarlos tú mismo.

APISIX Ingress admite 80+ plugins en APISIX de forma nativa, que admite múltiples métodos de autenticación como JWT, HAMC, wolf-rbac, etc. Estos plugins proporcionan una amplia variedad de funcionalidades que cubren la mayoría de los escenarios de uso.

Ejemplo de autenticación HMAC en la ruta de 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

Extensibilidad de Ingress NGINX y APISIX Ingress

Cuando las características básicas del controlador Ingress no pueden satisfacer las necesidades de los usuarios empresariales, solo se puede personalizar mediante extensión. A continuación, explicaremos cómo Ingress NGINX y APISIX Ingress extienden sus características.

Cómo Ingress NGINX extiende sus características

Ingress NGINX solo puede extenderse incrustando programas Lua.

Ejemplo de desarrollo de plugins para Ingress NGINX:

1. Escribe el programa Lua example-plugin
2. Instala el plugin en /etc/nginx/lua/plugins/<nombre de tu plugin> $\rightarrow$ /etc/nginx/lua/plugins/example-plugin en el pod de ingress-nginx
3. Habilita el example-plugin en ConfigMap y referencia este objeto ConfigMap al instalar Ingress NGINX

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

Cómo APISIX Ingress extiende sus características

APISIX Ingress proporciona una variedad de métodos para extender características, y los usuarios empresariales pueden elegir libremente el método según sus propias necesidades. APISIX admite:

• Desarrollo de plugins mediante Lua: simple y con casi ninguna pérdida de rendimiento
• Desarrollo mediante plugin-runner: se admiten lenguajes de programación como JAVA/Python/Go para el desarrollo, por lo que los usuarios pueden personalizar sus plugins sin aprender nuevos lenguajes
• Plugins mediante WASM: cualquier lenguaje que admita la construcción de WASM puede usarse para el desarrollo de plugins

Además, puedes escribir directamente código Lua a través del plugin serverless para satisfacer rápidamente las necesidades del negocio.

¿Por qué APISIX Ingress admite CustomResourceDefinition (CRD)?

Actualmente, APISIX Ingress admite tres configuraciones declarativas: Ingress, CRD y Gateway API. Aquí compararemos principalmente Ingress y CRD. Y explicaremos Gateway API después.

Ingress es más adecuado para usuarios empresariales que migran desde Ingress NGINX debido a su bajo costo de migración. Sus deficiencias también son evidentes, como capacidades semánticas débiles, falta de especificaciones estándar, etc. Y Ingress solo puede extenderse mediante anotaciones, pero las anotaciones no pueden admitir escenarios complejos. En comparación, CRD tiene las siguientes ventajas:

• Más fácil de usar ya que está más en línea con las semánticas de diseño del plano de datos
• Reutilización de configuraciones para reducir la redundancia
• Mejora de la funcionalidad y extensibilidad
• El plano de datos de APISIX tiene una comunidad activa, con actualizaciones y lanzamientos rápidos, y CRD puede admitir más capacidades del plano de datos fácilmente

Punto débil de Ingress NGINX: No admite recarga en caliente

Problemas causados por la configuración estática

Ingress NGINX se implementa principalmente basado en archivos de configuración de NGINX. Aunque se utilizan NGINX y Lua para lograr extensiones de características, solo resuelve parcialmente el problema de los archivos de configuración estáticos. Muestra insuficiencias en sus capacidades de enrutamiento y recarga. Por ejemplo, la configuración de NGINX debe recargarse cuando se agrega o modifica una regla. Con más y más reglas de enrutamiento y certificados, la operación de carga tomará más tiempo, desde unos segundos hasta más de diez segundos. Cada recarga de NGINX restablece el estado del balanceador de carga, impactando negativamente en el tráfico en línea, causando interrupciones breves, aumentando la latencia de respuesta y reduciendo la calidad del balanceo de carga.

Situaciones que desencadenan una recarga de NGINX

• Crear un nuevo recurso Ingress
• Agregar una sección TLS a un Ingress existente
• Cambiar las anotaciones de Ingress también puede afectar la configuración de upstream (por ejemplo, las anotaciones de balanceo de carga no necesitan recargarse)
• Agregar o eliminar una ruta en Ingress
• Eliminar recursos Ingress, Service o Secret
• Actualizar Secret

Las situaciones enumeradas anteriormente cubren la mayoría de los escenarios de uso del controlador Ingress. En un entorno de clúster con aplicaciones que se implementan con frecuencia, las operaciones (creación, actualización, eliminación, etc.) de recursos como Ingress y Secret se desencadenarán continuamente. Esto resultará en un aumento drástico en el número de recargas de NGINX, impactando significativamente el entorno de producción.

La arquitectura de Ingress NGINX determina que primero debe generar la configuración de NGINX y recargar para completar la actualización de la configuración. El problema de la recarga no se puede resolver sin ajustar la arquitectura. Para resolver este problema, APISIX Ingress ya no depende de la configuración de NGINX en su implementación de enrutamiento y cambió a una arquitectura de memoria pura. El enrutamiento dinámico se realiza mediante recarga en caliente, y NGINX ya no necesita reiniciarse.

Gateway API

Ventajas de Kubernetes Gateway API

Kubernetes Gateway API es más funcional que Ingress y está diseñado para evolucionar la red de servicios de Kubernetes a través de una interfaz expresiva, extensible y orientada a roles implementada por muchos proveedores y con amplio soporte de la industria. Gateway API tiene las siguientes características:

• Orientado a roles: Gateway está compuesto por recursos API. Diferentes recursos API representan diferentes roles para usar y configurar recursos de red de Kubernetes

• Fuerte expresividad: Gateway API admite funcionalidades principales, incluyendo coincidencia basada en encabezados, ponderación de tráfico y otras capacidades que solo eran posibles en Ingress mediante anotaciones personalizadas no estándar

• Extensible: Gateway API permite que diferentes recursos se vinculen en varias capas de API. Esto permite una personalización granular dentro de la estructura de la API

Estado de soporte de Gateway API

Kubernetes Gateway API es un estándar para extender la malla de servicios de Kubernetes. Su recurso Gateway puede usarse como una API de Kubernetes para gestionar el ciclo de vida del gateway, lo cual es muy poderoso. Muchos controladores Ingress lo admiten activamente, incluyendo Istio, Kong, Traefik, etc. Lamentablemente, Ingress NGXIN no planea admitir Gateway API todavía (Estado de implementación de Gateway API), mientras que APISIX Ingress ya admite la mayoría de las características de Gateway API: incluyendo HTTPRoute, TCPRoute, TLSRoute, UDPRoute, etc.

Resumen

Después de una comparación exhaustiva de APISIX Ingress e Ingress NGINX, podemos concluir que ambos softwares de código abierto son excelentes y las funciones esenciales de los dos son similares. En la arquitectura de microservicios, sin embargo, APISIX Ingress muestra más ventajas en el soporte de la gobernanza y descubrimiento de servicios al proporcionar chequeos de salud y cortocircuitos.

Ingress NGINX se caracteriza por su simplicidad y facilidad de uso, con algunas deficiencias evidentes, como dificultades en la extensión de características. APISIX Ingress, que llegó más tarde, resolvió el punto débil de la recarga en caliente de NGINX y proporcionó mejores extensiones y funcionalidades. Por ejemplo, admitir Gateway API y CRD enriquece las capacidades del controlador Ingress en términos de desarrollo de proyectos.

En resumen, si deseas seleccionar un controlador Ingress con características más ricas y mejores extensiones, APISIX Ingress es altamente recomendado. Si eres nuevo en el controlador Ingress y no tienes muchos requisitos funcionales, Ingress NGINX también es una buena opción por su simplicidad.