De Traefik a APISIX: La Exploración de Horizon Robotics en Ingress Controller

En la industria automotriz, la mayoría de las empresas están en transición hacia la conducción autónoma y las nuevas energías. Especialmente en el caso de la conducción autónoma, cada empresa ha invertido muchos recursos para completar el desarrollo y entrenamiento de modelos de conducción autónoma.

En este proceso, ¿cómo garantizar la estabilidad y eficiencia del negocio mientras el producto se itera rápidamente?

Este artículo examinará la plataforma de desarrollo de IA de Horizon Robotics como ejemplo para ver cómo la puerta de enlace API Apache APISIX y el Ingress Controller ayudaron al equipo de I+D de Horizon Robotics a resolver este punto crítico.

Comparación de Puertas de Enlace

Limitaciones de Traefik

Antes de usar APISIX Ingress Controller, el Ingress Controller utilizado por el sistema de negocio era Traefik 1.x, pero había varios problemas.

• Traefik 1.x configura las reglas de enrutamiento a través de Ingress, y algunos complementos deben configurarse agregando Annotation. De esta manera, solo se pueden agregar complementos para todas las reglas bajo el Ingress actual, y no se puede lograr una configuración más granular.
• Traefik 1.x no admite la configuración visual de reglas específicas y no permite ubicar directamente un servicio específico accediendo a la URL de solicitud a través de navegadores.
• El archivo de configuración predeterminado de Traefik (ConfigMap) tiene pocos atributos, y muchas configuraciones predeterminadas requieren consultar la documentación oficial. Además, algunos parámetros no coinciden con la configuración predeterminada de NGINX, lo que hace que el mantenimiento sea más complicado.

En respuesta a los problemas anteriores, el equipo técnico de Horizon Robotics decidió reemplazar el Ingress Controller. Al inicio del proceso de selección, el equipo consideró actualizar Traefik a la versión 2.0 para resolver los problemas mencionados, pero como también necesitábamos usar un nuevo CRD para la actualización y el costo de migración era alto, tuvimos que probar otras soluciones de Ingress Controller.

Ventajas de APISIX Ingress Controller

En la etapa inicial de selección, comparamos principalmente Apache APISIX, Kong y Envoy. Sin embargo, otras soluciones no cumplían completamente con las necesidades de los escenarios existentes en términos de funcionalidad o rendimiento, excepto APISIX Ingress. Por lo tanto, finalmente elegimos APISIX Ingress. Además de algunas características generales, nos interesaron especialmente los siguientes puntos.

• Complementos ricos: Los complementos son ecológicamente sólidos, y todos los complementos admitidos por APISIX pueden configurarse de manera declarativa usando apisix-ingress-controller. Además, los complementos pueden personalizarse para un solo backend bajo ApisixRoute.
• Configuración visual: Con APISIX Dashboard, puedes ver cada apisix route. Si el mismo dominio está configurado en múltiples namespaces o archivos YAML, puedes buscar el prefijo de la ruta junto con APISIX Dashboard para ubicar rápidamente conflictos.
• Verificación granular: APISIX Ingress Controller verifica los recursos declarados en el CRD que gestiona. Si se declara un servicio inexistente en el CRD, el mensaje de error se almacena en el event de ApisixRoute y el cambio no surte efecto, lo que reduce algunos problemas causados por el uso incorrecto.
• Funcionalidades ricas: APISIX admite actualización en caliente, complementos en caliente, reescritura de solicitudes de proxy, múltiples autenticaciones, desarrollo de complementos en varios lenguajes y muchas otras características. Consulta APISIX features para más detalles.
• Comunidad activa: En comparación con otras comunidades de soluciones de código abierto, APISIX tiene muchos mantenedores y contribuyentes activos en Slack, GitHub y la lista de correo.
• Alto rendimiento: Como se puede ver en el gráfico a continuación, el rendimiento de APISIX es aproximadamente un 120% superior al de Envoy en pruebas de presión, y cuanto más núcleos haya, mayor será la diferencia en QPS.

Arquitectura General

Como se puede ver en el diagrama de arquitectura a continuación, APISIX Ingress sirve como punto de entrada para todo el tráfico. Todo el tráfico accedido ingresa a los servicios upstream (servicios de negocio) a través de APISIX Ingress, ya sea desde herramientas de línea de comandos, Web, plataformas SaaS o OpenAPI. En cuanto a la autenticación, dado que la empresa tiene un servicio de autenticación dedicado, utiliza directamente el complemento forward-auth de APISIX para lograr la autenticación externa.

En la capa de la puerta de enlace, todo el tráfico ingresa a través del nombre de dominio, y el tráfico primero pasa por LVS, que lo reenvía al nodo APISIX en el backend. Luego, APISIX distribuye el tráfico al Pod correspondiente según las reglas de enrutamiento. En LVS, también cambiaron el puerto predeterminado de APISIX Ingress de 9180 a 80 para que LVS apunte directamente a APISIX Ingress, lo que facilita el reenvío del tráfico.

Escenarios

Después de comprender la arquitectura general, compartiremos algunos escenarios que nuestra empresa está implementando actualmente con APISIX Ingress.

Carga de Archivos de Gran Tamaño

El primer escenario es la carga de archivos grandes, que puede ser menos común en empresas generales, pero es más frecuente en empresas que realizan entrenamiento de modelos de IA. Este escenario se encuentra principalmente en el sistema de entrenamiento de modelos de Horizon Robotics, donde los datos recopilados por I+D se cargan en el sistema a través de la red, y el tamaño de los datos suele superar varios cientos de GB. Sin ajustar ningún parámetro de APISIX, se produce un OOM cuando la cantidad de datos cargados es demasiado grande.

Debido a que el valor predeterminado de client_body_buffer_size es 1MB, cuando el búfer se llena, los archivos temporales se escriben en el disco, lo que provoca un alto IO en el disco.

Si el directorio donde se escriben los archivos temporales se apunta a la memoria compartida (/dev/shm), esto nuevamente conduce a un alto uso de la caché de APISIX.

Después de un ajuste continuo, descubrimos que la razón era que APISIX no tenía habilitada la carga en flujo. Para este escenario, actualizamos la versión de APISIX de 2.11 a 2.13 y ajustamos los parámetros de APISIX. Primero, cambiamos el parámetro proxy_request_buffering a off desde APISIX ConfigMap para habilitar la carga en flujo. Segundo, extrajimos la configuración reutilizable del CRD ApisixPluginConfig proporcionado por APISIX Ingress Controller y configuramos dinámicamente el client_max_body_size para las rutas que necesitan este escenario como configuración a nivel de namespace.

Llamadas de Servicio en Entornos Multi-nube

Para las llamadas de servicio en entornos multi-nube, parte del tráfico de negocio llega primero al IDC local y luego pasa por APISIX Ingress para llegar al Pod. Algunos servicios en el Pod acceden a los servicios de AliCloud a través del nombre de dominio. Además, existen algunos escenarios donde el servicio invoca otros servicios, principalmente para entrenamiento multi-nube. Los usuarios tomarán el IDC como punto de entrada y seleccionarán el clúster para enviar la tarea al clúster de nube correspondiente.

Autenticación Externa con forward-auth

Cuando comenzamos a usar APISIX Ingress, APISIX no admitía el complemento forward-auth, por lo que definimos un complemento personalizado basado en apisix-go-plugin-runner. Sin embargo, esto creó una capa adicional de llamadas gRPC, lo que dificultó la depuración y la visibilidad de los registros. Dado que APISIX admitió el complemento forward-auth a principios de este año, reemplazamos el complemento personalizado con el oficial, lo que reduce una capa de llamadas gRPC y facilita el monitoreo.

Monitoreo de Aplicaciones

En el monitoreo de aplicaciones, habilitamos el complemento Prometheus de APISIX globalmente y realizamos algunos ajustes y optimizaciones para nuestro propio negocio, como agregar concurrencia en tiempo real, QPS, tasa de éxito de API en tiempo real de APISIX y ancho de banda en tiempo real de APISIX para un monitoreo más granular.

Resumen

Actualmente estamos utilizando Apache APISIX Ingress Controller como puerta de enlace de tráfico solo para algunas de nuestras líneas de negocio, y pondremos en marcha otros negocios para aportar escenarios de aplicación más ricos a la comunidad. Si también estás comparando soluciones de Ingress Controller, esperamos que este artículo te dé algunas ideas. Cada vez más usuarios están utilizando Apache APISIX Ingress en entornos de producción, y si también estás usando APISIX Ingress, comparte tus casos de uso en la comunidad.