¿Por qué APISIX Ingress Controller es una mejor opción que Emissary-ingress?
Xin Rong
March 17, 2023
Información de fondo
Kubernetes Ingress es un objeto de API que se utiliza para definir reglas para enrutar el tráfico externo a servicios internos en un clúster. Un Ingress Controller se usa comúnmente para implementar la lógica del recurso Ingress y gestionar estas reglas de tráfico de manera centralizada.
En la práctica, los usuarios empresariales suelen necesitar funciones de gestión de tráfico como mTLS, reintentos, limitación de tasa y autenticación, las cuales no pueden ser cumplidas por la semántica del recurso Ingress. Por lo tanto, las implementaciones de Ingress Controller suelen extender funciones añadiendo CRDs adicionales. A continuación, se proporcionará una comparación detallada de las diferencias entre las implementaciones de APISIX Ingress Controller y Emissary-Ingress.
¿Qué es Apache APISIX Ingress Controller?
Apache APISIX Ingress Controller es un proyecto de código abierto bajo la ASF (Apache Software Foundation). Su plano de control configura y entrega recursos en Kubernetes, mientras que APISIX maneja el tráfico de negocio real. Para mejorar la seguridad, todo el proceso de despliegue utiliza una arquitectura completamente separada de plano de datos y plano de control, evitando efectivamente el riesgo de fuga de permisos del clúster de Kubernetes causado por ataques al plano de datos.
¿Qué es Emissary-Ingress?
Emissary-Ingress es un proyecto en incubación de la CNCF (Cloud Native Computing Foundation). Como plano de control del proxy Envoy, es responsable de analizar los recursos de Kubernetes, y todo el tráfico es procesado directamente por Envoy en el plano de datos. Al empaquetar el plano de control y el plano de datos en un solo contenedor, el conjunto es más fácil de acceder y desplegar.
La diferencia entre APISIX Ingress Controller y Emissary-Ingress
Además de soportar recursos Ingress, tanto APISIX Ingress Controller como Emissary-Ingress podrían soportar la configuración a través de CRDs y Gateway API para complementar las limitaciones de la semántica de Ingress.
Las siguientes secciones analizarán las diferencias y ventajas entre ambos desde las perspectivas de funcionalidades básicas, descubrimiento de servicios y escalabilidad.
Funcionalidades básicas
| Característica | APISIX Ingress | Emissary-ingress | |
| Protocolos | HTTP/HTTPS | ✓ | ✓ |
| gRPC | ✓ | ✓ | |
| TCP | ✓ | ✓ | |
| UDP | ✓ | ✕ | |
| Websockets | ✓ | ✓ | |
| Balance de carga | Round Robin | ✓ | ✓ |
| Ring Hash | ✓ | ✓ | |
| Least Connections | ✓ | ✓ | |
| Maglev | ✕ | ✓ | |
| Autenticación | External Auth | ✓ | ✓ |
| Basic | ✓ | ✓ | |
| JWT | ✓ | ✕ | |
| OAuth | ✓ | ✕ | |
| OpenID | ✓ | ✕ | |
| Gestión de tráfico | Circuit Breaker | ✓ | ✓ |
| Rate Limiting | ✓ | ✓ | |
| Canary | ✓ | ✓ | |
| Fault Injection | ✓ | ✕ | |
| Health Checks | ✓ | ✓ | |
Las funciones comunes de la puerta de enlace incluyen la gestión de tráfico, el balance de carga y la autenticación. Sin embargo, cabe destacar que Emissary-Ingress tiene un soporte relativamente limitado para la autenticación, que solo incluye capacidades de Basic Auth y External Auth.
Descubrimiento de servicios
En la arquitectura de microservicios, las aplicaciones suelen descomponerse en múltiples microservicios que trabajan juntos para cumplir una lógica de negocio específica. Dado que el número de instancias de microservicios cambia constantemente, se necesita un mecanismo para ayudar a los servicios a descubrirse y localizarse entre sí.
El descubrimiento de servicios se refiere a la forma en que los microservicios se localizan en la red al obtener información sobre el descubrimiento de servicios a través del nombre del servicio para determinar a qué instancia se enruta la solicitud.
Para los marcos de microservicios tradicionales, la selección de un registro a menudo se basa en requisitos comerciales específicos. Sin embargo, migrar un componente existente de registro y descubrimiento de servicios a un mecanismo de descubrimiento de servicios basado en DNS de Kubernetes puede implicar ciertos costos en términos de modificaciones.
Por otro lado, si la puerta de enlace soporta los componentes actuales de registro y descubrimiento de servicios, no es necesario realizar tales modificaciones, lo que puede resultar en un mejor soporte para los marcos de microservicios.
Aquí están las situaciones de soporte de los dos para los componentes de descubrimiento de servicios:
| Descubrimiento de servicios | Apache APISIX Ingress Controller | Emissary-Ingress |
|---|---|---|
| Kubernetes | ✓ | ✓ |
| DNS | ✓ | ✓ |
| Nacos | ✓ | ✕ |
| Eureka | ✓ | ✕ |
| Consul | ✓ | ✓ |
En cuanto al ecosistema de descubrimiento de servicios, APISIX Ingress Controller tiene un soporte más fuerte, y los usuarios pueden integrarlo fácilmente en su marco de microservicios existente a través del controlador Ingress.
Escalabilidad
Cuando la funcionalidad del controlador Kubernetes Ingress no cumple con requisitos específicos, los usuarios pueden extender su funcionalidad a través de desarrollo personalizado. Necesidades más personalizadas pueden ser satisfechas desarrollando plugins personalizados o modificando el código existente. Los controladores Ingress con una robusta escalabilidad pueden hacer que el desarrollo y la personalización de características sean más fáciles, proporcionando un mejor soporte y soluciones para escenarios específicos.
Emissary-Ingress
La extensibilidad de Emissary-Ingress es relativamente pobre, ya que no soporta la extensión a través del Envoy Filter personalizado. Dado que el plano de datos y el plano de control están integrados, requiere un desarrollo personalizado de todo el sistema. La complejidad del desarrollo personalizado para el plano de datos Envoy es alta y representa una carga significativa para los desarrolladores.
Además, si los usuarios necesitan un Emissary-Ingress más potente, deben actualizarlo al producto comercial de Ambassador, Edge Stack. Algunas características propietarias requieren pagos para obtener soporte.
APISIX Ingress Controller
El plano de datos de APISIX extiende principalmente su funcionalidad a través de plugins, que proporcionan más de 80 plugins listos para usar. APISIX Ingress Controller soporta todos los plugins proporcionados por APISIX, lo que podría satisfacer la mayoría de los casos de uso diarios.
Si se necesita personalización basada en escenarios comerciales específicos, APISIX ofrece múltiples opciones de extensión para que los usuarios elijan y combinen libremente según sus situaciones. Los métodos de extensión actualmente soportados son los siguientes:
- Desarrollar plugins usando el lenguaje Lua es relativamente simple y casi sin pérdida de rendimiento. Además, puedes usar el plugin serverless para escribir código Lua directamente, lo que puede satisfacer rápidamente los requisitos comerciales.
- Además del lenguaje Lua nativo, también puedes usar
Plugin RunneroWASMplugins para la extensión, que soportan el desarrollo de plugins personalizados en lenguajes de codificación como Java, Python y Go. Esto permite a los usuarios utilizar su lógica de negocio existente y seleccionar basándose en la pila tecnológica de su empresa o preferencias de desarrollo sin requerir un nuevo lenguaje.
APISIX Ingress Controller soporta completamente los métodos de extensión anteriores sin necesidad de desarrollos adicionales.
Rendimiento
Como componente proxy de tráfico de entrada de Kubernetes, gestiona todo el tráfico entrante de la plataforma y gestiona uniformemente varias reglas de tráfico, lo que impone mayores demandas en el rendimiento del proxy.
En este artículo, realizaremos pruebas de rendimiento en APISIX Ingress Controller (APISIX: 3.1.0) y Emissary-Ingress 3.4.0 en la misma instancia (4C 8G).
QPS
QPS (Consultas por segundo) representa el número de consultas que un servicio puede manejar por segundo. Cuanto mayor sea el número, mejor será el rendimiento.
- 5000 Ingress Resource QPS
Latencia
Latencia de respuesta: el tiempo que tarda el servidor en responder. Cuanto menor sea el retraso, mejor será el rendimiento.
El gráfico muestra que APISIX Ingress Controller mantiene un rendimiento consistente en diferentes escalas de recursos, demostrando un rendimiento bien equilibrado.
Por otro lado, Emissary-Ingress tiene un impacto significativo en QPS y latencia al manejar grandes escalas de recursos y diferentes coincidencias de enrutamiento, con un rendimiento que disminuye a medida que aumenta el número de recursos. Por lo tanto, a medida que el volumen de negocio crece en entornos de producción reales, el alto rendimiento de APISIX se vuelve más prominente.
Conclusión
Emissary-Ingress se caracteriza por su simplicidad y facilidad de integración, pero es más difícil para el desarrollo personalizado. Además, los requisitos adicionales de características dependen de los componentes relacionados de la plataforma para obtener soporte.
En comparación, APISIX Ingress Controller tiene ventajas en escalabilidad e integración de descubrimiento de servicios, con una fuerte extensibilidad y un desarrollo simple. Además, APISIX Ingress Controller tiene un rendimiento excepcional, particularmente en escenarios donde la escala del negocio continúa creciendo, mostrando ventajas significativas.