¿Cómo utiliza Zoom APISIX Ingress en su pipeline de entrega continua?

Antecedentes

En los últimos años, muchos software de conferencias en línea conocidos han surgido con el desarrollo de reuniones en línea y el trabajo remoto. El típico, Zoom, se ha convertido en una herramienta de reunión popular para la oficina en casa, la enseñanza en línea y los escenarios sociales. Cuenta con 350 millones de participantes diarios en reuniones y casi 470,000 clientes empresariales de pago que utilizan la plataforma. Además, datos recientes muestran que la cantidad de minutos utilizados para facilitar reuniones ha alcanzado más de 3.3 billones por año.

Sin embargo, como otras empresas de SaaS e internet, Zoom ha enfrentado desafíos técnicos a medida que su negocio se expande rápidamente.

• Un número significativo de microservicios: Debido al rápido crecimiento del negocio y los equipos de Zoom, se deben entregar más de 100 servicios backend. Sin embargo, es difícil gestionar eficientemente una gran cantidad de microservicios.

• Diversos entornos de despliegue: Las empresas SaaS a menudo encuentran escenarios en los que los clientes deben desplegar en nubes dedicadas, nubes privadas y multi-nubes. Los servicios de negocio de Zoom están en todo el mundo, por lo que existen desafíos técnicos con una gran cantidad de entornos de nube híbrida.

• Infraestructura compleja: Las empresas de internet de mediano y gran tamaño generalmente tienen equipos de infraestructura dedicados responsables de puertas de enlace API, centros de configuración, gestión de claves, registros, alarmas de monitoreo, bases de datos, etc. Dado que los equipos de gestión de I+D de Zoom están distribuidos globalmente, es un gran desafío integrar estos middleware e infraestructura complejos en la canalización de entrega continua.

Los desafíos anteriores no son una relación aditiva simple, sino una relación multiplicativa. En otras palabras, la situación real es mucho más compleja. Sin embargo, las herramientas de código abierto que Zoom utilizaba anteriormente ya no pueden satisfacer los requisitos actuales de Zoom. Es por eso que una canalización de entrega continua confiable es tan importante.

A continuación se detallan las razones por las cuales Zoom no continuó eligiendo estas herramientas de código abierto anteriores.

Debido a las limitaciones de las herramientas de código abierto anteriores, Zoom finalmente investigó algunas soluciones principales para construir la canalización de entrega continua subyacente.

Después de algunas rondas de comparación y verificación, Zoom finalmente eligió APISIX Ingress Controller para respaldar su nueva canalización de entrega continua.

Apache APISIX Ingress Controller

¿Qué es Apache APISIX Ingress Controller?

Apache APISIX Ingress Controller es un controlador de entrada nativo de la nube que utiliza Apache APISIX como el plano de datos para transportar el tráfico y extiende la funcionalidad de Kubernetes utilizando CRD (CustomResourceDefinition). Es responsable de interactuar con el servidor API de Kubernetes, solicitar control de acceso basado en roles (RBAC), monitorear cambios, implementar la conversión de objetos dentro del controlador Ingress, comparar los cambios y luego sincronizarlos con Apache APISIX. Además, puede admitir recursos personalizados, incluyendo APISIX Route, APISIX Upstream y otros ingresos nativos de Kubernetes, para controlar el tráfico externo que accede a los servicios desplegados en Kubernetes.

A continuación se muestra el Diagrama de Tiempo de APISIX Ingress Controller.

¿Por qué Zoom elige APISIX Ingress Controller?

Según los antecedentes anteriores, surge la pregunta: ¿qué tipo de canalización de entrega continua quiere construir Zoom, y cómo adopta APISIX Ingress para establecer su canalización de entrega continua subyacente?

Zoom utilizaba anteriormente NGINX como puerta de enlace API. Sin embargo, con el rápido desarrollo del negocio y el aumento de los microservicios, las limitaciones de la solución actual de NGINX son cada vez más evidentes.

Diferentes equipos deben mantener NGINX por separado, y miles de líneas de archivos de configuración de NGINX hacen que el mantenimiento sea difícil. Además, NGINX no puede escalar rápidamente cuando se despliegan muchas líneas en el servidor en la nube. Sobre el modo de recarga de NGINX, puedes consultar este blog. Los negocios de Zoom comenzaron a evolucionar hacia Ingress Controller.

El equipo de Puerta de Enlace API investigó algunas soluciones de código abierto. Después de simular la migración y el análisis de la configuración real del negocio en NGINX y una gran cantidad de pruebas de rendimiento y comparación del ecosistema de plugins, Zoom finalmente eligió el proyecto APISIX Ingress Controller de la Apache Software Foundation, explorando una puerta de enlace Cloud-Native más avanzada.

Considerando sus escenarios de negocio, Zoom puso más énfasis en las siguientes dos partes, que pueden ser satisfechas por APISIX Ingress.

• Seguridad de los datos: Zoom toma en serio la privacidad del cliente y la seguridad del servicio; por lo tanto, la autenticación y verificación mTLS se utilizan ampliamente en salas de reuniones en línea y llamadas telefónicas. Sin embargo, muchas puertas de enlace API similares solo pueden proporcionar este servicio en su versión empresarial, mientras que APISIX Ingress ofrece una gran viabilidad y conveniencia para lograr este objetivo.

• Estabilidad del servicio: Los servicios backend de Zoom requieren despliegues Multi-AZ (Multi-Zonas de Disponibilidad) para alta disponibilidad en diferentes regiones. Generalmente, coloca negocios en otros DC. Si ocurre un error en el DC original, el tráfico del cliente debe transformarse a otro, en el cual APISIX Ingress puede cumplir con éxito el requisito.

Características de Apache APISIX Ingress Controller

Tomando Apache APISIX como su plano de datos para transportar el tráfico de negocio, Apache APISIX Ingress Controller hereda las siguientes ventajas de Apache APISIX.

• Alto rendimiento y estabilidad: Como una puerta de enlace API dinámica de alto rendimiento, Apache APISIX es resistente y estable en su rendimiento, siendo utilizado en muchos escenarios de tráfico a gran escala de empresas.

• Comunidad activa: Como un proyecto de puerta de enlace API de código abierto de primer nivel y más activo, Apache APISIX posee una comunidad activa y ha mantenido una excelente tasa de crecimiento desde el primer día.

• Ecosistema rico: Apache APISIX admite protocolos L7, incluyendo HTTP(S), HTTP2, Dubbo, el protocolo IoT MQTT, etc. Además, APISIX admite protocolos L4 como TCP/UDP. Además, Apache APISIX 3.0 admite completamente ARM64.

• Múltiples plugins: Hay casi 100 plugins lanzados por APISIX oficialmente que los usuarios pueden usar con un simple arrastrar. La recarga en caliente y la orquestación dinámica de plugins brindan a los usuarios una gran conveniencia.

Además, el APISIX Ingress Controller también tiene las siguientes ventajas únicas:

• Buena compatibilidad: APISIX Ingress Controller admite múltiples versiones de recursos de entrada y puede ser compatible con diferentes versiones de Kubernetes.

• Actualización dinámica: No es necesario recargar el servicio al modificar rutas, certificados y otras configuraciones, asegurando el funcionamiento fluido del negocio.

• Escalado flexible: Dado que el APISIX Ingress Controller adopta una estructura que separa el plano de control y el plano de datos, el clúster del plano de datos de Apache APISIX puede expandirse independientemente sin escalar el APISIX Ingress Controller.

• Amigable con las operaciones y el mantenimiento: Bajo la arquitectura actual, los usuarios pueden elegir desplegar el clúster del plano de datos APISIX en el clúster de Kubernetes o en el entorno de máquinas físicas de metal desnudo según la situación real. Además, debido a la separación arquitectónica del APISIX ingress, el APISIX en el plano de datos transporta el tráfico mientras que el APISIX ingress controller es el componente del plano de control. Por lo tanto, la falla del APISIX Ingress Controller no afectará el tráfico del negocio.

Después de completar la selección de la puerta de enlace, el equipo de Puerta de Enlace API enfrentó un nuevo desafío: ¿cómo migrar la configuración original de la puerta de enlace API de cientos de servicios a APISIX Ingress? El equipo de Infraestructura de Zoom estaba desarrollando la canalización de entrega continua, lo que puede reducir significativamente el costo de migración de la conversión de nginx.conf y otras configuraciones de Ingress a APISIX Ingress.

El proceso y las funciones de la construcción de la canalización de entrega continua

La canalización de entrega continua de Zoom

La canalización de entrega continua es un sistema de entrega de aplicaciones de extremo a extremo que implementa un único modelo para declarar todos los requisitos de entrega de aplicaciones y organizar y ejecutar todos los pasos de entrega continua en una línea.

Hay seis partes en la canalización de entrega continua:

1. Preparar: preparar recursos preestablecidos, incluyendo infraestructura, middleware, recursos de servicios en la nube, etc.;

2. Configurar: preparar los archivos de configuración y las claves requeridas por la aplicación;

3. Desplegar: usar K8s para el despliegue en escenarios nativos de la nube (incluyendo información sobre contenedores, imágenes de contenedores, parámetros, versiones e instancias);

4. Acceder: crear un Servicio de Kubernetes y configurar automáticamente las reglas de enrutamiento del Apache APISIX Ingress si el despliegue requiere acceso externo;

5. Observar: Realizar configuraciones relacionadas con la observabilidad, como monitoreo, alarmas, registro y análisis de seguimiento;

6. Escalar: Declarar las reglas de escalado dinámico de KEDA (Kubernetes Event-driven Autoscaling) a través de métricas de monitoreo.

Cómo adoptar APISIX Ingress en la canalización

Gestión de proyectos

Los gerentes de proyectos prestan más atención a las iteraciones de I+D y cómo gestionar mejor el progreso de lanzamiento iterativo y la eficiencia del personal en la línea de tiempo correspondiente a las iteraciones. Zoom utiliza internamente un flujo de trabajo GitOps para integrar la configuración de la Puerta de Enlace API en el modelo de entrega de aplicaciones. Bajo este modelo, la definición de las reglas de enrutamiento de APISIX se integra con "Desplegar" y otros enlaces, entregando el control de cambios a GitHub. Con la creación y fusión de ramas de GitHub, la canalización logra líneas de tiempo consistentes entre la aplicación y la configuración de la puerta de enlace, y el lanzamiento y la reversión.

# Fragmento de código de la canalización CD de Zoom en el repositorio Git
deploy:
  type: Deployment
  replicas: ~{ replicas, 2 }
  version: "latest"
  containers:
    - name: my-app
      image: "busybox"
      command: "echo 'Demo' && sleep 99d"
access:
  - protocol: https
    host: my-domain.my-org.com
    cert: my-tls-cert
    apisix:
      routes:
        http:
          - name: my-api
            authentication:
              # ......
            match:
              paths:
                - /my-api/*

De esta manera, se simplifica la gestión de lanzamientos en la gestión de flujos de trabajo dentro de GitHub y se resuelve el problema del desfase de tiempo entre los sistemas ascendentes y descendentes al coincidir cambios cuando se procesan múltiples iteraciones simultáneamente.

Desarrollo de aplicaciones

Los desarrolladores se centran principalmente en las capacidades de enrutamiento y autenticación de las API, que están fuertemente relacionadas con los servicios de negocio y deben ser completadas por los desarrolladores para lograr el efecto automático. Además, se centran en el desarrollo e implementación de funciones de negocio y el negocio de nivel superior, esperando construir una infraestructura lista para usar.

A partir de los códigos mencionados anteriormente, podemos ver que los desarrolladores solo necesitan definir Authentication y Match en esta canalización de entrega continua. No necesitan conocer la lógica subyacente:

• Primero, traducirlo a Kubernetes Deployment y Service.
• Luego, llamar a la API de la plataforma para verificar la corrección de la ruta.
• Finalmente, traducirlo a objetos ApisixRoute.

La integración de la configuración de APISIX y el flujo de trabajo de la canalización de entrega continua proporciona a los desarrolladores una forma más eficiente.

Gestión del entorno

Los requisitos complejos de gestión y control del entorno a menudo ocurren en escenarios toB, y se deben considerar problemas de entrega en algunos escenarios de nube privada, nube dedicada y nube híbrida.

Algunas configuraciones de APISIX ingress se implementaron para cumplir con el requisito de ocultar las diferencias ambientales. De esta manera, los administradores del sistema pueden controlar de manera integral las diferencias en algunos entornos heterogéneos. Todos los servicios desplegados en el entorno son efectivos, evitando la carga cognitiva y las operaciones de despliegue especiales causadas por las diferencias ambientales para los desarrolladores de aplicaciones y operaciones. Por ejemplo, Zoom puede usar configuraciones personalizadas para deshabilitar el seguimiento en algunos entornos, convertir objetos ApisixRoute en objetos Ingress nativos y Anotaciones de NGINX Ingress, y usar diferentes imágenes para extraer secretos.

Además, se requiere aislamiento multi-inquilino cuando múltiples líneas de negocio están utilizando el entorno APISIX. APISIX Ingress proporciona un selector de Anotaciones que permite que diferentes objetos ApisixRoute sean recogidos por diferentes instancias del APISIX Ingress Controller.

Gestión de infraestructura

El equipo de Puerta de Enlace API necesita controlar todas las instancias de APISIX, configurar políticas de seguridad de manera integral, implementar multi-zonas de disponibilidad, y así sucesivamente.

Cada plugin de la canalización proporciona elementos de configuración para los ingenieros de infraestructura. En el plugin ingress-apisix, hay una propiedad defaultPlugins.

Después de que el equipo de la puerta de enlace API configure la propiedad, la configuración tendrá efecto para todos los servicios, lo que es adecuado para una estrategia unificada de seguridad y control de riesgos.

Conclusión

APISIX Ingress Controller juega un papel importante en la canalización de entrega continua de Zoom, liberando la presión en la gestión de proyectos, el desarrollo de aplicaciones, la gestión del entorno y la gestión de middleware e infraestructura. El caso de Zoom es digno de aprender para otras empresas, y esperamos que APISIX Ingress Controller contribuya a la innovación de más empresas.

Además, Apache APISIX Ingress lanzó oficialmente V1.5 en agosto de 2022, que unifica la propuesta de todas las versiones de API de recursos y actualiza todas las versiones de API de CRD a V2. Al mismo tiempo, admite la mayoría de los recursos de la API de Gateway. Apache APISIX Ingress ha permitido que los recursos de Ingress utilicen plugins arbitrarios de APISIX al agregar una nueva Anotación “k8s.apisix.apache.org/plugin-config-name” a los recursos de Ingress. De esta manera, aumentará significativamente la facilidad de uso del APISIX Ingress Controller y reducirá el costo para que los usuarios migren de otros Controladores de Ingress a APISIX Ingress Controller.

Para más información, consulta Apache APISIX Ingress V1.5.