Por qué Jiakaobaodian elige APISIX Ingress Controller

Con la prevalencia de Kubernetes (abreviado como K8s), tenemos más opciones además del controlador de entrada NGINX predeterminado oficial para elegir, y el Apache APISIX Ingress Controller también se ha convertido en una opción popular para muchas empresas. Cada vez más compañías están reemplazando gradualmente su controlador de entrada con APISIX Ingress Controller.

Antecedentes

Wuhan Mucang Technology Co., Ltd fue fundada en 2011, y sus principales productos son docenas de aplicaciones automotrices como Jiakaobaodian. Desde su establecimiento hace más de 10 años, la empresa ha seguido la tendencia tecnológica y comenzó a adoptar la nube nativa en 2019, y varios proyectos dentro de la empresa han migrado a Kubernetes.

Sin embargo, en ese momento, dado que K8s acababa de surgir, había pocas opciones de puertas de entrada de tráfico disponibles. Por lo tanto, utilizamos el controlador de entrada predeterminado, NGINX Ingress Controller, durante casi 4 años. No obstante, durante ese período, se hizo cada vez más evidente que NGINX Ingress Controller ya no podía satisfacer nuestras necesidades, lo que nos obligó a buscar una nueva opción. Después de comparar los controladores de entrada más populares, decidimos utilizar Apache APISIX como la puerta de entrada de la empresa.

El problema con NGINX Ingress Controller

Los servicios de la empresa utilizan los protocolos HTTP y TCP, y solo los ingenieros de operaciones y mantenimiento saben exactamente cómo configurar el proxy TCP a través de NGINX Ingress Controller. Sin embargo, el personal de operaciones y mantenimiento es limitado. Sería ideal si pudiéramos delegar algunas de las operaciones y configuraciones básicas de NGINX al equipo de desarrollo, para así ahorrar costos de operaciones y mantenimiento.

Además de eso, también nos encontramos con los siguientes problemas:

Algunos cambios de configuración requieren recarga;
El proxy TCP tiene un alto costo de uso y no cubre todos los escenarios de tráfico;
Las operaciones de enrutamiento o tráfico solo pueden definirse mediante annotations, y no podemos definir y reutilizar configuraciones de manera semántica;
La reescritura, el corte de circuito, la transferencia de solicitudes y otras operaciones se implementan mediante annotations;
Falta de una plataforma de gestión, y el personal de operaciones y mantenimiento necesita operar mediante YAML, lo que es propenso a errores;
Baja portabilidad;
No es favorable para la integración con plataformas de contenedores.

Por estas razones, decidimos reemplazar nuestro antiguo controlador de entrada por uno nuevo.

Por qué APISIX Ingress Controller

Investigamos Apache APISIX y otros controladores de entrada, comparándolos en términos de rendimiento, facilidad de uso, escalabilidad e integración con plataformas, y finalmente seleccionamos APISIX Ingress Controller como la puerta de entrada de tráfico de K8s por las siguientes razones:

Buena escalabilidad;
Soporte para recarga en caliente de configuraciones;
Alto rendimiento;
Muchos complementos;
Soporte para CRD para integración con la plataforma de contenedores desarrollada internamente.

Arquitectura general

Dicho esto, echemos un vistazo a la arquitectura completa de la puerta de entrada. En un escenario empresarial real, los usuarios primero redirigen el tráfico a través de SLB (Server Load Balancer), y cuando el tráfico ingresa a K8s, cada servicio se invoca a través del clúster de APISIX. También implementamos muchas funciones comunes (lanzamiento canario, control de flujo, corte de circuito de API, control de seguridad de tráfico, control de tráfico de solicitudes/respuestas, etc.) en el lado de la puerta de entrada para unificar la gestión de servicios, reducir la complejidad del negocio y ahorrar costos.

Diagrama de arquitectura

Método de implementación

Nuestro negocio se implementa en diferentes plataformas en la nube (Huawei Cloud, Tencent Cloud, Alibaba Cloud), y podemos llevar rápidamente nuestro negocio en línea a través de Helm Chart, que es compatible con APISIX Ingress Controller. Al usar APISIX Ingress Controller, si encontramos características que pueden mejorarse, también presentamos PRs para ayudar a la comunidad a actualizar e iterar las características. En el proceso de implementación real, personalizamos algunas configuraciones según las características de nuestro negocio, como:

Crear NameSpace a través de K8s, implementar APISIX y APISIX Ingress Controller en diferentes NameSpace, y segregar el tráfico según las líneas de productos y la importancia del servicio;
Optimizar los parámetros del kernel TCP de Linux en el initContainer de APISIX;
Como necesitamos segregar el tráfico en términos de líneas de productos y importancia del servicio, la información de ClassName de K8s debe configurarse.

Al aislar el tráfico por diferentes líneas de productos e importancia, se puede minimizar la pérdida causada por fallas de software.

Integración con plataformas de contenedores desarrolladas internamente usando CRD

APISIX Ingress Controller actualmente admite muchos recursos CRD, por lo que podemos usar recursos CRD para integrar APISIX Ingress Controller con nuestra propia plataforma de contenedores. Sin embargo, dado que APISIX no proporciona un cliente Java, necesitamos usar la herramienta de generación de código proporcionada por K8s para generar el Modelo y usar CustomObjectApi para gestionar el CRD. Los objetos ApisixRoute están asociados con aplicaciones de la plataforma de contenedores y estructurados con objetos principales, lo que permite que tanto el personal de operaciones como los gerentes de proyecto operen en la plataforma de contenedores.

Escenarios de aplicación

Autenticación

Antes de usar Apache APISIX, implementamos la autenticación basada en la puerta de entrada de Istio, y después de migrar a Apache APISIX, elegimos usar el complemento forward-auth, que mueve inteligentemente la lógica de autenticación y autorización a un servicio de autenticación externo. La solicitud del usuario se redirige al servicio de autenticación a través de la puerta de entrada, y cuando el servicio de autenticación responde con un estado no 20x, la solicitud original se bloquea y se reemplaza el resultado. De esta manera, es posible devolver un informe de error personalizado o redirigir al usuario a la página de autenticación si la autenticación falla.

Cuando un cliente envía una solicitud a una aplicación, primero es procesada por el complemento forward-auth de APISIX, y la solicitud se redirige a un servicio de autenticación externo a través de forward-auth, y el resultado finalmente se devuelve a la puerta de entrada de APISIX. Si la autenticación es exitosa, el cliente puede solicitar el servicio normalmente. Si la autenticación falla, se devuelve un código de error.

Control de flujo

Debido a las características del negocio de la empresa, hay cinco o seis meses de tráfico máximo cada año. Una vez que hay demasiadas solicitudes, necesitamos expandir manualmente la capacidad, pero debido a la acumulación de solicitudes, el servicio puede no iniciarse después de la expansión, lo que llevaría a un colapso en cascada de todo el enlace, por lo que necesitamos limitar el flujo y la velocidad del clúster.

Por lo tanto, usamos los complementos limit-conn, limit-req y limit-count de APISIX para limitar las solicitudes y prevenir colapsos en cascada. Es más fácil limitar el flujo y la velocidad modificando complementos, y debido al mecanismo de recarga en caliente de APISIX, no es necesario reiniciar los complementos al configurarlos, por lo que pueden entrar en vigor de inmediato. Al controlar el tráfico, también se pueden detener algunos ataques maliciosos y proteger la seguridad del sistema. También hemos implementado HPA (Horizontal Pod Autoscaler) en la plataforma K8s, que escala automáticamente hacia arriba y hacia abajo una vez que la cantidad de tráfico es demasiado grande o demasiado pequeña, con complementos de limitación de flujo y velocidad de APISIX para evitar colapsos masivos.

Observabilidad

En términos de observabilidad, actualmente monitoreamos el tráfico en toda la plataforma a través de SkyWalking. El complemento SkyWalking de APISIX permite una interfaz directa con la plataforma SkyWalking existente, y la interfaz de usuario de SkyWalking facilita la visualización de los nodos de enlace que están consumiendo rendimiento. Además, dado que los puntos de monitoreo están ubicados en el lado de la puerta de entrada, más cerca del usuario, es más fácil verificar los puntos que consumen tiempo.

Con el complemento kafka-logger, los registros de acceso y errores generados por APISIX pueden escribirse directamente en el clúster de Apache Kafka. Con esta ventaja, el clúster de APISIX puede escalar de manera horizontal y sin estado sin necesidad de formatear discos, rotar registros o realizar otras operaciones. Si los registros se almacenan localmente, necesitamos realizar operaciones adicionales y no podemos lograr una escalabilidad rápida. Al enviar los registros al clúster de Apache Kafka, también podemos analizar los registros en tiempo real y mejorar y optimizar el sistema basándonos en los resultados del análisis.

Conclusión

Dado que APISIX Ingress Controller acaba de lanzarse, aún no hay tantos escenarios de aplicación. Continuaremos profundizando en los escenarios de aplicación y aportando más ejemplos de uso a la comunidad.

Cada vez más equipos están utilizando Apache APISIX Ingress Controller en entornos de producción. Si también estás utilizando APISIX Ingress Controller, te animamos a compartir tus casos de uso en la comunidad.